[Fix] Fix FlashInfer CUTLASS MoE for unquantized models and single-GPU, bump FlashInfer to 0.6.8

[askliar]

This is a future-looking PR

Summary

• Fix quant_scales type on unquantized path (flashinfer_cutlass_moe.py): Pass quant_scales=[] instead of None for the unquantized (bf16/fp16) MoE path. The C++ binding expects List[Tensor]; passing None causes a type error at runtime.

• Remove spurious use_ep guard (oracle/unquantized.py): The flashinfer_cutlass_available check was gated on use_ep=True, preventing the CUTLASS backend from being selected on single-GPU (EP=1) deployments. FlashInferExperts supports EP=1 natively (ep_size=1, ep_rank=0). The use_ep parameter is removed from select_unquantized_moe_backend entirely.

• Bump FlashInfer to 0.6.7 (Dockerfile, versions.json, requirements/cuda.txt): Update flashinfer-python and flashinfer-cubin from 0.6.6 to 0.6.7.

Test plan

• Verify FlashInfer CUTLASS MoE activates on single-GPU with VLLM_USE_FLASHINFER_MOE_FP16=1 (previously silently fell back to Triton)
• Verify unquantized MoE models (e.g. MTP draft model) run without type errors on the CUTLASS path
• Verify EP>1 deployments are unaffected
• Verify FlashInfer 0.6.7 builds and runs correctly in Docker

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[gemini-code-assist]

Code Review

This pull request updates the FlashInfer library version to 0.6.7 across the Dockerfile, versions.json, and CUDA requirements. It also refactors the unquantized MoE backend selection logic by removing the use_ep (Expert Parallelism) parameter from the select_unquantized_moe_backend function and its associated calls and conditions, simplifying the backend selection process. Additionally, quant_scales is now initialized as an empty list instead of None in flashinfer_cutlass_moe.py. A review comment points out that a logging condition in vllm/model_executor/layers/fused_moe/oracle/unquantized.py is too broad and could lead to a misleading log message, suggesting to use the flashinfer_cutlass_available variable for accuracy.

[gemini-code-assist]

The condition (not use_dp) is too broad and can lead to a misleading log message. The log suggests that "FlashInfer MoE is available for EP", but this elif block can be entered even when FlashInfer is not available (e.g., on unsupported hardware or if has_flashinfer_cutlass_fused_moe() is false).

To ensure the log message is accurate, the condition should check if the FlashInfer CUTLASS backend is actually available. The flashinfer_cutlass_available variable already encapsulates all the necessary checks (hardware support, not use_dp, etc.).

Using flashinfer_cutlass_available as the condition ensures that this log is only shown when the feature is truly available but not enabled via VLLM_USE_FLASHINFER_MOE_FP16.

Suggested change

	elif (not use_dp):
	elif flashinfer_cutlass_available:

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @askliar.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork