Baseten Grid 提了一个问题：完成一项编码任务到底花多少钱？

编码代理交来一份看起来很干净的改动，要修复失败的测试。改动没通过 CI，开发者让代理再试一次。第二次碰了仓库中更大的一片代码，审查人员为原本以为五分钟就能处理的补丁花了半小时。哪个模型更便宜？

Baseten 在 11 月 4 日推出了 Grid 的公开预览。它把已批准模型的访问网关、路由器，以及用量和防护规则的集中控制结合在一起。服务可以放在受支持的编码工具与模型之间，让团队对请求应用统一的策略。抢先体验页面引导团队加入候补名单。

分母要用实际验收的结果

每项验收任务的成本。Telli.sh 原创示意图。

令牌单价衡量的是一个模型用量单位的价格。团队要交付的是通过验收条件的成果。一次请求可以得到答案，一次运行可以产生差异，但任务依然可能没完成。把这些事件分开计数，路由实验才有参考价值。

假设两条路线分别接到 100 项相似的任务。较便宜的一条为所有尝试花了 50 美元，完成了 50 项可验收任务。另一条花了 90 美元，完成了 90 项。这个假设中，每个可接受结果的模型成本都是 1 美元。加上人工审核时间、工具费用和等待重试的代价，两条路线就可能不同。差异可能向任何一边倾斜。

失败尝试也要算在分子里。如果放弃的尝试从账目中消失，遇到难题就退出的路线也会显得很高效。成功的定义也要保持不变。修改文档可能只要差异获得批准，迁移则需要用已有数据测试，并保留回滚路径。

任务类别也很重要。全仓库迁移 API 的难点是掌握上下文、协调和许多小改动。涉及隐蔽的并发缺陷时，只改一行可能更难。文件数量和提示词长度只有在能预测你所在环境的结果时，才是有用的信号。

读路由实验时，同时看成本和通过率

路由实验。Telli.sh 原创示意图。

Baseten 的技术报告比较了始终使用 Opus 5.5，以及在该模型和 GLM 5.3 Flash 之间分配任务这两种办法。公司把 DeepSWE、SWE Atlas QnA 和 Terminal-Bench 的任务混合评估，报告了一个成本低 72%、通过率与始终使用 Opus 相差不超过 0.8 个百分点的设置。报告也和花费相近的随机路由作了比较。这一点很重要，因为即使靠抛硬币决定，把更多工作送给便宜模型也会降低平均模型成本。

路由阈值体现了你愿意为预期的成功支付多少。更重视费用，就可以把更多任务送到较便宜的路线。更看重结果时，另一种设置可以优先使用能力较强的模型。Baseten 的结果基于它选用的模型、任务和价格假设。你的团队有不同的工作分布，失败的代价也不同。

产品公告在早期基准测试中使用了成本最多降低 70% 的另一项取整数字。应把它和技术实验中的 72% 以及相应的通过率对比分开读。技术报告有价值的部分，是说明费用和表现如何一起变化。团队可以按自己看重的指标选一个点，再看这个点能否在实际工作中站得住脚。

网关可以让执行的策略看得见

Grid 公告介绍了获准模型、团队级控制和用量可见性。平台团队可以把组织评估过的模型提供给开发者，同时观察使用分布。即使还没有把路线选择交给系统，这也有助于弄清钱花在了哪里。

实际要做的决定有好几项。哪家服务商可以看到专有代码？某个仓库允许用哪些模型？重试预算由谁负责？出故障后谁能覆盖路线选择？只要管理员理解每项控制的范围，网关就可以成为共用的判断边界。

模型网关和代理运行环境是不同的控制点。网关可以决定请求发给哪个模型。代理能否读取凭证、写文件或访问网络，取决于工具或运行环境。限制路由要配合运行时权限才能发挥作用。较便宜的路线在使用高权限工具时，也需要遵守同样的约束。

证据也要有边界。路由日志能解释费用为什么变化，但追踪记录里也可能有代码、路径和客户故障的细节。要决定平台可以记什么、谁能看、能保留多久。开发者看不到策略时，遇到请求被拒或被送到了意外路线，就不容易排查。

更改默认设置前，先试试路由

1. 选两三类常见任务。既包括更新常规测试之类的简单工作，也包括需要向后兼容的迁移之类的困难工作。
2. 开始之前定义验收证据。编码任务可以要求回归测试通过、差异干净、审查人批准，并确认没有意外的文件改动。
3. 用当前默认模型记录基线。包括失败尝试、重试以及由开发者手动做完的工作。保留生产环境的安全和数据约束。
4. 在等价的任务上比较路由。如果有访问资格，连接账号前先看官方文档，核对网关支持的工具和权限。
5. 决定何时升级。初次失败可以触发第二个模型，但没有上限的重试可能比一开始就用强模型更贵。设置上限，并记录升级的原因。
6. 对结果出错影响较大的任务保留手动指定路线的方式。试验后在总成本和验收数据之外，也查看这些例外。

