vLLM turns MiniMax’s day-zero promise into GPU-specific serving code

The MiniMax-Inferact promise of day-zero vLLM support now has a technical artifact behind it. The vLLM team has published serving images, recipes and hardware-specific optimization details for MiniMax-M3.1-Flash across NVIDIA Blackwell, NVIDIA Rubin and AMD MI350-series GPUs.

This is more than a model-loader compatibility patch. MiniMax-M3.1-Flash combines an NVFP4 key-value cache, NVFP4 mixture-of-experts weights, block-sparse attention and a DSpark speculative-decoding model. vLLM’s release supplies different kernels and execution paths for those features on each accelerator family.

What changed

For NVIDIA Blackwell, vLLM uses a CUDA 13.4 instruction to dequantize NVFP4 data inside the sparse-attention kernels. The project reports up to 1.7× faster indexer decode and 1.3× faster sparse-attention decode. It also extended its MegaMoE work to NVFP4 and fused query/key/value projection, normalization, rotary embeddings and cache insertion, reporting roughly 19% lower median time to first token in one tensor-parallel configuration.

The Rubin path has separate SM107 kernels rather than inheriting the Blackwell implementation unchanged. On AMD MI355X, vLLM uses FlyDSL kernels, context parallelism and a single-launch “mono” decode path intended to reduce launch overhead. The project reports the mono kernel replacing roughly 1,170 launches per sparse MoE decoder layer and raising interactivity by 50%–65% on an agentic-coding trace.

The implementation also changes memory economics. According to vLLM, MiniMax-M3.1’s NVFP4 checkpoint is 250.1 GB, down from 451.5 GB for the earlier MXFP8 checkpoint, while its NVFP4 cache uses 43.75% fewer bytes per token than FP8. On four NVIDIA B300 GPUs with 256K-token sequences, the team says that raises fitted concurrency from 28 to 76 sequences.

Who should care

Inference-platform teams evaluating very-long-context agent workloads now have a concrete matrix to test: Blackwell, Rubin and MI350 deployments are supported, but through materially different kernels and communication strategies. That makes hardware selection inseparable from the serving configuration rather than a simple image swap.

The release also includes day-zero reinforcement-learning support using veRL, FSDP2 and LoRA against the NVFP4 checkpoint. That brings post-training and serving closer together, although the published measurements remain project-reported results rather than an independent comparison.

What to try

vLLM provides separate prebuilt NVIDIA and AMD images and points operators to model-specific recipes. Teams should reproduce the latency and throughput frontier with their own prompt lengths and concurrency, verify the required CUDA or ROCm stack, and note that the nightly Python package will follow after upstream review. The immediate value is not one headline benchmark; it is that the model release arrives with explicit, inspectable serving paths instead of an unsupported compatibility claim.