2、GPU显存基础：显存架构、带宽、容量、计算与显存的关系，以及显存瓶颈的识别方法
大模型训练与推理的显存瓶颈，本质上是对GPU硬件资源理解不足所导致的。显存（VRAM）并非一个简单的“大仓库”，而是由存储介质、控制逻辑、总线接口共同构成的复杂子系统。本章将从显存的物理架构出发，厘清带宽、容量与计算单元（SM/CUDA Core）之间的协作关系，并给出可操作的显存瓶颈识别方法。理解这些基础概念，是后续进行KV Cache优化、张量并行、量化部署等高级调优的前提。
2.1 显存架构：从物理颗粒到逻辑寻址
现代GPU显存采用层级化架构设计，其核心目标是平衡容量、带宽与延迟三者之间的矛盾。以NVIDIA H100 SXM为例，其显存子系统由三层构成：最底层是HBM3物理颗粒，中间层是显存控制器（Memory Controller），最上层是L2 Cache与SM（Streaming Multiprocessor）之间的片上互联网络。
HBM（High Bandwidth Memory）通过硅通孔（TSV）技术将多个DRAM die垂直堆叠，并通过一个宽接口与GPU芯片相连。H100的显存位宽高达5120-bit，而普通GDDR6显存位宽仅为384-bit。这种物理架构差异直接决定了带宽上限：H100的理论带宽为3.35TB/s，而RTX 4090仅为1.0TB/s。理解这一点对后续优化至关重要——当模型并行度提升时，通信量呈线性增长，而带宽是硬性约束。
带宽 = 显存时钟频率 × 位宽 × 倍率（DDR为2，HBM为2） 共同决定。例如A100的HBM2e频率为2.4Gbps，位宽5120-bit，则带宽 = 2.4 × 10⁹ × 5120 / 8 / 10⁶ ≈ 1.55TB/s（实际标称2.0TB/s含冗余）。在部署大模型时，应优先查询官方规格表中的“Memory Bandwidth”参数，而非仅看显存容量。
2.2 显存容量与计算密度的匹配关系
大模型推理的显存占用主要由三部分构成：模型权重（FP16下约2字节/参数）、KV Cache（随序列长度线性增长）、以及激活值（Activation）。以LLaMA-2-70B为例，仅权重就需要约140GB显存（70B × 2Bytes），这直接决定了必须使用多卡并行或量化技术。
计算与显存的关系可用“算术强度”（Arithmetic Intensity）衡量：算术强度 = 计算量（FLOPs）/ 数据移动量（Bytes）。当算术强度低于GPU的“拐点”（Roofline模型中的ridge point）时，程序受带宽限制；高于拐点时，受计算限制。对于Transformer解码阶段，每个Token的生成涉及约2×N×L次FLOPs（N为模型参数量，L为层数），但需要读取全部权重，因此算术强度极低，通常处于带宽受限状态。
| 模型规模 | 权重显存（FP16） | KV Cache（4K上下文） | 推荐GPU配置 | 瓶颈类型 |
|---|---|---|---|---|
| 7B | 14GB | ~1GB | 单卡A100 40GB | 带宽受限 |
| 13B | 26GB | ~2GB | 单卡A100 80GB | 带宽受限 |
| 70B | 140GB | ~10GB | 2×A100 80GB | 容量+带宽双瓶颈 |
| 175B | 350GB | ~25GB | 8×A100 80GB | 容量瓶颈为主 |
上表揭示了两个关键规律：第一，模型参数量翻倍，权重显存线性增长，但KV Cache增长相对缓慢；第二，当单卡无法容纳模型时，必须引入张量并行或流水线并行，这会引入通信开销，进一步加剧带宽压力。
2.3 显存瓶颈的识别方法：从现象到根因
在实际部署中，显存瓶颈通常表现为三种现象：OOM（Out of Memory）报错、GPU利用率低但显存占用高、以及推理延迟异常波动。识别瓶颈需要结合多个维度的监控指标，而非仅看单一数据。
- 容量瓶颈判断：使用
nvidia-smi观察显存占用率。若持续超过95%且伴随OOM风险，则属于容量瓶颈。此时应优先考虑量化（INT8/INT4）、KV Cache量化或卸载策略。 - 带宽瓶颈判断：使用
ncu（NVIDIA Nsight Compute）或nvidia-smi dmon查看“Memory Throughput”指标。若该值持续高于80%而SM利用率低于50%，则说明程序在等待数据搬运，属于典型的带宽受限。 - 计算与显存失衡：通过Roofline模型分析。若实测性能远低于理论峰值，且算术强度低于拐点，则优化方向应聚焦于减少数据移动（如算子融合、kernel合并），而非增加计算并行度。
2.4 实战案例：LLaMA-2-13B推理性能调优
某企业尝试在单张A100 80GB上部署LLaMA-2-13B（FP16），目标吞吐量为100 tokens/s。初始测试发现实际吞吐量仅为45 tokens/s，且GPU利用率波动明显。
初始现象：nvidia-smi显示显存占用约28GB（权重26GB + KV Cache 2GB），远未达到80GB上限；但GPU利用率在30%-70%之间剧烈波动，SM Active Warps占比低。
分析过程：使用 ncu --set full 采集性能计数器，发现Memory Throughput达到92%，而SM Busy仅为38%。进一步分析发现，每个Token生成时，需要从HBM读取全部26GB权重，而计算量仅为2×13B×2×1（单层）≈ 52 GFLOPs，算术强度 = 52×10⁹ / 26×10⁹ ≈ 2 FLOPs/Byte，远低于A100的拐点（约10 FLOPs/Byte）。
优化措施：
- 将权重从FP16转为INT8量化（使用GPTQ算法），权重显存降至13GB，算术强度提升至4 FLOPs/Byte。
- 启用KV Cache量化（INT8），将KV Cache显存从2GB降至1GB。
- 使用
vLLM框架的PagedAttention，减少显存碎片并提高缓存命中率。
结果对比：优化后吞吐量提升至82 tokens/s（提升82%），Memory Throughput降至65%，SM利用率提升至55%。虽然仍受带宽限制，但已接近硬件极限。若需进一步提速，需考虑多卡张量并行以分摊带宽压力。
2.5 显存架构对部署策略的启示
理解显存架构后，可以推导出几条实用的部署原则：
- 优先匹配带宽而非容量：对于推理场景，选择高带宽GPU（如H100、A100）比单纯增加显存容量更有效。例如，RTX 4090虽有24GB显存，但其1TB/s带宽在长序列生成时可能成为瓶颈。
- 利用L2 Cache局部性：当模型较小（如7B）能完全装入L2 Cache（A100为40MB）时，重复读取权重将命中缓存，实际带宽需求大幅降低。因此，小模型在消费级GPU上也能获得不错性能。
- 警惕多卡通信开销：张量并行虽然能解决容量问题，但AllReduce通信量随卡数线性增长。当卡数超过4张时，通信开销可能抵消并行收益，此时应优先考虑流水线并行或模型并行。
显存瓶颈的识别不是一次性的静态分析，而是贯穿模型部署全生命周期的动态过程。随着序列长度变化、并发请求数增加，瓶颈可能从容量型转变为带宽型。建议建立持续监控体系，将 nvidia-smi、ncu 与业务指标（如TTFT、TPOT）关联分析，才能精准定位问题。