Pareto 26.10 与 Pareto 26.9：一个数字区分了这两个版本

将Pareto 26.10与Pareto 26.9进行比较，主要是在研究那些没有变化的地方。同一供应商、同一复合架构、同样 131,072 个 token 的最大响应长度、同样五个已声明参数、供应商自家定价页面上同样公布的费率，以及在两个版本共有的唯一一项基准测试上，较旧模型以十分之一分的优势领先。在人们通常用来比较模型的那些层面上，这两者就是同一款产品，只是版本号不同。但有一个层面并非如此，而这个层面决定了哪些工作负载能够使用其中任何一个：上下文窗口，26.9 提供 262,144 个 token，而 26.10 提供 1,048,576 个。此类版本发布背后的已记录 AI 故障和智能体事件收录在OrcaRouter AI Incident Archive中，每条记录都附有自己的来源、严重程度、置信度评级和争议标记。

两者均已上线。pareto-26.10 是于 2026 年 10 月 15 日成为 pareto 别名背后默认版本的发布版本，当时 Unbiased 将其正式可用版本迁移到了该版本上；pareto-26.9 是九月份的发布版本，供应商称其“仍然可用”，供任何希望继续留用的人使用。这就是今天摆在调用者面前的全部决策，而本页其余内容则是其背后的细节。

周围的事实

两个模型均被记录为接受文本和图像输入并返回文本，且两者都未发布 Hugging Face 标识符——本次比较双方的权重均为闭源，因此没有可下载并自行托管的内容。两者都没有独立基准测试。两者均由单一提供商 Unbiased 自身提供服务，这意味着对于这两个版本，在供应商自己的技术栈内都没有可用于故障转移的第二个主机。因此，下文的比较是在同一供应商同一产品线的两种配置之间进行，而不是在两个生态系统之间进行。

上下文就是整个论证。

4× 的上下文提升，听起来不过是规格表上的一行数字——除非你把它落到人们实际使用长上下文模型的场景中去理解。

在 262,144 个 token 时，完整仓库的智能体会话、冗长的支持记录或持续数小时的研究线程都属于分块问题。你需要检索、总结、维护滚动窗口，并接受模型看到的是任务的重建版本，而不是任务本身。在 1,048,576 个 token 时，这些工作负载就能容纳——并不总是宽裕，而且在没有缓存命中、每百万输入 token 0.80 美元的价格下也并不便宜，但它们能容纳。这两个版本的实际区别在于，你的流水线是否需要在数据和模型之间加入一个检索层。

那是一个真正的工程决策，而且它也是本页上唯一一个能给出站得住脚答案的决策。其他所有选项都足够接近，因此选择应基于质量以外的其他因素来做出。

并排，逐维度

• 模型字符串 — pareto-26.10（自 2026-10-15 起为 pareto 背后的默认项）对比 pareto-26.9（保留，非默认）。

• 上下文窗口 — 1,048,576 个 token，对比 262,144 个 token。

• 最大响应 — 两者均为 131,072 个 token。各版本之间保持不变。

• 模态——两者均为文本 + 图像输入、文本输出。

• 已声明的参数——26.10 上的 max_tokens、temperature、top_p、tools、tool_choice；26.9 上相同的参数集外加 response_format。

• 工具调用 —— 在 26.10 中，tool_choice 仅限 auto；是否调用由模型决定，你无法强制调用。

• 权重 — 两者均为闭源；两份记录中均无 Hugging Face 标识符。

• 服务提供商——只有一个，即供应商，两者皆然。

• 公布费率——两者均为每百万 token $0.80 输入 / $0.03 缓存 / $3.20 输出，依据供应商当前的定价页面。

• DeepSWE v1.1 — 在 26.10 上以每任务 $0.24 的成本达到 69.9%，而在 26.9 上以每任务 $0.29 的成本达到 70.0%，两者均由供应商运行。

其中有两行值得单独用一段来说明，因为它们正是容易被误报的地方。

没人宣传的结构化输出差异

参数列表并不相同。26.9 的目录记录在受支持的参数中声明了 response_format；26.10 的记录则没有。26.10 声明的参数面是 max_tokens、temperature、top_p、tools 和 tool_choice，仅此而已。

仔细读，别把它当成标题一扫而过：某个参数没有出现在已声明的清单里，并不能证明端点会拒绝它，而且厂商自己的 API 文档也没有列出这两份清单中的任何一份。但如果你的流水线依赖 JSON 模式或受 schema 约束的输出，而你又基于“新版本是严格超集”这一假设从 26.9 迁往 26.10，那么这个假设没有任何已发布的内容作支撑。迁移之前先用你自己的流量测一测，或者准备好客户端侧的输出校验。这是件小事，却会在某个周二变成一起事故。

两张实时费率卡对 26.9 的费用存在分歧

这是比较中最混乱的部分，也是最有可能影响真实决策的部分。

