9 篇博文 含有标签「capacity-planning」

一位容量规划师带着基于干净的过去四周回溯窗口构建的 Token 预测走进了季度预算审查会议。这四周中有三周恰好跨越了一个地区性假期。在此期间，日活跃会话下降了 40%。预测结果比 Q+1 的实际消耗低了 35%，限流仪表盘在新季度的第一天就全线飘红，而复盘发现模型的表现完全符合预期——它计算了最近四周需求的平均值并进行了向前预测。模型没有错。错的是窗口。

这不是一个关于蹩脚预测者的故事。这是一个关于将 LLM Token 支出视为与它共用成本中心的 EC2 账单相同形态的故事。EC2 账单受你控制的基础设施决策支配：配置的实例、预留容量以及响应负载的扩展策略。而 Token 账单则受决定休长假的用户的支配。前者是工程输出，后者是消费者需求。如果规划者混淆了两者，就会不断地在日历确保是非平稳的窗口上构建预测。

当你的应用程序第一次从模型供应商那里收到 429 错误时，发生了一些重要的事情，但几乎没人注意到。并不是错误本身，而是接下来执行的那行代码。也许你的 HTTP 客户端会以指数退避进行重试。也许它会降级到更小的模型。也许它会将请求排队，或者直接丢弃，又或者显示一个永远无法解决的加载动画。无论它做什么，这种行为现在就是你的容量策略。它决定了当供不应求时，哪些用户能获得服务，哪些用户的体验会降级。

而且，几乎可以肯定你并没有亲自制定过这个策略。它是由编写 SDK 封装的人、重试装饰器，或者是某人从教程中复制的三行 try/except 代码决定的。在负载下，你的系统中最重要的决策——当无法兼顾所有任务时该怎么办——正由一段没人审视过的代码作为容量决策来执行。

这篇文章的观点是，你应该把这段代码视为它的真实面貌：一个负载削减策略和一个容量计划，而不是一个错误处理器。429 并不是问题所在。问题在于你已经将系统在资源竞争下的行为设计，外包给了库的默认设置。

传统的容量规划（capacity planning）建立在一个默认的假设之上：请求在大体上是可以互换的。Web 服务器处理登录、搜索、结账 —— 尽管这些操作有所不同，但它们的差异都在一个范围之内。你衡量每秒请求数（RPS），观察 p50 和 p99 延迟，乘以安全系数，然后进行资源配置。这个模型之所以有效，是因为工作的基本单位 —— 单个请求 —— 具有稳定的成本。

Agent（智能体）的工作负载从根本上打破了这个假设。你对 Agent 的一个查询可能通过一次简单的生成就解决了：300 个 token 输入，200 个输出，两秒钟搞定。但下一个查询，表面上看起来一模一样，却可能触发一个规划步骤，分发出 40 个工具调用（tool calls），在每一轮对话中重新读取不断增长的上下文，并在四分钟内消耗掉 120 万个 token。同样的端点（endpoint），同一个用户，同一条代码路径。单个请求的成本差异可能达到三个数量级，而且请求中没有任何信息能预先告诉你接下来会遇到哪种情况。

十四个月前，在你公司的某个角落，一位财务总监和一位平台负责人签署了一份为期数年的算力加速器资源承诺协议。他们根据前一个季度的遥测数据构建了一个峰值负载模型，谈到了比按需计费价格低 40% 到 70% 的折扣，并锁定了集群的规格——而你现在的产品路线图必须去适应这个规格。产品团队中没有人参与过那次会议。应用工程团队中也没有人见过那份电子表格。这份合同具有法律约束力，只有在履行承诺的前提下才能享受折扣，而它买下的容量边界，现在成了产品经理们正在规划的每一个第三季度功能的隐形天花板。

大多数团队直到第二年才会察觉到这个差距：容量合同本质上是路线图决策，但它们是由那些看不见路线图的人，使用不包含路线图信息的输入数据做出的。产品“三人组”认为他们正从一个清晰的优先级积压任务中挑选功能。财务部门认为他们正在优化一个固定的预算边界。在各自的语境下他们都是正确的，而冲突则会在规划会议上显现——当架构师提议为新的助手功能使用 700 亿参数模型时，平台负责人会平静地说，集群使用率已经达到 85%，如果不挤掉其他项目，这个模型根本放不下。

