全部摊开，包括变难看的。
一个编造的参考部署：中等规模的 AI 客服 + 文档问答产品，每月八百万次调用，六个月里从单一旗舰档搬到调度阶梯。下面每个数字都出自这同一个模型，所以它们之间可以互相对账。
三个我们不太想印的数字
它们放在页面靠上而不是脚注里，因为一个只会变好的页面不值得相信。
+1%
P99 延迟变差 1%
升级的请求跑两跳，而它们正好落在尾巴上。同一次跑里中位延迟降了 58%——这个取舍就是产品本身，不是意外。
20%
/review 只省了 20%
它的下限是裁判分 p10 ≥ 84，已经贴近旗舰以下档位够得着的天花板。本来就没多少便宜路可走，硬走就会破下限。
11%
过路由吃掉约 11% 的账单
8.7% 的调用被判高了一档，悄悄多花了钱。把阈值调紧能压下去，换来的是升级率上涨。
参考部署
编造的、固定的，全站都用它。如果别处哪个数字跟这张表对不上，是那个数字错了。
| 参数 | 值 | 说明 |
|---|---|---|
| 每月调用量 | 8,000,000 | 3 / 12 · 平均 / 峰值每秒请求数 |
| 每次调用输入 / 输出 token | 1,800 / 320 | 960 · 同一个问题，深推理档要多出不少输出 |
| 基线档（未路由前） | L-3 | 6% 的基线调用是重试 |
| 端点数 | 4 | 各端点份额见下一张表 |
| 阶梯矩阵里的档位 | 23 | 来自七家供应商的中立代号，其中四个是自托管权重 |
四个端点，各自对自己的下限交卷
每个端点自己声明下限，量纲也自己挑：散文类用裁判分分位，结构化输出用 schema 通过率。四个端点都在自己声明的下限之上。降幅之间差三倍，原因每次都是下限。
按份额加权是 65.0%（影子重放还没摊进来），摊进来之后是 64%。
难度带 × 档位 的裁判分
这才是当初该拿来选型的那张表。在一批不分难度的流量上测，旗舰以下的档位全都很难看——因为例行问题和硬问题被平均到了一起。把同一批流量按难度带切开，在占 42% 流量的那一带上，便宜档和旗舰档看不出差别。
| 档位 | D1 例行 · 42% | D2 常规 · 34% | D3 复杂 · 19% | D4 高风险 · 5% |
|---|---|---|---|---|
| C-0 | 88.2 | 85.0 | — | — |
| S-1 | 86.8 | 79.4 | 66.1 | 51.8 |
| M-2 | 89.1 | 86.1 | 76.3 | 63.2 |
| L-3 | 90.4 | 89.8 | 87.9 | 78.6 |
| L-3R | 90.6 | 90.2 | 89.4 | 85.4 |
平均下来是这样
| 口径 | 整体裁判分 |
|---|---|
| 基线：全量走旗舰档 | 89.1 |
| 调度后：只算首选档 | 85.8 |
| 调度后：算上阶梯 | 86.8 |
尾巴反而是往好里走的
整体裁判分掉了 2.3 分，我们不藏。p5 尾部涨了 2.8 分，因为声明过的下限会逼着系统把最烂的那批答案重做一遍——单档架构根本不会注意到它们烂，它没有参照物。
- +2.8尾巴反而是往好里走的p5 68.4 → 71.2
六个月的账单
真正要看的是两条线之间的面积：实际付的钱，和同样这些流量继续全量走旗舰档要付的钱。同期请求量涨了 30%，所以反事实那条线在往上爬，账单那条在往下掉。
| 月份 | 调用量（百万） | 调度覆盖率 | 账单 | 全量旗舰的话 |
|---|---|---|---|---|
| M0 基线 | 8.0 | 0% | $86.5k | $86.5k |
| M1 | 8.2 | 15% | $80.1k | $88.6k |
| M2 | 8.5 | 35% | $71.3k | $91.9k |
| M3 | 8.9 | 60% | $59.2k | $96.2k |
| M4 | 9.4 | 82% | $48.2k | $101.6k |
| M5 | 9.9 | 95% | $41.8k | $107.0k |
| M6 | 10.4 | 100% | $40.4k | $112.4k |
五条里有三条是我们自己吃掉的，不是供应商的：升级时被丢弃的低档调用、3% 的影子重放、分类器摊销。加起来 0.21 美元/千次，占调度后成本的 5.4%。写出来是因为不写的话，你的账会比 PPT 上的难看。
| 项目 | 美元 / 千次调用 |
|---|---|
| 模型推理（五档混合） | $3.669 |
| 升级浪费（丢弃的低档调用） | $0.073 |
| 影子重放（3% 流量） | $0.105 |
| 指纹分类器（自托管摊销） | $0.030 |
| 裁判评分（6% 抽样） | $0.007 |
| 合计 | $3.884 |
单位答案成本
按 token 算账算的是尝试次数。这个口径算的是真正被采纳的答案，分子里装着重试、被丢弃的低档调用、裁判抽样和影子重放。我们只认这一个口径。
| 口径 | 单位成本 | 采纳率 | 单位答案成本 |
|---|---|---|---|
| 基线 | $10.81 | 94.1% | $11.49 |
| 调度后 | $3.88 | 94.6% | $4.11 |
两条延迟分布
大多数请求变快了，因为它们本来就不难。升级的那部分要付两跳的钱，而它们恰好堆在尾巴原本就在的地方。
| 分位 | 基线 | 调度后 | 变化 |
|---|---|---|---|
| P50 | 2,265ms | 955ms | −58% |
| P75 | 3,532ms | 1,927ms | −45% |
| P90 | 5,911ms | 4,223ms | −29% |
| P95 | 7,545ms | 7,257ms | −4% |
| P99 | 13,332ms | 13,511ms | +1% |
Switchyard 自己加了多少
中位 6 毫秒，p95 11 毫秒，p99 19 毫秒；其中指纹在 p95 占 9 毫秒，决策加预算检查占 4 毫秒。跟它挑出来的那次模型调用比，这是个舍入误差——这也是这件事值得做的唯一前提。
- 11ms调度自身开销p50 6 · p99 19
- 9 / 4 毫秒指纹 / 决策与预算，p95p95
一次有损可用，复盘
一次示意事件：旗舰档上游的 429 率在八分钟里从 0.3% 冲到 31.4%。下面是状态机对此做了什么。
时间线
- t = 0
- 上游 429 率 0.3%。normal。只有那个滚动 60 秒窗口在盯着。
- t = 4 分
- 窗口越线之后 40 秒，/chat 与 /docqa 进入 brownout。检测时限目标是 60 秒，这次用了 40 秒。
- 动作
- 顶档由旗舰档换成中型档，输出上限从 1,024 压到 512，关掉深推理档。
- 峰值
- 上游失败率峰值 31.4%。用户侧错误率峰值 1.1%。最糟的时候 41% 的应答来自降级档，整体裁判分掉到 81.6。
- t = 30 分
- 上游回到 0.3%。冷却让降级阶梯再多用十分钟，然后顶档按放量曲线回来。
这笔账
上游 31.4% 的调用在失败，用户侧错误率峰值 1.1%。代价付在质量上而不是可用性上：41% 的应答走了降级档，整体裁判分有大约二十分钟掉了五分左右。
触发规则：上游 5xx 与 429 在 60 秒内超过 8%。
示意事件：旗舰档上游 429 率从 0.3% 冲到 31.4%