过去两年，「训练」这个词在大多数创业团队里几乎从工程会议中消失了。模型微调交给脚本，训练基础设施交给云厂商。 但同样在过去两年，「推理成本」这个原本属于基础设施角落里的话题，被一次次提到了 CFO 桌上。
本文想讨论三件事：推理成本由什么构成、为什么 KV cache 几乎是其中唯一的杠杆，以及为什么「加卡」经常解决不了问题。
1. 推理成本的拆解
把一次推理请求的总成本摊到 token 上，可以拆成四个量：
- 显存占用：模型权重 + KV cache，与序列长度线性相关。
- 算力消耗：每个 token 的乘加次数，主要由模型架构决定。
- 带宽开销：权重加载、attention 读写，与并发和批大小强相关。
- 调度损耗：排队、抢占、冷启动，会把利用率削掉 20–40%。
真正可控的只有两项：KV cache 策略和批处理。前者影响显存占用，后者影响带宽开销。 「加卡」能解决算力瓶颈，但几乎不解决带宽和调度——这正是「多卡救不了你」的本质。
2. KV cache：唯一的可调旋钮
KV cache 本质上是用显存换算力：避免每生成一个 token 都重算前面的 attention。 问题在于它是「免费出现在显存里、又极难被驱逐」的一种资源。 一旦请求变长，显存占用会迅速反超模型权重本身。
几条可以直接动手的方向：
- Paged attention：把 KV cache 切成固定大小的 page，按需分配，能把长尾请求的显存占用砍掉一半。
- Prefix 共享：多轮对话里的 system prompt 完全可以共享一份 KV，而不是每次重新计算。
- 驱逐策略：对极长上下文做滑动窗口 + 重计算，而不是无脑缓存。
3. 批处理：带宽比算力贵
推理卡最贵的资源从来不是 FLOPS，而是 HBM 带宽。 在 LLaMA-3 8B 上，每生成一个 token 需要从显存读出约 16GB 的权重（按 fp16）。 即使是 H100 的 3TB/s 带宽，也只够支持每秒 ~200 个 token 的单请求——这正是单并发永远跑不满 GPU 的原因。
批处理把多个请求拼在一起，权重只读一次、收益按请求数线性放大。 但「拼得越多越好」也是错的：当批大小超过一定阈值，attention 的显存和延迟开始主导。 真正可用的批大小，是模型规模 × 显存 × 延迟 SLA 三者的解。
# 一个粗略的可用批大小估算
def max_batch(model_params_gb, gpu_mem_gb, kv_per_seq_mb, avg_seq_len, util=0.85):
free = gpu_mem_gb * util - model_params_gb
return int((free * 1024) / (kv_per_seq_mb * avg_seq_len))4. 调度损耗：被忽视的 30%
很多团队的 GPU 监控看板显示「利用率 90%」，账单却对不上。 问题出在调度：冷启动、模型加载、context 切换、抢占恢复，这些都不计入 utilization，却都计入成本。
解决思路只有两个：减少切换（让请求稳定地落在同一组实例上）、减少冷启动（预热 + 模型常驻）。 这也是 AIPMS 在「服务发布」模块里默认开启影子流量和灰度发布的原因——它直接降低调度损耗。
5. 结语
推理优化不会像训练那样有「一次突破吃三年」的红利。 它更像运维：每一个百分点的优化都要在工程里反复打磨。 真正决定一个 AI 产品能不能挣钱的，往往不是模型选型，而是这一层运维是否扎实。
如果你也在被这些事折磨，欢迎邮件交流，下一篇会写多卡推理的真实成本账。