vLLM 为 MiniMax-M3.1-Flash 提供 Day-0 支持

MiniMax-M3.1-Flash 是 MiniMax-M3 系列的最新模型，在推理、编码、智能体和视觉任务上均有改进。它还针对推理效率进行了构建，采用原生 NVFP4 KV 缓存、NVFP4 量化的 MoE 权重，以及用于投机解码的 DSpark 草稿模型。

vLLM 在发布当天即支持 MiniMax-M3.1-Flash，覆盖 NVIDIA Blackwell GPU、配备专用 Rubin 内核的 NVIDIA Rubin GPU，以及 AMD MI350 系列 GPU，在智能体工作负载上表现出强劲性能。

TL;DR

• MiniMax 稀疏注意力（MSA），为索引器和注意力路径均配备 NVFP4 KV 缓存，外加 NVFP4 MoE 权重和 DSpark 草稿模型。
• Blackwell MSA 内核使用新的 CUDA 13.4 QMUL4 指令在内核内将 NVFP4 反量化为 FP8：索引器 QK 解码最高提速 1.7 倍，稀疏注意力解码提速 1.3 倍。
• NVFP4 MegaMoE，支持 MXFP8 共享专家融合和提前释放 TMEM：预填充阶段内核延迟降低 20%，预填充吞吐量提升 7%。
• 索引器解码上下文并行（DCP）：在 4× GB300 上、512K 上下文时，每个稀疏层的索引器最高提速 3.3 倍。
• QKV GEMM + norm + RoPE + KV-insert 融合：在 512+ tokens 时预填充提速 1.1–1.6 倍，TP4 下 P50 TTFT 约降低 19%。
• FlashInfer PrimiTS 后端用于 DSpark 草稿模型注意力：比 FlashAttention 4 快 1.3–2 倍，总前向时间降低 5%。
• Rubin（SM107）MSA 内核也已集成到 vLLM 中，性能达到业界领先水平。
• AMD MI350 系列：NVFP4 原生 MSA 内核、索引器解码上下文并行、双批次重叠和单内核带来全面2–3 倍的性能提升。
• 智能体服务：在 NVIDIA GB300 上，延迟敏感端最高每用户 418.9 tok/s；在 NVIDIA Rubin 上，最高每用户 724.9 tok/s，每 GPU 总计 191.5K tok/s；在 AMD MI355X 上，SemiAnalysis AgentX 基准测试中每美元 TCO 最高可处理1.333 亿总 tokens。
• Day-0 RL 支持：在 NVFP4 检查点上使用 veRL、FSDP2 和 LoRA 进行端到端 RL。

快速开始

两家厂商均提供预构建镜像：

• NVIDIA：vllm/vllm-openai:minimax-m31-flash
• AMD：vllm/vllm-openai-rocm:minimax-m31-flash

请注意，该模型只有在代码经过审查并合并到上游后才会出现在 nightly PyPI wheel 中，这通常需要约一周时间。完整配方见 vLLM Recipes，检查点见 MiniMaxAI/MiniMax-M3.1-Flash。

NVIDIA 上的 TP4

我们推荐使用 CUDA 13.4 工具包以获得最佳性能。

vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
  -tp 4 \
  --reasoning-parser minimax_m3 \
  --block-size 128 \
  --kv-cache-dtype nvfp4 \
  --attention-config '{"indexer_kv_dtype": "nvfp4"}' \
  --speculative-config '{"method":"dspark","num_speculative_tokens":7,"attention_backend":"FLASHINFER_TS","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
  --disable-hybrid-kv-cache-manager

AMD 上的 TP4

vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
  -tp 4 \
  --reasoning-parser minimax_m3 \
  --block-size 128 \
  --kv-cache-dtype nvfp4 \
  --attention-config '{"indexer_kv_dtype": "nvfp4", "indexer_decode_cp": true}' \
  --quantization-config.moe mxfp8 \
  --speculative-config '{"method":"dspark","num_speculative_tokens":3,"attention_backend":"TRITON_ATTN","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
  --disable-hybrid-kv-cache-manager

MSA 入门

