vLLM 发布 MiniMax-M3.1-Flash Day-0 支持

MiniMax-M3.1-Flash 是 MiniMax-M3 系列的最新模型，在推理、编码、智能体（agentic）和视觉任务方面均有提升。该模型专为推理效率而构建，采用原生 NVFP4 KV Cache、NVFP4 量化 MoE 权重，以及用于推测解码（speculative decoding）的 DSpark 草稿模型。

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

TL;DR

• MiniMax 稀疏注意力机制 (MSA)：索引器和注意力路径均采用 NVFP4 KV Cache，并结合 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 插入融合：在 512+ token 长度下，预填充速度提升 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 内核、索引器解码上下文并行、双批次重叠（dual-batch overlap）以及 mono 内核，实现全面 2–3× 的性能提升。
• 智能体服务 (Agentic Serving)：在 NVIDIA GB300 上，对延迟敏感的场景下每用户可达 418.9 tok/s；在 NVIDIA Rubin 上，每用户可达 724.9 tok/s，每 GPU 总吞吐量达 191.5K tok/s；在 AMD MI355X 上，基于 SemiAnalysis AgentX 基准测试，每美元 TCO（总拥有成本）可达 133.3M 总 tokens。
• Day-0 RL 支持：在 NVFP4 检查点上，通过 veRL、FSDP2 和 LoRA 实现端到端强化学习支持。

快速开始

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

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

请注意，该模型只有在代码经过审查并合并到上游仓库后，才会发布在 PyPI 的 nightly 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 模型系列采用了一种块稀疏注意力（block-sparse attention）的变体来替代全注意力机制 (arXiv 2606.13392)，从而提升推理效率。KV Cache 被划分为每块 128 个 token。一个轻量级的索引器（indexer）针对每个 GQA 组使用单个共享的 index-key head，对上下文中的每个 key 进行打分，然后将这些分数通过 max-pooling 聚合为每个块的一个分数。主注意力随后仅在前 16 个块上精确运行，且始终保留最近的块。无论上下文长度如何，这将每个 query 处理的 key 数量上限控制在 2,048 个。

图 1：MiniMax 稀疏注意力。每个 GQA 组的索引器选出其 top KV 块，该组内的所有 query head 仅在这些块上进行精确注意力计算。逐步演示如下。

MiniMax-M3.1 架构的新特性

MiniMax-M3.1 在推理效率上相比上一代有了显著提升：它原生支持量化感知训练，采用 NVFP4 KV Cache，且其路由 MoE 权重也以 NVFP4 格式存储。NVFP4 专家模型将检查点大小从 451.5 GB（MiniMax-M3-MXFP8）缩减至 250.1 GB，体积减少了 44.6%。NVFP4 KV Cache 每个 token 仅需 34,560 字节，而 FP8 格式需要 61,440 字节，每 token 节省 43.75% 的存储空间。综合来看，在四块 NVIDIA B300 GPU 上使用 DEP4 部署方案并处理 256K token 序列时，M3.1 可容纳 76 个并发序列，而使用 FP8 KV Cache 的 M3 仅能容纳 28 个。这意味着在相同硬件条件下，M3.1 支持的并发序列数量约为 M3 的 2.7 倍，从而直接提升了服务吞吐量。

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

性能优化

vLLM 在多种硬件平台上为 MiniMax-M3.1 提供了强劲的性能表现。在 NVIDIA GPU 上，我们发布了针对 NVFP4 KV Cache 优化的内核。我们的 MSA 代码库（vllm-project/MSA）包含针对不同工作负载和操作调优的内核，涵盖 MSA 索引器的预填充（prefill）和解码（decode）、稀疏注意力的预填充和解码，以及一个专用于 MSA 的 top-k 内核。

图 3：Blackwell 架构上单个 MiniMax-M3.1 稀疏解码层在解码阶段（M ≤ 32）的内核级耗时分布。带编号的徽章标记了本文提到的优化项；点击任一徽章即可高亮显示相关内核。

NVIDIA Blackwell 优化的 MSA 内核

