自托管 Mistral Large 4：踩坑后的经验教训

Mistral 发布 Mistral Large 4 的权重时，一个约 1 万亿参数、每次激活约 520 亿参数的模型，我的收件箱里很快冒出同一个问题：我们能自己跑吗？自托管开放权重已经不再是爱好者的幻想，而是实实在在的架构选项，这意味着很多团队即将犯下代价不菲的错误。其中几个我已经亲眼见过。这篇文章是踩坑之后的总结：实践者通常会在哪些地方把自托管搞错，每次又该怎么修正。

错误一：把“开放权重”理解成“想怎么用就怎么用”

第一个错误发生在还没碰 GPU 之前。Mistral Large 4 采用改良版 MIT 风格许可证，其中有一条重要的例外：如果你或你的关联公司经营模型即服务（MaaS）业务，在商业使用该模型之前需要向 Mistral 单独申请商业许可。对于在公司内部运行推理的团队来说，比如总结文档或为员工提供编程助手，通常没问题。但如果是计划转售推理能力的创业公司，在给 Mistral 发邮件之前，这基本就是一道硬门槛。

实践中，大家在两个方向上都可能出错。有些团队看到新闻稿里的“开放”二字，就基于这些权重开发商业产品，结果在融资尽职调查时才发现限制条款，这是最糟糕的时机。还有些团队矫枉过正，以为许可证禁止一切商业用途，实际上它针对的主要是竞争性推理服务商。解决办法很朴素但必不可少：让法务团队阅读许可证原文，而不是只看发布公告。至于你把它叫做“开放权重”还是“可用权重”，社区为此争论得很激烈，这种争论也并非无理。但工程决策应该以许可条款实际允许你的业务做什么为准。

还有一个细节：这种许可模式现在已经是主流大厂权重发布的常态，而不是例外。如果你的架构需要在 Mistral、Qwen 以及其他前沿权重模型之间切换，你需要的是一份许可证对照表，而不是一次性的审查。在搭建集群之前，先把这张表格做出来。

错误二：根据宣传页而不是计算来配硬件

这是最烧钱的错误。有工程师看到“1T 参数”，扫一眼公司机房里的四块 H200，心想 540 GB 显存差不多够了。其实不够，而这背后的算术只需要九十秒，却能省下一个季度的尴尬。

以 BF16 精度计算，一万亿参数光是权重就需要约 2 TB 内存。量化到 8 位约需 1 TB，4 位约 500–560 GB，这还没算 KV cache、激活值和服务开销。那台 540 GB 的服务器只有在你能接受较短的上下文窗口和少量并发用户时，才装得下 4 位模型。混合专家架构（每个 token 激活 520 亿参数）降低的是每个 token 的计算量，对显存却毫无帮助：全部一万亿参数仍需常驻在可寻址的内存中。而在 MoE 中，专家权重的访问模式难以预测，因此把它们卸载到 CPU 内存会严重拖慢延迟，这一点和稠密模型不同。

正确的做法是从服务需求倒推，而不是从硬件正推。先确定目标上下文长度、并发数和每秒 token 数，再算出你负担得起的量化等级，最后才推导需要的硬件。如果结果是八块 H200 或一对 NVL72 级别的节点，而这个数字让你心疼，那很好，这种心疼说明模型在按预期工作。我们之前写过相关问题，参见GPU 显存不够用时该怎么办，那里提到的方案（卸载、更小的量化、更小的模型）在这里同样适用，只不过规模已经上升到数据中心级别。

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

值得注意的是，诚实版本的那张表包含了 KV cache 和其他开销。不诚实的版本只算权重，而这正是很多团队最后得到一个“能加载、但最多只能服务三个用户”的模型的原因。

错误三：把量化当成免费午餐

团队接受需要量化之后，下一个错误通常是认为 4 位量化“基本等同于原模型”。有时确实如此，但更多时候并非如此，而且失效的恰恰是你最在意的那些能力。

我反复见到的模式是：团队用类似 MMLU 的选择题基准测试 4 位部署，发现只下降了 1%，于是就上线了。之后生产用户反馈，长篇多文件的代码重构会偏离轨道，或者工具调用的 JSON 偶尔出现细微的格式错误，概率低但出现频繁。激进的量化对长链路、结构化和低温度采样的任务影响尤其大，而这些恰恰是智能体和编程场景的核心，也正是你选择前沿模型的理由。平均分几乎不变，尾部却全面崩溃。

正确的做法是：量化的程度以任务评测能容忍的范围为准，而不是以显存被逼到什么程度为准。用你自己工作负载的提示词，分别在 FP8、4 位和 3 位版本上运行并对比。如果 3 位版本通过了你的评测，恭喜，硬件成本直接减半；如果没通过，再漂亮的基准平均分也救不了你。另外，只要官方发布了原生量化版本，就优先选择。Mistral 在 BF16 权重之外还发布了 NVFP4 变体，官方量化版本附带了经过测量的质量差异数据，比你花一个下午验证过的社区 GPTQ 转换版本要可靠得多。

量化等级本质上是一份质量预算，而不是一个压缩参数。把它花在你的工作负载承受得起损失的地方。

错误四：把 API 价格和 GPU 价格相比，就当成了 TCO 分析

典型的表格是这样的：“API 每百万输出 token 收费 2.10 美元，预留的 GPU 节点每小时收费 X 美元，因此在每月 Y 个 token 的时候自托管就能回本。”这张表几乎总是错的，而且错误方向是让你多花钱。

