Hightouch 今天在 Hacker News 上发了一篇博客，标题说 Jev 加 Opus 的混合路由「在 Opus 精度下便宜 4 倍」。发布十小时冲到 400 多分、90 多条评论（截至发稿）。
同一篇文章里还有另一个数字：开箱最多便宜 90 倍。
两个数字差 20 倍。评论区没有一个人指出这件事。
我把两个数都算了一遍，发现它们是同一个公式在两个参数下的取值。而我们上个月做完的另一组独立实测，数字落在同一个公式的另一个位置上，差 3%。
4.39 倍从哪来
先把他们的算术摊开。
Opus 5.5 处理 1000 条身份记录要 3.86 美元。Jev 处理同样的量要 0.05 美元。纯看单价，差 77 倍。
但他们的做法不是全程用 Jev。流程是：Jev 先判，置信度落在 30% 到 90% 之间的转给 Opus 复核。最终只有 22% 的请求被升级。
所以总成本是：
按 22% 的升级率理论估算，总成本是 0.05 + 0.22 × 3.86 ≈ 0.90 美元。原文表格里实测的总成本是 0.88 美元，比理论估算低 2%，差额来自升级样本的实际 token 数少于全量均价，不是取整。
3.86 除以 0.88 约等于 4.39。原文只写「> 4x」，4.39 是按表中成本折算出来的，这个数就是「便宜 4 倍」的全部来源。
注意这里混了两件事：单价比 77 倍，和实际升级比例 22%。4.39 是这两者合成的结果，不是模型本身的性质。
把「省多少」写成一个函数
设 r 是需要升级到大模型的比例，p 是小模型单价除大模型单价。
总成本等于小模型全量跑一遍，加上升级部分补的差价：
cost = p + r × (1 - p)省钱倍数就是它的倒数：
cost_multiple = 1 / (r + (1 - r) × p)代 Hightouch 的数进去，p = 0.05 / 3.86 = 0.01295，r = 0.22：
1 / (0.22 + 0.78 × 0.01295) = 4.35和他们公布的 4.39 差 0.9%，差异来自上文 0.88 与 0.90 两个成本口径。公式对得上。
他们自己的 Harder test，算出来是 1.83 倍
这是整件事有意思的地方。
同一篇博客里，除了 Easy set 的 0.88 美元，还报了一组 Harder test 的成本：Jev 单独跑 2.94 美元，Opus 单独跑 5.39 美元。
5.39 除以 2.94 等于 1.833。
这个数不是他们算出来的，是从他们的表格里除出来的。但它已经说明：换一组更难的样本，4.39 直接掉到 1.83。
把 1.833 代回公式反解 r：
1 / 1.833 = r + (1 - r) × 0.01295
0.5456 = r + 0.01295 - 0.01295r
0.5326 = 0.98705r
r = 53.9%也就是说，Harder test 上的升级率是 53.9%，不是 22%。标题里的 4 倍取的是 Easy set 那一档。
同一个模型，同一条流水线，同一套阈值，只是因为样本难度不同，省钱倍数从 4.39 掉到 1.83。顺带一提，这组 Harder test 上混合方案的准确率是 95.3%，比 Opus 单跑的 95.1% 还高 0.2 个百分点。
我们那组实测，1.77 倍已经顶到天花板
上个月我们对 Jev 做过四组实验。延迟部分做了 8 次采样，成本按实际 token 数核算，原始数据在公开仓库里。
测出来的单次成本是 0.0000255 美元，对比 DeepSeek 的 0.0000451 美元，倍数 1.77。
当时只觉得厂商宣传的 400 倍在真实工作流里不存在。现在把这组数字代进同一个公式才明白：1.77 不是我们测出来的性能，是这道题的满分。
因为 p = 0.0000255 / 0.0000451 = 0.5654，天花板是 1 / 0.5654 = 1.769。
我们的实测 1.77 已经接近这个成本比下的理论上限 1/p = 1.769，说明在低基准价下，升级率再怎么优化也很难拉开差距。不管 Jev 多快、升级率多低，拿它去省 DeepSeek 的钱，数学上都不可能超过 1.77 倍。我们一开始就站在终点线上。
Hightouch 之所以能报 4 倍，是因为它拿 Opus 做基准，p = 0.01295，天花板 77.2 倍。换成 DeepSeek 做基准，天花板立刻塌到 1.77。
基准选谁，决定了标题写 4 倍还是 1.8 倍。
速查表：4 倍是业务属性，不是模型属性
把公式画成表，横轴是升级率：
| 需要升级的比例 | 对 Opus 基准 | 对 DeepSeek 基准 |
|---|---|---|
| 0% | 77.2x | 1.769x |
| 10% | 8.96x | 1.642x |
| 22% | 4.35x | 1.513x |
| 30% | 3.24x | 1.437x |
| 40% | 2.45x | 1.353x |
| 53.9%（Hightouch Hard 集反推） | 1.83x | 1.25x |
| 60% | 1.65x | 1.210x |
| 74% | 1.35x | 1.127x |
| 90% | 1.11x | 1.045x |
| 100% | 1.00x | 1.000x |
读法很直接：如果你的业务有 74% 的请求需要升级，省的是 1.35 倍，不是 4 倍。到 90%，账面 1.11 倍已经接近持平；再算上双重调用带来的网络延迟与网关工程维护，实际就是倒贴钱。
你的业务难度，才是那个分母的实际取值。
这个反推不是我第一个做的
Hacker News 评论区里，一位叫 ezotony 的用户在本文结论之前就算出了同一件事。他用 (2.94 − 0.06) / 5.39 反推出约 53% 的升级率，指出这和 Easy set 的 22% 是同一个阈值跑出来的两个结果。
我做的事只是往前推了一步：把 53.9% 代回公式得到的 1.83，和另一组完全独立的实测 1.77，落在同一个位置。
两个不相干的数据集，一条公式，差 3%。这个吻合本身比任何一方的结论都更有说服力。
怎么用你自己的流量算
你需要两个数。
第一，p。查你和目标大模型的实际单价。这一步简单，但要用真实单次成本，不是官网标价除以假设的调用量。我们那次实测的 0.0000255 就是按实际 token 数算出来的，和标价换算差了将近一倍。
第二，r。这个难一点，因为升级率不是配置项，是数据属性。做法是拿真实流量跑一遍小模型，注意不能用平衡采样，统计置信度分布，落在升级区间内的比例就是 r。
拿到这两个数，代进 1 / (r + (1-r) × p)，得到的是你这套方案的省钱上限，不是别人的。
顺便说一句：那个 90 倍的宣传数字是纯单价口径，原文没交代算法，我能对上的最接近的一次推导是 Gemini 的 4.48 美元除以 Jev 的 0.05 等于 89.6，意味着升级率 0%。没有人有 0% 的升级率，除非那个任务简单到不需要小模型判断。
这个结论的边界
Hightouch 的基准是 Opus 5.5，任务是一个二元判定，单次调用，没有工具、没有多轮、没有检索。
换成多档评分题，情况会更差。我们用 12 篇 arXiv 论文的摘要跑同一道 1–5 分评分题（n=12，单次运行，无人工金标准）：Jev 只给出四个取值，一篇都没打满；DeepSeek 只给两个取值，12 篇里 9 篇直接打满。小模型在多档评分上更保守，置信度更容易落进升级区间，r 会被推高，4 倍会进一步缩水。
再换成自然分布流量，而不是 50/50 的平衡采样，r 通常比实验室里更高。这两个方向都让 4 倍往下走。
数据与出处
Jev 的原始数据在公开仓库里，8 次采样的中位数、最小值、最大值、波动区间都在：
Hightouch 原文：hightouch.com/blog/llm-judges-identity-resolution
HN 讨论：news.ycombinator.com/item?id=50397429
# AGENT-SUMMARY
任务：验证「AI 级联路由省钱倍数」的宣传口径与真实业务差距
核查方式：3 个独立 agent 并行
1. Hightouch 官方博客原文逐项核对（8 组数字）
2. 自有实测数据核对（CSV + 实测文章，7 组数字）
3. HN 评论区 93 条评论抓取（归功来源 + 反方论点）
核心结论：cost_multiple = 1/(r + (1-r)*p)
4.39x 对应 r=22%（Easy set）
Harder test 反推 r=53.9% → 1.83x
自有实测 1.77x = DeepSeek 基准下的理论上限 1.769x
数据复现：https://github.com/Wen199312/awendxb-benchmarks
微信扫码 · 微信支付
支付宝扫码本文采用 CC BY 4.0 许可。欢迎转载与引用，请注明作者并附上原文链接。
Licensed under CC BY 4.0. Quoting and republishing are welcome with attribution and a link back to this article.