MiniMax M3 x vLLM：百万 token 多模态推理的 Day-0 部署

我们很高兴地宣布 vLLM 对 MiniMax M3 系列的 Day-0 支持，包括 MiniMaxAI/MiniMax-M3^[1] 和 MiniMaxAI/MiniMax-M3-MXFP8^[2] 的 BF16 与 MXFP8 checkpoint。

MiniMax M3 面向的正是生产环境中正变得常态化的负载：百万 token 上下文、原生多模态推理、coding 与 agent 工作流、工具调用，以及可控的 thinking 行为。难的不只是把模型加载起来，而是让全新的 MiniMax 稀疏注意力路径、多模态预处理、MXFP8 MoE 执行、EAGLE3 投机解码、prefix caching 和部署 recipe 在一个用户真正能跑起来的推理引擎里协同工作。

本文将依次介绍模型特性、vLLM 的实现、这次发布背后的 kernel 与缓存工作，以及 Day-0 之后我们正在落地的下一批优化。

MiniMax M3 的 Day-0 支持把长上下文、多模态、稀疏注意力的服务能力带进了 vLLM。

vLLM 为 MiniMax M3 提供初始 Day-0 支持：

• • 模型系列： BF16 与 MXFP8 两个 MiniMax M3 checkpoint，支持 1M token 上下文（受硬件容量与部署配置约束）。
• 
  
• • 核心架构： MiniMax 稀疏注意力（MSA），一种稠密/稀疏混合的注意力设计：对 128 token 的 KV 块打分，按 query 和 KV group 选出 top 块，再在选中的块上做 GQA 注意力。
• 
  
• • 服务栈：minimax_m3 工具与 reasoning 解析器、thinking 模式控制、纯文本与多模态路径、TP/EP 部署、prefix caching、chunked prefill、EAGLE3 投机解码，以及一个开箱可用的 Docker 镜像。
• 
  
• • 投机解码： Day-0 EAGLE3 支持，draft 模型发布在 Inferact/MiniMax-M3-EAGLE3^[3]。
• 
  
• • RL 后训练： NVIDIA NeMo RL^[4] 中对 MiniMax M3 的 Day-0 GRPO 后训练，以 vLLM 作为生成后端。
• 
  
• • 性能工作： MSA prefill 与 decode kernel、indexer-score 与 top-k kernel、融合的 QKNorm + RoPE + KV 写入、GemmaNorm 与量化路径优化，以及 MXFP8 MoE 后端集成。
• 
  
• • 路线图： FP8 indexer/KV-cache 工作、TRTLLM-Gen MoE、更广的 disaggregated serving recipe、context-parallel 长 prefill 工作，以及进一步的多模态 gateway 优化。
• 
  

在 NVIDIA 上，MSA 使用默认的注意力后端，vision encoder 跑在 FlashInfer 后端（--mm-encoder-attn-backend FLASHINFER）上，配合共享内存 processor cache 和数据并行 encoder。

在 Blackwell 级节点上跑 MXFP8 checkpoint，起点是：

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

具体 recipe 取决于目标加速器、模型 dtype、上下文长度、流量形态，以及部署优先考虑吞吐、延迟还是最大上下文容量。验证已在 NVIDIA H200、GB200 和 B300 上完成。完整的 NVIDIA 与 AMD 启动 recipe、部署策略和调优旋钮，见 vLLM 的 MiniMax M3 recipe^[5]。

AMD ROCm

MiniMax M3 可以在 AMD Instinct GPU 上运行。MSA 跑在 Triton 注意力后端上，因此 AMD 部署需加上 --attention-backend TRITON_ATTN；vision encoder 使用 AITER FlashAttention 后端（--mm-encoder-attn-backend ROCM_AITER_FA），配合共享内存 processor cache 和数据并行 encoder。

MXFP8 checkpoint：

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 12 让 vLLM 的缓存块与 MSA 的稀疏块粒度对齐。--max-model-len 控制对外宣告的上下文长度与 KV 容量规划。--tensor-parallel-size 和 --enable-expert-parallel 决定注意力、投影和 MoE 专家如何在多 GPU 间切分。agent 负载应启用 minimax_m3 工具与 reasoning 解析器，长上下文 recipe 应说明该目标下是否启用了 prefix caching、chunked prefill、EAGLE3 投机解码和多模态预处理。