它忽略了利用率。API 让你用上别人的算力，按 token 计费，利用率由服务商保证。而你自托管的集群，利用率取决于你的流量模式，而大多数内部工作负载是突发性的：工作时间很忙，夜里空转，发版前后又会突然飙升。按峰值配置的集群大部分时间都半空着。此外还有那些不会出现在表格里的成本：一套值班轮岗制度，要维护包括 vLLM 升级、CUDA 驱动不匹配在内的服务栈，还有凌晨两点因为 KV cache 碎片化而被叫醒的故障；模型更新的频繁折腾（每次新权重发布你都要重新验证吗？你的评测套件会说要）；以及那位 ML 工程师的机会成本，他现在成了 GPU 的看守人，而不是在做产品。

还有一个没人计入成本的变动目标问题。Mistral 在这个模型从预览版到正式版之间，把 API 价格几乎砍掉了一半：输入 token 从每百万 1.36 美元降到 0.70 美元。任何基于旧价格算出的自托管投资回报分析，现在都成了虚构。前沿模型的推理成本按季度下降，而你的硬件折旧却是按多年计算的。这种不对称是自托管商业论证中悄无声息的杀手。

解决办法是：只为 API 在结构上无法提供的理由去自托管。这些理由确实存在，也很真实，但在大多数公司实际运营的规模下，“规模化后更便宜”很少是其中之一。

自托管到底在什么时候更划算

那么，在本地运行 Mistral 级别的权重什么时候比 API 更好？看过团队做对和做错之后，我发现成功的情况大致集中在四类：

• 数据驻留与主权。受监管行业、国防相关工作，以及有硬性司法管辖要求的欧盟机构。我在现实中见过一个约束：某公司出于合规原因禁止使用中国背景的模型，而来自欧洲实验室、具备可审计来源的开放权重，解决了任何 API 合同都无法解决的问题。
• 离线或间歇性连接的环境。如果网络根本无法保证，本地权重就是整个架构的基础。我们在构建可离线工作的 LLM一文中探讨过这种模式。
• 持续、可预测、高吞吐的工作负载。以稳定吞吐量全天候运行的批量文档处理，确实可能比按 token 计费更划算，因为它从结构上解决了利用率问题。
• 微调与改造。你无法在别人的微调接口允许的范围之外微调他们的 API。拥有权重意味着拥有训练流程：在领域语料上继续预训练、定制对齐、蒸馏为更小的部署模型。

需要注意的是，清单上没有延迟。除非你愿意在投机解码和针对 batch-1 优化的服务上大力投入，否则自托管一个万亿参数的 MoE 模型，并不会比配置良好的 API 延迟更低。另外还有一点不在清单上：“避免对单一供应商的依赖”。你今天下载的权重，一年内就会落后两代，你又会回到同样的决策点。这也顺便说明，一些实践者习惯于把重要的权重发布保存一份本地副本，是有道理的。存储很便宜，而选择权很宝贵。

客观的看法是，开放权重和 API 是互补关系，而不是竞争关系。我认识的好几个团队都采用混合方案：用 API 承接突发的交互式流量，用本地权重处理受监管或批量密集的那部分。技能可以互相迁移，你的 vLLM 配置、评测框架和提示词模板，在两种场景下都能用。如果你在投入前沿规模之前想先掌握运维基础，我们的指南在自己的硬件上运行大语言模型完整介绍了整个服务栈。

错误五：用基准测试而不是你的工作负载来评估

最后这个错误会让前面所有的努力付诸东流。团队把每一步都做对了：许可证审过了，硬件算过了，量化在公开基准上测过了，然后上线的模型却被用户讨厌，因为评测从来没有衡量过用户真正在做的事情。

公开基准回答的是“这个模型总体能力如何”，但它回答不了“这个模型能否以我们需要的语气和格式给支持工单分类，在 4 位量化下、在我们的并发压力下做到这一点”。我们之前写过为什么 AI 基准测试漏掉了 90% 的真实工作，而自托管会让这个差距更加明显：过去由 API 服务商管理的每个变量，现在都由你负责。部署栈、采样参数、模型训练时所用的系统提示词规范，每一项都可能出错，而且都得你自己负责。

解决办法是在承诺硬件之前，先搭建一套三层评测体系：

1. 来自生产环境的黄金集。几百条真实提示词，配以经过审核的理想输出，覆盖你实际的任务分布，包括那些冗长、杂乱、多轮的复杂案例。
2. 回归测试框架。每个候选方案（API 与本地、FP8 与 4 位、旧权重与新发布版本）都自动跑一遍黄金集。使用强大的评判模型打分，同时辅以人工抽查；对于结构化输出，不要盲目信任评判模型。
3. 影子运行期。让本地部署和 API 并行处理真实流量，持续两周，对比输出结果，并测量真实负载下的真实延迟。KV cache 的容量配置错误和量化后的尾部失效，正是在这个阶段才会真正暴露出来。

这套测试框架只要帮你一次，就值回票价：当新的权重版本发布时，你可以用数据在一个下午内回答“要不要升级”，而不是在会议上靠感觉争论。

真正的教训：开放权重改变的是问题，而不是答案

一年前，“我们要不要自托管一个前沿模型？”还只是个假设，因为前沿模型根本无法下载。Mistral Large 4 以及其他一众万亿参数模型的发布，让它变成了一个涉及真金白银的真实决策。但决策框架本身并没有变，只是变得不得不认真对待了。

当主权、连接性、持续的业务量，或修改模型的需求要求你这么做时，就选择自托管。当你的流量是突发性的、团队规模较小，而你的差异化优势在于产品而非推理栈时，就选择付费使用 API。无论你选哪一条路，在签字之前都要做那九十秒的显存计算，读一读许可证，并搭建好评测框架。权重现在是开放的了，但坑也一样是开放的。