Unbiased 只发布一张费率卡——输入 $0.80、缓存输入 $0.03、输出 $3.20——并且不按发布版本分别定价。照字面理解，这意味着今天 26.10 和 26.9 的每 token 成本相同，于是迁移是免费的，上下文容量的增加就成了唯一的变量。与此同时，该模型自身的技术列表记录中，26.9 仍保留着九月的数字：输入 $2.50、缓存 $0.25、输出 $7.50。撰写本文时，两个来源都仍在线。两者都没有标注日期，厂商也没有发布任何变更日志条目来解释这次变动，因此在所有记录中都找不到一行可供引用的"某月某日价格下调"的说明。

实用建议并不光鲜。假定采用较低的卡，因为你能读取的三个界面中有两个公布了它，而其中之一正是客户据以计费的页面——然后在预算中敲定数字之前再核对一遍。如果你要把任一发布版本固定用于成本归因，要知道，跨越 10 月 15 日过渡期的混合月份在事后无法干净地拆分，因为这些发布版本在不同时间点的定价不同，而供应商也没有为其变更标注日期。

一分，零点一分，却得不出任何结论

两个发布版本唯一共用的基准是 DeepSWE v1.1，而厂商自己的数字显示，26.9 为 70.0%，26.10 为 69.9%。这两个数字均由厂商运行得出，其中较旧的一项基于 30 项任务的切片而非完整评估集，并且 Unbiased 将整个比较描述为未经独立验证。

诚实的解读是，这项测量无法区分这两个版本。在部分任务切片上，0.1 分的差异处在单次运行的噪声范围内；无论把它当作哪个方向的排名——说“26.10 退步了”，还是说“26.10 更好，因为每任务成本更低”——都是在过度解读。每任务成本数字的差异更大（0.24 美元对 0.29 美元），而且即便是这些数字，也来自不同月份的运行，基于一个混合模型，其底层构成厂商并未披露。

这张表确实告诉你的是：哪里不该看。如果你要在这两者之间就质量做选择，那你依据的是一个无法支撑这一选择的数字。区分它们的证据是架构层面的——上下文窗口和参数面——而这两者都能以评分所不具备的方式得到验证。

按工作负载，该调用哪个

• 在整个代码仓库上执行智能体编码——26.10。1M 窗口决定了是发送整个仓库，还是发送它的摘要。

• 长文档或长转录文本分析——26.10，出于同样的原因，并且要注意输入费用：未命中缓存的 1M tokens 仅输入部分每请求就是 $0.80。

• JSON 模式或受 schema 约束的输出流水线——先使用 26.9，直到你亲自测试过 26.10 的行为，因为 26.9 声明的参数列表包含 response_format，而 26.10 的不包含。

• 已在生产环境运行且能适配 262K 的工作负载——26.9。没有公开证据表明迁移能改善输出，而固定版本是成本更低的决策。

• 任何你希望使用供应商当前默认值、又不想维护版本锁定的场景——通过不带版本号的 pareto 别名使用 26.10，但需理解该别名遵循的是供应商的日历，而不是你的日历。

对于同时运行构建与验证闭环两端的团队来说，实用的做法是将 26.10 固定用于长上下文处理环节，并把 26.9 保留为对照分支——这正是路由层的用途所在。OrcaRouter 并不承载任何 Unbiased 模型，因此这两个字符串都通过供应商自家的 API 调用；我们所提供的是一个密钥、一套集成，用于接入你会拿 26.10 来 对比的那些模型，这样评估这次切换就不必再签第二份合同。OrcaRouter 按供应商的标价原样转结，加价 0%，这一说法针对的是我们确实提供的模型，而不是这一个。

没人安排的迁移

这场对比之所以是现实问题而非学术讨论，是因为这一变化已经落在了那些并未主动要求它的人身上。10 月 15 日，pareto 这个别名从 9 月版本迁移到了 26.10。任何直接调用该裸字符串的人，都在未改动任何代码的情况下获得了四倍大的上下文窗口和一套不同的参数面；而且，由于厂商的文档指出未知的模型标识符不会被拒绝，一个拼写错误的版本固定标识仍会被当作 Pareto 来提供服务并计费，而不是明确报错。

如果你当时在预览版本线上，那么这条路已经关闭：Unbiased 已告知预览用户迁移到 pareto 或 pareto-26.10。如果你当时在 pareto 上并假定其稳定，那么无论这个假设是否引发了问题，它现在都已经显现在你自己的日志里。

无论哪种情况，修法都一样，而且只需一行：写明你测试的是哪个版本。带版本限定的字符串，正是让成本模型可以相减、让回归可以归因的关键，而这也是该厂商为这两件事提供的唯一机制。

什么仍然未经验证

这两个发布版本都没有独立基准测试。Artificial Analysis 没有为其中任何一个提供页面，也没有评估者发布过对供应商测试框架的复跑结果。本次比较中的每一个数字——四个分数、每任务成本数据、上下文窗口——要么由供应商发布，要么读取自模型的技术信息记录，而且这些分数特别带有供应商自己的“初步”和“未经独立验证”标签。

这不是避开任一模型的理由。这是一个理由，让你去决定那些可核查的事项：你的工作负载是否适合 262K，你的流水线是否需要 response_format，以及你是想使用别名还是固定版本。这三个问题都有答案。哪个模型更好则没有答案，而且无论读多少遍已发布的规格表，也读不出答案。