跳到正文
vLLM Blog· vLLM Team·· 2026-06-12精选AI 评分66

vLLM 为 MiniMax M3 提供 day-0 支持，覆盖 1M token 多模态推理

MiniMax M3 in vLLM: Day-0 Serving for 1M-Token Multimodal Reasoning

AI 导读

vLLM 宣布对 MiniMax M3 系列提供 day-0 支持，涵盖 BF16 与 MXFP8 两个 checkpoint，支持 1M token 上下文、原生多模态推理、工具调用与可控思考模式。

推荐理由

vLLM 官方给出 MiniMax M3 的 day-0 部署配方与内核改动，读者可据此判断 1M 上下文多模态推理的落地成本。

正文 · AI 翻译

我们很高兴地宣布，vLLM 从第 0 天起就支持 MiniMax M3 系列，包括位于 MiniMaxAI/MiniMax-M3 和 MiniMaxAI/MiniMax-M3-MXFP8 的 BF16 和 MXFP8 检查点。

MiniMax M3 专为生产中日益常见的工作负载而构建：百万 token 上下文、原生多模态推理、编码与智能体工作流、工具使用以及可控思考行为。难点不仅在于加载模型，还在于让新的 MiniMax 稀疏注意力路径、多模态预处理、MXFP8 MoE 执行、EAGLE3 推测解码、前缀缓存和部署方案在一个用户真正能运行的推理引擎中协同工作。

本文介绍模型特性、vLLM 实现、此次发布背后的内核与缓存工作，以及我们在第 0 天之后即将落地的后续优化。

Figure 1: MiniMax M3 day-0 support brings long-context, multimodal, sparse-attention serving to vLLM.
图 1：MiniMax M3 第 0 天支持为 vLLM 带来长上下文、多模态、稀疏注意力推理服务。

TL;DR

vLLM 为 MiniMax M3 提供初始第 0 天支持：

  • 模型系列：BF16 和 MXFP8 MiniMax M3 检查点，支持 1M token 上下文，具体取决于硬件容量和部署配置。
  • 核心架构：MiniMax 稀疏注意力（MSA），一种混合稠密/稀疏注意力设计，对 128 token 的 KV 块进行评分，为每个查询和 KV 组选择 top 块，并在选中的块上运行 GQA 注意力。
  • 服务栈：minimax_m3 工具和推理解析器、思考模式控制、纯文本和多模态路径、TP/EP 部署、前缀缓存、分块预填充、EAGLE3 推测解码，以及可用的 Docker 镜像。
  • 推测解码：第 0 天 EAGLE3 支持，草稿模型发布于 Inferact/MiniMax-M3-EAGLE3。
  • RL 后训练：在 NVIDIA NeMo RL 中进行第 0 天 MiniMax M3 GRPO 后训练，使用 vLLM 作为生成后端。
  • 性能工作：MSA 预填充和解码内核、索引器评分和 top-k 内核、融合 QKNorm + RoPE + KV 插入、GemmaNorm 和量化路径优化，以及 MXFP8 MoE 后端集成。
  • 路线图：FP8 索引器/KV 缓存工作、TRTLLM-Gen MoE、更广泛的解耦服务方案、上下文并行长预填充工作，以及进一步的多模态网关优化。

MiniMax M3 支持矩阵

能力MiniMax M3 新增内容vLLM 支持
1M token 上下文长上下文文本、代码、智能体轨迹和文档工作负载--max-model-len 配置、块大小 128 方案、前缀缓存、分块预填充、MSA 内核
MiniMax 稀疏注意力在选定的 128 token KV 块上进行块稀疏 GQA混合注意力后端、索引器评分内核、top-k 块选择、稀疏 GQA 预填充/解码
MXFP8 模型权重面向大规模部署的高效 MoE 服务Blackwell 级系统上的 DeepGEMM MXFP8 MoE 后端，以及 Hopper 级系统上的 Marlin MXFP8
原生多模态文本之外的图像和视频输入模型特定的多模态预处理路径和 vLLM 服务集成
工具和推理输出智能体工作流和可控思考minimax_m3 工具解析器、minimax_m3 推理解析器、thinking_mode 聊天模板控制
EAGLE3 推测解码用于生成的草稿模型加速使用 Inferact/MiniMax-M3-EAGLE3 的第 0 天 EAGLE3 方案

