AI 工作负载的容量规划：当 Token 成为你的核心资源时，传统方法为何失效

你的 GPU 监控面板正在欺骗你。利用率显示 60%，推理集群看起来健康无虞。用户却在经历 8 秒的首 Token 时间（TTFT）。值班工程师检查内存——正常。计算——正常。然而队列在增长，延迟在飙升。这就是将传统容量规划应用于 LLM 工作负载时会发生的事：你信赖的指标指向了错误的地方，真正的瓶颈在用户开始抱怨之前一直不可见。

根本问题在于：LLM 消耗的是一种本质上不同的资源。CPU 服务交换的是计算和内存。LLM 服务交换的是 Token——而 Token 的行为与请求截然不同。

为什么 Token 不等于请求

在传统 Web 服务中，你根据并发请求数和响应时间来进行容量规划。请求大体上是均匀的：一次典型 API 调用耗时几十到几百毫秒，消耗有限的 CPU 资源，然后干净地退出。负载均衡器均匀分配，基于 CPU 利用率或请求速率的自动扩缩容有效运行。

LLM 推理违反了所有这些假设。

首先，Token 消耗与输入长度呈非线性关系。 含有 500 个 Token 上下文的请求，处理时间远低于含 50,000 个 Token 的请求——不是 100 倍的差距，但差异显著，因为预填充阶段注意力机制存在二次复杂度。当上下文窗口常规达到 200K Token（有些模型支持 100 万+），单个长上下文请求可能独占 GPU 数秒。

其次，输出是逐 Token 生成的。 与传统响应一次性刷出完整载荷不同，LLM 输出在解码阶段是逐 Token 流式传输的。一个请求 2,000 Token 文章的用户，在整个生成期间都占据着一个 GPU 槽位。GPU 无法用那个槽位处理其他请求。你管理的不是请求并发性——而是 Token 槽位占用率。

第三，工作负载的突发性与典型 Web 流量截然不同。 自动化管道提交的一批文档摘要任务，可以在几秒内向队列注入 1,000 万个 Token。运行多步推理循环的智能体系统，每个任务消耗的 Token 比简单聊天补全多 5 到 30 倍。你无法用泊松分布加安全边际来建模这种情况。

实际后果是：LLM API 强制执行的每分钟 Token 配额是有原因的。当你构建自己的推理基础设施时，你继承了同样的容量问题，却没有了这些护栏。

KV 缓存：容量规划真正的所在

每个规划 LLM 容量的工程师都关注计算（FLOPS），却忽略了真正的瓶颈：内存带宽和 KV 缓存压力。

推理过程中，模型为注意力机制维护一个键值缓存——每层每个 Token 对应一个缓存条目。对于 Llama 70B 这样的大模型（全精度），每 1 万个 Token 的上下文大约需要 200MB 显存。32 个并发请求，每个持有 1 万个 Token 的上下文，仅缓存就需要 6.4GB——这还不包括模型权重和激活值。

KV 缓存随上下文长度和并发请求数线性增长。到某个点，它就会超出可用 GPU 内存。当这发生时，你不会得到优雅的降级——你会得到 OOM 错误，或请求被悄悄阻塞在队列中。

但还有一个更隐蔽的问题会先出现：内存带宽饱和。在解码阶段，每生成一个 Token 都需要从 DRAM 中读取整个 KV 缓存。对于大型上下文或大批次，这会在 GPU 计算达到 100% 之前就使内存带宽饱和。研究发现，即使 GPU 利用率指标看起来健康，大批次推理中超过 50% 的注意力核心周期也在等待 DRAM 访问。这就是面板欺骗你的方式。

这就是为什么 GPU 利用率是 LLM 工作负载中错误的主要容量信号。一台显示 60% GPU 利用率的服务器，可能已经 95% 受限于内存带宽。传统监控框架对这种区别毫无概念。

传统供应模型如何崩溃

Web 服务容量规划的假设：

• 资源（CPU、内存）与吞吐量线性对应
• 水平扩展按比例分配负载
• 利用率百分比是剩余余量的可靠代理

这些假设对 LLM 推理都不成立。