EAGLE3 投机解码

MiniMax M3 在 vLLM 中还有 Day-0 的 EAGLE3 投机解码支持。draft 模型发布在 Inferact/MiniMax-M3-EAGLE3^[3]，当负载与接受率行为契合目标流量时，部署可以走 draft 模型路径以获得更低的生成延迟。

要启用 EAGLE3，在部署命令里加上一段投机解码配置：

示例使用 num_speculative_tokens=3，这是一个用于验证的保守起点。生产 recipe 应针对部署流量组合下的接受率、TPOT、吞吐和目标延迟来调这个值。

Thinking 模式

MiniMax M3 暴露了可控的 thinking 行为。在 vLLM 中，通过 chat_template_kwargs 传入模式：

MiniMax M3 对推理系统的意义体现在三个方向。

借助 MiniMax 稀疏注意力的 1M token 上下文

最核心的架构变化是 MiniMax 稀疏注意力（MSA）。MSA 不让每个 query 都对完整 KV cache 做稠密注意力，而是用一条 index 路径给 KV 块打分，为真正的注意力计算挑出最相关的块。默认粒度是 128 token 的 KV 块，选中的块在一个 GQA group 内共享。

具体来说，每个 query token 走三步：

• 1. 用一个小的 index head 给候选 KV 块打分。
• 
  
• 2. 选出 top 块，同时应用配置好的块规则。
• 
  
• 3. 仅在选中的 KV 块上做 online-softmax 注意力。
  
  

这既保留了用户期待的长上下文行为，又把每个生成 token 的注意力计算量约束住了。实际上，MiniMax 稀疏注意力正是让 MiniMax M3 的 1M token 上下文在 vLLM 服务中变得可行的机制。

MSA 机制细节

MSA 把两个问题分开：哪些过去的块值得读，以及如何在这些块上做注意力。index 路径回答第一个问题——给固定的 128 token KV 块打分。稀疏 GQA 路径回答第二个问题——在选中的块上做注意力。

选中的集合不只是学习得到的 top-k。M3 配置暴露了 init_blocks / sparse_init_block 和 local_blocks / sparse_local_block，但当前 recipe 使用 init_blocks=0、local_blocks=1。实践中，确定性规则是 query token 附近的局部窗口块，其余选中的块来自 indexer 打分的 top-k 选择。正确性取决于一些细节：不完整的末尾块必须被 mask，块内的因果边界必须被尊重，同时进入 top-k 的局部块不能被重复计入，批处理请求可能有不同的有效块范围。

原生多模态

MiniMax M3 是一个多模态模型，而不是一个外挂 sidecar 的纯文本 checkpoint。服务路径必须处理图像和视频输入，把它们预处理成 patch tensor，保留 grid 元数据，并把结果交给模型，同时不抢占生成所需的 GPU 时间。

对 vLLM 部署而言，这次发布工作包含模型专属的多模态预处理与解析器支持，让用户可以通过同一个服务接口跑纯文本、工具调用、reasoning 和多模态负载。

MXFP8 MoE 权重

MXFP8 checkpoint 是为高效大规模服务设计的。验证使用了面向 Blackwell 级系统的 DeepGEMM MXFP8 MoE 后端，以及面向 Hopper 级系统的 Marlin MXFP8。

MiniMax M3 是一个混合模型：部分层走稠密注意力，稀疏层则路由到 MiniMax MSA 后端。vLLM 把这个区分藏在模型与注意力后端之内，因此调度器、缓存分配、批处理、prefix caching 和服务从外部看依然是熟悉的样子。对不熟悉这些内部机制的读者，Anatomy of vLLM^[6] 是这一节很好的伴读。

MiniMax 稀疏注意力后端

MSA 后端有两项独立职责。

第一，计算稀疏元数据。indexer 给 KV 块打分，应用配置好的块选择规则，输出 top-k 块 ID。对 M3 而言，选择是基于块的：稀疏的单位就是缓存管理器已经理解的、page 一样的 128 token 块。