快速开始：使用 vLLM 运行 MiniMax M3

在 NVIDIA 上，MSA 使用默认注意力后端，视觉编码器在 FlashInfer 后端（--mm-encoder-attn-backend FLASHINFER）上运行，并带有共享内存处理器缓存和数据并行编码器。

对于 Blackwell 级节点上的 MXFP8 检查点，起点是：

vllm serve MiniMaxAI/MiniMax-M3-MXFP8 \
  --block-size 128 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3 \
  --mm-encoder-attn-backend FLASHINFER \
  --mm-processor-cache-type shm \
  --mm-encoder-tp-mode data

对于 BF16：

vllm serve MiniMaxAI/MiniMax-M3 \
  --block-size 128 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3 \
  --mm-encoder-attn-backend FLASHINFER \
  --mm-processor-cache-type shm \
  --mm-encoder-tp-mode data

具体配方取决于目标加速器、模型 dtype、上下文长度、流量形态，以及部署是优先考虑吞吐量、延迟还是最大上下文容量。验证已在 NVIDIA H200、GB200 和 B300 上完成。有关 NVIDIA 和 AMD 的完整启动配方、部署策略和调优参数，请参阅 MiniMax M3 的 vLLM 配方。

AMD ROCm

MiniMax M3 可在 AMD Instinct GPU 上运行。MSA 运行在 Triton attention 后端上，因此 AMD 部署需添加 --attention-backend TRITON_ATTN；视觉编码器使用 AITER FlashAttention 后端（--mm-encoder-attn-backend ROCM_AITER_FA），并配有共享内存处理器缓存和数据并行编码器。

对于 MXFP8 检查点：

vllm serve MiniMaxAI/MiniMax-M3-MXFP8 \
  --block-size 128 \
  --tensor-parallel-size 8 \
  --attention-backend TRITON_ATTN \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3 \
  --mm-encoder-attn-backend ROCM_AITER_FA \
  --mm-processor-cache-type shm \
  --mm-encoder-tp-mode data

对于 BF16：

vllm serve MiniMaxAI/MiniMax-M3 \
  --block-size 128 \
  --tensor-parallel-size 8 \
  --attention-backend TRITON_ATTN \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3 \
  --mm-encoder-attn-backend ROCM_AITER_FA \
  --mm-processor-cache-type shm \
  --mm-encoder-tp-mode data

验证已在 MI350 系列和 MI300 系列 GPU 上完成。

重要的部署调优参数

MiniMax M3 有几个比通常更重要的调优参数。--block-size 128 将 vLLM 缓存块与 MSA 的稀疏块粒度对齐。--max-model-len 控制对外公布的上下文长度和 KV 容量规划。--tensor-parallel-size 和 --enable-expert-parallel 决定 attention、投影和 MoE 专家如何在 GPU 之间拆分。对于智能体工作负载，应启用 minimax_m3 工具和推理解析器，长上下文配方应说明该目标是否启用了前缀缓存、分块预填充、EAGLE3 推测解码和多模态预处理。

EAGLE3 推测解码

MiniMax M3 在 vLLM 中还提供 day-0 EAGLE3 推测解码支持。草稿模型发布于 Inferact/MiniMax-M3-EAGLE3，使部署能够使用草稿模型路径，在工作负载和接受行为适合目标流量时降低生成延迟。

要启用 EAGLE3，请在服务命令中添加推测解码配置：

vllm serve MiniMaxAI/MiniMax-M3-MXFP8 \
  --block-size 128 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --tool-call-parser minimax_m3 \
  --enable-auto-tool-choice \
  --reasoning-parser minimax_m3 \
  --mm-encoder-attn-backend FLASHINFER \
  --mm-processor-cache-type shm \
  --mm-encoder-tp-mode data \
  --speculative-config '{"method":"eagle3","model":"Inferact/MiniMax-M3-EAGLE3","num_speculative_tokens":3,"attention_backend":"FLASH_ATTN"}'