MiniMax-M3 模型系列用块稀疏注意力的一种变体（arXiv 2606.13392）替代全注意力，以提高推理效率。KV 缓存被划分为 128 个 token 的块。一个轻量级索引器为每个 GQA 组使用一个索引查询，针对单个共享索引键头对上下文中的每个键打分，然后对这些分数进行最大池化，得到每个块一个分数。主注意力随后精确运行，但仅作用于前 16 个块，且最近的块始终保留。这样无论上下文多长，每个查询最多只涉及 2,048 个键。

收益在解码阶段最大，而解码阶段受内存带宽限制。每一步仍会扫描整个上下文的索引键，但每层每个 token 仅需 128 字节，是稠密注意力所读取的 1,024 字节 K/V 的八分之一（FP8，4 个 KV 头 × 128 维）。随后仅为选中的 2,048 个 token 读取完整的 K/V。在长上下文解码时，每步的 HBM 流量降至稠密注意力读取量的约 12.5%。

图 1：MiniMax 稀疏注意力。每个 GQA 组的索引器挑选其 top KV 块，该组中的每个查询头都恰好只关注这些块。逐步查看。

MiniMax-M3.1 架构的新特性

MiniMax-M3.1 相比上一代大幅提升了推理效率：它针对 NVFP4 KV 缓存进行了原生的量化感知训练，其路由 MoE 权重以 NVFP4 存储。NVFP4 专家将检查点从 451.5 GB（MiniMax-M3-MXFP8）缩小至 250.1 GB，减小了 44.6%。NVFP4 KV 缓存每个 token 需要 34,560 字节，而非 FP8 的 61,440 字节，每个 token 节省 43.75%。综合来看，在四块 NVIDIA B300 GPU 上采用 DEP4 部署和 256K token 序列时，M3.1 可容纳 76 个并发序列，而使用 FP8 KV 缓存的 M3 仅能容纳 28 个，在相同硬件上约为其 2.7 倍，这直接提升了服务吞吐量。

图 2：MiniMax-M3.1 经过量化感知训练，索引器和稀疏注意力均使用 NVFP4 KV 缓存。更改 KV 缓存数据类型、并行方式、GPU 或上下文长度，查看可容纳的序列数。

性能优化

vLLM 在多个硬件平台上为 MiniMax-M3.1 提供了强劲性能。在 NVIDIA GPU 上，我们提供了针对 NVFP4 KV 缓存优化的内核。我们的 MSA 仓库（vllm-project/MSA）包含针对不同工作负载和操作调优的内核。这些包括 MSA 索引器 prefill 和 decode、稀疏注意力 prefill 和 decode，以及一个 MSA 专用的 top-k 内核。

图 3：Blackwell 上解码时（M ≤ 32）的一个 MiniMax-M3.1 稀疏解码层，逐内核展示。编号徽章标记了本文中的优化项；点击其中一个可高亮其内核。

NVIDIA Blackwell 优化的 MSA 内核

KV 缓存以 NVFP4 存储，而查询保持 FP8，因此我们无法使用原生 NVFP4 张量核心指令进行矩阵乘法。相反，内核将 NVFP4 KV 缓存反量化为 FP8，并运行 FP8 MMA。为保持反量化成本低廉，我们使用了 CUDA 13.4 中引入的 Blackwell 专用 PTX 指令 mul.e4m3x4.e2m1x4.e4m3x4（SASS QMUL4）。它在一条指令中按比例因子缩放四个 NVFP4 值并生成四个 FP8 值。相比之前的 FP16 往返路径，这大大减少了 CUDA 核心指令数。结果是在索引器 QK 解码内核上最高提速 1.7 倍，在稀疏注意力解码内核上提速 1.3 倍。

NVFP4 MegaMoE

MegaMoE 是现代专家并行（EP）部署的关键构建模块。我们将 DeepGEMM 的 MegaMoE 扩展到 NVFP4 精度，并融合了 MXFP8 共享专家，在我们的分支（vllm-project/DeepGEMM）中开源。为 MegaMoE 添加 NVFP4 支持不仅仅是替换数据类型。相比之前的 FP8×FP4 路径，NVFP4 将每个元素的字节数减半，并将张量核心吞吐量翻倍。内核的其余部分也必须随之改变，否则流水线会失去平衡。

其中一项改动是在 FC1 尾声阶段提前释放 TMEM 阶段。此前，TMEM 阶段只有在尾声结束后才会被释放。这种等待是不必要的，因为尾声完全在寄存器中运行。只要累加器被加载到寄存器中，TMEM 就可以在任何算术运算发生之前被释放。在 prefill 中，这使内核总延迟降低了 20%，而更快的 NVFP4 计算在 prefill 中最为重要。它还将整体 prefill 吞吐量提高了 7%。