非线性扩展：一块 A100 上的 7B 参数模型可以处理一定的请求量。两块 A100 不会给你 2 倍的吞吐量——这种关系取决于模型架构、批次大小，以及你是在并行化张量运算还是运行独立的模型副本。使用张量并行时，增加 GPU 可以改善每个请求的延迟，但不一定能改善每美元的吞吐量。

CPU 侧瓶颈：随着上下文长度增长，请求包含工具调用，分词、运行时编排和服务间通信成为延迟的重要贡献者。研究发现，随着智能体工作负载增加，多 GPU 推理集群中 CPU 导致的速度下降变得显著——这是 CPU 利用率指标在严重之前不会暴露的故障模式。

余量计算在 p99 处失效：如果你的平均请求耗时 2 秒，利用率为 70%，传统计算认为你有 30% 的余量。但 LLM 延迟具有高度右偏尾。落在队列末尾、排在多个长上下文任务后面的请求，经历的延迟是乘法而非加法的。LLM 服务的 p99 延迟通常是中位数的 5 到 10 倍。将平均利用率规划到 70% 在尾部几乎没有缓冲。

正确的容量信号

实际上能预测 LLM 服务集群何时耗尽余量的指标：

队列深度是最可靠的领先指标。当请求开始排队时，集群已经耗尽了并发服务容量。每个副本 3 到 5 个排队请求的阈值应该触发扩展。这是基于 Kubernetes KEDA 的自动扩缩容器使用 vLLM 的 vllm:num_requests_waiting 指标的信号——不是 CPU%，不是 GPU%，不是请求速率。

KV 缓存利用率（vLLM 中的 gpu_cache_usage_perc）是物理容量信号。当这个值超过 80 到 85%，新的长上下文请求要么被拒绝，要么会抢占正在运行的请求。按副本监控这个指标，而不是聚合值。

TTFT 和 ITL 是直接映射到用户体验的延迟信号。TTFT（首 Token 时间）主要受预填充吞吐量影响。ITL（Token 间延迟）主要受解码内存带宽影响。它们在不同负载模式下以不同方式退化。在 ITL 稳定的情况下 TTFT 尖峰，表明预填充饱和——你同时运行了太多提示密集型请求。在 TTFT 稳定的情况下 ITL 尖峰，表明解码饱和——你有太多长时间生成任务占用槽位。

以 Token/秒为单位的吞吐量（而非请求/秒）是正确的容量分母。两个 1K Token 的请求和一个 2K Token 的请求代表等量的负载。基于请求速率的自动扩缩容会系统性地低估长上下文工作负载。

预填充-解码分离：改变数学的架构

历史上容量规划如此困难的原因之一，是预填充和解码在争用相同资源的同时，优化要求完全相反：

• 预填充受计算限制：受益于大批次、高计算利用率、并行处理。
• 解码受内存带宽限制：受益于小批次、快速内存访问、低每槽并发。

当两个阶段在同一 GPU 上运行时，你永远处于妥协状态——对良好的解码吞吐量而言计算约束太强，对良好的预填充吞吐量而言内存约束太强。

预填充-解码分离通过为每个阶段运行独立的 GPU 池来解决这个问题。请求进入预填充池，其上下文并行处理，生成的 KV 缓存传输到解码池，然后生成继续进行。Meta、Perplexity 和 LinkedIn 已在生产中部署了这一方案，报告与统一架构相比，综合吞吐量提升了 2 到 7 倍。

容量规划的含义非常重要：你现在可以独立调整预填充和解码池的大小。长提示短输出的工作负载（摘要、分类）需要更大的预填充池。短提示长输出的工作负载（创意写作、代码生成）需要更大的解码池。这解锁了统一架构无法实现的每阶段成本优化。

预测 Token 需求

估算未来容量需要与传统服务不同的预测方法。

从按工作负载类型划分的 Token 消耗基准开始。客户支持聊天机器人每次对话平均可能有 800 个输入 Token 和 200 个输出 Token。文档分析管道每个文档可能提交 5 万个输入 Token。智能体编程助手每个任务可能产生 10 次工具调用，每次消耗 2K Token。这些配置文件截然不同，必须分别跟踪——将它们汇总成单一的"请求"指标会丢失你需要的信息。

