428B 权重开了：想本地跑 MiniMax，显存账怎么算？

MiniMax 把 M3.1 Flash 的权重放出来了。对在做 Coding Agent、企业知识库或私有化服务的团队，这个消息确实容易让人手痒：模型卡上写着 428B 总参数、每个 token 激活约 23B、最高 1M 上下文，还列了 SGLang、vLLM 和多芯片部署入口。

于是问题很快从“要不要试”跳到“把它拉到本地跑”。这里最容易踩的一脚，不是下载命令打错，而是把 23B 激活参数 理解成“这就是一套 23B 本地模型”。它不是。

MiniMax 的官方模型卡把 M3.1 Flash 定义为原生多模态 MoE。MoE 可以理解成一个很大的专家库：每次生成一个 token，只叫其中一小部分专家上班。23B 说的是这一次前向计算会被激活的量；428B 则仍是整套权重的规模。前者会影响每 token 的算力路径，后者先决定了你得把多大的模型文件、权重分片和运行时状态放进机器或集群。

这篇不评判它“强不强”。官方的分数、速度和成本都有各自的评测设置，离你们自己的代码库、并发和数据权限还有一段距离。更实际的问题是：如果你打算把它变成一个团队能依赖的 Agent，显存账、上下文账、服务账和验收账，该从哪里开始算？

23B 激活，不会让 428B 的文件消失

MoE 最容易被误读成“只激活 23B，所以只要按 23B 买显存”。这把两件事揉在了一起。

推理时，路由器会选择一部分专家处理当前 token，所以计算量和每一步带宽压力会比一个同等总参数的稠密模型更友好。MiniMax 也把稀疏注意力、量化感知训练和 DSpark 推测解码列为这代模型的效率设计。官方模型卡还保留了 draft head，供兼容的服务实现使用。

但服务进程不能只带“这一轮刚好会被选中”的专家出门。完整 checkpoint、专家路由、分片策略、通信和框架的运行时缓冲都还在。把参数量乘以每个参数的存储字节数，只能得到一个不含上下文缓存与运行时开销的理论下界：

仅看参数本体的粗略下界：

428B × 2 bytes ≈ 856 GB    # FP16／BF16 量级
428B × 1 byte  ≈ 428 GB    # 8-bit 量级
428B × 0.5 byte ≈ 214 GB   # 4-bit 理想化量级

这不是硬件采购报价。量化格式会有元数据和分组尺度，框架还会留运行时空间；不同并行方式也会改变每张卡承担的部分。它只负责把一个误会挡在门外：A23B 适合描述每步计算的稀疏性，不适合替代整套权重的存储预算。

真正要问供应商或基础设施同事的，反而是更朴素的几句：权重用什么精度落盘和加载？一张卡实际可给模型多少可用内存？服务框架打算怎样切专家？如果其中一张卡掉线，排队中的请求会怎么处置？这些答案没齐之前，“能不能跑”还只是一个很乐观的动词。

1M 上下文，先别把它当成默认档位

模型卡写的是“最高 1M token 上下文”。这很有吸引力：一个仓库、一批文档、长会话记录，好像都可以一次塞进去。可 Agent 的长上下文不是一个只在请求开始时付一次的钱包。

每个还在窗口里的 token 都会留下 KV cache。它存的是模型为后续注意力计算准备的中间状态，像把整本资料做成随时可翻的索引卡。窗口变长、并发变高，索引卡就跟着堆；你还要给系统提示词、工具调用回包、重试和观测留位置。MiniMax 在模型卡中也写得很克制：可用上下文长度和吞吐取决于 GPU 内存与服务配置。

所以，做本地 POC 时不该只拿一条很短的 demo 跑通就宣布成功。至少把你们最常见的三种请求摆进去：

• 真正会把资料拉长的任务，例如跨多个文件的代码修改或长文档核对；
• 会连续调用工具的任务，观察每一步回包怎样挤占上下文；
• 需要重试或转人工的失败路径，确认上下文、日志和临时文件是否能完整保留。

如果你们大多数请求只用到几万 token，先把窗口上限、截断策略和摘要策略设清楚，往往比一上来追 1M 更划算。长窗口是能力上限，不是默认体验承诺。把最大值设成常态，常见结果是吞吐难看、排队变长，排障时还得在一大段历史里找那条真正出错的工具回包。

开放权重，只是从“模型选择”走到了“服务选择”

MiniMax 推荐的推理入口是 SGLang、vLLM 和 TokenSpeed，并给了 FlagOS 多芯片资料。这份清单很有用，但它不是一键部署的同义词。

挑框架时，别只看“能不能加载这个模型”。至少把下面几条写进你的试验记录：

要验的东西	不是在验什么	真正在验什么
吞吐	单条 demo 能不能出字	目标并发、目标上下文下的首 token 与完整任务耗时
可靠性	连续跑十分钟没报错	超时、取消、重试、卡故障后的请求如何收尾
工具调用	模型会不会输出 JSON	结构化输出失败时是否能被识别、修复并留下证据
数据边界	机器在内网	日志、提示词、附件、缓存和追踪数据分别落到哪里
升级	今天的镜像能启动	新权重、量化版本、驱动与服务框架升级后能否回归验证

这张表看着不像模型测评，才更接近 Agent 的真实账。模型只是会调用工具的核心；让它在夜里持续跑下去的，是路由、权限、队列、限流、观测、评测和回滚。没有这些，开放权重会把“供应商的托管责任”原样交回到你们手里。

一个很实用的分界线是：如果目标只是验证模型能否理解内部资料，或确认它对某类代码任务的表现，先走 API 或短时间的单机 POC，能更快得到信号。若任务明确要求数据不离开受控环境、调用量稳定、团队已有 GPU 运维和评测基线，再把多卡服务、路由和权限拆成独立项目。把第二种工作当成“下载模型的后半步”，很容易低估周期。

