MiniMax M3 接入 vLLM：百万 Token 多模态推理的 Day-0 服务

我们很高兴地宣布 vLLM 对 MiniMax M3 系列提供 day-0 支持，包括位于 MiniMaxAI/MiniMax-M3 和 MiniMaxAI/MiniMax-M3-MXFP8 的 BF16 和 MXFP8 检查点。

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

本文将介绍模型特性、vLLM 实现、发布背后的 kernel 和缓存工作，以及我们在 day-0 之后即将推出的下一轮优化。

图 1：MiniMax M3 day-0 支持为 vLLM 带来了长上下文、多模态、稀疏 attention 的 serving 能力。

TL;DR

vLLM 为 MiniMax M3 提供了初始的 day-0 支持：

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

MiniMax M3 支持矩阵

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

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

在 NVIDIA 上，MSA 使用默认的 attention 后端，视觉编码器在 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 启动方案、部署策略和调优参数，请参阅 vLLM recipe for MiniMax M3。

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 expert 如何在 GPU 之间拆分。对于 agent 工作负载，应启用 minimax_m3 工具和推理解析器，并且长上下文方案应说明是否为目标启用了前缀缓存、分块预填充、EAGLE3 推测解码和多模态预处理。

EAGLE3 推测解码

MiniMax M3 在 vLLM 中也具有 day-0 的 EAGLE3 推测解码支持。草稿模型发布在 Inferact/MiniMax-M3-EAGLE3，当工作负载和接受行为适合目标流量时，部署可以使用草稿模型路径来降低生成延迟。

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

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": "解释 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 在三个方向上对推理系统具有重要意义。

具有 MiniMax Sparse Attention 的 100 万 Token 上下文

核心架构变化是 MiniMax Sparse Attention (MSA)。MSA 并非让每个 query 密集地关注整个 KV 缓存，而是使用索引路径对 KV 块进行评分，并为实际的 attention 计算选择最相关的块。默认粒度为 128 token 的 KV 块，所选块在 GQA 组内共享。

实际上，每个 query token 遵循三个步骤：

1. 使用一个小型索引头对候选 KV 块进行评分。
2. 选择 top 块，同时应用配置的块规则。
3. 仅对这些选定的 KV 块运行 online-softmax attention。

这保留了用户期望的长上下文行为，同时限制了每个生成 token 的 attention 工作量。实际上，MiniMax Sparse Attention 是使 MiniMax M3 的 100 万 token 上下文对 vLLM serving 切实可行的机制。

图 2：MiniMax Sparse Attention 在从 100 万 token 历史中选择稀疏的 128 token KV 块时，保持本地和全局上下文可用。

MSA 机制详解

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

选定的集合不仅仅是学习到的 top-k。M3 配置暴露了 init_blocks / sparse_init_block 和 local_blocks / sparse_local_block，但当前方案使用 init_blocks=0 和 local_blocks=1。实际上，确定性规则是 query token 附近的本地窗口块，而其余选定的块来自索引器评分的 top-k 选择。正确性取决于细节：必须屏蔽不完整的最终块，必须尊重块内的因果边界，同时排名在 top-k 中的本地块不得重复计数，并且批处理请求可以具有不同的有效块范围。

原生多模态

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

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

MXFP8 MoE 权重

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

vLLM 实现

MiniMax M3 是一个混合模型：某些层路由到密集 attention，而稀疏层路由到 MiniMax MSA 后端。vLLM 将此区别保留在模型和 attention 后端之后，因此调度器、缓存分配、批处理、前缀缓存和 serving 从外部看仍然熟悉。对于不熟悉这些内部机制的读者，Anatomy of vLLM 是本节的良好伴侣。

MiniMax Sparse Attention 后端

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

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

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

• 预填充索引器评分： Triton kernel 计算块分数和 top-k 块选择。
• 预填充稀疏 GQA： Triton 和 MiniMax-AI/MSA CuTe/SM100 路径支持块稀疏 GQA attention。CuTe 路径将 query 到块的映射反转成 K-major CSR 形式，以便可以有效地重用 KV 块。
• 解码索引器评分： 拆分式解码 kernel 扫描候选块，对其进行评分，并合并 top-k 结果。
• 解码稀疏 GQA： GQA 解码 kernel 使用选定的块页面并合并部分 attention 输出。