NVFP4 indexer DCP（解码上下文并行）

在低延迟服务中，每个 GPU 在完整上下文上为自己的 index head 打分。在四块 GPU 上，这意味着每个 indexer 层要读取完整 index 缓存四次。Indexer DCP 则改为按上下文拆分工作。每个 GPU 在四分之一页面上为全部四个 head 打分。然后，它通过 NVLink 将每个 head 的本地 top-16 发送给拥有该 head 的 GPU，由后者将候选合并为最终的 top-16。选择结果保持精确，并且在 4× NVIDIA GB300 GPU 上、512K 上下文时，indexer 每个稀疏层的运行速度最高提升 3.3×。

QKV GEMM + norm + RoPE + KV 插入融合

MiniMax-M3.1 的 QKV 和 indexer 投影过去会将完整的 QKV 张量写入 HBM。随后第二个内核再将其读回，用于 norm、RoPE 和 KV 缓存插入。我们将整条链路融合进单个 GEMM 内核，其尾声逐个 head 处理 FP32 累加器。它对 query 和 index query 应用 norm 和 RoPE。它还将 K、V 和 index key 量化为 NVFP4，并直接写入各自的缓存。QKV 张量从不接触 HBM。在 GB300 上，512 个或更多 token 的 prefill 批次运行速度提升 1.1–1.6×，并且在 TP4 下 P50 首 token 时间（TTFT）下降约 19%。

用于 DSpark drafter 的 FlashInfer PrimiTS

MiniMax-M3.1 使用 DSpark 作为其投机解码 drafter，它以 4096 token 的滑动窗口运行非因果 GQA。此前，vLLM 在 FlashAttention 4 上运行该 drafter，而后者并未针对解码形状进行优化。我们将其切换到 FlashInfer 的 PrimiTS 后端。PrimiTS 比 FlashAttention 4 快 1.3–2×，并将整体前向时间减少 5%。

NVIDIA GB300 上的 Agentic 工作负载基准测试

vLLM 在 agentic 服务负载上提供强劲性能。我们使用 SemiAnalysis AgentX 基准（详见我们之前的文章）在 NVIDIA GB300 上对我们的 day-0 镜像进行基准测试。在延迟敏感的前沿端，MiniMax-M3.1-Flash 保持每用户每秒 418.9 个 token。在前沿更靠后的位置，它在每 GPU 每秒服务 38.6K 总 token 的同时，让每个用户保持在每秒 200 个 token 以上。在吞吐端，它达到每 GPU 每秒 153.8K 个 token，约为最具交互性点的 24×，同时每个用户仍能看到约每秒 127 个 token。

图 4：NVIDIA GB300 上 MiniMax-M3.1-Flash 的 AgentX Pareto 前沿，使用 7 个投机 token 和 3.16–3.26 个 token 的合成接受长度（包括第一个 token）。将鼠标悬停在点上可查看其指标。

NVIDIA Rubin 优化的 MSA

我们还在 NVIDIA Rubin GPU 上优化了该模型。为缓解 NVFP4 到 FP8 的转换开销，我们将 NVFP4 直接转换为 FP16，并以 FP16 为 indexer 运行 score MMA。这使反量化指令减少约三分之一，并且分数变得精确，而不再带有为运行 FP8 MMA 而产生的 E4M3 重新舍入。

在查询数 ≤4 时，单头索引器解码内核更进一步：它利用 SM107 的打包 fma.rn.f32x2.f16x2，对每个 MMA 结果只应用一次块缩放，而不是对每个 K 值应用一次。这还通过每个 SM 运行三个 CTA 实现了更多延迟隐藏。Rubin 更大的共享内存（328 KB，Blackwell 为 228 KB）和额外的 Tensor Memory 列（576，Blackwell 为 512）使这成为可能。

最后，由于 Rubin 的 SM 数量多于 Blackwell，工作规划器根据 SM 数量来确定 tile 大小，因此工作均匀分布在 Rubin 的全部 212 个 SM 上。