本地化要有边界，别把所有请求塞进同一台服务

把模型部署在受控环境里，通常是为了处理内部资料、获得更确定的路由能力，或把持续调用的成本与延迟控制在自己手里。但“模型在内网”只解决了路径中的一段。一个 Agent 还会带着请求 ID、系统提示词、检索片段、工具参数、附件、追踪日志和失败现场向前走。每一份副本都要有归宿。

因此，本地服务的第一版架构不必追求把全部任务接过去。更稳的做法是先为它划一条窄车道：只处理某一类已分级的内部知识问答，或者只负责代码任务中的候选补丁生成；账户权限、真实写入和高风险工具继续留在已有的审批链路。这样做能把“模型表现”与“权限设计”分开看，也不会因为一次模型超时就拖垮整条业务流程。

路由层也别被忽略。模型卡列出的上下文、图像和视频能力很丰富，可真实请求未必都需要这套配置。一个短文本分类、一段长代码分析、一次图文资料核验，应该有不同的上下文预算、并发上限和超时。能把简单任务送到更小的服务，把必须保留在私有环境的任务送到这套模型，把不确定的任务升级给人工或已有 API，才是在利用开放权重，而不是把新模型当作唯一入口。

部署后的第一周，建议把每个请求都记成一条很短的运行记录：任务类别、输入规模、实际占用的上下文、工具调用次数、端到端耗时、结果是否被接受，以及失败落在哪一层。这样一周后讨论扩容时，手里会有“哪类任务真的受益”的样本，而不是一张只记录平均 TPS 的仪表盘。若某类请求总在检索阶段超时，继续调模型参数不会让它变好；若人工总在拒绝同一种输出，应该回头改验收样例或权限边界。

本地推理还会引入版本选择。官方模型卡已提示第三方量化版本的结果可能不同，团队应把权重版本、量化方式、服务镜像与测试集一起记入每次实验。否则两周后看到一次质量波动，很难判断是模型、框架、驱动，还是某条提示词和检索数据已经变了。能复现的对照，比一条漂亮的单次结果更有用。

上线前还要刻意制造几次“不好看”的情况：工具接口慢三十秒、向量检索返回过期文档、输出 JSON 少了一个字段、请求在生成中被取消、某张卡暂时不可用。观察系统能否区分模型失败、工具失败和基础设施失败，并保留足够的证据供人复盘。Agent 出问题时，日志里只写“模型调用失败”几乎没有帮助；你要知道它当时带了什么上下文、尝试了哪一步、有没有触及不该触及的动作。

这也是为什么权重、框架和运维从来不是三张独立的票。没有一条可审计的调用链，部署再本地也很难说服安全与业务同事把真实任务交进来。

官方榜单能帮你筛候选，不能替你签收

M3.1 Flash 的模型卡给了不少成绩，例如 DeepSWE v1.1 为 73.7、OSWorld 2.0 为 61.7、CyberGym 为 82.2。它也列出了评测设置：有些项目采用指定的 Agent、上下文长度或裁判模型；空白分数不代表零分。官方还特别说明，这些是官方权重的结果，第三方量化可能不同。

这正好提醒了一件常被省掉的事：选模型时可以看横向表，接模型时必须自己定义“完成”。

如果 Agent 的工作是改代码，验收不该停在“补丁生成了”。把单测、静态检查、依赖变更、权限范围和回归样例连起来，才知道它能否安全进入你们的流水线。如果任务是文档问答，别只看回答像不像；加入权限错配、过期文档、冲突资料和引用缺失的样本。如果它会操作浏览器或企业系统，连失败时是否停下、是否能留下可审计的动作记录一起测。

MiniMax 公告里提到该模型面向 Agent、编程、Computer Use 和安全任务，并给出 200+ TPS 与成本下降的官方说法。这些材料足够让它进入候选池；它们不足以推出“你们的任务也会同样快、同样便宜”。一条完整任务会经历模型生成、工具等待、网络、重试、人工确认和日志写入，哪一段才是瓶颈，要用自己的工作负载回答。

一个不浪费 GPU 的落地顺序

如果团队真的要评估 M3.1 Flash，我会把顺序压成四步，而不是先搭一座很大的集群：

1. 把任务切小。 选一个可验收的任务，例如“根据问题定位仓库中的两个相关文件并产出修改建议”，不要从“让它接管研发流程”开始。
2. 记录基线。 用当前 API 或已有模型跑同一批样本，记录任务成功率、端到端耗时、token、人工返工和失败类型。没有基线，后面看到的只有一串很热闹的 TPS。
3. 做受限的本地 POC。 固定权重版本、量化方式、框架版本、上下文上限和并发，跑成功路径也跑失败路径。模型卡提到的 SGLang、vLLM、TokenSpeed 可以是起点，不是默认答案。
4. 再决定扩容。 只有当数据边界、稳定调用量、效果差异和运维责任都已经被证据支持，才谈多卡、跨节点或多租户。此时再看 FlagOS 一类的多芯片方案，讨论才不会飘在参数表上。

这里没有任何一步要求你相信“本地一定更省钱”。有的团队会因为缓存、持续调用和数据约束得到收益；有的团队会发现 API 的弹性、升级速度和故障责任更合适。把结论留给真实负载，比在发布当天替机器房做决定靠谱得多。

权重开放是一件好事，它让选择多了一扇门。门后却不是一台轻巧的 23B 模型，而是一套 428B 权重、长上下文、服务框架和验收体系共同组成的工程题。

你们下一次评估开放权重模型时，最容易漏算的是显存、上下文，还是运维和验收？

小岛AI｜记录一线实战、踩坑与成长