预填充执行

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

1. 构建 query、key、value 和索引投影。 密集投影产生索引器和 attention kernel 所需的表示。
2. 对块进行评分。 索引路径为每个候选 KV 块计算一个分数。评分归约可以使用块级规则，例如 max 或 log-sum-exp，具体取决于模型配置。
3. 选择块。 Top-k 选择将学习到的块分数与配置的块规则相结合，然后为每个 query 和 KV 组发出块 ID。
4. 运行稀疏 GQA。 Attention kernel 仅读取选定的 KV 块，并计算与仅限于该选定集的密集 attention 传递相同的 online-softmax attention 结果。

对于最终的稀疏 GQA 工作，有两种有用的调度方式。Query-major 调度很直接：每个 query 遍历其选定的 KV 块。当许多 query 选择同一个块时，KV-block-major 调度对于长 prompt 更好。在这种调度中，vLLM 构建一个 K 到 Q 的映射，以便可以在输出合并之前跨多个 query 加载和重用同一个 KV 块。

解码执行

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

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

图 3：vLLM 将密集层路由到标准 attention，将稀疏层路由到 MiniMax MSA 后端。

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

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

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

前缀缓存和分块预填充

前缀缓存很重要，因为 M3 工作负载经常重用长 prompt：代码库、文档、多轮 agent 轨迹和多模态上下文。分块预填充很重要，因为一个 100 万 token 的请求不应作为一个巨大的预填充来独占引擎。它们共同构成了发布就绪的压力测试：索引缓存状态、主 attention KV 状态、密集 attention 状态、前缀命中、抢占、批处理、长上下文块边界，所有这些都需要在方案被视为生产就绪之前就相同的块表达成一致。

多模态和解析器集成

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

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

对于生产部署，预处理应尽可能在 GPU 执行之前处理。目标架构是一个网关，它下载媒体、解码帧、采样视频、调整图像大小和归一化、创建 patch 张量，并将即用型张量传递给 worker。

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

解析器方面对于 agent 流量同样重要。工具调用和推理解析器将模型特定的文本约定转换为结构化的 API 响应。没有正确的解析器，模型可以生成有用的文本，但应用程序难以使用。

图 4：对于 MiniMax M3，CPU 端的图像和视频预处理应将准备好的张量交给 vLLM worker，以便 GPU 时间保留给推理。

性能优化

MiniMax M3 改变了瓶颈。MSA 减少了密集 attention 工作，但引入了索引器评分工作、块选择、稀疏元数据构建以及其他小型 kernel。vLLM day-0 实现专注于保持这些新部分廉价。

指导原则很简单：不要花更多时间来决定读取哪些块，而不是通过不读取所有块来节省的时间。该原则体现在三个地方：块主预填充、精简的解码索引器评分 kernel，以及在 attention 路径周围融合小型逐元素或缓存写入 kernel。

KV-Block-Major 预填充

在预填充期间，许多 query token 可以选择相同的 KV 块。一个朴素的 query-major 稀疏 attention kernel 会重复地将相同的 KV 块从 HBM 移动到片上内存。块稀疏结构为我们提供了更好的调度：围绕 KV 块组织工作，然后处理需要每个块的所有 query。

MiniMax-AI/MSA CuTe/SM100 路径通过构建 K 到 Q 的 CSR 映射、运行块主稀疏 attention kernel 以及使用 log-sum-exp 归约来组合部分输出来实现这一点。这提高了长 prompt 和 agent 流量的算术强度，在这些场景中，长缓存上下文很常见。

图 5：KV-block-major 预填充跨 query 重用选定的 KV 块，在最终 LSE 归约之前减少冗余的内存移动。

解码索引器评分 Kernel

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

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

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

解码 Kernel 中的推测解码

EAGLE3 支持还需要 MiniMax M3 解码 kernel 有效地处理推测验证。在推测解码中，一个请求可以一次验证多个草稿 token，因此 MSA 解码 kernel 不能假设每个请求恰好有一个 query token。

