Mistral Large 3 落地：单卡推理的成本账，比想象中复杂

Mistral Large 3 落地：单卡推理的成本账，比想象中复杂

上周把 Mistral Large 3 接进内部的服务里，本来只想做个简单的代码补全功能，结果卡了整整两天。

说实话，一开始我没太把这个模型当回事。Mistral 这几年的节奏大家都清楚，Small 系列主打端侧部署，Large 系列主打闭源推理。Large 3 发布的时候，官方宣传页上写着“欧洲最强闭源模型”，参数规模和推理能力对标 GPT-4o 和 Claude 3.5 Sonnet。我随手扫了一眼 Benchmark 数据，Code Completion 准确率确实高，但我想的是：我们这个项目没必要上这么重的模型，Small 3 或者 Small 4 应该够用。

结果上线第一天就打了脸。

我们的场景是实时代码审查，要求延迟低于 800ms。用 Small 4 的时候，RT 稳定在 400ms 左右，但准确率只有 62%——很多边界 case 直接漏掉。换成 Large 3，准确率飙到 89%，但 RT 直接炸到 1.2s。为了压延迟，我试了一圈量化方案，FP8、INT4、甚至尝试了最近很火的 Q4_K_M 量化，结果要么效果崩塌，要么显存占用超标。

有意思的是，Mistral 官方在文档里轻描淡写地提了一句：“Large 3 支持 Speculative Decoding 优化，建议在 A100 或 H100 上部署。” 这句话看着简单，实际操作起来坑死了。

我们先是在一台 A100 80GB 的机器上试，用 vLLM 部署，开启 Continuous Batching。配置参数基本照着官方示例来：--tensor-parallel-size 1，--max-model-len 4096，--enable-speculative-decoding。启动倒是顺利，但跑起来之后发现吞吐率并不理想。每个请求的 TTFT（首 token 延迟）大概在 300ms 左右，后续 token 生成速度倒是稳定，但整体延迟还是达不到要求。

后来查了 vLLM 的 GitHub Issue，发现有人提到 Large 3 的 KV Cache 占用比预期大。我仔细看了下模型结构，Large 3 用的是混合注意力机制，部分层是 Full Attention，部分是 Sliding Window。这意味着 KV Cache 不能简单地按序列长度线性估算，实际占用可能比理论值高 20%-30%。我把 --max-model-len 从 4096 降到 2048，延迟确实降了，但长代码片段的理解能力明显下降。

单卡跑不通，那就多卡。我们临时调了一台 H100 80GB 的机器，开了 2 路 Tensor Parallel。结果更离谱——延迟没降多少，显存直接爆掉。查日志发现是 vLLM 在 TP=2 时的显存分配策略有问题，中间层的激活值占用过多。把 --gpu-memory-utilization 从 0.9 调到 0.85，才勉强跑起来，但吞吐率反而下降了 15%。

说实话，当时方案 A 和 B，我选了 A 因为 H100 资源现成。事后看选错了，应该直接上 A100 单卡 + 更激进的量化。

后来换了个思路，尝试了 ONNX Runtime 的推理优化。把 Large 3 导成 ONNX 格式，用 TensorRT 做后端加速。这个方案的好处是显存占用可控，而且可以精细控制算子融合。但问题是导模过程极其麻烦，Large 3 的某些自定义算子在 ONNX 里不支持，得自己写 Custom Op。折腾了大半天，终于跑通，RT 压到了 600ms，准确率保持在 87% 左右。

这个过程让我意识到一个问题：Mistral 官方在宣传 Large 3 的时候，过于强调它的推理能力，却很少提部署成本。Small 系列可以在单卡 MacBook 上跑，Large 系列却要 A100/H100 + 复杂的优化。对于很多中小团队来说，这个门槛太高了。

我后来跟几个做 Infra 的朋友聊，发现大家都有类似感受。Mistral 的策略很明确：Small 系列走开源低价路线，抢端侧市场；Large 系列走闭源高价路线，抢企业级市场。但这个策略有个隐患——企业用户想要的是“开箱即用”，而 Large 3 目前离这个目标还很远。

上周我又跑了一组对比实验。把 Large 3 和 Claude 3.5 Sonnet 在同一台 A100 上跑同样的测试集。Claude 用官方 API，Large 3 用本地部署。结果是：Claude 的延迟更稳定（虽然贵），Large 3 的延迟波动大（受并发影响明显）。这意味着如果要用 Large 3，必须自建一套完整的推理服务，包括负载均衡、自动扩缩容、监控告警。这套成本加起来，可能比直接调 API 还贵。

我现在的建议是：如果你的场景对延迟敏感，且团队有专门的 Infra 人力，可以考虑本地部署 Large 3；否则，还是老老实实调 API 或者用 Small 系列。别被官方宣传骗了。

你们在项目里用过 Large 3 吗？有没有遇到类似的部署坑？评论区聊聊。