部署大模型做推理，最先撞上的墙往往不是算力慢，而是显存爆了。我们团队第一次把一个几十 B 参数的模型搬上单卡，batch 稍微开大一点就 OOM，长一点的对话都跑不完。后来才发现，推理的显存账要一笔一笔算，优化手段也有明确的取舍顺序。

## 一、先把显存的账算清楚

推理时的显存大头有三块：模型权重、KV Cache、中间激活值。权重是固定的，基本等于参数量乘以精度；KV Cache 则随 batch size 和上下文长度线性增长，长对话场景下它经常反超权重成为第一大户；激活值相对小一些，但某些结构下也不容忽视。优化之前先估算这三块的占比，再决定刀往哪儿下。

## 二、KV Cache：长上下文的隐形杀手

KV Cache 是为了避免重复计算而缓存的键值，代价就是显存。上下文翻倍，KV Cache 占用也翻倍。对策有几类：限制最大上下文与 batch 的组合、对 KV Cache 做量化、以及复用公共前缀（比如系统提示词只存一份）。多轮对话产品里，前缀复用往往是性价比最高的一招。

## 三、量化：用精度换空间

把权重从高精度降到低精度，显存直接砍半甚至更多。经验是：先试权重量化，效果不够再动 KV Cache；对精度敏感的任务，量化后一定要跑自己的评测集对齐，别只看公开榜单。注意量化不是免费的，推理速度还取决于硬件对低精度算子的支持程度，具体以官方资料为准。

## 四、并行：单卡放不下就拆开

张量并行把模型切到多卡上，每卡只存一部分权重和 KV Cache，是最常用的横向扩容手段；流水线并行则按层切分，适合对延迟不极端敏感的场景。代价是卡间通信开销，选之前先看机器的互联带宽。

## 实战建议清单

- 先估算：权重 + KV Cache 上限，batch 和上下文按业务峰值取
- 长对话场景优先做 KV Cache 优化和前缀复用
- 量化后务必用自己的业务评测集验精度
- 多卡优先张量并行，通信带宽是硬约束
- 留一成左右的显存余量，别把卡跑到 100%

你们在实际部署里，显存最大的坑踩在哪一块？是 KV Cache 爆了，还是量化后精度掉了？欢迎分享。