第二，在这些块上计算注意力。prefill 和 decode 的形状不同，因此 vLLM 使用专门的 kernel：

• • Prefill indexer-score： Triton kernel 计算块得分和 top-k 块选择。
• 
  
• • Prefill 稀疏 GQA： Triton 和 MiniMax-AI/MSA^[7] 的 CuTe/SM100 路径支持块稀疏 GQA 注意力。CuTe 路径把 query 到块的映射反转成 K-major 的 CSR 形式，从而高效复用 KV 块。
• 
  
• • Decode indexer-score： split 风格的 decode kernel 扫描候选块、打分并合并 top-k 结果。
• 
  
• • Decode 稀疏 GQA： GQA decode kernel 消费选中的块 page，并合并部分注意力输出。
• 
  

Prefill 执行

prefill 处理 prompt 并创建 KV cache。对 M3 而言，prompt 长度和稀疏元数据都很重要。这条路径在概念上有四个阶段：

1. 1. 构建 query、key、value 和 index 投影。 稠密投影产出 indexer 和注意力 kernel 所需的表示。
2. 
   
3. 2. 给块打分。 index 路径为每个候选 KV 块计算得分。打分归约可以使用块级规则，如 max 或 log-sum-exp，取决于模型配置。
4. 
   
5. 3. 选块。 top-k 选择把学习到的块得分与配置好的块规则结合，再为每个 query 和 KV group 输出块 ID。
6. 
   
7. 4. 跑稀疏 GQA。 注意力 kernel 只读取选中的 KV 块，计算出与"限制在该选中集合上的稠密注意力"相同的 online-softmax 注意力结果。
8. 
   

最后的稀疏 GQA 工作有两种有用的调度方式。query-major 调度很直接：每个 query 遍历自己选中的 KV 块。KV-block-major 调度在长 prompt 且很多 query 选中同一个块时更好。在该调度下，vLLM 构建一个 K-to-Q 映射，这样一个 KV 块可以加载一次后在输出合并前被很多 query 复用。

Decode 执行

decode 的形状不同。每一步通常为每个活跃序列处理一个新 token，但一个 batch 中可以包含很多上下文长度不同的序列。runtime 更新缓存状态、给候选块打分、应用局部窗口处理、选出 top 块、跑稀疏 GQA decode，并在 kernel 使用 split 工作时合并部分输出。由于这在每个生成 token 上都发生，indexer-score 和 top-k kernel 是 TPOT 的一部分，而不只是 setup 开销。

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

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

MiniMax M3 可以把 KV 当作普通的 paged KV 存储，并在计算路径上施加稀疏性。这让 vLLM 在保持缓存管理器简单的同时，又给了 kernel 所需的灵活度：

• • 主注意力 KV cache 与 indexer K cache 都被显式追踪。
• 
  
• • 一旦该 recipe 的缓存状态交互被验证，prefix caching 和 chunked prefill 就能继续使用稳定的缓存块。
• 
  
• • 相关的 disaggregated-serving 和 NIXL 风格的传输路径，可以把缓存当作 paged state 处理，而由注意力后端负责稀疏选择。
• 
  

Prefix Caching 与 Chunked Prefill

prefix caching 重要，是因为 M3 负载经常复用长 prompt：代码库、文档、多轮 agent trace 和多模态上下文。chunked prefill 重要，是因为一个 1M token 请求不应该作为一个巨大的 prefill 独占整个引擎。两者合起来是发布就绪度的压力测试：index 缓存状态、主注意力 KV 状态、稠密注意力状态、prefix 命中、抢占、批处理和长上下文 chunk 边界，都必须在同一份 block table 上达成一致，一个 recipe 才应被视为生产就绪。

多模态与解析器集成

MiniMax M3 包含针对工具、reasoning 和多模态输入的模型专属解析行为。vLLM 支持包括：

• • --tool-call-parser minimax_m3，用于工具调用格式化。
• 
  
• • --reasoning-parser minimax_m3，用于 reasoning 输出提取。
• 
  
