CPU 的设计目标是让一件事做得尽可能快——上一篇讲的所有复杂性（多级缓存、乱序执行、分支预测）都服务于这一点。
GPU 的设计目标完全相反：让一万件事同时发生，而不在意每件事本身做得有多快。
这个根本差异解释了 GPU 所有让人困惑的特性：为什么有数千个"核"但单核性能远不如 CPU？为什么 LLM 推理的瓶颈是显存带宽而不是算力？为什么批大小（batch size）会显著影响推理吞吐量？
一、GPU 和 CPU 的根本差异
一个 CPU 核心面积里包含了大量复杂逻辑：分支预测单元、乱序执行引擎、多级缓存……这些东西占了 80% 以上的面积，真正做计算的部分（ALU）只占一小部分。
GPU 做了相反的取舍：把那些复杂逻辑全部去掉，把腾出来的面积全部填满计算单元。结果是：每个 GPU 核心非常简单，但数量极多。NVIDIA A100 有 6912 个 CUDA 核心；H100 有 16896 个。
代价是：每个 GPU 核心的单线程性能远不如 CPU 核心。如果你只需要执行一件事，CPU 可能快 10 倍。但如果你有一万件事要同时做，GPU 赢了。
二、SM 和 Warp：GPU 的调度单位
GPU 的 6912 个 CUDA 核心不是各自独立工作的，它们被组织成若干个 Streaming Multiprocessor（SM）——A100 有 108 个 SM，每个 SM 包含 64 个 CUDA 核心。
SM 内部执行的最小单位叫 Warp——32 个线程捆绑在一起，每次作为一个整体执行同一条指令（SIMT，Single Instruction Multiple Threads）。32 个线程同时做同一件事，只是操作的数据不同。
这里有一个重要限制：Warp 内的 32 个线程必须走相同的代码路径。如果有一个 if-else，一部分线程走 if，一部分走 else，GPU 会让两组线程依次执行（先 if 组，再 else 组），空闲那组等待。这叫 Warp Divergence（Warp 分歧），会降低实际利用率。这就是为什么 GPU 不擅长处理有复杂分支逻辑的代码。
GPU 掩盖延迟的方式和 CPU 完全不同：不通过缓存，而是通过海量线程切换。当一个 Warp 在等待显存数据（延迟约 400-800 个时钟周期），SM 立刻切换到另一个 Warp 继续执行，零成本（GPU 的线程上下文是硬件维护的，切换不需要保存/恢复寄存器）。等第一个 Warp 的数据回来了，它重新进入调度队列。
这意味着：GPU 需要足够多的活跃线程，才能把显存等待时间填满。如果线程数太少，SM 会有大量空闲，GPU 利用率低。
三、LLM 推理的真正瓶颈：显存带宽，不是算力
很多人以为 LLM 推理慢是因为计算量太大。实际上，大多数 LLM 推理场景的瓶颈是显存带宽，不是算力（FLOPS）。
为什么？LLM 推理时，每生成一个 token，需要把模型的所有权重从显存读取到计算单元。一个 7B 参数的模型，用 FP16 存储，大小约 14GB。每生成一个 token，就需要读取 14GB 数据。
A100 的显存带宽是 2TB/s（每秒 2 万亿字节），读 14GB 需要 7ms。在这 7ms 里，A100 的 312 TFLOPS 算力实际上大量闲置——计算单元在等数据，而不是在计算。
这类场景叫做内存带宽受限（Memory Bandwidth Bound），对应的瓶颈不是 FLOPS，而是带宽。增加计算能力对这类瓶颈毫无帮助，提高显存带宽才有效。这解释了为什么 H100 比 A100 在 LLM 推理上的提升，很大程度来自 HBM3 带宽的提升（3.35TB/s vs 2TB/s），而不只是 FLOPS 的提升。
什么情况下从带宽受限变成计算受限？批处理（batching）。当你把多个请求打包成一个 batch 一起推理时，模型权重只需要读取一次，但可以同时服务 batch 内的所有请求。batch size = 32 时，读一次权重服务 32 个请求，每个请求的"读权重成本"是 1/32。batch 越大，计算利用率越高，越接近算力受限。
这就是为什么 LLM 推理服务里，批大小的设置对吞吐量影响极大——batch size 从 1 到 32，在带宽受限的场景下，吞吐量可以接近线性提升。
四、显存容量：KV Cache 的真正限制
推理时除了模型权重，还需要存储 KV Cache——每个 token 在每个注意力层计算出的 Key 和 Value 向量，用于后续 token 的注意力计算。
KV Cache 的大小随序列长度线性增长。一个 7B 的 LLaMA 模型，32 层，每层 Key 和 Value 各 128 维，FP16 存储：
每个 token 的 KV Cache 大小 = 2（K+V）× 32（层）× 128（维度）× 2（bytes）= 16,384 bytes ≈ 16KB
一个 2000 token 的对话 = 32MB KV Cache。听起来不大，但如果同时服务 100 个用户，就是 3.2GB KV Cache。加上模型权重 14GB，总共需要约 17GB 显存——A100 的 80GB 显存看起来宽裕，但当 context 变长（8K、32K、128K token）或并发用户增多时，显存很快就不够了。
这是现在大量工程工作的核心挑战：如何在有限显存里服务尽可能多的用户、尽可能长的 context。vLLM 的 PagedAttention、FlashAttention 的显存优化，都在解决这个问题。
五、HBM vs GDDR：显存技术的差异
消费级 GPU（RTX 4090）用 GDDR6X 显存；数据中心 GPU（A100、H100）用 HBM（High Bandwidth Memory）。
两者的核心差异：
- GDDR：带宽约 0.9-1TB/s，容量最大约 24GB，成本较低
- HBM3（H100）：带宽约 3.35TB/s，容量最大 80GB，成本高昂
HBM 通过在 GPU 芯片旁边垂直堆叠多层 DRAM 并以极宽的总线连接，实现了远高于 GDDR 的带宽。代价是面积大、发热多、成本高——这正是 H100 要几万美元一张的原因之一。
对于 LLM 推理，带宽是最关键的参数。用 RTX 4090 跑 LLM，带宽瓶颈远比 A100 严重，单 token 生成速度慢很多，尽管它的 FLOPS 不算低。
六、PCIe vs NVLink：多卡通信的瓶颈
单张 GPU 显存有限，大模型（70B、405B）需要多张 GPU 分布式推理。GPU 之间的通信带宽是另一个瓶颈。
- PCIe 5.0 × 16：约 64GB/s 双向带宽（通过 CPU 主板）
- NVLink 4.0（H100 标准配置）：900GB/s 双向带宽（GPU 直连）
差距是 14 倍。用 PCIe 连接的多卡系统（消费级服务器或云上多 GPU 实例），GPU 间通信会成为严重瓶颈。用 NVLink 连接的 HGX 系统（NVIDIA DGX）可以把多张 GPU 的显存几乎当成一块大显存使用。
这解释了为什么大模型训练和推理对 GPU 互联的要求很高，以及为什么"A100 × 8 NVLink" 和 "A100 × 8 PCIe" 在大模型上性能差异巨大。
七、对后端工程师的实际意义
理解了 GPU 资源模型，几个实际的工程判断就有了依据：
LLM 推理服务的性能瓶颈在哪里：通常是显存带宽和显存容量，不是算力。监控 GPU 显存利用率和显存带宽利用率，比看 FLOPS 利用率更有诊断价值。
批大小的设置：尽量提高 batch size，能显著提升吞吐量（在带宽受限场景下接近线性提升）。代价是单请求延迟增加。根据 SLA 要求在吞吐和延迟之间取舍。
实例选型：需要长 context 或大并发 → 优先选显存容量大的（A100 80GB、H100 80GB）；需要高吞吐短 context → 优先看显存带宽（H100 HBM3 > A100 HBM2e）；预算有限的小模型 → RTX 4090 可以考虑，但带宽是瓶颈。
量化的价值：把模型从 FP16 量化到 INT8 或 INT4，模型大小减半或减为 1/4，读取权重的带宽需求也随之减小，推理速度可以有明显提升（在带宽受限场景下）。这是为什么量化在实际部署中被广泛使用。
八、总结
- GPU 的核心设计：大量简单核心（数千个），用海量线程切换掩盖显存延迟，追求吞吐而非单核速度
- SM 和 Warp：108 个 SM，每个 SM 同时调度多个 Warp（32 线程），硬件零成本切换
- LLM 推理的真正瓶颈：显存带宽（memory bandwidth bound），不是算力（compute bound）
- 批大小的重要性：batch 越大，权重读取成本分摊越多，吞吐越高；batch = 1 时几乎完全受带宽限制
- 显存容量：模型权重 + KV Cache，context 越长显存消耗越多，并发用户越多消耗越多
- HBM vs GDDR：HBM 带宽远高于 GDDR，是数据中心 GPU 的核心优势
- 多卡通信：NVLink 比 PCIe 带宽高 14 倍，大模型分布式推理对互联带宽要求极高
CPU 追求的是让一件事尽快完成；GPU 追求的是让尽可能多的事同时进行。理解这个根本差异，是理解现代 AI 基础设施的起点。