KV Cache 以 NVFP4 格式存储，而查询向量保持 FP8 格式，因此我们无法直接使用原生的 NVFP4 Tensor Core 指令进行矩阵乘法。相反，内核先将 NVFP4 KV Cache 反量化为 FP8，然后执行 FP8 MMA（矩阵乘累加）。为了降低反量化开销，我们使用了 CUDA 13.4 中引入的一项新的 Blackwell 专用 PTX 指令 mul.e4m3x4.e2m1x4.e4m3x4（对应 SASS 指令 QMUL4）。该指令可在单条指令中将四个 NVFP4 值与其缩放因子相乘，并生成四个 FP8 值。这比之前的 FP16 往返转换路径所需的 CUDA Core 指令少得多。最终，索引器 QK 解码内核的速度提升最高可达 1.7 倍，稀疏注意力解码内核的速度提升可达 1.3 倍。

NVFP4 MegaMoE

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

其中一项改动是在 FC1 epilogue 阶段提前释放 TMEM stage。此前，TMEM stage 仅在 epilogue 完成后才释放。由于 epilogue 完全在寄存器中运行，这种等待是不必要的。一旦累加器加载到寄存器中，即可立即释放 TMEM，无需等待任何算术运算完成。这一优化使 prefill 阶段的总内核延迟降低了 20%，而更快的 NVFP4 计算在此阶段最为关键。同时，整体 prefill 吞吐量也提升了 7%。

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

在低延迟服务场景中，每个 GPU 都会针对完整上下文对其自身的 index head 进行评分。在四卡配置下，这意味着每个 indexer 层都要读取完整的 index cache 四次。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 insert 融合

MiniMax-M3.1 的 QKV 和 indexer 投影原本会将完整的 QKV 张量写入 HBM。随后，第二个内核再将其读回以执行 norm、RoPE 和 KV cache 插入操作。我们将整个链条融合进单个 GEMM 内核，其 epilogue 逐 head 处理 FP32 累加器。它对 query 和 index query 应用 norm 和 RoPE，同时将 K、V 和 index key 量化为 NVFP4 并直接写入各自的缓存中。QKV 张量全程无需接触 HBM。在 GB300 上，当 prefill 批次包含 512 个或更多 token 时，运行速度提升 1.1–1.6 倍；在 TP4 配置下，P50 首 token 时间（TTFT）降低约 19%。

FlashInfer PrimiTS for the DSpark drafter

MiniMax-M3.1 使用 DSpark 作为其推测解码（speculative decoding）的草稿模型（drafter），该模型运行非因果 GQA，并采用 4096-token 滑动窗口。此前，vLLM 在 FlashAttention 4 上运行草稿模型，但后者并未针对解码形状进行优化。我们将其切换至 FlashInfer 的 PrimiTS 后端。PrimiTS 比 FlashAttention 4 快 1.3–2 倍，并将整体前向传播时间减少了 5%。

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

vLLM 在智能体服务（agentic serving）工作负载上表现出强劲性能。我们在 NVIDIA GB300 上使用 SemiAnalysis AgentX 基准测试对我们的 Day-0 镜像进行了评测（详情见我们的上一篇文章）。在对延迟敏感的前沿区域，MiniMax-M3.1-Flash 实现了每用户 418.9 tokens/s 的速度。沿着前沿进一步扩展，它在保持每 GPU 总吞吐量达到 38.6K tokens/s 的同时，确保每个用户的速度仍高于 200 tokens/s。在吞吐量极限端，它达到了每 GPU 153.8K tokens/s，约为最高交互性点的 24 倍，而每个用户仍能获得约 127 tokens/s 的速度。

图 4：NVIDIA GB300 上 MiniMax-M3.1-Flash 的 AgentX 帕累托前沿，包含 7 个推测 token 和合成接受长度 3.16–3.26 tokens（含首个 token）。将鼠标悬停在点上可查看其指标。

针对 NVIDIA Rubin 优化的 MSA