• • 对 thinking_mode 的 chat template 支持。
• 
  
• • 面向图像和视频输入的多模态预处理集成。
• 
  

对生产部署而言，预处理最好尽可能在 GPU 执行之前完成。目标架构是一个 gateway：下载媒体、解码帧、采样视频、缩放并归一化图像、创建 patch tensor，再把可直接运行的 tensor 传给 worker。

这一点重要，是因为多模态请求在 API 边界上看着小，预处理后却可能很大。一段视频可能需要帧采样、逐帧缩放、patch 生成和元数据打包。把 CPU 密集的媒体工作放在上游，能让 GPU 调度更容易推理。

解析器一侧对 agent 流量同样重要。工具调用与 reasoning 解析器把模型专属的文本约定转换成结构化的 API 响应。没有正确的解析器，模型可能生成有用却难以被应用消费的文本。

 

性能优化

MiniMax M3 改变了瓶颈所在。MSA 减少了稠密注意力的工作量，但引入了 indexer-score 工作、块选择、稀疏元数据构建和额外的小 kernel。vLLM 的 Day-0 实现专注于让这些新增部分保持廉价。

指导原则很简单：决定读哪些块所花的时间，不应该超过不读全部块所省下的时间。这一原则体现在三处：block-major prefill、精简的 decode indexer-score kernel，以及围绕注意力路径融合小的逐元素或缓存写入 kernel。

KV-Block-Major Prefill

在 prefill 阶段，很多 query token 可能选中同一个 KV 块。一个朴素的 query-major 稀疏注意力 kernel 会反复把同一个 KV 块从 HBM 搬到片上内存。块稀疏结构给了我们一个更好的调度：围绕 KV 块组织工作，然后处理所有需要每个块的 query。

MiniMax-AI/MSA^[7] 的 CuTe/SM100 路径正是这样做的：构建 K-to-Q 的 CSR 映射、跑一个 block-major 稀疏注意力 kernel，并用 log-sum-exp 归约来合并部分输出。这提升了长 prompt 和 agent 流量（长缓存上下文常见）的算术强度。

Decode Indexer-Score Kernel

在 decode 阶段，indexer 对每个生成 token 都在关键路径上。引擎必须把 query 侧的 index 向量与候选 key 侧的 index 向量比对，把每个 128 token 块归约成一个得分，应用局部窗口处理，并只保留 top 块供稀疏 GQA 使用。

优化后的 decode 路径使用专门的 indexer-score kernel，而不是把问题当作一个 padding 过的稠密 GEMM。这避免了围绕参差不齐的 per-request 块范围增加额外工作，并让 top-k 边界紧贴得分计算。

decode 路径也必须留意内存流量。选中的 KV 块在逻辑序列空间里是稀疏的，但在内存里依然 page 一样，所以除非复用足以划算，kernel 应避免把稀疏 page 变成大的临时稠密 tensor。

Decode Kernel 中的投机解码

EAGLE3 支持还要求 MiniMax M3 的 decode kernel 高效处理投机验证。在投机解码中，一个请求可以一次验证多个 draft token，因此 MSA decode kernel 不能假设每个请求只有一个 query token。

一种 fallback 是用 prefill kernel 来做投机验证，但代价很高：prefill kernel 通常是为大得多的 token 数量调优的，在小的 draft-token batch 上表现很差。它们通常也不兼容 full CUDA graph 模式，而后者对低延迟 decoding 是一项重要优化。

Day-0 实现更新了 MSA 的 decode indexer、top-k 选择和稀疏 GQA decode kernel，以支持统一的 decode_query_len。这些 kernel 把投机验证 token 按 request-major 顺序展平，再把每个 query token 映射回正确的请求元数据、序列长度、block table 和因果位置。这让 EAGLE3 验证能用 decode 专用的 split-K 路径，而不必 fallback 到针对性更差的 prefill 风格路径，同时把投机路径保持在已有 decode 实现附近。

