MiniMax M3.1 Flash 开放权重与部署要点

MiniMax M3.1 Flash 的看点不只在跑分，而在权重开放时，推理框架和硬件优化是否已经准备好。原文给自部署团队的结论很直接：先算 KV cache 能装下多少并发，再拿真实任务测成本，别急着引用厂商的降价数字。

这篇值得读的地方，是把模型发布拆成了可检查的工程条件。不过，文中的容量和性能数据来自厂商及 vLLM，作者提出了测试方法，没有交出自己的实测结果。

稀疏注意力为什么还会撞上显存墙

M3.1 Flash 是原生多模态混合专家模型（MoE），总参数约 428B，每个 token 激活 23B，支持文本、图像、视频输入，上下文最高 1M tokens。激活参数少有利于减少计算，但不能据此判断整套服务需要多少显存。

它采用 MiniMax Sparse Attention（MSA）：轻量索引器先给历史 key 打分，再按 128-token 块做最大池化，每次查询只对得分最高的 16 块执行注意力计算。因此，无论上下文多长，每个 query 最多读取 2,048 个 key。

这里最容易产生误解。

读得少，不等于存得少。 每个 token 的 K、V 仍要留在 KV cache 中。稀疏注意力减少了读取和计算，却没有消除缓存随上下文增长的存储压力。

NVFP4 则在存储侧缓解问题。模型经过量化感知训练，路由专家以 NVFP4 存储，KV cache 也原生使用 NVFP4。原文给出的检查点体积从 M3 MXFP8 版本的 451.5 GB 降至 250.1 GB；每 token 的 KV cache 从 FP8 的 61,440 字节降至 34,560 字节。发布包还包含推测解码草稿模型 DSpark。

vLLM 的容量示例更有参考价值：同样使用 4 张 B300、256K 上下文，M3 配 FP8 KV cache 可容纳 28 条并发序列，M3.1 则为 76 条，约为 2.7 倍。它说明缓存压缩能扩大容量，但不能直接推出业务吞吐也提高 2.7 倍。

权重能下载之后，为什么还要先看 vLLM

原文区分了两个日期：10 月 19 日发布公告、上线 API；10 月 23 日开放 Hugging Face 权重，并提供 vLLM 首日支持。使用 API 的团队可以从前一个日期开始评估，自部署团队还得确认后一套条件。

这次首日支持包含专门优化的计算内核：

• Blackwell MSA 内核使用 CUDA 13.4 的 QMUL4 指令，在内核中将 NVFP4 反量化为 FP8，索引器 QK decode 最高提速 1.7 倍。
• DeepGEMM 的 MegaMoE 扩展到 NVFP4，并融合 MXFP8 共享专家。在 4 张 GB300、512K 上下文下，索引器解码上下文并行让每个稀疏层的索引器最高提速 3.3 倍。
• 融合 QKV、norm、RoPE、KV-insert 的内核，在 TP4 下将 P50 首 token 时间降低约 19%。此外还有专用 Rubin 内核。
• AMD 版本使用共享内存中的 2 KB 查找表完成 NVFP4 反量化，并通过「mono kernel」把每个解码层约 1,170 次内核启动合并为一次。

这些数字衡量的是不同环节，不能叠乘成模型整体加速比。同一份权重，落到不同硬件和推理实现上，服务表现可能差很多。

部署还有版本问题。原文给出的预构建镜像是 vllm/vllm-openai:minimax-m31-flash，另有 ROCm 版本，但没有写出其完整标签。nightly PyPI wheel 当时仍等待上游审核，vLLM 团队称通常约需一周。因此，照着发布配方验证时，应固定镜像标签，别默认当前安装包已经包含这些支持。

微调侧则提供 veRL、FSDP2，以及 NVFP4 检查点上的 LoRA 支持。其价值是让训练侧的基础模型量化方式与推理侧一致，减少训练和服务不一致带来的问题。

跑分能筛模型，真实任务才能定预算

MiniMax 公布的成绩包括 DeepSWE v1.1 的 73.7%、OSWorld V2 的 61.7、BankerToolBench 的 76.2，以及 CyberGym 的 82.2。API 价格为每百万输入 tokens 0.15 美元、每百万输出 tokens 0.60 美元。

匿名测试阶段的「Space Bunny」据 MiniMax 称处理过超过 200 万亿 tokens。这些都是厂商口径，不能当作独立验证。

服务性能同样要看测试条件。AgentX 公布了 GB300 上每用户 418.9 tok/s、Rubin 上 724.9 tok/s，以及 MI355X 上每美元总体拥有成本（TCO）对应 133.3M tokens。原文明确指出，这些结果基于基准框架和合成的推测解码接受长度。接受长度可以理解为一次验证能采纳多少个草稿 token，它会影响推测解码收益。

作者建议，用包含工具调用、长文件读取、重试的真实 coding-agent 轨迹，同时测试 API 和自部署端点，比较每用户吞吐与每个完成任务的总成本。这个建议合理，但它是待执行的测试方案。

便宜的 token，只有转化为便宜的成功任务，才值得写进预算。

我的判断

我认同原文把注意力从榜单拉回缓存容量、计算内核和真实任务。对需要长上下文、多轮工具调用的团队，这些条件比单次回答速度更接近实际瓶颈。

但它也有适用前提。4 张 B300 的容量示例，以及 GB300、Rubin、MI355X 的性能结果，都依赖特定硬件、实现和负载，不能直接外推到现有 GPU。原文也没有给出真实任务下的 API 与自部署成本对照。所谓「便宜 70%」在结尾只是作者提醒别轻信的数字，没有对应的测算依据。

与自部署相比，API 可以更快开始验证模型能力；自部署是否划算，还要补上硬件、利用率和运维成本。原文没有算清这笔账。最后关于效率提升会被更长上下文和更多 agent 工作负载消耗的「杰文斯悖论」，也属于作者判断，文中没有需求数据支撑。

还应保留一层来源意识：原文披露，它由 AI agent 自主研究、撰写和发布，未经人工审核。它适合提供核对清单，具体发布状态与性能仍需核验。

能拿来做什么

• 评估 coding agent 时，保留包含读文件、工具调用和重试的完整任务轨迹，用同一批任务比较 API 与自部署的完成质量、耗时和成本。
• 规划长上下文服务时，分别计算模型权重与 KV cache 的显存需求，再检查目标并发；不要用每 token 激活 23B 参数代替容量估算。
• 准备部署时，把权重页面、对应硬件内核、镜像标签和运行配方一起归档；涉及微调时，再确认训练与推理的量化方式一致。