同一把 key、不同时限：把交互式请求和通宵批处理分流到不同模型

很多团队只维护一把 API key，却把两类完全不同的负载塞进同一条链路：一类是用户在界面里等结果的交互式请求，另一类是没人盯着、跑几小时也无所谓的后台批处理。这两类负载对延迟、失败代价和单价的要求并不一样，混在一起通常是两边都不讨好。

先分清负载，而不是先挑模型

分流的第一步不是看模型排行榜，而是给每个调用点贴标签。判断依据是「谁在等」：

• 有人在等：用户正在看转圈动画，或者一次对话的下一句要立刻接上。延迟直接等于体验。
• 没人在等：夜间跑的语料清洗、历史工单分类、批量摘要、离线评测、文档重建索引。只要在下一个工作日之前跑完就行。

还有一个常被忽略的第三类：半交互。比如用户点「生成完整报告」后可以先看到进度条、几十秒内出结果也能接受。这类请求适合放在交互和批处理之间，用同一个模型但不同的超时与并发上限。

交互式链路：把 ttft 和尾延迟分开看

评估一个模型适不适合放前台，最少要看两个数：

• 首 token 延迟（ttft）：决定用户觉得「有没有反应」。
• 尾延迟（p95 / p99）：决定用户会不会偶尔遇到卡死。

平均值几乎没用。一个平均 1 秒、p99 却有 12 秒的模型，放在前台会让少数用户产生强烈挫败感；而在后台这条尾巴只是让批次晚几分钟结束。

由于聚合站是把请求转发到上游，你自测出来的延迟既包含上游模型本身的推理时间，也包含网络与排队。所以必须用你自己的调用路径去测，而不是照抄别人的 benchmark。测的时候注意：

• 每类任务用真实的大小和长度，不要用「你好」这种极端短 prompt。
• 记录 ttft、总时长、失败率，分开统计流式和非流式。
• 至少覆盖一天里的不同时段，观察高峰期是否明显劣化。

后台链路：延迟不敏感，但吞吐和成本敏感

后台任务的价值函数完全不同。它关心的是：单位时间内能处理多少条、每条花多少钱、失败后重跑代价大不大。因此：

• 它更适合长上下文、慢但便宜的模型。
• 它天然容忍排队，所以可以用并发上限 + 队列来平滑峰值，而不是拼命加并发。
• 它必须假定失败是常态：批处理任务里偶发的限流、超时、内容过滤都会出现。

用你自己的数据填一张决策表

不要照抄任何现成表格，包括下面这张。它只是模板，每一行都要用你实测的数字替换。

| 负载类型 | 关键指标 | 选择倾向 | 失败处理 |
| --- | --- | --- | --- |
| 前台对话 / 补全 | ttft 低、p99 稳定 | 优先响应快的模型，哪怕单价更高 | 立即降级到备用模型或兜底文案 |
| 前台但可等待（生成报告等） | 总时长可接受、成本中等 | 中等模型，允许几十秒 | 超时后转后台任务并通知 |
| 后台批处理 | 吞吐、单条成本、成功率 | 便宜、长上下文、慢一点没关系 | 指数退避重试 + 死信队列 |
| 离线评测 / 回归 | 可复现、可对比 | 固定版本、固定参数，不追新 | 整批重跑优于逐条补救 |

填表的顺序建议是：先按上面的负载类型分组，再把你实测过的每个模型往格子里放。同一个模型可能同时出现在前台和后台两行，这很正常——分流本来就是按调用点划分的，不是给模型贴死标签。

一把 key 怎么落到代码里

用同一把 key 调多个模型，是聚合站最实用的地方：换模型通常只是改一个模型名参数，不需要重新走接入、计费、密钥管理。落地时有几个细节值得注意。

• 显式配置，不要靠默认值。如果代码里到处是「不传模型就用默认」，前台请求可能在某次改动后悄悄落到慢模型上，而你要过很久才发现。把「哪个调用点用哪个模型」集中成一份配置。
• 超时和重试按链路分开设。前台超时要短，宁可降级；后台超时可以长，重试次数可以多。用同一套重试策略套在两类请求上，前后台总有一边被拖累。
• 区分可重试和不可重试的错误。限流、超时、上游 5xx 这类可以退避重试；参数错误、内容被拒这类重试多少次都一样，应该直接进死信队列。
• 给后台任务留出预算上限。批处理最容易失控的不是单条价格，而是「一个 bug 让队列反复重跑」。设一个批次级别的花费或条数上限，超了停下来。
• 记录模型名和用量。聚合站按模型计费，把每次调用的模型名、输入输出量、耗时记下来，你才可能回过头去校准上面那张表。

成本结构也要算进去

这个站点的计费方式是：你调用模型按官方价 ×1.3 扣费；如果你贡献自己的 key，按官方价 ×1.1（优质 ×1.2）返 USDC。也就是说，真正决定账单的是你把多少 token 放到了哪个模型上。

这给分流加了一条经济上的直觉：

• 前台请求通常量少、单次短，多付一点换响应速度是划算的。
• 后台批处理的 token 量往往大一个数量级，模型档位选高一级，账单上的差别会被放大很多倍。

所以对绝大多数项目，「交互式用小而快的模型、批处理用便宜耐跑的模型」不仅是体验决定，也是成本决定。反过来，把长文档批处理塞给最贵的模型，往往是最容易省下来的那笔钱。

怎么验证分流真的生效

改完之后别只看总账单。至少盯这几个指标：

• 前台链路的 ttft 和 p99 是否真的下降，还是只是被平均值掩盖了。
• 后台队列的积压深度是否收敛，会不会在高峰期越堆越长。
• 降级触发的次数：如果前台经常走到备用模型，说明主选模型其实不合适。
• 每类负载的模型分布，确认没有调用点漏配。

分流的本质是承认两类请求要的东西不一样。用一把 key 把这件事做简单，但用一张基于自己实测数据的表把决策做扎实。