同一条路径支持对统一的投机 decode batch 做 full CUDA graph 覆盖。kernel launch grid 保持形状稳定，选中的参数避免不必要的 Triton 特化，padding 的请求行被显式处理，因此被捕获的图可以安全重放。这些细节之所以重要，是因为只有当 draft-token 接受带来的收益不被额外的 kernel launch、重编译或缓存状态开销抵消时，投机解码才能改善 TPOT。我们预计会在不同 draft 长度、并发水平和流量组合下持续优化这条路径。

Kernel 融合

几个较小的 kernel 被融合或改走自定义 op，以减少 launch 开销和 HBM 往返：

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

发布路径有意保守：在 Day-0 上，正确性与稳定的缓存行为胜过启用每一个可能的图或融合旋钮。随着公开 recipe 成熟，更激进的融合可以陆续落地。

量化与 KV Cache Dtype

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

CUDA Graph 与编译行为

CUDA graph 对 decode 很有价值，因为 M3 在每个 token 步骤前后引入了若干小操作。但只有在被捕获的路径在不同 batch 形状、缓存状态和稀疏元数据下都稳定时，图捕获才有帮助。Day-0 路径在需要时使用保守的图设置，再随着验证成熟而扩大覆盖范围。

在公开发布前，vLLM 团队每天就准确率、吞吐、投机解码和容器可用性做验证。

验证循环有三个目标：

1. 1. 功能正确性： 模型能加载、能服务请求、能解析工具与 reasoning 输出，并能处理纯文本加多模态输入。
2. 
   
3. 2. 准确率持平： 在 kernel、缓存、解析器和 recipe 改动后，benchmark 结果与预期的模型行为保持一致。
4. 
   
5. 3. 服务就绪度： 容器镜像能以预期的 TP/EP/投机解码设置在目标加速器上运行。
6. 
   

最有用的测试把短的正确性任务与长输出、长上下文负载组合起来。短任务能快速捕获解析器、格式和明显的数值问题。长上下文任务能捕获 MSA 元数据、prefix caching、chunked prefill 和 KV-cache 布局问题。投机解码测试能捕获那些在普通准确率跑测中可能不显现的接受率回退。

这次验证中的一份代表性快照，在 B300 上测得：

这些是工程验证测量，而非官方 benchmark 排名；具体结果会随镜像版本、权重、recipe 和硬件而变化。

不止服务：用 NeMo RL 做 RL 后训练

Day-0 支持不只关乎推理服务。强化学习框架把 vLLM 当作训练循环中产出 rollout 的生成引擎，因此在 vLLM PR #45381^[8] 中为服务提供动力的同一份 MiniMax M3 工作，也让 M3 的后训练在 Day-0 就成为可能。

NVIDIA NeMo RL^[4] 现在以 vLLM 作为非共置（non-colocated）的生成后端来跑 MiniMax M3。短时 GRPO（Group Relative Policy Optimization）后训练已在 BF16 checkpoint 上验证，使用 NeMo AutoModel 配合专家并行和 BF16 vLLM 生成。长跑收敛以及专家并行之外的并行策略仍在验证中，但早期结果说明了一条扎实的服务路径的价值：服务 M3 的引擎，也正是驱动 RL 训练 rollout 阶段的那一个。参考 recipe 见 NeMo RL MiniMax M3 指南^[9]。

Day-0 实现只是起跑线。下一批工作已经在路上：

• 
  
• • FP8 indexer 与 KV-cache 路径： 在保持稀疏注意力准确率的同时，降低 KV-cache 内存压力、提升 batch 容量。
• 
  
• • TRTLLM-Gen MoE： 改善 Blackwell 上 MXFP8 专家执行的性能。
• 
  
• • Context 并行： 当单节点不够时，改善超长上下文 prefill 的扩展性。
• 
  
• • Disaggregated serving： 为 M3 流量扩展 NIXL 和 prefill/decode disaggregation recipe，基于 Large-Scale Serving with vLLM^[10] 中的方向。
• 
  
• • Kernel 融合： 减少 MSA 引入的众多小的 indexer、top-k、量化和归一化 kernel。
• 
  
• • 多模态 gateway 路径： 把图像与视频预处理保持在关键的 GPU 生成循环之外。

vLLM 支持 MiniMax M3 吗？

