每天一百万次模型调用，团队队列的八步设计

01 · 第一步：把每天一百万次换算成容量边界

每天一百万次调用，平均每秒约十二次，但平均值不能决定队列容量。先按业务记录到达峰值、输入与输出令牌分布、调用耗时和允许等待时间。交互任务与夜间批处理必须分别测算。用到达速率乘以平均处理时间估算在途请求，再用压测验证尾部延迟，别直接把估算值当作安全并发上限。

02 · 第二步：先定义任务，再接入持久队列

每个任务应携带任务编号、租户、优先级、模型、截止时间、最大输出量和预算上限。正文较大时，只在队列中保存受控存储的引用。提交方收到持久化确认后才算入队成功；执行方通过有期限的租约领取任务，完成结果落库后再确认消费。租约过期可能导致重复执行，因此不能承诺天然“只执行一次”。

03 · 第三步：拆开交互、批处理与重试通道

不要让长文档批处理堵住等待即时反馈的用户。建立交互、普通批处理和延迟重试通道，并为不同租户分配权重与并发上限。优先级不能意味着无限抢占：给批处理保留最低处理份额，避免持续饥饿。积压超过阈值时，延后低优先级任务，或在入队前明确拒绝，而不是无限接收。

04 · 第四步：同时限制请求数、令牌数和在途量

调度器至少维护三道闸门：请求速率、令牌速率和并发量。按账户、模型与租户分层控制，只有全部获得许可才发起调用。流式响应从建立连接到结束都占用在途名额。额度不足的任务应等待下一次调度，不要占着工作线程休眠；收到限流响应后，动态降低发送速率。

05 · 第五步：派发前预留预算，完成后按实结算

使用估算输入量和输出上限预留费用，响应完成后按实际用量核销，并释放剩余额度。缓存写入与缓存读取需要分别核算，不能把命中缓存视为免费。Quanta 适合希望用一个余额管理多模型持续负载的团队，调用按实际令牌计量，缓存读写单独计价。可以开设 Quanta 账户，先用受控预算验证计费记录与内部台账能否对齐。

06 · 第六步：把重试变成有上限的恢复流程

只对明确可恢复的错误重试，采用指数退避与随机抖动，并设置最大次数和总截止时间；服务端提供等待提示时优先遵守。超时不一定代表上游没有执行，重发可能产生额外费用。用业务任务编号防止结果重复入库，对执行状态不明的调用单独记录和对账，不要宣称本地去重能够消除上游重复计费。

07 · 第七步：用最老任务年龄判断系统是否失速

仪表盘除了队列长度，还应展示最老任务年龄、排队时间、执行时间、限流比例、重试消耗和每个成功任务的成本。按租户与模型拆分观察，避免整体平均值掩盖局部拥堵。失败任务进入隔离队列，保留脱敏后的诊断信息；人工修复后按原任务编号恢复，防止整批盲目重放。

08 · 第八步：按预算与截止时间逐级放量

先以小流量验证领取、续租、确认和故障恢复，再逐级提高并发。压测应覆盖突发入队、限流、连接中断与工作节点退出。提前规定停止放量条件：等待时间超标、预算核销异常或重试持续增长。扩容只能解决执行能力不足；遇到上游限额或预算瓶颈，应降低接收速度、延期处理或明确拒绝，让积压始终可解释、可控制。