日均百万次模型调用：团队该把队列边界画在哪里

团队手册ZH2026-10-294 次阅读

01 · 百万次日调用，先算峰值再配并发

每天一百万次调用，平均每秒约十二次，但平均值会掩盖批量导入、定时任务和集中上线带来的峰值。负责人先问三件事：请求何时集中到达、任务最长能等多久、失败后是否值得重做。

用到达速率乘以平均执行时长，可以粗估所需并发；再结合延迟分布、输入输出长度和服务限额校验。请求数相同，长文本任务也可能占用更多容量。

至少分出交互、后台和补偿任务三类。交互任务设置短截止时间，批处理允许等待，补偿任务限制吞吐，避免故障恢复时挤占正常流量。

每类再按团队分配份额，并给低优先级任务保留最低处理能力。否则，一个部门的批量任务可能堵住其他团队，持续插队也会让后台任务永远跑不完。

工作进程多，不代表可用容量大。调度器应同时检查请求速率、令牌预算和在途并发；共享上游额度的队列，也要共享限流状态。

提交时预估输入与输出令牌，完成后按实际用量校正。队列过长时启动背压：延后接收批任务、拒绝过期请求，或暂停非必要生产任务，防止积压继续扩大。

只对适合恢复的错误重试，采用指数退避和随机抖动，并遵守服务端给出的等待时间。参数错误应直接处理，不能反复排队。

任务携带稳定标识，结果写入须能去重。超时不代表上游没有执行，重新调用可能再次计费。超过重试次数或截止时间的任务进入隔离队列，等待检查。

预算应成为准入条件。使用 Quanta 承接持续调用时，一个余额可覆盖多种模型，按实际令牌计量，缓存写入与读取分别计价。团队可开设一个账户，先用小批量任务验证成本与排队策略。

为每条业务队列设置日预算和单任务上限；缓存收益应按实际命中核算，避免把重复提交当成低成本调用。

先放少量流量，检查队列最老任务年龄、等待时间分位数、成功率、重试比例与实际支出，再逐步扩大。给扩容、暂停和恢复明确的负责人及触发条件，让积压出现时有人能够及时决策。