支持。本文覆盖了 vLLM 对 MiniMax M3 BF16 与 MXFP8 checkpoint 的 Day-0 支持，包括 MSA 注意力、模型专属解析器、EAGLE3 投机解码、多模态预处理、TP/EP 服务 recipe，以及一个开箱可用的 Docker 镜像。

什么是 MiniMax 稀疏注意力？

MiniMax 稀疏注意力给固定的 128 token KV 块打分，为每个 query 和 GQA group 选出最相关的块，应用配置好的局部窗口规则，再在该选中集合上做稀疏 GQA。在当前 M3 recipe 中，这对应 init_blocks=0、local_blocks=1。

MXFP8 是否意味着 KV cache 也是 MXFP8？

不是。MXFP8 描述的是模型权重与 MoE 执行路径。KV-cache dtype 是一个独立的服务决策；当前的稀疏注意力验证把原生 KV 存储与量化 KV-cache 支持当作各自独立的路线图工作。

对 1M token 上下文最重要的设置是什么？

重要的起点是 --block-size 128、为所选 batch 与上下文形状准备足够的 GPU 内存，以及一个说明了是否启用 prefix caching、chunked prefill 和 EAGLE3 投机解码的 recipe。默认情况下 vLLM 会从 model config 读取上下文长度，因此你不需要设置 --max-model-len。如果 GPU 内存有限，或不需要完整的 1M token 窗口，可以传入 --max-model-len 把它压低，以减少 KV-cache 压力。

我们要感谢 MiniMax 团队开源 MiniMax-M3，也感谢 MiniMax 管理层对 vLLM 的信任与支持！本次模型支持由 Inferact Inc. 主导——这是一家致力于把 vLLM 发展为世界级 AI 推理引擎、通过让推理更便宜更快来加速 AI 进步的公司。NVIDIA 和 AMD 为硬件支持做出了贡献。

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

• • Anatomy of vLLM^[6]，了解调度器、KV cache、prefix caching 和分布式执行背景。
• 
  
• • Speculative Decoding in vLLM^[11] 和 P-EAGLE^[12]，了解 draft 模型路径。
• 
  
• • Large-Scale Serving with vLLM^[10]、KV Offloading Connector^[13] 和 Moriio KV Connector^[14]，了解 prefix 复用、KV 搬运和 disaggregated serving。
• 
  
• • NeMo RL：MiniMax M3 指南^[9]，了解以 vLLM 作为生成后端的 GRPO RL 后训练。

1. 1. MiniMaxAI/MiniMax-M3 — huggingface.co/MiniMaxAI/MiniMax-M3
2. 2. MiniMaxAI/MiniMax-M3-MXFP8 — huggingface.co/MiniMaxAI/MiniMax-M3-MXFP8
3. 3. Inferact/MiniMax-M3-EAGLE3 — huggingface.co/Inferact/MiniMax-M3-EAGLE3
4. 4. NVIDIA NeMo RL — github.com/NVIDIA-NeMo/RL
5. 5. vLLM MiniMax M3 recipe — recipes.vllm.ai/MiniMaxAI/MiniMax-M3
6. 6. Anatomy of vLLM — vllm.ai/blog/2025-09-05-anatomy-of-vllm
7. 7. MiniMax-AI/MSA — github.com/MiniMax-AI/MSA
8. 8. vLLM PR #45381 — github.com/vllm-project/vllm/pull/45381
9. 9. NeMo RL MiniMax M3 指南 — github.com/NVIDIA-NeMo/RL/blob/minimax-m3/docs/guides/minimax-m3.md
10. 10. Large-Scale Serving with vLLM — vllm.ai/blog/2025-12-17-large-scale-serving
11. 11. Speculative Decoding in vLLM — vllm.ai/blog/2024-10-17-spec-decode
12. 12. P-EAGLE — vllm.ai/blog/2026-03-13-p-eagle
13. 13. KV Offloading Connector — vllm.ai/blog/2026-01-08-kv-offloading-connector
14. 14. Moriio KV Connector — vllm.ai/blog/2026-04-07-moriio-kv-connector

 vLLM 官方博客

vllm.ai/blog/2026-06-12-minimax-m3-vllm