选择合适的 GPU
对于自托管 LLM 的 AI 团队来说,选择合适的 GPU 是最重要的早期决策之一。这个选择直接影响吞吐量、延迟、显存上限和总体成本。人们很容易依赖 GPU 基准测试或 GPU 对比表来指导决策。然而,这些数字很少能反映 LLM 工作负载在特定用例中的全貌。
GPU 与显卡与加速器
首先,让我们澄清几个经常被混用但含义不同的术语。
GPU(图形处理单元)
GPU 是处理器芯片本身。它最初为渲染图形而设计,能够同时运行数千次计算。在现代 AI 工作负载中,GPU 是承担繁重计算工作的"大脑"。
显卡
显卡是包含 GPU 的完整硬件封装。它包括芯片、显存(VRAM)、散热系统、电源连接器和输出端口。你可能还会看到"视频卡(video card)"或"图形适配器(graphics adapter)"等术语。GPU 只是显卡的一部分,但它是核心组件。
加速器
加速器是更广泛的专用硬件类别,旨在加速特定类型的计算。GPU 是一种加速器,但还有其他类型,例如:
- AI/ML 加速器(如 Google TPU、Intel NPU)
- 密码学加速器
- 物理处理单元(PPU)
- 为特定任务配置的现场可编程门阵列(FPGA)
关键区别在于:所有现代显卡都包含 GPU,所有 GPU 都是加速器,但并非所有加速器都是 GPU 或专注于图形。如今,许多 GPU 主要被用于非图形工作,如 ML/AI 训练和推理,而非图像渲染。
如果你从云厂商租用算力,你通常只会看到标为 GPU 的成本。但在阅读他们的营销材料或博客文章时,准确理解描述的对象很重要。
为什么 GPU 的选择对推理很重要
现代 AI 应用越来越多地由 LLM 等生成式 AI(GenAI)模型驱动。与传统 ML 模型不同,这些模型可以达到数千亿参数,例如具有 671B 参数的 DeepSeek-V3.1。要运行这种规模的模型,你需要极其强大的 GPU,如 NVIDIA H200 或 AMD MI300X。这样,你才能借助最新的优化技术充分释放它们的推理潜力。
然而,并非每个工作负载都需要那么强大的性能。较小的开源 LLM(如 Llama-3.1-8B)可以在 NVIDIA L4 或 AMD MI250 等中端 GPU 上高效运行。轻量级模型甚至可以在入门级显卡或通用云实例上运行。
关键在于为任务找到合适的 GPU,以实现最佳的性价比。错误的选择会导致瓶颈,限制吞吐量,增加延迟并推高成本。
了解 GPU 类型
并非所有 GPU 都为相同目的而构建。当你查看 GPU 基准测试时,经常会看到数据中心显卡、消费级显卡,甚至移动芯片的混合。在为你的推理工作负载选择之前,理解主要类别很重要。
消费级 GPU
这些 GPU 最初为游戏而制造,但仍被广泛用于较小的开源 LLM 和实验。它们通常显存较少,但具有成本效益。例如 NVIDIA RTX 4090 或 AMD Radeon RX 7900 XTX。
工作站 GPU
工作站显卡介于消费级和数据中心硬件之间。它们非常适合需要在单台机器上获得强大算力的专业人士,通常用于 3D 设计、可视化或模型原型开发。NVIDIA RTX A6000 或 AMD Radeon Pro W6800 等显卡属于这一类。
数据中心 GPU
企业依赖数据中心 GPU 进行大规模 AI 推理和高性能计算(HPC)工作负载。它们提供高显存(40–192GB)、强大的显存带宽,以及多实例 GPU(MIG)或 NVLink 等功能,用于跨集群扩展。例如 NVIDIA A100、H100 和 B200,以及 AMD MI300X 和 MI350X。
对于租用云算力的团队或在本地部署 LLM的团队来说,数据中心 GPU 通常是最实际的选择。
选择 GPU 的关键考量
在选择 GPU 时,请记住,原始的基准测试数字并不能说明全部情况。最佳选择取决于硬件规格、工作负载规模和生态系统支持的组合。
GPU 显存(VRAM)
VRAM 决定了模型规模和上下文长度的上限,因为推理期间 GPU 接触的一切都必须驻留在显存中:模型权重、激活和 KV 缓存。权重决定了基线占用,因此模型必须先能装下,然后才能开始服务。例如,拥有 671B 参数的 DeepSeek V3 和 R1,需要 8 块 NVIDIA H200 GPU(每块 141 GB)才能运行。相比之下,像 Phi-3 这样的较小模型在量化后可以装入 16–24GB。KV 缓存随后会消耗剩余的 VRAM,这限制了你能够支持的上下文长度。
在生产环境中,主要的挑战往往是 KV 缓存。其大小随序列长度线性增长,这意味着长上下文工作负载会迅速耗尽显存。为了避免瓶颈,你需要分布式推理技术,如预填充-解码分离和KV 缓存卸载。
更多信息,请参阅 GPU 内存层级。
显存带宽
显存带宽是指 GPU 在其 HBM 与计算核心之间移动数据的速度,以 GB/s 或 TB/s 衡量。对于 LLM 推理来说,它是最重要的规格之一,因为解码阶段受显存限制。为了生成每个新 token,GPU 必须反复从 HBM 流式读取大部分或全部模型权重(以及不断增长的 KV 缓存),而每读取一字节数据所做的计算相对较少。
因此,单流解码速度的理论上限约为:
maximum decode tokens/sec ≈ memory bandwidth / bytes read per token
例如,一个 FP16 的 70B 参数模型包含约 140 GB 权重。在 HBM 带宽约为 3.35 TB/s 的 H100 SXM 上,这意味着在考虑任何其他开销(如 KV 缓存)之前,每条序列的理论上限约为 24 tokens/s。
这就是为什么预填充阶段(并行处理提示词)与解码阶段表现截然不同。这也解释了为什么批处理能如此有效地提高吞吐量:相同的权重读取可以在许多序列之间复用,使 GPU 能够用显存带宽压力换取额外的计算工作。
计算吞吐量
计算吞吐量是指 GPU 每秒能执行多少次数学运算,以 FLOPS(每秒浮点运算次数)衡量,它限制了受计算限制的预填充阶段:编码长提示词、处理大批次,以及任何算术强度高的工作负载。现代数据中心 GPU 通过专用的矩阵单元(NVIDIA Tensor Cores、AMD Matrix Cores)达到这些数字,而较低的精度大约能使速率翻倍(如 FP16 → FP8 → FP4)。
在阅读规格表时,请记住几个注意事项:
- 注意星号。厂商经常在稀疏模式或最低支持精度下引用峰值 FLOPS。请在同一精度和相同的稠密/稀疏假设下比较显卡。
- FLOPS 不是面向用户的指标。你最终关心的是每秒 token 数与延迟(TTFT 和 ITL)。GPU 可能拥有巨大的 FLOPS,但在解码期间却受显存带宽瓶颈限制,因此这两个数字需要结合起来看。
- 精度支持是一道硬门槛。原生 FP8 需要 NVIDIA H 系列或更新。较旧的显卡会回退到更高精度,从而失去吞吐量优势。
要进一步推动有效吞吐量,可以应用投机解码、预填充-解码分离和连续批处理等技术。
GPU 互连
GPU 互连决定了当你的工作负载跨越多个 GPU 时(在单节点内以及跨多个节点),你可以多快地交换数据(如 KV 缓存)。这对于使用张量并行、流水线并行或其他分布式推理技术的大型模型尤其重要。如果互连速度慢,增加更多 GPU 可能会提高显存容量,但无法带来预期的吞吐量或延迟改进。
- 节点内互连。这是指同一台服务器内 GPU 之间的通信。对于紧耦合的多 GPU 推理,NVIDIA NVLink/NVSwitch 或 AMD Infinity Fabric 等高带宽互连通常比仅使用 PCIe 的设置快得多。例如,在 H100 上,NVLink 提供 900 GB/s 的双向 GPU 到 GPU 带宽,大约比单条 PCIe 5.0 链路的 128 GB/s 双向带宽快 7 倍。
- 节点间互连。这是指不同 GPU 服务器之间的网络连接。单个节点通常包含 4 到 8 个 GPU,尽管也存在更大或更专用的系统。一旦模型或工作负载由于功率、散热或外形尺寸等限制而超出单个节点的支持能力,通信就必须通过网络进行。一个实用的解决方案是 InfiniBand(配合 GPUDirect RDMA)或经过精心调优的 RoCEv2 以太网。
作为经验法则,尽可能将通信最密集的并行化保持在单个节点内。如果需要跨节点扩展,请评估整个集群拓扑,而不仅仅是 GPU 类型。
成本与可用性
消费级和工作站 GPU 易于获取且更便宜,但通常受限于 VRAM。数据中心 GPU 为企业 AI 部署提供了规模和可靠性,但价格高昂。对于 NVIDIA H100 和 H200 这样的高性能 GPU 尤其如此。
对于企业 AI 团队来说,更大的挑战是 GPU CAP 定理:一个 GPU 基础设施无法同时保证控制(Control)、按需可用性(Availability)和价格(Price)。
| 超大规模云 | NeoCloud(Serverless) | NeoCloud(长期承诺) | 本地部署 | |
|---|---|---|---|---|
| 控制(Control) | 高 | 低 | 中 | 高 |
| 按需可用性(Availability) | 中 | 高 | 低 | 低 |
| 价格(Price) | 高 | 中 | 低 | 中 |
生态系统与框架支持
GPU 的有效性取决于支持它的软件。NVIDIA 受益于成熟的 CUDA Toolkit 和 TensorRT-LLM 生态系统。AMD 的 ROCm 栈正在稳步改进,PyTorch、vLLM、SGLang 和 MAX 的支持日益增长。
将 GPU 与开源 LLM 匹配
不同的模型在不同类型的 GPU 上表现最佳。下表将流行的 NVIDIA 和 AMD GPU 映射到合适的开源 LLM。有些模型需要多块 GPU 才能满足 VRAM 需求,或者你可能需要量化等优化技术。
请将此表仅作为参考。对于生产部署,始终要在目标硬件上对你的模型进行基准测试。
需要记住的事项:
- FP8 支持。如果你选择 NVIDIA GPU,请注意依赖原生 FP8 权重的 LLM 只能在 NVIDIA H 系列(或更新)GPU 上运行。这是因为 A 系列显卡缺乏 FP8 硬件支持。
- 单 GPU 与多 GPU。有些模型可以在单块显卡上运行,但通常多块 GPU 能提升性能(例如在高并发场景中)。
- 硬件灵活性。大多数模型可以在不同的硬件上运行。例如,gpt-oss-20b 和 gpt-oss-120b 可以在 NVIDIA A100、H100、H200、B200 GPU 或 AMD MI300X、MI325X、MI355X GPU 上运行。限制因素通常是 VRAM 和集群规模,而不是架构。了解如何计算服务 LLM 所需的 GPU 显存。
如果你正在评估自托管 LLM 的 GPU 选项,我们支持通过单一代码库在 NVIDIA、AMD、Apple Silicon、CPU 等硬件上运行开源和自定义模型。你可以本地运行模型,在自己的云环境(BYOC)中部署,或根据需要使用共享和专用端点。
常见问题
权重何时以及如何加载到 GPU 显存中?
权重加载发生在服务启动时。以下是具体的流程:
- 从磁盘(SSD / 网络存储)读取模型文件
- 模型检查点(如
.safetensors、.bin) - 通过 CPU 读取
- 与 GPU 显存相比非常慢
- 带宽:SSD 约为 1–10 GB/s
- 模型检查点(如
- CPU RAM 暂存
- 权重被临时放入系统内存
- 通常进行反序列化或内存映射
- CPU RAM 带宽:典型配置下约为 50–200 GB/s
- 传输到 GPU HBM
- 在服务进程的整个生命周期内缓存在那里
一旦复制完成,权重便存储在 HBM 中,可在每次前向传播中重复读取。对于解码,权重不会从磁盘或 CPU 重新加载;它们直接从 HBM 复用。
如果你使用张量并行,每个 GPU 都持有每层权重矩阵的一部分。
对于 AI 工作负载,最好的 GPU 对比工具是什么?
大多数通用的 GPU 对比工具专注于游戏或图形性能,这并不能反映真实的 AI 推理工作负载。对于 LLM,你需要能够衡量吞吐量与延迟指标(如 TTFT 和 ITL)的工具。
你可以从查看 vLLM、SGLang、MAX 和 TensorRT-LLM 等框架的基准测试结果开始。它们提供了现成的脚本,帮助你比较不同 GPU 上的推理性能。
然而,这些框架通常需要手动配置和调优,这可能很耗时。
我在哪里可以购买或租用 GPU 服务器?
你可以根据规模、控制需求和预算,购买本地 GPU 服务器或租用云 GPU。
AWS、Google Cloud 和 Azure 等云提供商允许你按需租用 H100、H200 或 MI300X GPU。
CoreWeave 和 Nebius 等 NeoCloud 提供商提供更低的成本和灵活的计费方式。然而,对于受监管或企业环境,它们通常提供较少的控制和合规保证。
如果你希望完全拥有,你可以从 Dell、GIGABYTE 或 HPE 等原始设备(OE)合作伙伴处直接购买 GPU 服务器,这些合作伙伴直接与 NVIDIA 和 AMD 合作。这种方式给你最大的控制权,但也意味着更高的前期成本和更长的采购周期。
如何查看我拥有什么 GPU?
在大多数系统上,你可以使用命令行工具快速验证你的 GPU 类型:
- Linux:
nvidia-smi(适用于 NVIDIA)或amd-smi(适用于 AMD)。 - macOS:
system_profiler SPDisplaysDataType。 - Windows: 打开设备管理器 → 显示适配器。
在选择 GPU 时,CUDA 和驱动版本有多重要?
非常重要。GPU 性能不仅仅关乎硬件。你的 NVIDIA 驱动、CUDA 版本和框架构建(如 PyTorch、vLLM、SGLang、MAX、TensorRT-LLM)都需要相互匹配。如果不匹配,你会遇到错误、性能下降,或缺少 FP8 或 FlashAttention 等功能。如果你想知道这些不匹配之所以重要的底层原因,请参阅 GPU 架构基础。
对于 NVIDIA GPU:
- 驱动包含 CUDA Driver API 并直接与 GPU 通信
- CUDA toolkit 提供开发工具、编译器和库
- cuDNN、cuBLAS 和 NCCL 驱动 PyTorch 和大多数推理引擎内部的运算
- 框架构建是为特定 CUDA toolkit 版本编译的
如果栈的任何部分过时,你可能会遇到以下问题:
- "CUDA driver version is insufficient(CUDA 驱动版本不足)"
- 内核失败
- 吞吐量低下
- 缺少 FP8、FlashAttention 或设备级优化
一个简单的经验法则:
- 你的驱动的 CUDA 版本必须 ≥ 你的框架构建所用的 CUDA toolkit 版本。
- 较新的驱动通常与较旧的 CUDA toolkit 向后兼容。
- 较旧的驱动无法运行较新的 CUDA 运行时。
你可以用以下命令确认你的驱动和 GPU:
nvidia-smi
# Example output:
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.129.03 Driver Version: 535.129.03 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
这意味着你的驱动支持最高 CUDA 12.2 运行时。你的框架可以用 CUDA 12.2、12.1、11.8 等构建,但不能用 12.3 或更新版本。
要升级,请下载官方的 CUDA toolkit 和驱动包。