预填充稀疏注意力也从局部域优化中受益。我们通过 CUDA 虚拟内存 API 分配部分缓冲区，使 2 MB 页面在两个域之间交替，组合内核将每个 tile 交给其 SM 位于持有该 tile 数据的域中的 CTA。在 Rubin 上，预填充与解码注意力内核使用每条指令 K=64 的密集 FP8 MMA，这将 MMA 指令数减半，并以 Blackwell FP8 速率的两倍运行。

NVIDIA Rubin 上的智能体工作负载基准测试

在 NVIDIA Rubin 上，MiniMax-M3.1-Flash 在同一基准测试中进一步推进了前沿。在延迟敏感端，它保持每用户每秒 724.9 个 token。沿前沿进一步，它在每 GPU 每秒服务 157.3K 总 token 的同时，保持每用户高于每秒 200 个 token。在吞吐端，它达到每 GPU 每秒 191.5K 个 token，同时每用户仍获得约每秒 134 个 token，在相同每用户速率下约为 GB300 的 1.5 倍。

图 5：MiniMax-M3.1-Flash 在 NVIDIA Rubin 上的 AgentX 帕累托前沿。将鼠标悬停在某个点上可查看其配置和指标。

AMD GPU 支持

在 AMD GPU 上，我们带来了 NVFP4 KV 缓存支持，因此 AMD 部署也可以使用低精度格式来减少 KV 缓存内存。对于解码，我们添加了索引器 DCP 以加速长上下文解码，以及一个加速低延迟推理的 mono 内核。对于预填充，序列并行和双批次重叠减少了引擎内部的通信，新的 KV 缓存布局使每个 KV 块能够以单次传输移动到解码节点。MSA 和 mono 内核使用 FlyDSL 构建，这是 AMD 用于 GPU 内核的 Python DSL，并得到了 FlyDSL 团队的帮助。

NVFP4 MSA 内核

MiniMax-M3.1 使用 NVFP4 KV 缓存（QAT）对主注意力和索引器进行训练，但 CDNA4 没有原生指令来反量化 NVFP4。为了保持 MSA 内核快速，我们将反量化转变为表查找。只有 256 种可能的 E4M3 缩放和八种 E2M1 幅值，因此我们将每个缩放值（已舍入为 FP8）预先计算到 LDS 中的 2 KB 表中。一次 v_perm_b32 字节置换加上一次符号位 XOR 即可将四个 FP4 值转换为 FP8。该内核还仅对最多 64 个共享它的请求反量化一次共享前缀页。这些共同使稀疏解码注意力比将选定块转换为 FP8 并运行 FP8 注意力内核快最多 2.5 倍。

NVFP4 索引器 DCP

我们在 AMD 上使用与 NVIDIA 相同的 indexer decode 上下文并行，而在 CDNA4 上它还带来了额外收益。没有 DCP 时，TP4 下每块 GPU 都要在完整上下文上为自己的 index head 打分，因此 index 缓存会被读取四次。这还会导致矩阵核心利用率不足。一个 DSpark-3 解码步骤每个请求只有 4 行 query，仅填满 16×16×128 FP8 MFMA 的 16 列中的 4 列。使用 DCP 后，每块 GPU 在四分之一上下文上为全部四个 head 打分，因此 4 个 head × 4 行填满了全部 16 列。单个 kernel 交换 index query、对其分块打分，并通过 Infinity Fabric 将每个 head 的分数直接写入所属 GPU 的内存。设备端握手确保这在 HIP graph 内正常工作。随后 owner 像之前一样选出 top 16，并且由于分数与单 GPU 版本逐位一致，选择结果完全精确。在 4× MI355X 上，对于 45 个 30K–210K token 的请求，indexer 在每个稀疏层上最高快 2.8×。

SP + DBO prefill 与单次读取 KV 传输

在 TP4 下，MI355X 上的长 prompt prefill 受限于通信，既包括节点内 GPU 之间的通信，也包括 prefill 节点与 decode 节点之间的通信。在引擎内部，双批次重叠（DBO）将张量并行集合通信隐藏在另一个 microbatche 的计算之后。序列并行（SP）则直接削减流量。每块 GPU 保留四分之一的 token，attention 输出以 MXFP8 进行 all-to-all 交换，使每块 GPU 在自己的 token 上运行完整的 o_proj，而 MoE 输出则进行 reduce-scatter。这将每 GPU 每 token 每层的流量从约 36 KB 降至 20 KB，并且 norm、量化和 router 仅在四分之一的 token 上运行。

