4、显存瓶颈分析：显存带宽利用率、显存碎片化、KV Cache优化、PagedAttention原理
显存瓶颈，说白了就是你的模型在GPU里「跑不动」了。我见过太多团队，模型精度调得漂漂亮亮，一上生产就卡死。为什么？显存扛不住了。
这一章，我们聚焦四个核心问题：显存带宽利用率、显存碎片化、KV Cache优化，以及当下最火的PagedAttention原理。嗯，这些都是我日常排查性能问题时，几乎必查的项目。
4.1 显存带宽利用率：你的GPU在「摸鱼」吗？
显存带宽，就是GPU从显存里读数据的速度。你想想看，如果计算单元跑得飞快，但数据搬不过来，那不就是「等米下锅」吗？
我个人习惯用 nvidia-smi 配合 Nsight Systems 来抓带宽利用率。有个指标叫 DRAM Active Cycles，如果这个值低于80%，说明你的GPU大部分时间在「摸鱼」——等着数据从显存里搬过来。
核心公式：
带宽利用率 = (实际读取字节数 / 理论峰值带宽) × 100%
理想值：> 70%
警告值：< 40%
我在项目中遇到过最典型的情况：用PyTorch写了个大矩阵乘法，结果带宽利用率只有15%。查了半天，发现是数据排布问题——内存访问不连续，导致缓存命中率极低。
避坑指南：
我曾经在优化一个BERT推理时，发现带宽利用率死活上不去。后来用 torch.cuda.memory_stats() 一查，发现大量 非对齐访问。解决办法很简单：把输入tensor的最后一维对齐到128字节。嗯，就这一改，带宽利用率从32%飙到了68%。
4.2 显存碎片化：看不见的内存杀手
显存碎片化，就像你硬盘里的文件碎片。明明总容量还有，但就是分配不出一个连续的大块。推理引擎里，这个问题尤其严重——因为每次请求的序列长度不一样，分配的内存块大小也千奇百怪。
我建议你用 torch.cuda.memory_summary() 来查看碎片化程度。重点关注 Large Block Pool 和 Small Block Pool 的比例。如果小块的个数超过大块的10倍，那基本可以断定碎片化严重。
| 碎片化等级 | 表现 | 建议操作 |
|---|---|---|
| 轻度 | 分配延迟 < 5ms | 监控即可 |
| 中度 | 分配延迟 5-20ms | 启用内存池预分配 |
| 重度 | 分配延迟 > 20ms 或 OOM | 必须使用PagedAttention |
注意： 显存碎片化不会直接报错，它只会让你的推理越来越慢。我曾经排查过一个线上服务，每次请求延迟从50ms慢慢涨到500ms，最后发现就是碎片化在作祟。重启服务能暂时解决，但治标不治本。
4.3 KV Cache优化：把重复计算省下来
Transformer推理时，每个token都要重新计算之前所有token的Key和Value。这太浪费了。KV Cache就是把这些中间结果存下来，下次直接用。
但KV Cache有个问题：它太吃显存了。对于一个7B模型，序列长度2048，batch size 1，KV Cache就要吃掉大约 2GB 显存。你想想看，如果batch size 32呢？64GB就没了。
我个人常用的优化手段有几种：
- KV Cache量化：从FP16降到INT8，显存直接减半。代价是精度损失，但很多场景下可以接受。
- 共享KV Cache：如果多个请求的prompt前缀相同，可以共享一部分KV Cache。这在对话系统中特别有用。
- 动态释放：对于长序列，早期token的KV Cache其实很少被访问了，可以优先释放。
经验数据：
我在一个对话机器人项目里，通过KV Cache量化+共享前缀，把显存占用从48GB降到了12GB。推理速度反而提升了30%，因为减少了显存带宽压力。
4.4 PagedAttention原理：像操作系统管理内存一样管理显存
PagedAttention，说白了就是把显存当成虚拟内存来管理。操作系统怎么管理物理内存的？分页。PagedAttention就怎么管理KV Cache——分成固定大小的块（Page），按需分配。
为什么需要它？因为传统的KV Cache是连续分配的。你想想看，如果序列长度是2048，你就得一次性分配2048个token的KV Cache空间。但实际推理时，你根本不知道最终长度是多少。分配多了浪费，分配少了又得重新分配——碎片化就来了。
PagedAttention的做法是：
- 把KV Cache分成固定大小的 Block（比如每个Block存16个token的KV）
- 每个Block在显存里可以 不连续 存放
- 用一个 Page Table 来记录逻辑Block到物理Block的映射
- 推理时，按需分配新的Block，用完就回收
这样做的好处很明显：
- 零碎片化：因为Block大小固定，分配和回收都不会产生碎片
- 高利用率：可以做到接近100%的显存利用率
- 支持动态长度：序列长度变化时，只需要增减Block数量
实现细节：
PagedAttention的核心数据结构是 BlockTable。它是一个二维数组，第一维是序列ID，第二维是逻辑Block索引。每个元素指向一个物理Block的地址。推理时，GPU kernel通过BlockTable来访问KV Cache，而不是直接计算地址。
我建议你在实现时注意几个点：
- Block大小选择：太小了Page Table太大，太大了内部碎片多。我个人习惯选16或32。
- 预分配策略：可以预先分配一个大的Block Pool，避免推理时频繁分配。
- 回收机制：序列结束后，Block要立即回收。可以用一个Free List来管理空闲Block。
注意： PagedAttention虽然好，但不是银弹。它增加了地址转换的开销。如果你的序列长度很短（比如<128），这个开销可能超过收益。我一般建议序列长度超过512时才启用。
知识体系总览
下面这张图，是我梳理的显存瓶颈分析知识体系。你可以把它当成一个检查清单：
嗯，以上就是显存瓶颈分析的核心内容。记住一个原则：先诊断，再优化。不要一上来就上PagedAttention，先看看是不是带宽利用率的问题，或者是不是碎片化在作怪。我见过太多人，工具用得挺花哨，但连基本的问题都没定位清楚。
想要更多资料，联系可可