明确建模突发性。LLM Token 消耗遵循高方差分布，而非泊松分布。文档处理管道通常批量提交工作，产生急剧的峰值。智能体工作负载在高峰使用期间产生复合的递归 Token 消耗。生产工作负载的峰值与平均 Token 吞吐量之比通常为 3 到 8 倍，而不是 Web 服务呈现的 1.5 到 2 倍。

为 KV 缓存规划，而不仅仅是计算。对于你想支持的每个并发用户层级，计算在中位数和 p95 上下文长度下 KV 缓存所需的显存。从 GPU 内存容量反向推算最大并发请求数。这给出了约束条件——大多数集群在达到计算限制之前先遇到内存限制。

考虑 GPU 扩展滞后。与 CPU 自动扩缩容在几秒内提供新实例不同，GPU 实例初始化需要几分钟。涉及多 GPU 模型加载的更极端扩展事件可能需要 10 到 15 分钟。这意味着被动扩缩容不足以处理急剧的流量峰值。构建你的预测，使其能在预计饱和前 15 到 30 分钟检测到趋势拐点，而不是之后。

实用的自动扩缩容架构

鉴于这些约束，LLM 推理的可行自动扩缩容设计结合了三个信号：

• 队列深度作为触发器：当待处理请求超过阈值时扩展（快速、被动响应）
• p90 TTFT 作为 SLA 执行器：即使没有排队，当延迟进入危险区域时也要扩展（捕捉内存带宽饱和）
• KV 缓存利用率作为硬上限：超过 85% 时阻止新请求或触发紧急扩展（防止 OOM 级联）

缩容应该保守。刚刚处理完一批长上下文请求的集群，KV 缓存状态会碎片化，飞行中请求的解码时间会升高。在突发流量的尾部过于激进地缩容，会延长仍在接收生成输出的用户的延迟。

对于多层服务（不同用户群的不同 SLA 层级），在队列层进行请求优先级排序比在模型层强制 SLA 更有效。将高级层请求路由到具有预留余量的专用副本，而不是试图通过模型级调度强制延迟保证——LLM 生成的延迟方差使后者不可靠。

这对团队实践意味着什么

LLM 容量规划需要被视为一等工程实践，而非运营事后工作。这意味着：

• 使用真实 Token 分布而非均匀合成请求进行负载测试。GuideLLM 和类似工具可以模拟生产流量配置文件——在部署前使用它们，而非在事故之后。
• 在计费和可观测性系统中按功能、模型、用户层级跟踪 Token 消耗。聚合的请求计数几乎没有什么用处。
• 将 Token 预算纳入产品设计。当一个功能在没有最大上下文约束的情况下发布时，用户和自动化管道会将 Token 消耗推到可用限制。不受控的输入长度是一个拒绝服务攻击向量。
• 将 KV 缓存大小视为一等基础设施决策，等同于数据库连接池大小或消息队列深度。它应该出现在你的容量评审中，而不是事后复盘报告里。

在 LLM 容量方面做对的工程师，是那些内化了他们在操作内存带宽受限、Token 计价、高输出方差且扩展机制缓慢的系统的人。来自 Web 服务基础设施的思维模型让你走到一半——但它们失效的边缘，正是你的用户经历中断的地方。

结论

GPU 利用率、请求速率和响应时间 SLO——Web 服务容量规划的标准工具箱——对 LLM 推理来说是必要但不充分的。真正的容量约束是 KV 缓存显存、内存带宽饱和和 Token 槽位占用率。队列深度是你的领先指标；TTFT 和 ITL 是你的 SLA 工具。

随着智能体工作负载的普及和上下文窗口扩展到数百万 Token，传统供应模型与 LLM 基础设施实际需求之间的差距将会扩大。围绕 Token 消耗配置文件、分离阶段架构和多信号自动扩缩容构建容量规划的团队，将以更低的成本和更高的可靠性运营，而不是用内嵌 Web 服务假设运行同样的集群。

数学并不难——但前提是你在测量正确的东西。