Mistral 这次做了一个有点反直觉的决定。
过去两年，模型厂商的策略基本是"专款专用"——推理用 thinking 模型，聊天用 instruct 模型，编程用 coding 模型。用户根据自己的场景选模型，或者更常见的做法：每个场景调不同的 API。
Mistral Small 4 直接把这条路堵死了。
一个模型，同时具备 Magistral 级别的推理能力、Pixtral 的多模态输入、以及 Devstral 的编程代理能力。用户不再需要选模型，只需要告诉它你想让它用多大力气思考。
关键数字
119B 总参数，128 个专家，每 token 只激活 4 个——算下来每 token 大约 6B 活跃参数（含 embedding 和输出层约 8B）。256K 上下文窗口。Apache 2.0 开源。
配置推理强度是这个产品最有趣的设计。你可以让它"快答"，走低延迟路线；也可以切换到深度推理模式，让它像 thinking 模型一样逐步拆解问题。同一个模型，两种运行模式。
官方给出的性能对比：相比 Mistral Small 3，延迟优化场景下端到端完成时间减少 40%，吞吐优化场景下每秒请求数提升 3 倍。
基准测试：输出效率比分数更有意思
在 AA LCR 基准上，Mistral Small 4 得分 0.72，输出长度仅 1.6K 字符。对比 Qwen 系列拿到相近分数需要 5.8-6.1K 字符——差了三倍多的输出量。
这不是分数高低的问题。输出短意味着推理延迟更低、API 成本更少、用户体验更直接。一个模型如果要用三倍的文字量才能拿到同样的分数，在实际部署里是要付真金白银的。
LiveCodeBench 上 Small 4 超过了 GPT-OSS 120B，同时输出量少 20%。这个效率差距在大规模调用场景下会迅速变成成本差距。
部署
推荐配置是 4x HGX H100、4x HGX H200 或 2x DGX B200。和 NVIDIA 的合作已经落实到 vLLM 和 SGLang 两个推理框架的优化上。社区侧，llama.cpp、Transformers、SGLang 都已经支持。
如果你在自己的机器上跑，119B 的总参数量意味着至少需要 200GB+ 显存来加载全模型。不过 MoE 架构的好处是实际推理时只有一小部分参数在工作，量化后部署门槛会低不少。
判断
Small 4 的定位很清晰：它不是去和 Opus、GPT-5.5 拼绝对能力的。它的卖点是"一个模型解决大部分场景，而且跑得便宜"。
对于中小团队来说，这个思路有吸引力。与其维护三四个不同模型的 API 接入、调试、fallback 逻辑，不如用一个 Small 4 覆盖聊天、文档分析、简单编程和推理。牺牲一点天花板，换来部署复杂度的大幅降低。
但如果你需要最顶级的推理深度或编程能力，Small 4 的"全能但非极致"定位可能不满足需求。它的代码能力对标的是 Devstral 的水平——够用，但不是 SWE-bench 刷榜级别。
Mistral 这一步走的是实用主义路线。在模型能力过剩、调用成本敏感的 2026 年，"一个模型干所有事"的性价比叙事，比"我们某个单项第一"更能打动实际掏钱的人。
下一个值得观察的点是：Small 4 的可配置推理模式在实际场景中的表现是否和基准测试一致。基准环境下的"深度推理"和真实业务场景中的表现往往是两回事。
相关阅读：
主要来源：