Mistral 把三个模型压成一套 128B 权重
2026 年 4 月 28 日，Mistral AI 发布 Mistral Medium 3.5。按官方技术博客与第三方评测披露的参数，这是一个 128B 稠密（dense）模型，上下文窗口 256K，输入支持文字与图像，输出为文字。接口层面提供 reasoning_effort 可调参数、function calling、structured outputs，以及面向编码任务的 Agent 能力。
一套权重，不再按任务路由
这次改动最实在的地方在模型数量。此前指令遵循、推理、编码由三个独立模型分别承担，工程上要加一层路由，按请求类型把流量分给不同模型。Mistral Medium 3.5 把这三类能力合并进单一 128B 稠密权重，调用方不需要再判断"这条请求该走哪个模型"，改由 reasoning_effort 在单次请求里调整推理强度。
对搭系统的人来说，路由层是可以直接拆掉的一层。少一层路由，就少一套版本对齐和灰度发布的麻烦：三个模型各自升级时，行为差异要在路由层兜住；现在只有一个权重需要跟踪。代价是推理强度和成本的调节从"选模型"变成"调参数"，需要重新测一遍参数取值和延迟、费用的对应关系。
256K 上下文与图像输入
256K 的上下文窗口配上图像输入，指向的是长文档和截图类任务：整份代码仓库、多份合同、带表格的扫描件，可以一次性塞进同一个请求，不必先做切片和检索。评测文章把这类场景列为该模型的主要卖点，但公开的分项跑分数据目前还不完整。
Mistral Medium 3.5 采用开放权重的方式发布，这一点在中等规模模型里不算常见。权重可下载意味着私有部署和微调成为选项，也意味着第三方能直接在自有任务上复现官方说法，而不是只依赖厂商给的 benchmark 表格。
接下来看什么
参数和接口已经清楚，剩下的是验证：reasoning_effort 调到高档位时，延迟和准确率如何取舍；256K 上下文在长文档中段的事实召回是否稳定；编码 Agent 在多轮工具调用里会不会跑偏。这几项在真实业务里的表现，比发布时的榜单更能决定它是否被换上去。
来源