一种回退方案是使用预填充 kernel 进行推测验证，但这会带来高昂的成本：预填充 kernel 通常针对更大的 token 数量进行调整，因此它们在小型草稿 token 批次上表现不佳。它们通常也不兼容完整的 CUDA graph 模式，而 CUDA graph 模式是低延迟解码的重要优化。

Day-0 实现更新了 MSA 解码索引器、top-k 选择和稀疏 GQA 解码 kernel，以支持统一的 decode_query_len。Kernel 以 request-major 顺序展平推测验证 token，然后将每个 query token 映射回正确的请求元数据、序列长度、块表和因果位置。这使得 EAGLE3 验证可以使用解码专用的 split-K 路径，而不是回退到针对性较差的预填充风格路径，同时使推测路径接近现有的解码实现。

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

Kernel 融合

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

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

发布路径有意保守：正确性和稳定的缓存行为优先于在 day-0 启用每个可能的 graph 或融合旋钮。随着公共方案的成熟，可以落地更激进的融合。

量化和 KV 缓存 Dtype

MXFP8 检查点主要改变权重和 MoE 执行，而不是 KV 缓存的概念结构。公共方案应分别说明模型 dtype、MoE 后端和 KV 缓存策略："MXFP8 模型"并不自动意味着每个缓存和中间张量都是 MXFP8。路线图包括 FP8 索引器和 KV 缓存路径，因为 KV 容量直接控制部署可以服务多少长上下文和批处理流量。

CUDA Graphs 和编译行为

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

验证

在公开发布之前，vLLM 团队在准确性、吞吐量、推测解码和容器可用性方面进行了每日验证。

验证循环有三个目标：

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

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

在 B300 上测量的验证代表性快照：

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

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

图 6：在发布公共 MiniMax M3 方案之前，候选发布验证会检查准确性、吞吐量和推测解码。

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

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

现在使用 vLLM 作为非共置生成后端运行 MiniMax M3。已在 BF16 检查点上验证了简短的 GRPO (Group Relative Policy Optimization) 后训练运行，使用了具有 expert 并行性的 NeMo AutoModel 和 BF16 vLLM 生成。超出 expert 并行的长期运行收敛和并行性策略仍在验证中，但早期结果显示了坚实的 serving 路径的价值：服务 M3 的引擎也是驱动 RL 训练 rollout 阶段的引擎。NeMo RL MiniMax M3 guide 提供了参考方案。

路线图：未来之路

Day-0 实现是起点。接下来的工作已经在进行中：

• FP8 索引器和 KV 缓存路径： 减少 KV 缓存内存压力并增加批次容量，同时保持稀疏 attention 准确性。
• TRTLLM-Gen MoE： 改善 MXFP8 expert 执行在 Blackwell 上的性能。
• 上下文并行： 改善当一个节点不足时的超长上下文预填充扩展。
• 分离式 serving： 扩展 M3 流量的 NIXL 和预填充/解码分离方案，基于 Large-Scale Serving with vLLM 中的方向。
• Kernel 融合： 减少 MSA 引入的许多小型索引器、top-k、量化和归一化 kernel。
• 多模态网关路径： 将图像和视频预处理排除在关键的 GPU 生成循环之外。

MiniMax M3 vLLM 常见问题解答

vLLM 是否支持 MiniMax M3？

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

什么是 MiniMax Sparse Attention？

MiniMax Sparse Attention 对固定的 128 token KV 块进行评分，为每个 query 和 GQA 组选择最相关的块，应用配置的本地窗口规则，并在该选定集上运行稀疏 GQA。在当前 M3 方案中，这对应于 init_blocks=0 和 local_blocks=1。

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

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

对于 100 万 token 上下文，哪些设置最重要？

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

致谢

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

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

• Anatomy of vLLM 提供了调度器、KV 缓存、前缀缓存和分布式执行的背景知识。
• Speculative Decoding in vLLM 和 P-EAGLE 提供了草稿模型路径的背景知识。
• Large-Scale Serving with vLLM、KV Offloading Connector 和 Moriio KV Connector 提供了前缀重用、KV 移动和分离式 serving 的背景知识。
• NeMo RL: MiniMax M3 guide 提供了使用 vLLM 作为生成后端的 GRPO RL 后训练的背景知识。