更快的 prefill 引擎只有在 KV 缓存也能快速到达 decode 节点时才有帮助。vLLM 的逐层 KV 缓存布局将每个 KV 块拆分为 125 个小页，每页都需要自己的 NIXL RDMA 读取。我们改用 block-outer 布局，将每个块存储为一行连续的 1.82 MB，因此 NIXL 只需一次读取即可移动它。综合来看，引擎和 KV 传输的改动使 16K+ token 的 prefill 批次在 4× MI355X 上快 1.8–2.1×。

低延迟 mono kernel

在低并发下，AMD GPU 上的 decode 受限于启动开销：kernel 启动开销比数学计算耗时更长。Mono decode 通过将每个稀疏 MoE 解码层作为单次 FlyDSL kernel 启动来解决这个问题。这一次启动涵盖了从 QKV 投影和稀疏 attention 到张量并行 all-reduce 以及 MXFP4 MoE 的所有内容，取代了大约 1,170 次 kernel 启动。在 TP4 下的 MI350X 上，这使解码步骤最高快 2.3×，并在低并发下将 8K 输入/1K 输出吞吐量翻倍。在 agentic-coding 轨迹上，它将交互性提高了 50–65%。

AMD MI355X 上的 Agentic 工作负载基准测试

我们的 AMD 实现还提供了强劲的每成本性能。在 InferenceX AgentX 基准测试中，MiniMax-M3.1-Flash 在延迟敏感的前沿端保持每用户每秒 331.0 个 token。在前沿的更远处，它使每个用户保持在每秒 170 个 token 以上，同时每美元 TCO 交付 3460 万个总 token。在成本高效端，它达到每美元 1.333 亿个 token，几乎是最具交互性点的 10×，而每个用户仍能看到约每秒 79 个 token。

图 6：MiniMax-M3.1-Flash 在 AMD MI355X 上的 AgentX 帕累托前沿，以每美元 TCO 的总 token 数计。c1 和 c4 使用 3.2 token 的合成接受长度与 7 个投机 token；其他点使用 2.45 token 与 3 个投机 token。将鼠标悬停在点上可查看其指标。

Day-0 RL 支持

我们从 MiniMax-M3.1 的 NVFP4 检查点开始对其运行 RL，并且只训练 rank-32 的 LoRA 适配器。veRL 训练器以与引擎服务该模型相同的方式量化基础模型：路由专家使用 NVFP4，其他投影使用 MXFP8，并在每一步之后仅将适配器同步到引擎。在引擎侧，专家 LoRA 运行在 FlashInfer 的 TRTLLM NVFP4 MoE 内核中，因此基础专家仍然运行在常规服务内核上。

在训练之前，我们从三个方面检查了训练器和引擎是否一致。引擎收到的权重与训练器发送的完全一致；两者将每个 token 路由到相同的专家（路由重放）；两者为相同 token 分配的 logprob 接近。

剩余的差距通过 token 级重要性采样（TIS）来校正，重要性比率上限为 2。由于每个批次只进行一次优化器步进，训练器将 rollout logprob 用作旧 logprob，并跳过本应重新计算它们的额外前向传播。

在 DAPO-Math-17K 上使用 16 块 GB300 GPU，200 步 GRPO 将 AIME-2024 准确率从 36.3% 提升到 67.5%。在同一次运行中，训练奖励从 −0.06 上升到 0.67，train/rollout KL 保持较低，从 0.040 下降到 0.024。

图 7：在 DAPO-Math-17K 上使用 veRL 对 MiniMax-M3.1-Flash 进行 Day-0 RL（16× GB300，200 步 GRPO）：AIME-2024 准确率、训练奖励和 train/rollout KL。使用选项卡在它们之间切换。

致谢

我们衷心感谢 MiniMax 团队开源 MiniMax-M3.1-Flash。我们也感谢 Inferact、NVIDIA 和 AMD（Hongxia Yang 负责 mono 内核，Felix Marty、Andy Luo、Felix Li、Hattie Wu、Gilbert Lei 和 Peng Sun）在 vLLM 中为该模型提供 day-0 支持，同时感谢 FlyDSL 团队在 AMD 内核方面的帮助以及 vLLM 社区。