GPU利用率优化：显存管理实战

可视化演示

展示SM Occupancy计算占用率、显存碎片化优化前后对比、PagedAttention分页管理KV Cache的原理。

GPU利用率指标：给后厨装上温度计

把 GPU 想象成 AI 大饭店的后厨：每一顿饭都由多口灶台（SM）同时烹饪，每口灶台还能接待好几组厨师。这里最小的调度单位叫 warp（线程束），你可以把它理解成一组固定人数的厨师小队。如果灶台灯亮着但厨师小队没坐满，菜就不会出锅，这就是 GPU 利用率低下最常见的状态。

SM Occupancy 是后厨管理中最基础的体温计，它的定义是：单个 SM 上真正在活动的线程束数量，除以该 SM 理论上最多能容纳的线程束数量。它衡量的是「灶台座位坐满没有」，而不是「菜炒得有多快」。一个 kernel 的计算利用率很高，也可能是在等食材——也就是等显存数据，这时真正拖后腿的是访存瓶颈。

实战中使用 Nsight Compute 打开 kernel 分析报告，重点看 SM Activity（计算活动）和 Memory Throughput（访存吞吐）。如果两者都快接近 100%，说明 ALU 在等数据，典型访存瓶颈；如果两者都低于 50%，则要怀疑 Occupancy 太低、启动开销过大或者 GPU 根本没吃饱。就像后厨总管要同时看灶台、切菜台和传菜口，不能只盯一个画面下结论。

显存碎片化：冷库被切成了乐高拼图

显存就像后厨的冷库，每次请求都要向管理员申请一块地方放中间产物。如果管理员坚持给你一整块连续货架，而冷库已经被多次占用和释放切得七零八落，就会出现很多「塞不下整块食材」的小空档，这就是外部碎片。外部碎片最直观的后果是：明明仓库总空闲空间很充足，但一整块大内存就是申请不到。

还有另一种看不见的浪费叫内部碎片。管理员为了对齐效率，习惯按 512MB 的货架大小分配：你只需要 300MB，他仍给你 512MB，剩下 212MB 被悄悄锁死，别人不能用。两者叠加，显存利用率会显著下降。工程上常用外部碎片率来量化冷库的混乱程度。

在 PyTorch 中，显存由 Caching Allocator 管理，它会把释放的块缓存起来复用，但长时间训练会产生碎片。推荐设置 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True 或调节 max_split_size_mb 来缓解；推理服务中则可以用块级页式分配，从根上绕开「必须连续」的约束。这就像把冷库改造成一格一格可组合的冰柜，小格子也能灵活拼出大空间。

KV Cache优化：留住有用的半成品

大模型生成句子时，每生成一个 token，注意力层都要重新看一遍历史上所有 token。如果每次都把已经切好的葱姜蒜扔掉重新切，后厨会累死。于是聪明的主厨把处理过的 K 矩阵和 V 矩阵当作半成品留在台面上，供后续每个新 token 直接取用，这批半成品就叫 KV Cache。

KV Cache 是推理显存占用的主要大头。它的体积随序列长度、层数、隐藏维度和请求数线性增长，非常夸张。一个 7B 模型的权重可能是 14GB，但长对话中的 KV Cache 很快也会达到十几 GB。理解它的计算公式，是优化显存的第一步。

优化 KV Cache 的常用手段包括：前缀共享（多个请求共用餐前准备）、KV Cache 量化为 INT8/INT4、滑动窗口注意力只保留最近若干 token，以及用 PagedAttention 按块动态分配。永远记住：KV Cache 是随请求动态增长的，不是一次性分配完成的，所以管理它比管理权重更需要精细操作。

PagedAttention：按页取菜的分页冷库

传统 KV Cache 分配是一锤子买卖：每个请求一开始就申请一整块连续显存，而且只能按最大可能长度预留。就像客人还没点菜，你就把一整头猪放进制冷柜，结果客人只吃了两片肉，剩余空间还因为被占用而无法挪作他用。连续分配加上动态增长，让显存浪费率常常超过 50%。

PagedAttention 的灵感来自操作系统里的虚拟内存分页。它把 KV Cache 切成固定大小的块，逻辑上每个请求的序列是连续的，但物理上这些块可以散落在显存的任意空位。哪里有空格子就放哪里，再用一张「页表」把散落的块串起来。它需要多少块，就只占多少块。

