当 Agent 平台第一次崩溃时，事后分析报告（Postmortem）通常包含这样一句话：“周五我们还有八周的冗余容量。到了周一下午，我们已经达到了已配置容量的 140%。”没有人撒谎。容量模型本身是正确的，只是被应用到了一个它从未被设计用来应对的工作负载上。传统的容量规划假设需求沿着一条平滑曲线增长，周季节性是主导信号，最坏的情况是可以提前六个月规划的“黑色星期五”。Agent 工作负载彻底打破了这一假设。
Agent 需求的形态不是曲线，而是悬崖。有三件事造成了这种悬崖效应，并且它们会产生复合影响。一个企业级客户的入驻，就能根据你已经签署的合同通知，在通宵之间将基线移动 10 倍。一个 Agent 循环可以将微小的用户活动增长放大为扇出倍增的浪潮，对推理端的冲击比面向用户的图表显示的要高出 30 倍。单个产品变更——例如启用工具调用、延长上下文、切换到更大的模型——可以在用户数量不变的情况下，将单个任务的 Token 消耗提高一个数量级。
如果你的容量规划以 QPS 为单位，且你的冗余预算是“75% 的利用率是健康的”，那么你不是在规划。你是在赌这三个“悬崖”不会在同一个星期降临。
为什么 QPS 不再是正确的度量单位
无状态 Web 服务的容量规划是以 QPS 为导向的，因为每次请求的成本大致恒定。一次搜索查询就是一次搜索查询。方差足够小，以至于平滑曲线是真实存在的。
LLM 推理的工作方式并非如此。每次请求的成本由 Token 决定——输入 Token 决定预填充（prefill）计算量，输出 Token 决定解码（decode）计算量，在典型的上下文长度下，自回归解码器在每个输出 Token 上花费的时间大约是每个输入 Token 的 10 倍。一个 Agent 任务在数十次推理调用中可能会消耗 50,000 到 500,000 个 Token，这取决于工具调用树的深度。路由到同一个端点的两个请求，其成本差异可能达到两个数量级。
这意味着正确的单位在供给侧应该是 每秒每 GPU 的 Token 数（tokens per second per GPU），在需求侧应该是 每个任务的 Token 数 × 每个用户的任务数 × DAU。一个标榜“我们在 800ms 的 p95 延迟下提供 200 QPS”的容量模型，几乎无法告诉你下个季度能否撑过去，因为它没有说明这些查询消耗了哪些 Token。
一个有用的计算公式：
所需 tokens/sec = (每个任务的输入_tokens + 每个任务的输出_tokens) × 每天每个用户的任务数 × DAU / 每天的秒数 × 峰值因子 × 扇出倍数
公式中的每一项都是独立变化的。当产品变更时，每个任务的 Token 数会变化。当行为转变时，每个用户的任务数会变化。DAU 随着销售额增长。峰值因子随着地理位置变化。扇出倍数随着 Prompt 的修改而变化。QPS 预测将所有这些因素压缩成一个数字，从而丢失了结构。
扇出倍数是头等公民级别的容量输入项
团队最容易忘记追踪的、也是成本最高的一项指标就是扇出倍数（fanout multiplier）——即每个用户可见的任务在 Agent 循环内部生成了多少次模型调用。
Anthropic 的官方数据显示，Agent 消耗的 Token 大约是对话（Chat）的 4 倍，而多 Agent 系统则会将这一数字推高到 15 倍左右。关于循环工具组合（cyclic tool composition）的独立研究测量到，仅仅因为循环遍历工具图的方式，固定查询的 Token 消耗就会增加到 14.6 倍。这些都不会显示在面向用户的仪表盘上。用户发起一次“总结这份文档”。在 Agent 内部：一次规划器（planner）调用、六次检索调用、三次工具参数构建调用、两次当工具返回格式错误的输出时的重新规划调用、一次验证器（verifier）调用以及一次总结器调用。总共十三次模型调用。六次检索。注入回上下文的十二个工具结果负载。数万个 Token。
扇出倍数最危险的特性在于它是 Prompt 的函数，而不是用户的函数。一位资深工程师将规划器 Prompt 调整为“在选择工具前考虑三个替代方案”，因为这让评估得分提高了两个百分点。全网的扇出倍数从 8 变到了 22。评估变绿了。容量模型却没有变。三周后，其他因素让 DAU 增长了 5%，推理层就开始因报错而频繁触发报警。
能够捕捉到这一点的纪律是将扇出视为头等指标：
- 测量每个 Agent 类别的平均值和 p95 扇出，而不仅仅是按工作负载测量。
- 在每次 Prompt 或工具注册变更时，在变更合并到生产环境之前重新测量。
- 像追踪延迟回归一样追踪扇出倍数的回归——设置告警和预算。
- 将每个任务的 Token 消耗作为发布准入指标，而不是事后才去查看的仪表盘。
如果你判断“Agent 正在做更多工作”的唯一信号是你的推理账单，那么当你发现时已经晚了三周，且容量早已跌入悬崖。
预测之外的三个断崖
Agent 基础设施中会出现三种明显的断崖形状。每种都需要不同的机制来应对。
上线断崖（Onboarding cliffs）。一个新的企业客户在 3 月签约，5 月上线，带来了 40,000 名在你的预测中并不存在的日活用户。合同只给了你两周的运营通知。销售在 11 月就知道了，容量团队却是通过一条 Slack 消息才得知的。这里的解决方法是契约式和组织层面的，而非技术层面的：一旦交易达成，客户上线工作流就需要立即将预期的 DAU、预期的人均任务数以及上线日期写入容量预测系统。如果你的财务团队能根据同样的信号构建收入预测，你的基础设施团队就能构建负载预测。
扇出断崖（Fanout cliffs）。一次 prompt 编辑、向注册表添加一个工具、模型变更或上下文长度的增加，都可能让单个任务的 token 消耗增加 2 到 10 倍。这些在用户可见的指标中是隐形的。它们只出现在“人均任务 token 数”和“单 GPU 每秒 token 数”中。缓解措施是引入持续集成（CI）检查：如果固定评测集上的扇出乘数超过了配置的阈值，且未经审核确认，则直接判定构建失败。
行为断崖（Behavioral cliffs）。一个新功能上线后，原本每周使用两次 Agent 的用户开始每天使用 12 次。DAU 曲线几乎没有波动，但人均任务数增长了 6 倍。原本为 2.4 任务/用户/天设计的容量，现在需要处理 14.4 任务/用户/天。行为断崖是最难预测的，因为它们处于产品决策的下游，而这些决策并不总是会经过基础设施团队。防御性措施是将人均任务数作为一个单独跟踪、单独告警的指标——并将任何达到两位数的周环比变化视为规划事件，而非单纯的积极产品信号。
冗余量是个错误的问题
传统的容量规划将冗余量（headroom）定义为利用率百分比：“我们运行在 70%，拥有 30% 的冗余。”当最坏的情况只是正常的峰值是谷值的两倍时，这种做法是足够的。但对于断崖风险来说，这是错误的框架，因为断崖并不受历史流量的限制。
正确的框架是断崖生存能力（cliffs-survivable）。你当前的容量在不触发告警的情况下，能同时吸收这三个断崖中的几个？在同一周内同时发生上线断崖和扇出断崖是现实中的失效模式，而不是“周二下午 3 点我们的利用率短暂达到了 85%”。在断崖式工作负载中购买平滑曲线的利用率，正是导致发布日宕机的原因——因为你通过提高运行温度（利用率）节省的每一分钱，实际上都花在了“本周不会出现断崖”的假设上。
这里有一个反直觉的推论：在断崖式工作负载中，低 GPU 利用率通常是一个特性（feature），而不是一个 bug。一个在二级供应商处拥有 2 倍突发预算、以 45% 利用率运行的团队，在面对 10 倍的断崖时，虽然服务质量可能下降，但仍能维持可用。而那个一直将“利用率优化到 85%”的团队则会直接宕机。将利用率视为最大化目标的工具和仪表盘，本质上是在与这类工作负载作对。
这在财务对话中表现得非常明显。CFO 看到利用率低下的硬件会问为什么。诚实的回答是：在一个方差主导均值的工作负载中，利用率指标是错误的目标——正确的目标是，在不发生宕机的情况下，你可以吸收多少比例的现实断崖场景。重新定义指标，容量决策对于那些不必处理告警的人来说也会变得清晰易懂。
为断崖而设计的预留策略
一旦你接受了这种工作负载形状，一套特定的预留策略就顺理成章了。
预留底层容量（Reserve the floor）。为稳态最小值（而非平均值）确定长期承诺容量的规模。预留计划通常比按需付费低 30–50%，多年期承诺的折扣更高。这是最便宜的一层，你应该让它接近满负荷运行——但仅限于你非常有信心在 12 个月后依然存在的负载部分。
在二级供应商上进行突发扩容（Burst on a secondary provider）。通过路由层访问拥有按需容量的第二个供应商或第二个区域。每个 token 的价格更高。这没关系——你只需在尾部流量上摊销这部分高价。计算公式是：按需价格是预留价格的 2.5 倍，用于 8% 的总 token，与仅使用预留容量相比，综合成本增加了 12%。这 12% 就是你针对断崖期间宕机的保险费。如果断崖每季度发生一次，这笔保险费在第一次发生时就值回票价了。
将降级作为刻意的策略，而非后备方案。当突发定价超过阈值时，将非关键路径路由到较小的模型。客户支持摘要可以在流量激增期间运行在更便宜的模型上。而高风险的合同分析 Agent 则保留在旗舰模型上。这不仅是抽象意义上的优雅降级——它是一条带有每 token 价格阈值和每条路由质量预算的路由规则。
断路器，而非重试。当主供应商返回 429 或 5xx 错误超过阈值时（一个常见的规则：如果在 60 秒窗口内有 40% 的流量失败），绕过重试，将所有流量路由到等效的二级模型，并进入一段冷却期——比如 20 分钟——然后再重新测试主供应商。在断崖期间，重试风暴会将一次宕机变成两次。
这种技术栈的形态——承诺的底层、按需突发、模型降级、断路器切换——并不是你在事故发生时临时构建的决策树。它是预先部署好的，实现它的路由层是一等公民的生产服务，而不仅仅是一个配置文件。
落地后的成熟面貌
一个容量成熟的智能体平台，从内部看是这样的：其容量模型是以 token 计量的，而不是 QPS。扇出乘数 (fanout multiplier) 是针对每个智能体类别进行跟踪的指标，并配有在发生性能回归时报错的 CI 检查。销售漏斗在交易达成时（而非上线时）就会将入驻负载写入容量预测。预留策略拥有一个为确保稳定性而设定的承诺底线 (committed floor)，一个为应对极端峰值场景 (cliff scenarios) 而设定的按需突发层，以及一个当突发定价超出预算时能降级非关键路径的路由层。冗余度 (Headroom) 的报告标准是“能承受的峰值压力”，而非“利用率百分比”。值班工程师看到的仪表盘与 CFO 看到的仪表盘拥有共同的语言。
这一切背后的架构认知是：智能体工作负载的 GPU 容量并不是一个云成本优化问题。它是一个与你的错误预算 (error budget) 并存的可靠性问题。那些将其视为财务问题的团队，要么购买了难以负担的冗余，要么在最重要的时刻遭遇意外停机。而那些将其视为可靠性问题的团队则在做更枯燥的工作：以 token 为核心的容量计算、将扇出作为核心指标、对企业需求进行合同化度量，以及制定一套假设极端情况必然发生的预留策略。当危机降临时，只有他们仍在为客户提供服务。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