该示例使用 num_speculative_tokens=3，这是用于验证的保守起点。生产配方应根据部署流量组合的接受率、TPOT、吞吐量和目标延迟来调整此值。

思考模式

MiniMax M3 提供可控的思考行为。在 vLLM 中，通过 chat_template_kwargs 传入模式：

from openai import OpenAI
 
client = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")
model = client.models.list().data[0].id
 
messages = [{"role": "user", "content": "Explain MiniMax Sparse Attention."}]
 
for mode in ["enabled", "disabled", "adaptive"]:
    response = client.chat.completions.create(
        model=model,
        messages=messages,
        extra_body={
            "chat_template_kwargs": {
                "thinking_mode": mode,
            },
        },
    )
    print(mode, response.choices[0].message.content)

模型关键特性与新能力

MiniMax M3 在三个方向上对推理系统具有重要意义。

100 万 token 上下文与 MiniMax 稀疏注意力

核心架构变更是 MiniMax 稀疏注意力（MSA）。MSA 不再让每个查询对完整 KV 缓存进行密集注意力计算，而是使用索引路径对 KV 块评分，并选择最相关的块进行真正的注意力计算。默认粒度为 128 token 的 KV 块，所选块在 GQA 组内共享。

实际而言，每个查询 token 遵循三个步骤：

  1. 用小型索引头对候选 KV 块评分。
  2. 选择 top 块，同时应用配置的块规则。
  3. 仅对选定的 KV 块运行在线 softmax 注意力。

这既保留了用户期望的长上下文行为，又限制了每个生成 token 的注意力计算量。实际上，MiniMax 稀疏注意力是使 MiniMax M3 的 100 万 token 上下文在 vLLM 服务中切实可行的机制。

Figure 2: MiniMax Sparse Attention keeps local and global context available while selecting sparse 128-token KV blocks from a 1M-token history.
图 2：MiniMax 稀疏注意力在保留局部和全局上下文的同时，从 100 万 token 历史中选择稀疏的 128 token KV 块。

MSA 机制详解

MSA 将两个问题分开：哪些过去的块值得读取，以及如何对这些块运行注意力。索引路径通过对固定的 128 token KV 块评分来回答第一个问题。稀疏 GQA 路径通过对选定块运行注意力来回答第二个问题。

所选集合并非仅由学习到的 top-k 决定。M3 配置暴露了 init_blocks / sparse_init_block 和 local_blocks / sparse_local_block，但当前配方使用的是 init_blocks=0 和 local_blocks=1。在实践中，确定性规则是查询 token 附近的局部窗口块，而其余被选中的块来自索引器评分的 top-k 选择。正确性取决于一些细节：末尾的部分块必须被掩码，块内的因果边界必须被遵守，同时也在 top-k 中排名的局部块不能被重复计算，并且批量请求可能具有不同的有效块范围。

原生多模态

MiniMax M3 是一个多模态模型，而不是一个带有独立附属组件的纯文本检查点。服务路径必须处理图像和视频输入，将它们预处理为 patch 张量，保留网格元数据，并将结果交给模型，同时不占用生成所需的 GPU 时间。

对于 vLLM 部署，发布工作包括模型特定的多模态预处理和解析器支持，以便用户可以通过同一服务界面运行纯文本、工具使用、推理和多模态工作负载。

MXFP8 MoE 权重

MXFP8 检查点专为高效的大规模服务而设计。验证已在 Blackwell 级系统上使用 DeepGEMM MXFP8 MoE 后端，在 Hopper 级系统上使用 Marlin MXFP8。

vLLM 实现

MiniMax M3 是一个混合模型：一些层路由到稠密注意力，而稀疏层路由到 MiniMax MSA 后端。vLLM 将这种区分隐藏在模型和注意力后端之后，因此调度器、缓存分配、批处理、前缀缓存和服务从外部看起来仍然熟悉。对于刚接触这些内部机制的读者，Anatomy of vLLM 是本节的良好补充。

MiniMax 稀疏注意力后端

