model=auto 下延迟和成本打架时：为一个工作负载把选择钉死

model=auto 用起来省心：调用方不指定模型，由网关按当时的可用性、负载和价格策略挑一个。但省心的代价是——你的工作负载特性被折叠成一条统一的路由规则。当同一套 auto 同时服务交互式请求和后台批处理时，延迟与成本就会开始互相拉扯。

auto 路由在优化什么

聚合网关的自动路由通常综合几个信号：候选模型的健康度与配额、当前排队情况、单位 token 的计费成本，以及请求本身的形态（上下文长度、是否流式、是否带工具）。它给出的是一个"综合最优"，而不是"对你这个业务最优"。

这一点很关键：综合最优意味着它会在某些时刻牺牲延迟换成本，在另一些时刻反过来。对你的交互场景来说，这种摆动不可预测；对你的批处理来说，这种摆动又常常是多余的。

延迟敏感的交互任务

对话补全、IDE 内联建议、客服实时回复这类场景，用户体验直接绑定首 token 时间和总响应时间。

在 auto 下常见的问题：

• 请求被路由到更便宜的模型或更空闲但更远的后端，单次耗时波动大；
• 高峰期为了分散压力，同一会话的连续请求落到不同模型，导致风格、格式甚至工具调用行为不一致；
• 流式的首包时间不稳定，前端加载态难以设计。

这类工作负载真正需要的是可预测的上界，而不是平均值好看。

成本敏感的批处理任务

离线摘要、数据清洗、内容分类、批量翻译这类任务，延迟以分钟甚至小时计，吞吐和单价才是主变量。

在 auto 下常见的问题：

• 路由为保障整体健康度把请求导向高价模型，成本被动上升；
• 无法通过"换便宜模型 + 重试"来主动压成本，因为选哪个模型不由你决定；
• 任务的可复现性差：同一批输入在不同时间跑出不同的模型分布，评测和回归失去基准。

批处理要的是可控的单位成本和可复现的模型集合。

什么时候该从 auto 切回显式别名

出现下面任一信号，就说明该钉死了：

• 有明确的延迟 SLO，且 auto 的 P95 反复越线；
• 同一会话/同一任务需要模型行为一致（提示词针对特定模型调过）；
• 成本需要预算化，波动无法向业务方解释；
• 做评测、回归或 A/B，必须固定变量；
• 需要按任务分层：交互走低延迟模型，批处理走低成本模型。

反过来，探索期、流量小、对延迟和成本都不敏感的内部工具，继续用 auto 是合理的。

怎么钉：分层而不是一刀切

不要全局关掉 auto，而是按工作负载拆成两组显式别名：

• 交互组：选一个首 token 稳定的模型，流式开启，不设自动降级；
• 批处理组：选单位成本最低且满足质量下限的模型，允许并发与重试。

在聚合站上，这通常只是把请求里的 model 字段从 auto 换成对应别名，其余参数不变，切换成本很低。建议先在非关键路径上跑一段时间，比对两组的延迟分布和实际扣费，再决定是否扩大范围。

成本侧要一起算

本站按官方价 ×1.3 扣费，贡献 key 按官方价 ×1.1（优质 ×1.2）返 USDC。这意味着显式指定模型之后，你依然能享受统一计费和单一 API key 的便利——钉死模型只影响路由结果，不影响结算方式。所以切回显式别名不是"放弃聚合的好处"，而是把路由决策从网关手里拿回到自己手里。

一个务实的迁移顺序

1. 按延迟敏感度给现有调用打标，分出交互与批处理两条流；
2. 交互流先切显式别名，观察首 token 时间和错误率；
3. 批处理流随后切换，用同批输入对比成本与质量；
4. 保留 auto 作为兜底分支，用于新功能探索和低优先级任务；
5. 定期复核：模型供给和价格会变，钉死的选择也需要重新评估。

小结

auto 适合不确定的工作负载，显式别名适合已被理解的工作负载。延迟和成本打架时，胜出的不该是网关的综合最优，而是你对这个业务的明确取舍。