vLLM 推理框架就是靠 this 思想把 KV Cache 利用率从 50% 以下提升到 90% 以上。更妙的是，多个请求如果有相同的前缀，页表可以让它们共享同一批物理块，这样系统提示词占用的显存几乎可以被所有会话复用。分页是一套优雅的「冷库改造方案」，它放弃了物理连续，换来了更高的格子和用率。

批处理与量化：合并出餐与浓缩汤包

后厨高峰期，如果一位客人一趟只点一个菜，灶台要不断烧热、关火、切换，效率极低。动态批处理就像把门口等位的客人按照相同口味合并成一大锅炒：一次处理更多 token，让每个 SM 的线程束尽量坐满。连续批处理（Continuous Batching）还会把正在生成的请求和刚到达的请求混在一起，让 GPU 永远在干活。

另一个降低显存压力的手段是量化。FP16 的权重每个数占 2 字节，INT8 只占 1 字节，相当于把食材做成浓缩汤包，体积小一半，味道却大体保留。量化的收益不只是省显存，还因为访存数据量变小，瓶颈从内存搬运中释放出来，真正提高了计算效率。

不过量化不是无代价的。它通常需要少量校准数据来估算数值范围，少数敏感层可能需要保留高精度。批处理同样有取舍：批量越大，单请求延迟越高，所以工程上要在吞吐和延迟之间拨动天平。好主厨会看客人能不能等：能等的客人拼大锅，急着吃的客人单独开小灶。

性能Profiling：回放厨房监控录像

后厨管理水平再高，也需要摄像头。Nsight 就是这样一套录像回放系统：它不仅能看平均利用率，还能逐帧、逐 kernel 地展示 GPU 内部每个阶段花了多长时间。有的时间真的在炒菜（计算），有的时间却是在等切好的菜从仓库送到台面（访存）。定位瓶颈，就是分清主厨在等锅还是在等菜。

用 Nsight Compute 打开一个 kernel，可以看到 SM Activity、Memory Throughput、Warp State 等指标。其中访存等待时间很关键：如果总执行时间里很大一部分是在等显存数据，那么再怎么提升 SM 频率也没用。可以把它写成一个简单比例：

完整优化流程是一个闭环：先用 Nsight 做 Profile，定位是哪类 kernel 慢；再根据指标判断是 Occupancy 不足、访存瓶颈还是碎片化严重；然后针对性调整批处理、PagedAttention 或量化策略；最后重新 Profile 验证收益。优化不是一锤子买卖，而是像后厨试菜一样，不断回放录像、尝菜、改配方。

AI 应用场景

Python 演示

import random class BlockAllocator:    def __init__(self, total_blocks=32, paged=False):        self.blocks = [False] * total_blocks        self.paged = paged        self.total_blocks = total_blocks     def alloc(self, need):        if need <= 0 or need > self.total_blocks:            return -1        if not self.paged:            for start in range(self.total_blocks - need + 1):                if not any(self.blocks[start:start + need]):                    for i in range(start, start + need):                        self.blocks[i] = True                    return start            return -1        free_idx = [i for i, used in enumerate(self.blocks) if not used]        if len(free_idx) < need:            return -1        for i in free_idx[:need]:            self.blocks[i] = True        return free_idx[:need] def simulate(seq, paged):    allocator = BlockAllocator(32, paged)    fails = 0    for need in seq:        if allocator.alloc(need) == -1:            fails += 1    return fails def main():    random.seed(7)    seq = [random.randint(1, 4) for _ in range(300)]    naive_fail = simulate(seq, False)    paged_fail = simulate(seq, True)    print("连续分配失败次数:", naive_fail)    print("分页分配失败次数:", paged_fail)    print("分页减少失败:", naive_fail - paged_fail) if __name__ == "__main__":    main()

1. class BlockAllocator:给连续分配和分页分配共用一个冷库模型，只是分配策略不同。
2. if not any(self.blocks[start:start + need]):连续分配要求找到一整段空闲块，任一小格被占用就跳过，这很容易产生碎片。
3. free_idx = [i for i, used in enumerate(self.blocks) if not used]分页方式先把所有空闲格编号收集起来，不要求连续。
4. for i in free_idx[:need]:` `self.blocks[i] = True取前 need 个空闲格散落占用，像按页把菜谱放进不同冷库格。
5. naive_fail = simulate(seq, False)跑一遍连续分配策略，统计失败次数。
6. paged_fail = simulate(seq, True)用同样的请求序列跑分页分配，对比碎片影响。

常见误区

面试题