我们还针对 NVIDIA Rubin GPU 对该模型进行了优化。为了缓解 NVFP4 到 FP8 转换带来的开销，我们将 NVFP4 直接转换为 FP16，并在索引器（indexer）中以 FP16 精度运行分数 MMA。这将反量化指令减少了约三分之一，并且分数变得精确，避免了因 E4M3 重新舍入而需运行 FP8 MMA 的问题。

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

最后，由于 Rubin 拥有比 Blackwell 更多的 SM，工作规划器根据 SM 数量来调整其 tile 大小，从而将工作均匀分布在 Rubin 的全部 212 个 SM 上。

Prefill 稀疏注意力同样受益于局部性域（locality domain）优化。我们通过 CUDA 虚拟内存 API 分配部分缓冲区，使 2 MB 页面在两个域之间交替排列，并且合并内核（combined kernel）会将每个 tile 交给其 SM 位于持有该 tile 数据的域中的 CTA。在 Rubin 架构上，prefill 和解码注意力内核使用 K=64 的密集 FP8 MMA 指令，这将 MMA 指令数量减半，并以 Blackwell FP8 速率的两倍运行。

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

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

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

AMD GPU 支持

NVFP4 MSA 内核

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

NVFP4 索引器 DCP

我们在 AMD 上采用与 NVIDIA 相同的索引器解码上下文并行（Indexer Decode Context Parallelism, DCP）策略，而在 CDNA4 架构上，这一策略带来了额外的性能提升。若不使用 DCP，在 TP4 配置下，每个 GPU 都会针对完整上下文独立计算其索引头得分，导致索引缓存被重复读取四次；同时，矩阵核心（Matrix Cores）的利用率也较低。以 DSpark-3 的解码步骤为例，每个请求仅有 4 个查询行，这只能填满 16×16×128 FP8 MFMA 指令中 16 列里的 4 列。启用 DCP 后，每个 GPU 只需对四分之一的上下文计算全部四个头的得分，从而通过“4 个头 × 4 行”填满所有 16 列。单个内核负责交换索引查询、计算各块得分，并通过 Infinity Fabric 将每个头的得分直接写入拥有该数据的 GPU 内存中。设备端握手机制确保这一流程能在 HIP Graphs 内部正常工作。随后，拥有者 GPU 像往常一样选取前 16 个结果；由于得分与单 GPU 版本逐位一致（bit-for-bit identical），选择结果是精确无误的。在 4× MI355X 硬件上，处理 45 个长度为 30K–210K token 的请求时，稀疏层的索引器运行速度最高提升至原来的 2.8 倍。

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

在 TP4 配置下，MI355X 上的长 Prompt Prefill 阶段受限于通信开销，包括节点内 GPU 之间的通信以及 Prefill 节点与 Decode 节点之间的通信。在引擎内部，双批次重叠（Dual-Batch Overlap, DBO）利用另一个微批次的计算来隐藏张量并行集合通信的延迟。序列并行（Sequence Parallelism, SP）则直接减少了通信流量本身。每个 GPU 仅保留四分之一的 token，注意力输出以 MXFP8 格式进行 All-to-All 交换，使得每个 GPU 能基于自身持有的 token 执行完整的 o_proj 运算，而 MoE 输出则通过 Reduce-Scatter 操作完成。这将每层每个 token 的单 GPU 通信量从约 36 KB 降低至 20 KB，且归一化（Norms）、量化和路由器的计算也仅需处理四分之一的 token。

更快的 Prefill 引擎只有在 KV Cache 也能快速传输至 Decode 节点时才真正有效。vLLM 默认的逐层 KV Cache 布局会将每个 KV 块分散到 125 个小页面中，每个页面都需要独立的 NIXL RDMA 读取操作。我们改用“块外层”（block-outer）布局，将每个块存储为连续的 1.82 MB 数据行，从而使 NIXL 能够通过单次读取完成传输。综合引擎优化与 KV 传输改进，在 4× MI355X 上，16K+ token 规模的 Prefill 批次速度提升了 1.8–2.1 倍。

低延迟 Mono Kernel