做内部试点，可以选取相似工作，对比由开发者选模型的时期与使用路由的时期。前者能借助开发者对仓库的熟悉，后者可能有更一致的策略和更好的可见性。把任务的差异记录下来，才看得出自动化在哪里有帮助，哪里还需要人的判断。

读一份条件对齐的任务记录

一个可行的起点是过去一个月已经完成的拉取请求。按最初的需求给任务打标签，例如依赖更新、有可复现测试的缺陷、跨仓库的改动，或者调查部署失败的开放式请求。为每项任务保存仓库版本和验收条件。选一组样本，分别用稳定基线和路由器重放，两边使用同样的工具、时间预算和测试环境。

依赖更新是一个含义比较明确的例子。指定的依赖变了，兼容性检查通过，拉取请求没有无关改动，就算成功。触及计费约定的工作需要更严格的审核，还可能需要人来理解不完整的需求。把这些任务类型分开，就能看清平均支出下降来自哪里。便宜路线在依赖更新中占优，却常常要重试才能改好计费逻辑时，可以给两类任务设不同路线。

把人工决定是否验收所花的时间也记下来。假设基线花 19 美元，在 20 项里交付 19 项可验收结果，而路由器花 9 美元交付 18 项。这个例子中，每项验收结果的模型成本分别是 1.00 美元和 0.50 美元。如果审核人员多花 20 分钟修正一个路由失败的结果，成本对比就会变化。组织可以把返工算进适合自己的指标，但金额和时间依然是不同的测量值。

弄清路由器用什么学习

Baseten 的技术文章列出了 DeepSWE 1.1、SWE Atlas QnA 和 Terminal-Bench 2.1。实验在任务中比较了 Claude Opus 5.5 和 GLM 5.3 Flash，并用未参与训练的数据评估路由器。这些细节影响结果能推广到哪里。找仓库里的代码位置，与运行命令行、使用外部工具或修改多个文件的工作，有不同的成本结构。客户侧的评估应能代表真正会发送的任务。

技术文章将 Cost、Balanced 和 Intelligence 描述为在请求时移动路由阈值的选项。产品团队可以利用这点做一轮影子对比。在同一套经授权的任务上重放，比较不同设置。如果集成会显示所选模型，就把它记下来。查看设置结果不一致的案例。如果高价路线主要用于团队认定敏感或难度高的任务，说明策略可能在发挥作用。如果分歧集中在一类普通的简单任务，就值得调整分类或策略。

把慢且昂贵的个案也算进去

平均延迟可能看不出一个难补丁经过好几个模型以后，用户实际等了多久。记录从发出请求到验收结果的实际时间，并标记重试、升级、超时和交接。只显示第一个模型响应时间的仪表盘，可能把处理人不得不重新开始的工作算成成功。把交接后的支出和时间也记进去。

大规模启用前，先给试验设上限。设定整个任务的预算，以及何时停止或交给更强模型的条件。失败的尝试应留下足够的证据，让下一次可以接着做。不要仅仅因为换了模型就重跑同一测试、重读同一文件。值得衡量的是事情实际推进了多少。

上线可以先从验收条件能自动判断、例外又能由人工核对的小范围任务开始。之后再加一类需要人判断是否验收的任务。分别比较每项验收成本、升级比例和审核耗时。换了一类工作还能保住收益，就更有依据设定默认策略。

模型换了，基线也要能用

某一周记录的结果，可能在模型、工具或仓库变化后过时。把模型标识、测试版本和验收规则与路线选择一起保存。调整策略时，重新运行少量有代表性的任务。保留几项代价高的失败，因为它们的成本容易淹没在均值里。

让审查人查看不同路线得出不同结果的案例，先不告诉他选了哪个模型。如果审查人也分不出哪份输出可以验收，应先改进验收条件，再多跑一些任务。团队就如何判断成功形成共识后，路由策略才更容易比较。

工作变了，路由策略也该跟着改进

路由的价值在于减少团队重复做同一项小决定。表现和费用能按同一工作单位衡量时，这个优势尤其明显。模型、价格和仓库都会变。保留基准任务并更新测试集，才能让策略跟上变化。

值得带进规划会议的数字，是团队为了交付可验收成果真正付了多少钱，并把相应的取舍说清楚。这样，工程负责人和预算负责人就有了共同的决策依据。

来源

• Baseten 11 月 4 日发布的 Grid 预览公告
• Baseten 11 月 4 日发布的 Router 技术报告

---

如果想把工作背后的对话和决定留成可搜索的记录，可以创建 Telli.sh 账号。