企业 AI 容量怎么规划：任务量、模型配额和队列背压分别算

将客服问答、资料检索、批量整理和业务写入分别归组。每类任务记录到达频率、输入大小、输出规模、模型调用次数、工具依赖及完成期限。请求量相同的两类任务，可能占用完全不同的资源。

一件任务使用三次模型调用，受理十件任务不等于只有十个模型请求。多 Agent、复核与重试会增加调用；等待工具或人工会延长任务占用状态，却不一定一直占用模型并发。任务执行槽位和模型请求槽位分别管理。

同时观察平均负载与峰值。每天总量适合估算账单，不足以判断上班后十分钟的排队。按业务需要采集负载窗口与分布，保留峰值来源，避免以全天均值替代容量要求。

供应商可能按部署、模型、区域、订阅或其他范围设定额度，并用自身窗口与估算方式判定限流。读取实际部署说明，记录单位与范围。平均 token 消耗可用于负载估算，但服务可能参考最大输出配置或其他请求估算，不能只靠月底计费明细推定所有请求都不会被限流。

假设每分钟到达 20 件同类任务，每件正常路径平均调用模型三次，每次平均实际输入与输出合计 1600 token。演算得到正常路径约 60 次模型请求、96000 token 每分钟。数字只用于负载拆解，不是任何模型或平台的额度与性能。

如果平均每次模型调用占用 20 秒，在到达与处理都稳定、没有突发时，60 次每分钟对应平均约 20 个同时进行的模型请求。这个粗算不包含任务峰值、长尾和排队，也不能把它当作 20 并发就一定达标的配置结论。

将重试、额外审核和工具等待单列。某类失败每件多调用两次模型，会明显改变请求预算；一份特别长的合同也可能主导 token 消耗。正式规划用自己的分布和压测结果，不将平均值乘一个任意系数就视为容量验证。

Microsoft 的预配吞吐文档说明预配部署与 PTU 的容量概念，并用请求形状、输出与输入的处理比例和缓存命中率估算所需容量。不同模型的换算参数不同；前面的平均实际 token 总量也不等于文档中的归一化容量口径。本文不提供“一个 PTU 等于多少件业务任务”的固定换算。

文档还区分 PTU 配额与实际可部署容量：拥有配额不保证所选区域与模型版本仍有足够资源。核对具体模型与版本的支持条件、实时可用容量、计费和扩展方式，再用预计任务混合与峰值测试。缩容或删除后释放的资源不保证之后可以重新取得。

模型请求等待改善后，数据库查询、检索、OCR 或外部写入仍可能成为瓶颈，应在完整任务中分别观察。预配与按量选择还涉及流量稳定性和业务预算，比较时包含正常负载、峰值等待、失败处置和闲置成本。部署请求成功不是业务容量已经通过验收。

设置队列长度或资源预算上限，并给任务保存受理时间、截止条件和当前状态。任务开始执行前检查剩余时间，模型、工具与重试继续共享该任务预算；已经超过期限的任务停止未提交动作并按规则通知或接管。

队列满时可以拒绝新增受理、降低非关键批处理速度、让请求方稍后重试或安排人工处理。选择应由业务要求决定，并给用户明确状态。无限排队只把过载变成更晚的失败，还可能增加存储和重复请求。

对模型限流实施调用层背压，同时限制业务受理，避免上层不停生成新任务。流式返回的首段内容不能代表后续工具动作已经完成。任务是否仍有机会在期限内交付，要看整个处理链路。

多个部门共用资源时，依据服务端确认的部门或租户范围分配配额与队列权重。保留必要的交互任务能力，批处理使用明确预算；一个部门大量重试不应吞掉其他部门全部处理机会。公平不一定是平均分配，但规则应公开且可检查。

AWS 的重试指导强调限制重试、使用退避与抖动，并避免多层重试放大。业务客户端、工作流和工具 SDK 都重试时，总调用量可能远高于单层设置，需要明确哪一层负责及总尝试预算。

服务已限流时，立即无上限重试会继续增加压力。遵循适用的服务等待指示，受控安排后续尝试；超出任务截止条件时停止并报告，而不是持续循环直到用户离开。不能重试的验证和权限错误应直接进入对应处理。

写入结果未知还需先查询权威结果。重试容量不仅要算请求次数，也要检查同一业务意图的幂等契约；队列恢复后重新生成请求编号，可能把原先的网络问题变成重复工单。

测试使用获授权的环境与明确负载上限，避免直接向真实客户系统制造请求洪峰。压力升高时既看吞吐和延时，也看错误、部分完成、转交与资源消耗。容量计划说明已验证范围及扩容触发条件；当任务类型、模型或工具变化，再复测受影响部分。