我曾合作过的一个团队发布了一个他们称之为 “小规模” 的功能：一个供几百名分析师使用的内部研究助手。他们的容量模型认为一次用户请求等于一次模型调用，因此他们根据峰值用户 QPS，并预留了标准的 30% 突发余量来设定预置吞吐量（provisioned throughput）的大小。发布当天，他们在不到一小时内就遇到了 429 错误，原本应该只消耗 40% 预留容量的流量却让容量达到了 100% 的饱和状态。事后复盘发现了一个之前没有人算进去的数字：平均每个请求触发了 11 次模型调用，而不是 1 次。

这是我在 Agent 推广过程中看到的最常见的容量估算失误。其中的数学逻辑并不复杂，失败模式也并不罕见。团队问错了单位问题——他们以用户请求为单位进行规划，而计费表是按模型调用次数计次的——他们支付真金白银买下的预留容量，在一种如果换成聊天产品本应被视为轻负载的压力下化为乌有。

打开你的 AI 功能延迟和质量看板，眯起眼睛仔细看。曲线大部分时间是平缓的，偶尔会有一些峰值，你的团队几个月来一直称之为“噪音”或“供应商异常”。现在，按小时和星期几来拆分这些数据。噪音显现出了真面目：在东部时间每个周一上午 9 点到 11 点之间，你的 p95 延迟比周六晚上高出 30–60%，缓存命中率下降 10–20 个点，重试率翻倍，每个任务的 token 支出也在悄然攀升。看板没有撒谎，它只是在做平均。

大多数团队发现这种模式的方式就像发现缓慢漏水一样：通过回溯没人能解释的季度账单。直觉是将其归结为供应商的不稳定性，给推理厂商提个工单，然后就此作罢。但这种模式其实与你的 LLM 供应商无关。事实是，你的 AI 功能现在构建在一堆共享的、对时间敏感的系统之上——模型 API、embedding API、你的 agent 调用的 SaaS 工具、接收 webhook 的客户自身基础设施——而其中每一个系统的周期性负载模式都会发生叠加。你继承了整个依赖链的昼夜曲线，而你的看板向你展示的是所有这些曲线的平均值。

你的财务团队会要求你提供一份你写不出来的容量规划。这不是因为你缺乏经验，也不是因为模型是新事物，而是因为经典容量规划所依赖的两个假设——可衡量的负载分布和在季度维度上稳定的单位成本——在 AI 工作负载面前都失效了。你交给他们的数字从第一天起就会是错的，而当偏差出现时，随后的讨论将不仅仅关乎账单。

《2026 年 FinOps 现状报告》将 AI 列为增长最快的新支出类别，大多数受访者表示 AI 成本超出了最初的预算预测——对于许多企业来说，推理现在消耗了 AI 账单的大部分。用 SaaS 风格的容量规划来管理它的本能反应——选择一个峰值 QPS，乘以单位成本，再加上 30% 的缓冲——产生的数字看起来像预测，其实际预测能力却如同占星术。你真正需要的容量规划看起来更像是 FinOps 场景模型，而不是采购电子表格，而生成它所需的工程工作属于平台工作，会一直与功能开发竞争资源，直到财务部门失去耐心。

黑色星期五的流量峰值来了。传统 API 服务的应对方式是启动更多容器。60 秒之内，你的容量就扩充到三倍。自动扩缩容器做了它一贯的事，你安然入睡。

但如果用同一个自动扩缩容器跑 LLM，结果就大相径庭了。新的 GPU 实例要在四分钟的模型权重加载之后才能上线。等那时候，你的请求队列已经塞满，现有 GPU 在半途生成的请求的内存压力下颠簸挣扎，用户盯着转圈圈的加载动画发呆。增加更多算力没有任何帮助——瓶颈根本不在你以为的地方。

AI 推理负载打破了让响应式自动扩缩容在传统服务中奏效的大多数假设。理解其中的原因，是构建能够扛住流量峰值的系统的前提。

你的负载均衡器将请求均匀地分配到你的 GPU 集群中。每个实例接收到的并发请求数量大致相同。一切看起来都很均衡。然而，一个实例的运行速度缓慢，仅为每秒 40 个 token，而另一个实例却能稳定在 200 个。仪表板显示请求数相等，但你的用户体验到的延迟却天差地别。

问题的根源在于：传统的负载均衡在请求层面运行，但 LLM 推理成本是随 token 数量扩展的。一个要求生成 4,000 个 token 文章的请求所消耗的 GPU 时间，是一个生成 80 个 token 分类结果请求的 50 倍。将它们视为同等单位，就像高速公路收费站只计算车辆数量而不区分摩托车和 18 轮大卡车一样。

这种请求层面的思维与 token 层面的现实之间的不匹配，正是古典排队论面临的最有趣的现代挑战。