MSA 后端有两个不同的职责。

首先，它计算稀疏元数据。索引器对 KV 块进行评分，应用配置的块选择规则，并输出 top-k 块 ID。对于 M3，选择是基于块的：稀疏性的单位与缓存管理器已经理解的 128 token 的类页块相同。

其次，它计算这些块上的注意力。预填充和解码具有不同的形状，因此 vLLM 使用专门的内核：

  • 预填充索引器评分： Triton 内核计算块分数和 top-k 块选择。
  • 预填充稀疏 GQA： Triton 和 MiniMax-AI/MSA CuTe/SM100 路径支持块稀疏 GQA 注意力。CuTe 路径将查询到块的映射反转为 K-major CSR 形式，以便 KV 块可以高效复用。
  • 解码索引器评分： 分割式解码内核扫描候选块，对其进行评分，并合并 top-k 结果。
  • 解码稀疏 GQA： GQA 解码内核消费选定的块页并合并部分注意力输出。

预填充执行

预填充处理提示并创建 KV 缓存。对于 M3，提示长度和稀疏元数据都很重要。该路径有四个概念阶段：

  1. 构建查询、键、值和索引投影。 稠密投影产生索引器和注意力内核所需的表示。
  2. 对块评分。 索引路径为每个候选 KV 块计算分数。评分归约可以使用块级规则，如 max 或 log-sum-exp，具体取决于模型配置。
  3. 选择块。 Top-k 选择将学习到的块分数与配置的块规则相结合，然后为每个查询和 KV 组输出块 ID。
  4. 运行稀疏 GQA。注意力内核只读取选定的 KV 块，并计算出与仅限该选定集合的稠密注意力传递相同的在线 softmax 注意力结果。

最终稀疏 GQA 工作有两种有用的调度方案。查询优先（query-major）调度很直接：每个查询遍历其选定的 KV 块。当许多查询选择同一个块时，KV 块优先（KV-block-major）调度更适合长提示。在该调度中，vLLM 构建一个 K 到 Q 的映射，使得一个 KV 块可以在输出合并之前被加载并在许多查询之间复用。

解码执行

解码具有不同的形态。每一步通常为每个活跃序列处理一个新 token，但批次中可能包含许多具有不同上下文长度的序列。运行时更新缓存状态、对候选块打分、应用局部窗口处理、选择 top 块、运行稀疏 GQA 解码，并在内核使用拆分工作时合并部分输出。由于这发生在每个生成的 token 上，索引器打分和 top-k 内核属于 TPOT 的一部分，而不仅仅是设置开销。

M3 的稀疏注意力配置控制块大小、top-k 数量、可选的初始块、局部窗口块、索引维度、稀疏层 ID、分数类型，以及仅将索引注意力用于选择的层。关键实现规则是，每个选定的块 ID 都必须映射回 vLLM 调度器和缓存管理器所知道的同一逻辑请求状态。

Figure 3: vLLM routes dense layers through standard attention and sparse layers through the MiniMax MSA backend.
图 3：vLLM 将稠密层路由到标准注意力，将稀疏层路由到 MiniMax MSA 后端。

KV 缓存布局：标准存储，稀疏计算

MiniMax M3 可以将 KV 存储为普通的分页 KV，并在计算路径中应用稀疏性。这使得 vLLM 可以保持缓存管理器简单，同时增加内核所需的灵活性：

  • 主注意力 KV 缓存和索引器 K 缓存被显式跟踪。
  • 一旦配方（recipe）的缓存状态交互得到验证，前缀缓存和分块预填充就可以继续使用稳定的缓存块。
  • 相关的分离式服务和 NIXL 风格传输路径可以将缓存视为分页状态，而注意力后端处理稀疏选择。

前缀缓存与分块预填充

前缀缓存很重要，因为 M3 工作负载经常复用长提示：代码库、文档、多轮智能体轨迹和多模态上下文。分块预填充很重要，因为一个 1M token 的请求不应作为一个巨大的预填充独占引擎。它们共同构成发布就绪性压力测试：索引缓存状态、主注意力 KV 状态、稠密注意力状态、前缀命中、抢占、批处理和长上下文块边界，在配方被视为生产就绪之前，都必须在相同的块表上达成一致。

