GPU Hardware & Computing Stack

LLM 推理性能不仅取决于模型参数量，还取决于 GPU 算力、内存容量、内存带宽以及底层计算软件栈。

核心概念：

Hardware
├── CPU
├── GPU
├── RAM / VRAM
├── Unified Memory
├── Memory Bandwidth
└── PCIe / NVLink

GPU Computing Stack
├── CUDA（NVIDIA）
├── ROCm（AMD）
└── Metal（Apple）

1. CPU、GPU 与内存

CPU 与 GPU

RAM 与 VRAM

• RAM：主要供 CPU 和操作系统使用的系统内存。
• VRAM：GPU 使用的显存，通常具有很高的内存带宽。

典型独立显卡架构：

CPU ─── System RAM
 │
 │ PCIe / NVLink
 │
GPU ─── VRAM

CPU 和 GPU 之间传输数据需要经过互连链路。

GPU 本地显存带宽通常远高于 PCIe 传输带宽。因此，如果推理过程中反复将模型权重从 RAM 传输到 VRAM，性能可能显著下降。

2. GPU Memory Bandwidth

Memory Bandwidth 表示单位时间内 GPU 内存系统能够传输的数据量，通常使用 GB/s 或 TB/s 表示。

这是 LLM Decode 性能的关键指标之一。

例如：

Model Weights
      ↓
Read from VRAM
      ↓
GPU Compute
      ↓
Generate Token

对于 Batch 较小、主要受内存带宽限制的 Decode，可以近似理解为：

$$\text{Tokens/s} \lesssim \frac{\text{Effective Memory Bandwidth}} {\text{Bytes Read per Decode Step}}$$

这只是理解 Memory-bound 的简化模型，不是实际性能的精确公式。

FLOPS 与 Memory Bandwidth

显存容量决定模型是否容易装下；显存带宽影响模型运行速度。两者不能混为一谈。

3. Unified Memory

Apple Silicon 采用 Unified Memory Architecture（UMA）。

Apple Silicon
├── CPU
├── GPU
├── Neural Engine
└── Unified Memory
       ↑
   Shared Memory Pool

CPU 和 GPU 可以访问同一个物理内存池，不需要像传统独立显卡那样，在完全分离的 RAM 与 VRAM 之间复制所有数据。

优点

• 减少 CPU/GPU 之间的数据复制。
• 更灵活地分配内存。
• 允许 GPU 使用较大比例的统一内存运行模型。

限制

• CPU、GPU 和其他系统组件共享总容量。
• GPU 实际可分配内存仍受到系统限制。
• 内存容量大不代表 GPU 计算速度快。
• 推理引擎和 GPU Kernel 的支持程度也会影响性能。

例如 16 GB Unified Memory 的 MacBook，并不意味着有 16 GB 完全独立、全部可用于模型的 VRAM。

还需要区别 Apple Silicon 的 Unified Memory 与 NVIDIA CUDA 的 Unified Memory：两者名称相似，但底层硬件架构和内存迁移机制不一定相同。

4. CUDA：NVIDIA GPU 计算平台

CUDA 是 NVIDIA 的 GPU 并行计算平台与编程生态。

NVIDIA GPU
     ↑
CUDA Driver / Runtime
     ↑
CUDA Libraries / Kernels
     ↑
PyTorch / vLLM / TensorRT-LLM
     ↑
LLM Application

CUDA 生态包括：

GPU Kernel

Kernel 是 GPU 上执行的一段计算程序。

例如 Transformer 中的：

• Matrix Multiplication。
• Attention。
• RMSNorm。
• Softmax。
• Quantized Matrix Multiplication。

同样的模型和 GPU，使用不同的 GPU Kernel，推理性能可能有明显差别。

FlashAttention 就是优化 Attention 计算和内存访问的重要算法与 Kernel 实现系列。

CUDA Stream

CUDA 支持异步执行 GPU 任务。

Stream 用于安排 GPU 操作的执行顺序，并在满足依赖与硬件条件时实现部分计算、数据传输的重叠。

它不等于 CPU Thread。

5. ROCm：AMD GPU 计算平台

ROCm 是 AMD 的 GPU 计算软件生态。

AMD GPU
    ↑
ROCm / HIP
    ↑
PyTorch / Supported Inference Engines
    ↑
LLM Application

其中 HIP 提供与 CUDA 编程模型相近的 GPU 编程接口。

ROCm 生态包括相应的计算库、编译工具链与 GPU 通信能力。

需要注意：

• 不是所有 AMD GPU 都获得相同的软件支持。
• PyTorch、vLLM 等工具是否可用，需要检查具体 GPU 型号和版本兼容性。
• CUDA Kernel 通常不能不经适配就直接在 AMD GPU 上运行。

6. Metal：Apple GPU 计算 API

Metal 是 Apple 的底层图形和 GPU 计算 API。

Apple GPU
    ↑
Metal / Metal Performance Shaders
    ↑
MLX / PyTorch MPS / llama.cpp
    ↑
LLM Application

相关概念：

PyTorch 示例：

import torch

device = "mps" if torch.backends.mps.is_available() else "cpu"

x = torch.randn(1024, 1024, device=device)
y = x @ x

其中 mps 是 PyTorch 用于访问 Apple Metal GPU 加速能力的 Device。

7. GPU Computing Stack 对比

注意：PyTorch ROCm 构建通常仍复用 torch.cuda API 命名，并不是使用 torch.rocm Device。

8. OOM 与模型内存占用

OOM（Out of Memory）表示内存不足。

LLM 推理需要的内存不只是模型权重：

$$\text{Memory Usage} \approx \text{Weights} +\text{KV Cache} +\text{Activations} +\text{Runtime Overhead}$$

常见 OOM 原因：

• 模型权重过大。
• Context Length 太长。
• 并发请求过多。
• KV Cache 持续增长。
• 运行时临时内存需求过高。

常见处理方法：

1. 使用更低精度的量化模型。
2. 减小 Context Length。
3. 降低最大并发数。
4. 使用更高效的 KV Cache 管理或量化。
5. 使用显存容量更大的 GPU。

如果模型超过可用显存，部分推理引擎可以将权重卸载到 CPU RAM，但可能因为跨设备数据传输而显著降低速度。

总结

LLM 推理硬件主要需要理解三个维度：

软件层：

LLM Framework / Inference Engine
               ↓
CUDA / ROCm / Metal Backend
               ↓
GPU Kernels
               ↓
GPU Hardware

对于实际部署：

• NVIDIA GPU：重点了解 CUDA、VRAM、Memory Bandwidth。
• AMD GPU：重点关注 ROCm 兼容性。
• Apple Silicon：重点了解 Unified Memory、Metal、MLX 和 llama.cpp。

核心结论：LLM 能否运行主要受内存容量约束，运行得多快则同时受到 GPU 计算能力、内存带宽、计算内核和推理调度策略影响。

---

参考文档

• NVIDIA CUDA Documentation
• AMD ROCm Documentation
• Apple Metal
• PyTorch MPS Backend
• Apple MLX