vLLM 对 MiniMax-M3.1-Flash 的 Day-0 支持：NVFP4 MSA 内核、MegaMoE 与 Agentic 基准测试

vLLM 在 NVIDIA Blackwell、NVIDIA Rubin 和 AMD MI350 系列 GPU 上为 MiniMax-M3.1-Flash 提供了 Day-0 支持，包括 NVFP4 内核、融合 QKV 流水线，以及针对 agentic 服务工作负载调优的投机解码。此次发布意义重大，因为它展示了低精度推理已经发展到何种程度：MiniMax-M3.1 是针对 NVFP4 KV 缓存进行量化感知训练的，而 vLLM 的内核利用了这一特性，在相同硬件上可容纳的并发序列数量约为上一代的 2.7 倍。

vLLM 发布了什么

vLLM 在三个硬件系列上为 MiniMax-M3.1-Flash 提供了 Day-0 服务支持：NVIDIA Blackwell GPU、NVIDIA Rubin GPU（配备专用 Rubin 内核）和 AMD MI350 系列 GPU。针对两家厂商都发布了预构建镜像，此次发布的重点是 agentic 工作负载下的性能。

MiniMax-M3.1-Flash 是 MiniMax-M3 系列的最新模型，在推理、编码、agentic 和视觉任务方面都有所改进。它同时为推理效率而设计，结合了原生 NVFP4 KV 缓存、NVFP4 量化 MoE 权重，以及用于投机解码的 DSpark 草稿模型。

vLLM 列出的主要优化包括：

  • MiniMax 稀疏注意力 (MSA)，对索引器和注意力路径均使用 NVFP4 KV 缓存，外加 NVFP4 MoE 权重和 DSpark 草稿器。
  • Blackwell MSA 内核，利用 CUDA 13.4 的 QMUL4 指令在内核内部将 NVFP4 反量化为 FP8：索引器 QK 解码速度提升高达 1.7 倍，稀疏注意力解码速度提升 1.3 倍。
  • NVFP4 MegaMoE，具有 MXFP8 共享专家融合和早期 TMEM 释放：prefill 阶段内核延迟降低 20%，prefill 吞吐量提升 7%。
  • 索引器解码上下文并行 (DCP)：在 4× GB300 上，512K 上下文下每个稀疏层的索引器速度提升高达 3.3 倍。
  • QKV GEMM + norm + RoPE + KV 插入融合：在 512+ token 时 prefill 速度提升 1.1–1.6 倍，TP4 下 P50 TTFT 降低约 19%。
  • 用于 DSpark 草稿器注意力的 FlashInfer PrimiTS 后端：比 FlashAttention 4 快 1.3–2 倍，总前向时间降低 5%。
  • Rubin (SM107) MSA 内核 已集成到 vLLM 中，性能达到业界领先水平。
  • AMD MI350 系列：NVFP4 原生 MSA 内核、索引器 DCP、双批重叠和 mono 内核全面带来 2–3 倍 的性能提升。
  • Day-0 RL 支持：在 NVFP4 检查点上，与 veRL、FSDP2 和 LoRA 实现端到端 RL。

MiniMax 稀疏注意力的工作原理

MiniMax-M3 模型系列用块稀疏注意力的变体取代了全注意力，以提高推理效率。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% 左右。

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 倍，这直接提升了服务吞吐量。

NVIDIA Blackwell MSA 内核优化

使用 CUDA 13.4 QMUL4 指令将 NVFP4 反量化为 FP8

KV 缓存以 NVFP4 格式存储，而查询保持 FP8，因此无法使用原生 NVFP4 张量核心指令进行矩阵乘法。相反，内核将 NVFP4 KV 缓存反量化为 FP8，并运行 FP8 MMA。

为了降低反量化成本，vLLM 使用了 CUDA 13.4 中引入的 Blackwell 专用 PTX 指令 mul.e4m3x4.e2m1x4.e4m3x4（SASS QMUL4）。它通过缩放因子缩放四个 NVFP4 值，并在单条指令中生成四个 FP8 值。这比之前的 FP16 往返路径所需 CUDA 核心指令少得多。结果是索引器 QK 解码内核速度提升高达 1.7 倍，稀疏注意力解码内核速度提升 1.3 倍。

NVFP4 MegaMoE

MegaMoE 是现代专家并行 (EP) 部署的关键构建块。vLLM 将 DeepGEMM 的 MegaMoE 扩展到 NVFP4 精度，并融合了 MXFP8 共享专家，已在项目的 vllm-project/DeepGEMM 分支中开源。

为 MegaMoE 添加 NVFP4 支持不仅仅是数据类型切换。与之前的 FP8×FP4 路径相比，NVFP4 将每元素字节数减半，并将张量核心吞吐量加倍，因此内核的其他部分也必须随之改变，否则流水线将失去平衡。