多模态与解析器集成

MiniMax M3 包含针对工具、推理和多模态输入的模型特定解析行为。vLLM 支持包括：

  • --tool-call-parser minimax_m3 用于工具调用格式化。
  • --reasoning-parser minimax_m3 用于推理输出提取。
  • 针对 thinking_mode 的聊天模板支持。
  • 针对图像和视频输入的多模态预处理集成。

对于生产部署，只要有可能，预处理最好在 GPU 执行之前处理。目标架构是一个网关，它下载媒体、解码帧、采样视频、调整和归一化图像、创建补丁张量，并将可直接运行的张量传递给工作进程。

这一点很重要，因为多模态请求在 API 边界上看起来可能很小，但经过预处理后会变得很大。一个视频可能需要帧采样、逐帧缩放、补丁生成和元数据打包。将 CPU 密集型媒体工作放在上游，可以让 GPU 调度更容易推理。

解析器侧对智能体流量同样重要。工具调用和推理解析器将模型特定的文本约定转换为结构化 API 响应。如果没有正确的解析器，模型可以生成有用的文本，但应用程序却难以消费。

Figure 4: For MiniMax M3, CPU-side image and video preprocessing should hand ready tensors to the vLLM worker so GPU time is reserved for inference.
图 4：对于 MiniMax M3，CPU 侧的图像和视频预处理应将就绪的张量交给 vLLM worker，以便 GPU 时间保留给推理。

性能优化

MiniMax M3 转移了瓶颈。MSA 减少了密集注意力计算，但引入了索引器分数计算、块选择、稀疏元数据构建以及额外的小内核。vLLM 的 day-0 实现专注于让这些新部件保持低成本。

指导原则很简单：决定读取哪些块所花的时间，不应超过不读取所有块所节省的时间。这一原则体现在三个地方：块主序预填充、精简的解码索引器分数内核，以及在注意力路径周围融合小型逐元素或缓存写入内核。

KV 块主序预填充

在预填充期间，许多查询 token 可能选择同一个 KV 块。朴素的查询主序稀疏注意力内核会反复将同一个 KV 块从 HBM 移动到片上内存。块稀疏结构为我们提供了更好的调度：围绕 KV 块组织工作，然后处理需要每个块的所有查询。

MiniMax-AI/MSA 的 CuTe/SM100 路径通过构建 K 到 Q 的 CSR 映射、运行块主序稀疏注意力内核，并使用对数求和指数归约来组合部分输出来实现这一点。这提高了长提示和长缓存上下文常见的智能体流量的算术强度。

Figure 5: KV-block-major prefill reuses selected KV blocks across queries, reducing redundant memory movement before the final LSE reduction.
图 5：KV 块主序预填充在查询之间复用选定的 KV 块，减少最终 LSE 归约前的冗余内存移动。

解码索引器分数内核

在解码中，索引器位于每个生成 token 的关键路径上。引擎必须将查询侧索引向量与候选键侧索引向量进行比较，将每个 128 token 块归约为一个分数，应用局部窗口处理，并仅保留用于稀疏 GQA 的顶部块。

优化的解码路径使用专门的索引器分数内核，而不是将问题视为填充的密集 GEMM。这避免了在参差不齐的每请求块范围周围增加额外工作，并使 top-k 边界靠近分数计算。

解码路径还必须注意内存流量。选定的 KV 块在逻辑序列空间中是稀疏的，但在内存中仍然是页状的，因此内核应避免将稀疏页转换为大型临时密集张量，除非复用足以证明其合理性。

解码内核中的推测解码

EAGLE3 支持还要求 MiniMax M3 解码内核高效处理推测验证。在推测解码中，一个请求可以同时验证多个草稿 token，因此 MSA 解码内核不能假设每个请求恰好有一个查询 token。

一种回退方案是使用 prefill kernel 进行投机验证，但代价很高：prefill kernel 通常针对大得多的 token 数量进行调优，因此在小的 draft-token 批次上表现不佳。它们通常也不兼容完整的 CUDA graph 模式，而后者是低延迟解码的一项重要优化。

