当需求是悬崖而非曲线时,如何进行 GPU 产能规划
当 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 正在做更多工作”的唯一信号是你的推理账单,那么当你发现时已经晚了三周,且容量早已跌入悬崖。
- https://www.spheron.network/blog/gpu-infrastructure-ai-agents-2026/
- https://www.bentoml.com/blog/where-to-buy-or-rent-gpus-for-llm-inference
- https://compute.exchange/blogs/reserved-vs.-on-demand-gpu-in-2026
- https://docs.cloud.google.com/vertex-ai/generative-ai/docs/provisioned-throughput/measure-provisioned-throughput
- https://www.finout.io/blog/provisioned-capacity-for-ai-a-beginners-guide-to-dedicated-vs.-on-demand-ai-capacity
- https://bentoml.com/llm/infrastructure-and-operations/fast-scaling
- https://www.yottalabs.ai/post/why-gpu-utilization-is-low-in-llm-inference-and-how-to-fix-it
- https://portkey.ai/blog/failover-routing-strategies-for-llms-in-production/
- https://docs.litellm.ai/docs/proxy/reliability
- https://openrouter.ai/docs/guides/routing/model-fallbacks
- https://www.netdata.cloud/academy/error-budget/
- https://platform.claude.com/docs/en/agent-sdk/agent-loop
- https://medium.com/@instatunnel/agentic-resource-exhaustion-the-infinite-loop-attack-of-the-ai-era-76a3f58c62e3
- https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices
