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

vLLM 在 NVIDIA Blackwell GPU 上于第 0 天支持 MiniMax-M3.1-Flash，在配备专用 Rubin 内核的 NVIDIA Rubin GPU 上以及 AMD MI350 系列 GPU 上也同样支持，在智能体工作负载上表现出强劲性能。

TL;DR

  • MiniMax 稀疏注意力（MSA）搭配NVFP4 KV 缓存同时用于索引器和注意力路径，外加NVFP4 MoE 权重以及一个DSpark草稿模型。
  • Blackwell MSA 内核使用新的 CUDA 13.4QMUL4指令在内核内将 NVFP4 反量化为 FP8：最高1.7× 更快索引器 QK 解码和1.3× 更快稀疏注意力解码。
  • NVFP4 MegaMoE结合 MXFP8 共享专家融合和提前 TMEM 释放：内核延迟降低 20%在预填充阶段，以及预填充吞吐量提升 7%。
  • 索引器解码上下文并行（DCP）：最高3.3× 更快在 4× GB300 上、512K 上下文时每个稀疏层的索引器。
  • QKV GEMM + norm + RoPE + KV-insert 融合：1.1–1.6× 更快在 512+ token 时的预填充，以及约P50 TTFT 降低 19%在 TP4 下。
  • FlashInfer PrimiTS用于 DSpark 草稿模型注意力的后端：1.3–2× 更快相比 FlashAttention 4，降低 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 上，最高每美元总 token 数 133.3M在 SemiAnalysis AgentX 基准测试上的 TCO。
  • 第 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 工具包以获得最佳性能。

vllmserveMiniMaxAI/MiniMax-M3.1-Flash\
-tp4\
--reasoning-parserminimax_m3\
--block-size128\
--kv-cache-dtypenvfp4\
--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

vllmserveMiniMaxAI/MiniMax-M3.1-Flash\
-tp4\
--reasoning-parserminimax_m3\
--block-size128\
--kv-cache-dtypenvfp4\
--attention-config'{"indexer_kv_dtype": "nvfp4", "indexer_decode_cp": true}'\
--quantization-config.moemxfp8\
--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 组的索引器选出其得分最高的 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 缓存 dtype、并行方式、GPU 或上下文长度，即可查看可容纳多少个序列。

性能优化

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

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

NVIDIA Blackwell 优化的 MSA 内核

KV 缓存以 NVFP4 存储，而 query 保持 FP8，因此我们无法使用原生 NVFP4 张量核心指令进行矩阵乘法。相反，该内核将 NVFP4 KV 缓存反量化为 FP8，并执行 FP8 MMA。为保持反量化开销较低，我们使用了 CUDA 13.4 中引入的 Blackwell 专用 PTX 指令，mul.e4m3x4.e2m1x4.e4m3x4（SASSQMUL4）。它在单条指令中将四个 NVFP4 值按其缩放因子缩放，并生成四个 FP8 值。相比之前的 FP16 往返路径，这所需的 CUDA 核心指令少得多。结果是在索引器 QK decode 内核上最高获得 1.7 倍加速，在稀疏注意力 decode 内核上获得 1.3 倍加速。

NVFP4 MegaMoE

MegaMoE 是现代专家并行（EP）部署的关键构建模块。我们将 DeepGEMM 的 MegaMoE 扩展到 NVFP4 精度，并融合了 MXFP8 共享专家，已在我们 fork 中开源（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 作为其投机解码草稿模型，该模型运行非因果 GQA，并带有 4096 token 的滑动窗口。此前，vLLM 在 FlashAttention 4 上运行该草稿模型，而 FlashAttention 4 并未针对解码形状进行优化。我们将其切换到 FlashInfer 的 PrimiTS 后端。PrimiTS 比 FlashAttention 4 快 1.3–2 倍，并将整体前向时间缩短了 5%。

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

vLLM 在智能体服务负载上表现出强劲性能。我们使用 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：MiniMax-M3.1-Flash 在 NVIDIA GB300 上的 AgentX 帕累托前沿，使用 7 个投机 token，合成接受长度为 3.16–3.26 token（包括第一个 token）。将鼠标悬停在某个点上可查看其指标。

NVIDIA Rubin 优化的 MSA

我们还在 NVIDIA Rubin GPU 上对该模型进行了优化。为缓解 NVFP4 到 FP8 的转换开销，我们将 NVFP4 直接转换为 FP16，并以 FP16 运行索引器的 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 比 Blackwell 拥有更多 SM，工作规划器根据 SM 数量来确定其 tile 大小，因此工作被均匀分配到 Rubin 的全部 212 个 SM 上。