day-0 实现更新了 MSA decode indexer、top-k 选择以及稀疏 GQA decode kernel，以支持统一的 decode_query_len。这些 kernel 按 request-major 顺序展平投机验证 token，然后将每个 query token 映射回正确的请求元数据、序列长度、block table 和因果位置。这使得 EAGLE3 验证可以使用 decode 专用的 split-K 路径，而不是回退到针对性较弱的 prefill 风格路径，同时让投机路径与现有 decode 实现保持接近。

同一路径支持对统一投机解码批次的完整 CUDA graph 覆盖。kernel 启动网格保持形状稳定，所选参数避免不必要的 Triton 特化，填充的请求行被显式处理，以便捕获的 graph 可以安全重放。这些细节很重要，因为只有当 draft-token 接受率不被额外的 kernel 启动、重新编译或缓存状态开销所抵消时，投机解码才能改善 TPOT。我们预计会继续针对不同的 draft 长度、并发水平和流量组合优化这条路径。

Kernel 融合

若干较小的 kernel 被融合或通过自定义 op 路由，以减少启动开销和 HBM 往返：

  • QKNorm + RoPE + KV insert：为 MSA 路径组合了归一化、位置编码和缓存写入。
  • GemmaNorm 和 AllReduce + Norm 工作：减少张量并行执行中归一化周围的开销。
  • 量化路径清理：改进 silu_mul_quant_fp8 以及相关的 MXFP8/MoE 输入路径。
  • Router 和 MoE kernel：减少稀疏专家路径中的开销，并为更深入的 TRTLLM-Gen 集成做准备。

发布路径有意保持保守：在 day 0，正确性和稳定的缓存行为优先于启用所有可能的 graph 或融合开关。随着公开 recipe 成熟，更激进的融合可以逐步落地。

量化与 KV Cache 数据类型

MXFP8 checkpoint 主要改变权重和 MoE 执行，而非 KV cache 的概念结构。公开 recipe 应分别说明模型 dtype、MoE 后端和 KV-cache 策略：“MXFP8 模型”并不自动意味着每个 cache 和中间张量都是 MXFP8。路线图包含 FP8 indexer 和 KV-cache 路径，因为 KV 容量直接决定部署能够服务多少长上下文和批量流量。

CUDA Graph 与编译行为

CUDA graph 对 decode 很有价值，因为 M3 在每个 token 步骤周围引入了若干小操作。但 graph 捕获只有在捕获路径在批次形状、缓存状态和稀疏元数据之间保持稳定时才有帮助。day-0 路径在需要时使用保守的 graph 设置，然后随着验证成熟扩大覆盖范围。

验证

在公开发布之前，vLLM 团队每天在准确性、吞吐量、投机解码和容器可用性方面运行验证。

验证循环有三个目标：

  1. 功能正确性：模型能够加载、服务请求、解析工具和推理输出，并处理纯文本加多模态输入。
  2. 精度一致性：在内核、缓存、解析器和配方变更后，基准测试结果仍与预期模型行为保持一致。
  3. 服务就绪：容器镜像在目标加速器上以预期的 TP/EP/推测解码设置运行。

最有用的测试将短正确性任务与长输出和长上下文工作负载相结合。短任务能快速捕获解析器、格式化和明显的数值问题。长上下文任务能捕获 MSA 元数据、前缀缓存、分块预填充和 KV 缓存布局问题。推测解码测试能捕获普通精度运行中可能不会出现的接受率回归。

来自该验证的代表性快照，在 B300 上测得：

维度结果
GSM8K 严格 / 灵活准确率91.51% / 91.66%
ShareGPT @256 吞吐量8,530 tok/s
ShareGPT @256 TPOT56.0 ms
推测 Sonnet TPOT，并发 1 / 16 / 644.51 / 9.04 / 14.36 ms
Sonnet 上的推测接受率~67%，平均接受长度 ~3.0

这些是工程验证测量值，并非官方基准排名；确切结果因镜像版本、权重、配方和硬件而异。

