大模型推理成本控制 - 第1节
1. 成本全景
聊大模型推理成本，很多人第一反应就是「买显卡要花多少钱」。其实这只是冰山一角。我在几个推理项目里踩过坑之后，才真正把成本账算明白——今天咱们就把这张全景图摊开来看。
1.1 推理成本的四大构成
大模型推理的成本，说白了就是四块：算力、存储、带宽、电力。每一块都有它的脾气。
| 成本项 | 核心来源 | 占比参考 | 我的经验 |
|---|---|---|---|
| 算力 | GPU/TPU 的矩阵运算、注意力计算 | 50% - 65% | 这是大头，也是优化空间最大的地方 |
| 存储 | 模型参数、KV Cache、中间激活值 | 15% - 25% | KV Cache 经常被忽略，但它吃显存很凶 |
| 带宽 | 跨卡通信、跨机通信、用户请求传输 | 10% - 15% | 分布式推理时，带宽经常成为瓶颈 |
| 电力 | GPU 功耗、散热、机房制冷 | 10% - 20% | 电费是隐形成本，长期运行不容小觑 |
核心认知：算力成本是显性的，存储和带宽是隐性的。很多团队只盯着算力优化，结果发现显存爆了、通信慢了，整体成本反而更高。我建议一开始就把四块成本一起盘清楚。
1.2 算力成本：GPU 的「租金」与「利用率」
算力成本最直观。你租一台 A100 每小时多少钱，乘以运行时间，就是硬成本。但这里有个坑——GPU 利用率。
我在一个对话机器人项目里遇到过：GPU 利用率只有 30% 左右，但显存已经快满了。为什么？因为模型太大，batch size 打不上去。算力没跑满，但钱照付。这就是典型的「算力浪费」。
算力成本的关键公式：
有效算力成本 = GPU 单价 × 运行时间 ÷ GPU 利用率你想想看，利用率从 30% 提到 60%，成本直接砍半。所以优化算力成本，核心就是提高 GPU 利用率。
1.3 存储成本：模型参数 + KV Cache 的双重压力
存储成本分两块：
- 模型参数： 7B 模型约 14GB（FP16），70B 模型约 140GB。这是固定的，模型加载后就占着。
- KV Cache： 每个请求的 Key 和 Value 缓存。输入越长、batch size 越大，KV Cache 越大。
我记得有一次做长文本推理，输入长度 8K，batch size 32，KV Cache 直接吃了 40GB 显存。当时我整个人都懵了——比模型参数还大！
避坑指南： 我曾经在一个项目里忽略了 KV Cache 的存储开销，结果上线后频繁 OOM。后来加了 PagedAttention 和 KV Cache 量化，才把显存降下来。如果你做长序列推理，一定要提前算好 KV Cache 的峰值。
1.4 带宽成本：通信开销的「隐形杀手」
带宽成本在单卡推理时几乎可以忽略，但一旦上了多卡分布式推理，它就冒出来了。
举个例子：你用 8 张 A100 跑一个 70B 模型，每层计算都需要做 all-reduce 通信。如果跨机通信带宽不够，GPU 大部分时间都在等数据，算力利用率直线下降。
带宽成本的核心指标：
- 卡间带宽： NVLink 通常 600GB/s，PCIe 只有 32GB/s
- 机间带宽： InfiniBand 200Gbps vs 普通以太网 25Gbps
- 用户带宽： 请求传输延迟，影响 TTFT
说白了，带宽不够，算力再强也白搭。
1.5 电力成本：被低估的「长期账单」
电力成本很多人不算，但长期运行下来，它可能占到总成本的 15% - 20%。
一张 A100 满载功耗约 400W，8 卡机器就是 3.2kW，加上散热和机房制冷，实际功耗可能是 4-5kW。一年下来电费轻松超过显卡本身。
电力优化的思路：
- 动态电压频率调整（DVFS）
- 请求合并，减少空闲功耗
- 利用低功耗时段做批处理
1.6 成本优化的核心指标
聊完成本构成，咱们得知道怎么衡量优化效果。三个核心指标：TTFT、TPOT、吞吐量。
| 指标 | 全称 | 含义 | 对成本的影响 |
|---|---|---|---|
| TTFT | Time To First Token | 从请求发出到收到第一个 token 的时间 | 影响用户体验，间接影响请求量 |
| TPOT | Time Per Output Token | 生成每个 token 的平均时间 | 直接影响推理延迟和吞吐 |
| 吞吐量 | Throughput | 单位时间内处理的请求数或 token 数 | 直接决定单位成本 |
我的习惯： 做成本优化时，我一般先定吞吐量目标，再优化 TPOT，最后调 TTFT。因为吞吐量直接关联成本，TPOT 影响资源占用，TTFT 更多是体验指标。顺序搞反了，容易做无用功。
1.7 成本与性能的权衡关系
这里有个残酷的现实：成本优化和性能优化，很多时候是矛盾的。
举个例子：
- 你想降低 TPOT，可以加大 batch size，但显存压力变大，可能 OOM
- 你想提高吞吐量，可以上量化，但模型精度可能下降
- 你想降低 TTFT，可以预填充更多 KV Cache，但存储成本上升
我做过一个实验：把 batch size 从 1 提到 8，吞吐量提升了 4 倍，但 TPOT 增加了 30%。为什么？因为显存带宽成了瓶颈。这就是典型的 trade-off。
成本与性能的权衡矩阵：
| 优化手段 | 对成本的影响 | 对性能的影响 | 适用场景 |
|---|---|---|---|
| 增大 batch size | 降低单位 token 成本 | 增加 TPOT，可能 OOM | 离线批处理 |
| 模型量化（INT8/FP8） | 降低存储和算力成本 | 可能降低精度 | 对精度不敏感的场景 |
| KV Cache 量化 | 降低存储成本 | 轻微精度损失 | 长序列推理 |
| 请求合并 | 提高 GPU 利用率 | 增加 TTFT | 高并发场景 |
| 分布式推理 | 支持更大模型 | 增加通信开销 | 超大模型推理 |
核心原则： 成本优化不是一味地省钱，而是在满足性能 SLA 的前提下，找到成本最低的配置。我建议先定好性能红线（比如 TTFT < 500ms，TPOT < 50ms），再在这个约束下做成本优化。
1.8 成本全景知识图谱
下面这张图把本章的核心逻辑串起来了。你可以看到成本构成、核心指标、权衡关系是怎么连在一起的。
1.9 本章小结
好了，咱们把第一章的核心内容捋一遍：
- 成本四件套： 算力、存储、带宽、电力。算力是大哥，但其他三个也不能忽视。
- 三个核心指标： TTFT（首 token 延迟）、TPOT（每 token 延迟）、吞吐量。它们直接决定了你的成本效率。
- 权衡是常态： 没有免费的午餐。每个优化手段都有代价，关键是在性能 SLA 内找到最优解。