在低并发场景下，AMD GPU 上的解码过程受限于内核启动开销：内核启动耗时超过了实际计算时间。Mono decode 通过将每个稀疏 MoE 解码层作为单个 FlyDSL 内核启动来运行，从而解决了这一问题。这一次启动涵盖了从 QKV 投影、稀疏注意力机制到张量并行 all-reduce 以及 MXFP4 MoE 的全部操作，取代了大约 1,170 次内核启动。在 MI350X 上以 TP4（张量并行度为 4）运行时，这使得解码步骤速度提升高达 2.3 倍，并在低并发条件下将 8K 输入/1K 输出的吞吐量翻倍。在 agentic-coding（智能体编码）工作负载追踪中，交互性提升了 50–65%。

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

我们的 AMD 实现还展现了出色的性价比。在 InferenceX AgentX 基准测试中，MiniMax-M3.1-Flash 在对延迟敏感的前沿性能点上保持了每用户每秒 331.0 tokens 的速度。沿着前沿性能曲线进一步延伸，它在提供每美元 TCO（总拥有成本）34.6M tokens 总吞吐量的同时，仍确保每个用户的速度高于每秒 170 tokens。在成本效率端，它达到了每美元 133.3M tokens 的吞吐量，几乎是最高交互性点的 10 倍，而每个用户仍能获得约每秒 79 tokens 的速度。

图 6：MiniMax-M3.1-Flash 在 AMD MI355X 上的 AgentX 帕累托前沿，单位为每美元 TCO 的总 tokens 数。c1 和 c4 使用合成接受长度为 3.2 tokens 且包含 7 个推测 tokens；其他点使用 2.45 tokens 且包含 3 个推测 tokens。悬停于某一点可查看其具体指标。

Day-0 RL 支持

我们从 MiniMax-M3.1 的 NVFP4 checkpoint 开始进行强化学习（RL），仅训练 rank-32 的 LoRA adapters。veRL 训练器采用与推理引擎相同的方式对基础模型进行量化：路由专家（routed experts）使用 NVFP4，其他投影层使用 MXFP8，并且在每一步之后仅将 adapters 同步到引擎。在引擎侧，专家 LoRA 在 FlashInfer 的 TRTLLM NVFP4 MoE kernel 内部运行，因此基础专家仍然使用正常的 serving kernel 运行。

在训练前，我们通过三种方式验证了训练器和引擎的一致性：引擎接收到的权重与训练器发送的完全一致，两者将每个 token 路由到相同的专家（routing replay），并且两者对相同 token 分配的对数概率（logprobs）非常接近。

剩余的差异通过 token 级别的重要性采样（TIS）进行校正，重要性比率上限设为 2。由于每个 batch 只执行一次优化器步骤，训练器直接使用 rollout logprobs 作为旧 logprobs，并跳过了重新计算这些值的额外前向传播步骤。

在 DAPO-Math-17K 数据集上，使用 16 块 GB300 GPU 进行 200 步 GRPO 训练后，AIME-2024 准确率从 36.3% 提升至 67.5%。在同一轮训练中，训练奖励从 −0.06 上升至 0.67，而训练/采样 KL 散度保持较低水平，从 0.040 降至 0.024。

图 7：基于 veRL 框架在 DAPO-Math-17K 数据集上对 MiniMax-M3.1-Flash 进行的 Day-0 RL 实验（16× GB300，200 步 GRPO）：展示了 AIME-2024 准确率、训练奖励以及训练/采样 KL 散度的变化。可通过标签页切换查看不同指标。

致谢

我们衷心感谢 MiniMax 团队开源了 MiniMax-M3.1-Flash。同时，我们也感谢 Inferact、NVIDIA 和 AMD（特别感谢 Hongxia Yang 提供的 mono kernel，以及 Felix Marty、Andy Luo、Felix Li、Hattie Wu、Gilbert Lei 和 Peng Sun）为 vLLM 提供该模型的 Day-0 支持；此外，还要感谢 FlyDSL 团队在 AMD kernel 方面提供的帮助，以及 vLLM 社区的支持。