其中一项更改是在 FC1 尾声（epilogue）中提前释放 TMEM 阶段。以前，TMEM 阶段仅在尾声完成后才释放。这种等待是不必要的，因为尾声完全在寄存器中运行，因此一旦累加器加载到寄存器中，就可以立即释放 TMEM，而无需等待任何算术操作。这使得总内核延迟在 prefill 阶段降低 20%（此时更快的 NVFP4 计算最为重要），并将整体 prefill 吞吐量提高 7%。

NVFP4 索引器解码上下文并行 (DCP)

在低延迟服务中，每个 GPU 对整个上下文中的自身索引头进行评分。在四块 GPU 上，这意味着每个索引器层会将整个索引缓存读取四次。

索引器 DCP 改为按上下文拆分工作。每个 GPU 对四分之一的页面对所有四个头进行评分。然后，它通过 NVLink 将每个头的本地前 16 个结果发送给拥有该头的 GPU，后者将候选结果合并为最终的前 16 个。选择保持精确，在 4× NVIDIA GB300 GPU 上，512K 上下文下索引器每个稀疏层的速度提升高达 3.3 倍。

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

MiniMax-M3.1 的 QKV 和索引器投影过去将完整的 QKV 张量写入 HBM。然后，第二个内核将其读回以进行 norm、RoPE 和 KV 缓存插入。

vLLM 将整个链融合到一个 GEMM 内核中，其尾声逐头处理 FP32 累加器。它对查询和索引查询应用 norm 和 RoPE。它还将 K、V 和索引键量化为 NVFP4，并直接写入其缓存。QKV 张量永远不会触及 HBM。在 GB300 上，512 个或更多 token 的 prefill 批次运行速度提升 1.1–1.6 倍，TP4 下 P50 首次 token 生成时间 (TTFT) 降低约 19%。

用于 DSpark 草稿器的 FlashInfer PrimiTS

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

NVIDIA Rubin MSA 内核

在 NVIDIA Rubin GPU 上，vLLM 对模型进行了优化，以减轻 NVFP4 到 FP8 转换的开销：它将 NVFP4 直接转换为 FP16，并在索引器中以 FP16 运行分数 MMA。这将反量化指令减少了约三分之一，并且分数变得精确，而不是带有运行 FP8 MMA 所需的 E4M3 重新舍入。

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

由于 Rubin 的 SM 比 Blackwell 多，工作规划器根据 SM 数量调整平铺大小，因此工作均匀分布在 Rubin 的所有 212 个 SM 上。

Prefill 稀疏注意力也受益于局部性域优化。vLLM 通过 CUDA 虚拟内存 API 分配部分缓冲区，以便 2 MB 页面在两个域之间交替，组合内核将每个瓦片交给 SM 位于包含该瓦片数据的域中的 CTA。在 Rubin 上，prefill 和解码注意力内核使用密集 FP8 MMA，每条指令 K=64，这使 MMA 指令数量减半，并以 Blackwell FP8 速率的两倍运行。

AMD MI350 系列支持

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

通过查表实现的 NVFP4 MSA 内核

MiniMax-M3.1 针对主注意力和索引器都使用 NVFP4 KV 缓存（QAT）进行训练，但 CDNA4 没有用于反量化 NVFP4 的原生指令。为了保持 MSA 内核的速度，vLLM 将反量化转换为查表操作。由于可能的 E4M3 缩放因子只有 256 种，E2M1 幅值只有 8 种，因此内核将所有缩放后的值（已舍入到 FP8）预计算到 LDS 中的 2 KB 表中。一次 v_perm_b32 字节置换加上一次 XOR 符号位处理，即可将四个 FP4 值转换为 FP8。内核还仅对共享前缀页反量化一次，最多可供共享该页的 64 个请求使用。综合来看，这使得稀疏解码注意力比将选定块转换为 FP8 并运行 FP8 注意力内核快高达 2.5 倍。

CDNA4 上的 NVFP4 索引器 DCP

与 NVIDIA 相同，AMD 上也使用了索引器解码上下文并行，并且在 CDNA4 上带来了额外收益。没有 DCP 时，TP4 下每个 GPU 对整个上下文中的自身索引头进行评分，因此索引缓存被读取四次。这还导致矩阵核心利用率不足：DSpark-3 解码步骤每个请求只有 4 个查询行，仅填充 16×16×128 FP8 MFMA 的 16 列中的 4 列。

使用 DCP，每个 GPU 对四分之一的上下文中所有四个头进行评分，因此 4 个头 × 4 行填满所有 16 列。单个内核交换索引查询，对其块进行评分，并通过 Infinity Fabric 将每个头的分数直接写入拥有该头的 GPU 内存。设备端握手确保这在 HIP 图中正常工作。然后，所有者像以前一样选择前 16 个结果，并且由于分数与单 GPU 版本逐位相同，因此选择是精确的。在 4× MI355X 上，对于 45 个 30K–210K token 的请求，索引器每个稀疏层的速度提升高达 2.8 倍。

序列并行、双批重叠和单次读取 KV 传输