Prefill 稀疏注意力同样受益于局部性域优化。我们通过 CUDA 虚拟内存 API 分配部分缓冲区，使 2 MB 页在两个域之间交替，组合内核将每个 tile 交给一个 CTA，其 SM 位于持有该 tile 数据的域中。在 Rubin 上，prefill 与 decode 注意力内核使用密集 FP8 MMA，每条指令 K=64，这将 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 缓存内存。对于 decode，我们添加了 indexer DCP 以加速长上下文 decode，以及一个加速低延迟推理的 mono 内核。对于 prefill，序列并行和双批次重叠减少了引擎内部的通信，新的 KV 缓存布局让每个 KV 块以单次传输移动到 decode 节点。MSA 和 mono 内核构建于FlyDSL，AMD 用于 GPU 内核的 Python DSL，并得到了 FlyDSL 团队的帮助。

NVFP4 MSA 内核

MiniMax-M3.1 使用 NVFP4 KV 缓存（QAT）对主注意力和 indexer 进行训练，但 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 相同的索引器解码上下文并行，而在 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 倍。

SP + DBO 预填充与单次读取 KV 传输

在 TP4 下，MI355X 上的长提示预填充受限于通信，既包括节点内 GPU 之间的通信，也包括预填充节点与解码节点之间的通信。在引擎内部，双批次重叠（DBO）将张量并行集合通信隐藏在另一个微批次的计算之后。序列并行（SP）则削减流量本身。每块 GPU 保留四分之一的 token，注意力输出以 MXFP8 进行全对全交换，使每块 GPU 运行完整的o_proj在其自己的 token 上，并且 MoE 输出经过归约散射。这将每块 GPU 每层每 token 的流量从约 36 KB 降至 20 KB，并且归一化、量化和路由器仅在四分之一的 token 上运行。

只有当 KV 缓存也能快速到达解码节点时，更快的预填充引擎才有意义。vLLM 的逐层 KV 缓存布局会把每个 KV 块拆分到 125 个小页上，而每个页都需要单独进行一次 NIXL RDMA 读取。我们改用块外层布局，把每个块存储为一行连续的 1.82 MB 数据，这样 NIXL 只需一次读取就能搬移它。综合起来，引擎和 KV 传输的改动让 16K+ token 的预填充批次在 4× MI355X 上快了 1.8–2.1 倍。

低延迟单内核

在低并发下，AMD GPU 上的解码受限于启动开销：内核启动开销比计算本身耗时更多。单内核解码通过把每个稀疏 MoE 解码层作为一次 FlyDSL 内核启动来运行，从而解决了这个问题。这一次启动涵盖了从 QKV 投影和稀疏注意力到张量并行 all-reduce 以及 MXFP4 MoE 的全部内容，取代了大约 1,170 次内核启动。在 TP4 配置的 MI350X 上，这让解码步骤快了最多 2.3 倍，并在低并发下将 8K 输入/1K 输出的吞吐量翻倍。在智能体编码 trace 上，它把交互性提升了 50–65%。

AMD MI355X 上的智能体工作负载基准测试

我们的 AMD 实现还带来了出色的单位成本性能。在 InferenceX AgentX 基准测试中，MiniMax-M3.1-Flash 在延迟敏感的前沿端保持每用户每秒 331.0 个 token。沿着前沿继续，它在每美元 TCO 交付 3460 万总 token 的同时，让每个用户保持在每秒 170 个 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 上运行 RL，从其 NVFP4 checkpoint 开始，只训练 rank-32 的 LoRA adapter。veRL trainer 对基座模型的量化方式与引擎服务它时相同：路由专家上用 NVFP4，其他投影上用 MXFP8，并且每一步之后只把 adapter 同步到引擎。在引擎侧，专家 LoRA 运行在 FlashInfer 的 TRTLLM NVFP4 MoE kernel 内，因此基座专家仍然跑在正常的服务 kernel 上。

训练之前，我们检查了 trainer 和引擎在三个方面保持一致。引擎收到的正是 trainer 发送的权重；两者把每个 token 路由到相同的专家（routing replay）；两者对相同 token 给出的 logprobs 很接近。

剩余的差距用 token 级重要性采样（TIS）来校正，重要性比率上限设为 2。由于每个 batch 只做一次优化器更新，trainer 把 rollout logprobs 当作旧 logprobs，并跳过原本用于重新计算它们的额外前向传播。

在 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：在 MiniMax-M3.1-Flash 上用 veRL 在 DAPO-Math-17K 上进行 Day-0 RL（16× GB300，200 步 GRPO）：AIME-2024 准确率、训练奖励和 train/rollout 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 社区。