容量与成本规划
容量与成本规划回答两个问题：
需要多少资源才能稳定服务？
每个请求、每个用户、每个业务线大概要花多少钱？
LLM 服务不能只按 QPS 估算容量。真正决定资源消耗的是 token、上下文长度、输出长度、并发、KV Cache、模型大小、推理框架和延迟目标。
一句话概括：
LLM 容量 = token 吞吐 + 显存容量 + 调度效率 + 延迟目标 + 冗余
1. 先明确业务目标
容量规划不能从 GPU 数量开始，而要从业务目标开始。
需要先回答：
- 服务是在线聊天、API 调用、内部助手、长文档总结，还是离线批处理？
- 目标模型是什么？
- 是否需要流式输出？
- 用户能接受的 TTFT、ITL 和 p99 是多少？
- 峰值流量是多少？
- 输入和输出 token 分布是什么？
- 是否有长上下文请求？
- 是否有 RAG、工具调用或多模态输入？
- 可接受的错误率、限流率和排队时间是多少？
- 是否需要多区域、灾备或高可用冗余？
不同场景的容量目标差异很大。
| 场景 | 优先目标 |
|---|---|
| 在线聊天 | TTFT、ITL、p99、稳定性 |
| 企业知识库问答 | RAG 延迟、引用质量、token 成本 |
| 长文档总结 | 长上下文容量、KV Cache、超时控制 |
| 批量生成 | tokens/s、总完成时间、单位成本 |
| 多租户 API | 配额、公平性、隔离和账单 |
不要用离线 benchmark 的峰值 tokens/s 直接推线上容量。线上流量更复杂，有长尾、有突发、有取消、有工具调用，也有用户端慢消费。
2. QPS、并发和 Token Throughput
LLM 服务里，QPS 只是入口请求数，不等于真实工作量。
更重要的是：
| 指标 | 含义 |
|---|---|
| request rate | 每秒进入多少请求 |
| concurrency | 同时有多少请求在处理 |
| input tokens/s | 每秒处理多少输入 token |
| output tokens/s | 每秒生成多少输出 token |
| total tokens/s | 输入和输出合计吞吐 |
| active sequences | 推理引擎中运行的序列数 |
| KV Cache usage | 当前上下文占用的缓存资源 |
一个粗略关系是：
平均并发 ≈ 请求到达率 × 平均请求耗时
但在 LLM 服务里，请求耗时又受 input tokens、output tokens、排队和流式输出影响。
例如两个请求都是 1 QPS：
| 请求类型 | input tokens | output tokens | 资源压力 |
|---|---|---|---|
| 短问答 | 300 | 200 | 较低 |
| 长文档总结 | 32000 | 2000 | 极高 |
所以容量规划要按 token 分布做，而不是只按请求数做。
3. 输入输出 Token 分布
规划前要收集或估算真实流量分布。
至少需要：
- input tokens p50 / p90 / p99。
- output tokens p50 / p90 / p99。
- 每日请求量。
- 峰值请求速率。
- 流式请求比例。
- 长上下文请求比例。
- 超时和取消比例。
- 不同业务线或租户的流量占比。
建议按长度分桶：
| 桶 | 示例 |
|---|---|
| 短输入短输出 | 500 in / 300 out |
| 长输入短输出 | 16000 in / 500 out |
| 短输入长输出 | 1000 in / 3000 out |
| 长输入长输出 | 32000 in / 4000 out |
这四类请求对系统的压力完全不同。
- 长输入主要压 prefill、TTFT 和 KV Cache 初始分配。
- 长输出主要压 decode、ITL、运行 slot 和 KV Cache 持续占用。
- 长输入长输出最容易造成长尾和显存压力。
如果没有真实日志，可以先用产品假设和压测样本估算，但上线后要尽快用真实 token 分布修正。
4. 显存容量组成
推理显存大致由几部分组成：
总显存占用
= 模型权重
+ KV Cache
+ runtime / framework 开销
+ CUDA workspace
+ 临时激活和 buffer
+ 碎片和安全余量
其中模型权重是启动时的固定成本，KV Cache 是运行时随上下文和并发变化的成本。
权重显存可以粗略估算：
权重显存 ≈ 参数量 × 每个参数字节数
常见精度：
| 精度 | 每参数字节数 | 说明 |
|---|---|---|
| FP16 / BF16 | 2 bytes | 常见推理精度 |
| FP8 | 1 byte | 依赖硬件和框架支持 |
| INT8 | 1 byte | 需要量化方案支持 |
| INT4 | 0.5 byte | 显存低，但质量和性能需验证 |
例如 32B 参数模型使用 BF16 权重，权重本身约：
32B × 2 bytes ≈ 64GB
实际加载还要考虑框架开销、tensor parallel 切分、量化元数据和运行时 buffer。
5. KV Cache 对容量的影响
KV Cache 是 LLM 在线推理容量规划的重点。
它和这些因素相关：
- 模型层数。
- hidden size。
- attention heads / KV heads。
- KV Cache 精度。
- 上下文长度。
- 并发序列数。
- 是否使用 GQA / MQA。
- 推理框架的 cache block 管理。
直观理解：
上下文越长，并发越高，KV Cache 越大。
长上下文服务常见瓶颈不是权重放不下，而是 KV Cache 先占满。
容量规划时要区分：
| 项 | 特点 |
|---|---|
| 模型权重 | 固定占用，启动后基本稳定 |
| KV Cache | 随并发、上下文和输出长度变化 |
| runtime buffer | 随框架和 batch 参数变化 |
如果服务支持 128k 上下文，但大部分请求只有 2k，不代表每个请求都要按 128k 实际消耗 KV Cache。现代推理框架通常按实际 token 或 block 分配。但 max_model_len 设置过大仍可能影响预留策略、调度上限和最坏情况容量。
对应阅读：KV Cache。
6. 延迟目标决定可用吞吐
同一组 GPU 可以在不同延迟目标下给出不同容量。
例如：
- 离线批处理可以接受更高延迟，追求最大 tokens/s。
- 在线聊天需要较低 TTFT 和稳定 ITL，不能把 batch 堆到极限。
- 多租户 API 要控制 p99 和公平性，不能让少数长请求拖垮整体。
所以容量不是单一数字，而是一个条件：
在 p99 TTFT < 2s、p99 ITL < 200ms、错误率 < 0.1% 的条件下，
系统能稳定承载多少请求和 tokens/s。
压测报告如果只给峰值吞吐，没有延迟、错误率、token 分布和显存信息，不能用于生产容量规划。
7. GPU 数量估算
一个实用估算流程：
- 明确模型、精度、上下文长度和推理框架。
- 测出单副本在目标延迟下的稳定吞吐。
- 用真实 token 分布估算峰值 token 需求。
- 按峰值需求除以单副本稳定吞吐。
- 加上冗余、故障和发布灰度所需容量。
粗略公式：
所需副本数 ≈ 峰值 token/s 需求 ÷ 单副本稳定 token/s
再考虑：
- N+1 冗余。
- 灰度发布双版本并行。
- worker 重启和模型加载时间。
- 区域故障或节点维护。
- 长尾流量和突发峰值。
不要直接用理论 FLOPS 估算线上吞吐。实际吞吐受显存带宽、attention 实现、KV Cache、batch、输入输出长度、框架参数、多卡通信和调度策略影响。
8. 峰值流量和冗余
容量规划要按峰值，不是按日均。
需要关注：
- 日内峰值。
- 周期性峰值。
- 活动或发布带来的突发。
- 批处理任务是否和在线流量抢资源。
- 某个租户或用户的异常流量。
常见冗余策略：
| 策略 | 说明 |
|---|---|
| N+1 | 任意一个副本故障时仍能承载目标流量 |
| 灰度冗余 | 新旧版本同时运行，避免切换时无容量 |
| 峰值余量 | 为突发请求保留 buffer |
| 队列降级 | 超过容量时排队、限流或异步化 |
| 多集群容灾 | 区域故障时可切换 |
冗余不是浪费。LLM worker 加载模型可能很慢，如果没有余量，故障恢复期间会直接影响线上用户。
9. 多模型共享资源
一个平台通常同时服务多个模型：
- 小模型低成本处理简单任务。
- 大模型处理复杂任务。
- embedding 模型做检索。
- rerank 模型做排序。
- 多模态模型处理图片或音频。
共享资源时要注意：
- 不同模型显存占用不同。
- 不同模型的 token/s 不可直接相加。
- 大模型和小模型混部可能造成资源碎片。
- embedding / rerank 的 CPU、GPU 和批处理策略不同。
- 热门模型和冷门模型的副本策略不同。
建议把模型分成资源池：
| 资源池 | 适合任务 |
|---|---|
| 低延迟小模型池 | 分类、改写、轻量问答 |
| 主力聊天模型池 | 在线对话和 RAG |
| 长上下文模型池 | 文档总结和长上下文问答 |
| 离线批处理池 | 批量生成和评测 |
| embedding / rerank 池 | 检索链路 |
资源池隔离可以防止离线任务或长上下文请求拖慢在线聊天。
10. 成本组成
LLM 服务成本通常包括：
| 成本项 | 说明 |
|---|---|
| GPU 成本 | 云 GPU 租用、自建折旧、电力和机房 |
| CPU / 内存 | tokenizer、RAG、API 服务、工具调用 |
| 存储 | 模型文件、向量库、日志、缓存 |
| 网络 | 跨区传输、对象存储下载、外部 API |
| 工程运维 | 监控、部署、故障处理、版本管理 |
| 第三方 API | 外部模型、搜索、OCR、工具服务 |
线上成本不只来自 GPU。RAG 系统里的向量库、rerank、日志存储和工具调用也可能成为显著成本。
11. 单请求成本估算
单请求成本可以从 token 和资源时间两种角度估算。
如果使用外部模型 API，通常按 token 计费：
单请求成本
= input_tokens × 输入单价
+ output_tokens × 输出单价
+ 其他工具或检索成本
如果自建 GPU，通常按 GPU 时间分摊：
单位 token 成本
≈ GPU 每小时成本 ÷ 每小时稳定输出 token 数
更完整地看：
单请求成本
≈ input token 成本
+ output token 成本
+ RAG 检索成本
+ rerank 成本
+ 工具调用成本
+ 日志和存储成本
输出 token 往往比输入 token 更贵，因为 decode 阶段逐 token 生成，持续占用运行 slot 和 KV Cache。
12. 云 GPU 与自建 GPU
云 GPU 和自建 GPU 的取舍要看利用率、弹性、运维能力和现金流。
| 方案 | 优势 | 风险 |
|---|---|---|
| 云 GPU | 启动快、弹性好、少运维、适合波动流量 | 长期高利用率时成本可能高，库存和实例规格受限 |
| 自建 GPU | 长期高利用率下单位成本可能低，可控性强 | 前期投入高，运维复杂，扩容慢，硬件折旧和故障风险 |
| 混合模式 | 基础流量自建，峰值用云补充 | 调度、数据同步、版本一致性更复杂 |
粗略判断：
- 流量不稳定、业务验证期：优先云 GPU。
- 长期稳定高利用率：可以评估自建。
- 峰谷明显：考虑混合模式。
- 对数据驻留、网络和安全有强要求：自建或专有云更常见。
不管哪种方式，都要按真实利用率计算。GPU 长期空闲时，账面单价再低也不一定便宜。
13. 降本手段
常见降本方式：
| 方式 | 作用 | 风险 |
|---|---|---|
| 选择更小模型 | 降低权重显存和单 token 成本 | 能力可能不足 |
| 量化 | 降低显存和带宽压力 | 质量和兼容性需验证 |
| 蒸馏 | 用小模型承接部分任务 | 训练和评估成本增加 |
| 路由分层 | 简单任务走小模型，复杂任务走大模型 | 路由错误会影响质量 |
| prompt 压缩 | 减少 input tokens | 信息丢失风险 |
| RAG chunk 控制 | 减少无效上下文 | 召回不足风险 |
| prefix cache | 复用固定前缀 | 依赖请求模式 |
| 输出长度限制 | 控制 decode 成本 | 用户可能觉得回答不完整 |
| 批处理 | 提高吞吐 | 在线延迟可能变差 |
降本不能只看成本下降，还要看质量、延迟和故障风险。
例如 INT4 量化可能显著降低显存，但如果导致格式遵循变差、工具调用错误增加，整体业务成本可能反而上升。
14. 成本治理
成本治理要变成系统能力，而不是靠人工提醒。
建议实现：
- 按租户、用户、业务线统计 token。
- 设置 token/min、token/day、monthly budget。
- 对超长输入和长输出设置硬上限。
- 对低优先级任务排队或异步化。
- 对异常 token 增长告警。
- prompt 版本发布前做 token diff。
- 输出
finish_reason = length时记录截断率。 - 对 RAG chunk 数和工具调用次数设置预算。
典型预算策略：
普通用户：
max_input_tokens = 8000
max_output_tokens = 1000
token_per_minute = 20000
长文档任务：
进入异步队列
限制并发
单独计费或单独资源池
没有预算控制的 LLM API 很容易被少量长请求拉高成本。
15. 压测方法
容量规划必须靠压测校准。
压测应覆盖：
| 类型 | 目的 |
|---|---|
| 固定并发 | 看不同并发下延迟和吞吐 |
| 固定请求速率 | 模拟真实流量进入 |
| ramp up | 找到服务恶化拐点 |
| 长短混合 | 验证调度公平性 |
| 长上下文 | 验证 KV Cache 和 TTFT |
| 长输出 | 验证 decode 和 ITL |
| 突发流量 | 验证队列、限流和恢复 |
| 灰度双版本 | 验证发布期间容量余量 |
每次压测必须记录：
- 模型和版本。
- 精度和量化方式。
- GPU 型号和数量。
- 推理框架和启动参数。
- input / output token 分布。
- 并发或请求速率。
- TTFT、ITL、E2E。
- p50 / p90 / p99。
- tokens/s。
- 错误率、超时率、限流率。
- GPU、显存、KV Cache。
- worker 数量和副本策略。
没有这些上下文，压测结果不可复用。
16. 常见误区
16.1 只按 QPS 估算
QPS 相同，token 成本可能差几十倍甚至上百倍。
必须同时看 input tokens、output tokens、上下文长度和输出长度。
16.2 只看权重显存
模型能加载，不代表能承载目标并发。
KV Cache、runtime buffer 和长上下文会显著增加运行时显存。
16.3 用峰值 benchmark 当生产吞吐
benchmark 通常使用固定输入输出和理想 batch。生产环境有长尾、突发、取消、工具调用和多租户干扰。
应该使用目标延迟和错误率约束下的稳定吞吐。
16.4 忽略灰度和故障冗余
发布新模型时，新旧版本可能同时运行。worker 故障、节点维护和模型冷启动也需要容量余量。
如果刚好按峰值配满，发布和故障都会变成风险。
16.5 只优化单 token 成本
单 token 便宜不代表总体便宜。
如果小模型导致更多重试、人工介入或错误工具调用，业务总成本可能更高。
17. 实践检查清单
做容量和成本规划时，至少确认：
- 有真实或可解释的 input / output token 分布。
- 区分在线聊天、长文档、批处理和 RAG 流量。
- 明确 TTFT、ITL、p99、错误率和限流率目标。
- 单副本吞吐来自目标延迟下的压测，而不是峰值 benchmark。
- 显存估算包含权重、KV Cache、runtime buffer 和安全余量。
- GPU 数量估算包含峰值、N+1、灰度和故障恢复。
- 长上下文和长输出请求有单独治理策略。
- 多模型资源池有隔离或优先级。
- 成本按模型、租户、业务线和 token 类型拆分。
- 有 token 预算、限流、告警和降级方案。
- 云 GPU、自建 GPU 或混合模式有利用率假设。
- 每次模型、prompt、RAG 或推理参数变更后重新观察成本指标。
18. 和其他概念的关系
- 和 并发与批处理：batch 和并发决定目标延迟下的稳定 token throughput。
- 和 KV Cache：长上下文和高并发的显存瓶颈主要来自 KV Cache。
- 和 推理服务架构：路由、调度、worker 和多副本决定资源利用率。
- 和 可观测性：容量和成本规划依赖 token、延迟、GPU 和错误率指标。
- 和 硬件选型：GPU 型号、显存、带宽和成本决定部署边界。
- 和 模型部署流程：上线前必须用压测和灰度验证容量假设。
19. 总结
LLM 容量规划的核心不是“买几张 GPU”，而是把业务流量翻译成 token、显存、延迟和冗余需求。
一个可靠的估算过程是：
业务目标
-> token 分布
-> 延迟和错误率目标
-> 单副本稳定吞吐压测
-> GPU 和副本数估算
-> 峰值、灰度和故障冗余
-> 成本拆分和预算治理
只看 QPS、只看权重显存、只看峰值 tokens/s，都会低估真实生产成本。真正可用的容量，是在用户体验、稳定性和成本都可接受的条件下，系统能长期维持的吞吐。