模型支持列表上新增一行，背后可能是缓存格式、反量化、专家执行、投机解码和通信布局一起变化。vLLM 对 MiniMax-M3.1-Flash 的首日支持文章，值得读的正是这种跨层组合：模型原生为 NVFP4 KV 训练，只解决了低精度可用性；要把省下的字节变成并发和速度，还需重新安排数据如何进入算子、如何跨 GPU 与跨节点移动。原文：vLLM Delivers Day-0 Support for MiniMax-M3.1-Flash。

MiniMax 10 月 19 日发布公告强调长流程 Agent 的性能与成本，并报告更激进的稀疏性。公告没有公开完整服务配置和架构；理解这些收益，需要结合下面的 vLLM 实现机制及对应测试条件。

Inferact and the vLLM Team · 2026-10-23

稀疏注意力仍有一次全局扫描

MiniMax Sparse Attention 以 128-token 块组织 KV。轻量 indexer 为上下文评分，按块取最高分，再让主注意力只访问选中的 16 块，并保留最近块。每个查询的主注意力因此限制在 2,048 个 key 左右，但 indexer 仍需扫描完整历史；长上下文的开销并未全部消失，而是由大规模 K/V 读取转为更轻的索引读取。

原文以 FP8 的四个 KV head、128 维为例，索引每 token 每层读 128 字节，相比稠密 K/V 的 1,024 字节小得多。这解释了为什么稀疏模式在带宽受限 decode 中更有价值，也说明 indexer 并行化值得单独优化。主注意力精确计算选中集合，不等于与完整稠密注意力在算法上相同。

NVFP4 省容量，但转换成本也要计算

新模型的路由专家采用 NVFP4，checkpoint 从 M3-MXFP8 的 451.5 GB 缩至 250.1 GB，减少 44.6%；KV 每 token 从 FP8 的 61,440 字节缩至 34,560 字节，减少 43.75%。在四张 B300、DEP4、256K 序列的容量比较中，可容纳并发序列由 28 增至 76，约 2.7 倍。这是特定配置的容量结果，不代表所有工作负载吞吐都会同倍增长。

Blackwell 路径的 query 仍为 FP8，因此内核需要先把 NVFP4 KV 转成 FP8 再做矩阵乘。专用指令把多值缩放转换合并，减少中间 FP16 往返；作者报告 indexer QK decode 内核最高加速 1.7 倍、稀疏注意力 decode 内核最高 1.3 倍。低精度存储带来的收益，必须扣除转换和调度成本后才成为服务收益。

少读数据，也少等待资源

专家执行方面，NVFP4 MegaMoE 提前释放 FC1 epilogue 已不需要的 Tensor Memory 阶段，使下一阶段不用等寄存器里的算术完成。文章报告该调整让 prefill 内核延迟下降 20%，整体 prefill 吞吐提高 7%。这两个数字属于不同层级，不能把内核收益直接写成端到端收益。

QKV projection、norm、RoPE 与 KV 插入又合成一个 GEMM 路径，减少完整中间张量写入 HBM 再读回。GB300、TP4 的报告中，相关 prefill 批次更快，中位 TTFT 下降约 19%。这些细节共同说明，算力翻倍后，原本不起眼的资源占用与中间存储可能变成新的瓶颈。

索引并行把上下文分给多张卡

在 TP4 下，每张卡分别扫描完整索引缓存会产生四次重复读取。indexer DCP 改为每卡扫描四分之一上下文、计算全部相关索引头，再交换局部候选并合并最终 top-16。它重分配的是选块工作，而不是改变选块语义；文章称在对应实现中保持精确选择。

四张 GB300、512K 上下文的单稀疏层 indexer 最高加速 3.3 倍。AMD 路径也采用上下文分片，还让多头与多条投机查询填满矩阵单元形状。其收益依赖请求数、上下文长度和硬件执行形状，因此选择并行配置时要先判断是重复带宽还是低利用率占主导。

AMD 的转换与通信有不同解法

CDNA4 缺少相同的 NVFP4 转换指令，文章用小查找表预计算缩放值，再结合符号位完成转换；共享前缀还可在多请求间减少重复反量化。prefill 侧用 sequence parallelism 减少通信量，用 dual-batch overlap 将剩余通信藏在另一个微批计算后面。

跨节点的 KV 布局同样关键：旧布局把每个块拆成 125 个小页，需要多次 NIXL RDMA read；block-outer 布局把它连成一行约 1.82 MB，用一次读取搬运。在四张 MI355X 上，相关 engine 与传输改动让 16K 以上 prefill 批次加速 1.8–2.1 倍。低并发又另有合并算子启动的 mono kernel，不能假设一套内核适用于所有并发区间。

读 AgentX 曲线要保留投机条件

GB300 的 AgentX 前沿包含每用户 418.9 token/s 的低延迟点，以及最高 153.8K 总 token/s/GPU 的高吞吐点，后者每用户约 127 token/s。它们是不同运行点，不能拼成一组同时成立的性能。图注明确使用七个投机 token、合成接受长度 3.16–3.26，不能当作自然流量中 DSpark 的实测接受率。

AMD 图又以每美元 TCO 的总 token 衡量成本效率，与 NVIDIA 图的每卡吞吐单位不同，且不同点使用不同接受长度和投机配置。最有用的比较是相同延迟目标下的前沿，以及实际请求分布中的接受率、缓存命中和硬件价格，而非跨图挑最高数字。

文章还展示低精度基座加 rank-32 LoRA 的 RL 路径：在 16 张 GB300、DAPO-Math-17K、200 个 GRPO step 下，AIME-2024 从 36.3% 到 67.5%。这是单独的训练实验，不是 serving 内核优化带来的质量提升。原文核心机制图为交互组件，静态 hero 不能解释数据流，因此本篇不以装饰图替代机制图。

格式相同不代表执行路径相同

文章跨硬件比较特别容易被误读，因为同一种低精度格式在不同架构上可能采用不同转换与矩阵乘路径。Blackwell 用专用转换指令，AMD 用查表，Rubin 又利用不同计算精度和资源布局；共享的是模型与存储表示，内核实现却针对硬件重新平衡。移植时真正需要保留的是数值语义、选块逻辑和状态布局，而不是机械复制某个平台的指令安排。

同样，投机解码同时改变查询批量和内核形状。草稿模型更快，可能降低一部分延迟；验证阶段的接受长度和额外工作又决定最终是否划算。文章采用合成接受长度，让系统比较更可控，却将真实应用中的预测质量暂时固定住。要判断业务收益，需要在实际输入中恢复这个变量，观察它是否随代码任务、长上下文或温度变化。

把容量、单层与整机结果放回各自位置

容量数字回答能装下多少状态；内核数字回答某一步执行得多快；服务前沿回答在负载变化时用户速度与系统吞吐怎样交换。三者相互影响，却不是可以直接相乘的一组加速比。例如，增加并发会消耗刚省出的缓存容量，还可能把瓶颈推向索引扫描、通信或调度；低并发下减少启动次数的收益，也未必在高并发时保留。

这篇技术长文最适合按数据流阅读：先看模型产生什么缓存，再看查询和缓存怎样进入内核，接着看本节点与跨节点如何重组状态，最后对照测试曲线。这样可以辨别哪一项改进真正匹配自己的瓶颈，避免只凭一个精度名称或单卡峰值决定部署方案。文中展示了扎实的组合工程，但并没有给出所有硬件与负载之间一套固定不变的最优配置。