Figure 6: Release-candidate validation checks accuracy, throughput, and speculative decoding before public MiniMax M3 recipes are published.
图 6：在公开发布 MiniMax M3 配方之前，候选发布验证会检查准确率、吞吐量和推测解码。

超越服务：使用 NeMo RL 进行 RL 后训练

Day-0 支持不仅仅关乎推理服务。强化学习框架使用 vLLM 作为生成引擎，在训练循环内产生 rollout，因此为 vLLM PR #45381 中服务提供支持的同一 MiniMax M3 工作，也使 M3 后训练在 day 0 成为可能。

NVIDIA NeMo RL 现在以 vLLM 作为非共置生成后端运行 MiniMax M3。短 GRPO（Group Relative Policy Optimization）后训练运行已在 BF16 检查点上验证，使用 NeMo AutoModel 配合专家并行和 BF16 vLLM 生成。长期收敛和专家并行之外的并行策略仍在验证中，但早期结果显示了坚实服务路径的价值：服务 M3 的引擎也是驱动 RL 训练 rollout 阶段的引擎。NeMo RL MiniMax M3 指南 中有参考配方。

路线图：前路

day-0 实现只是起跑线。接下来的工作已经在进行中：

  • FP8 索引器和 KV 缓存路径：在保持稀疏注意力准确率的同时，降低 KV 缓存内存压力并提高批处理容量。
  • TRTLLM-Gen MoE：提升 MXFP8 专家执行的 Blackwell 性能。
  • 上下文并行：当单节点不够时，改善超长上下文预填充的扩展性。
  • 分离式服务：扩展 NIXL 和预填充/解码分离配方以应对 M3 流量，基于 Large-Scale Serving with vLLM 中的方向。
  • 内核融合：减少 MSA 引入的众多小型索引器、top-k、量化和归一化内核。
  • 多模态网关路径：将图像和视频预处理排除在关键 GPU 生成循环之外。

MiniMax M3 vLLM 常见问题

vLLM 支持 MiniMax M3 吗？

是的。本文介绍了 vLLM 对 MiniMax M3 BF16 和 MXFP8 检查点的 day-0 支持，包括 MSA 注意力、模型特定解析器、EAGLE3 推测解码、多模态预处理、TP/EP 服务配方以及可用的 Docker 镜像。

什么是 MiniMax Sparse Attention？

MiniMax 稀疏注意力对固定的 128 token KV 块进行评分，为每个查询和 GQA 组选择最相关的块，应用配置的局部窗口规则，并在所选集合上运行稀疏 GQA。在当前的 M3 方案中，这对应于 init_blocks=0 和 local_blocks=1。

MXFP8 是否意味着 KV 缓存是 MXFP8？

不是。MXFP8 描述的是模型权重和 MoE 执行路径。KV 缓存 dtype 是独立的服务决策；当前的稀疏注意力验证将原生 KV 存储和量化 KV 缓存支持视为独立的路线图工作。

对于 1M token 上下文，哪些设置最重要？

重要的起点是 --block-size 128、为所选批次和上下文形状提供足够的 GPU 内存，以及一个说明是否启用了前缀缓存、分块预填充和 EAGLE3 投机解码的方案。默认情况下，vLLM 从模型配置中读取上下文长度，因此你不需要设置 --max-model-len。如果你的 GPU 内存有限或不需要完整的 1M token 窗口，可以传入 --max-model-len 将其上限调低，以减少 KV 缓存压力。

致谢

我们要感谢 MiniMax 团队开源 MiniMax-M3，以及 MiniMax 领导层对 vLLM 的信任和支持！模型支持由 Inferact Inc. 主导，该公司致力于将 vLLM 发展为全球 AI 推理引擎，并通过让推理更便宜、更快速来加速 AI 进步。NVIDIA 和 AMD 为硬件支持做出了贡献。

MiniMax M3 建立在 vLLM 的几个领域之上：

来源：vLLM Blog · vllm.ai

MiniMax开源生态部署工程产品更新#产品更新#部署/工程#开源/仓库