在 TP4 下，MI355X 上的长提示 prefill 受通信限制，无论是节点内 GPU 之间还是 prefill 和解码节点之间。在引擎内部，双批重叠 (DBO) 将张量并行集合通信隐藏在另一个微批的计算后面。序列并行 (SP) 减少了流量本身。每个 GPU 保留四分之一的 token，注意力输出以 MXFP8 进行全对全交换，以便每个 GPU 对其自身的 token 运行完整的 o_proj，MoE 输出则进行 reduce-scatter。这将每个 GPU 的流量从每层每个 token 约 36 KB 降低到 20 KB，并且 norm、量化和路由器仅对四分之一的 token 运行。

更快的 prefill 引擎只有在 KV 缓存也能快速到达解码节点时才有帮助。vLLM 的逐层 KV 缓存布局将每个 KV 块拆分为 125 个小页面，每个页面都需要自己的 NIXL RDMA 读取。vLLM 切换到块外部布局，将每个块存储在单个连续的 1.82 MB 行 中，因此 NIXL 通过单次读取即可移动它。结合起来，引擎和 KV 传输的更改使 4× MI355X 上 16K+ token 的 prefill 批次速度提升 1.8–2.1 倍。

低延迟 mono 内核

在低并发下，AMD GPU 上的解码受启动限制：内核启动开销比计算时间更长。Mono 解码通过将每个稀疏 MoE 解码器层作为单个 FlyDSL 内核启动来解决这个问题。这一次启动覆盖从 QKV 投影和稀疏注意力到张量并行全归约和 MXFP4 MoE 的所有内容，取代了大约 1,170 次内核启动。在 MI350X 上，TP4 下，这使解码步骤速度提升高达 2.3 倍，并在低并发下将 8K 输入/1K 输出吞吐量翻倍。在 agentic 编码轨迹上，它将交互性提高了 50–65%。

Agentic 服务基准测试

NVIDIA GB300

vLLM 使用 SemiAnalysis AgentX 基准测试对其 NVIDIA GB300 上的 Day-0 镜像进行了基准测试。在延迟敏感的前沿，MiniMax-M3.1-Flash 保持 每个用户每秒 418.9 个 token。沿前沿进一步，它保持每个用户每秒 200 个 token 以上，同时每 GPU 每秒提供 38.6K 个总 token。在吞吐量端，它达到每 GPU 每秒 153.8K 个 token，约为 最具交互性点的 24 倍，而每个用户仍能看到约每秒 127 个 token。

GB300 测量使用了 7 个投机 token 和 3.16–3.26 个 token（包括第一个 token）的合成接受长度。

NVIDIA Rubin

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

AMD MI355X

在 InferenceX AgentX 基准测试上，MiniMax-M3.1-Flash 在延迟敏感的前沿保持 每个用户每秒 331.0 个 token。沿前沿进一步，它保持每个用户每秒 170 个 token 以上，同时每 TCO 美元交付 34.6M 个总 token。在成本效率端，它达到每美元 133.3M 个 token，接近 最具交互性点的 10 倍，而每个用户仍能看到约每秒 79 个 token。

对于 AMD 测量，c1 和 c4 点使用 3.2 个 token 的合成接受长度和 7 个投机 token；其他点使用 2.45 个 token 和 3 个投机 token。

Day-0 RL 支持

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

在训练之前，vLLM 通过三种方式检查训练器和引擎是否一致：引擎精确接收训练器发送的权重；两者将每个 token 路由到相同的专家（路由重放）；两者为相同 token 分配接近的 logprobs。

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

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

快速开始

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

  • 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

vLLM 建议使用 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

为什么此次发布很重要

MiniMax-M3.1-Flash 是量化感知训练在服务层带来回报的案例研究。由于模型是针对 NVFP4 KV 缓存进行训练的，而不是事后量化，vLLM 可以对索引器和稀疏注意力路径都使用 NVFP4，将检查点缩小 44.6%，并在四块 B300 GPU 上容纳比 FP8 KV 缓存前代产品多约 2.7 倍的并发 256K token 序列。

内核工作的另一个显著特点是其硬件特定性，而非通用性。Blackwell 获得 CUDA 13.4 QMUL4 反量化路径；Rubin 获得 FP16 分数 MMA、打包的 fma.rn.f32x2.f16x2 缩放，以及跨 212 个 SM 的 SM 数量感知瓦片规划；AMD CDNA4 获得一个 2 KB LDS 查表，以替代缺失的 NVFP4 反量化指令。每个平台通过不同的机制达到其数据，vLLM 在 vllm-project/MSA 仓库中发布了这些内核。

最后，此次发布覆盖了从训练到服务的完整闭环：Day-0 RL 与 veRL、FSDP2 和 LoRA 直接在 NVFP4 检查点上运行，并通过路由重放和 token 级重要性采样保持训练器和引擎对齐。这一组合——NVFP4 服务、Day-0 RL 以及三个硬件系列上的 agentic 基准测试——使其成为低精度推理部署的参考点。

Sources