GPU选型避坑指南：A100/H100/H200/H20怎么选？从真实案例讲起
摘要： 大模型时代，GPU服务器成了刚需。但A100、H100、H200、H20、L40S型号一堆，选错了浪费几万甚至几十万。本文从6个真实选型踩坑案例出发，帮你理清GPU选型的核心逻辑。
关键词： GPU选型、A100、H100、H200、大模型推理、显存带宽、NVLink、AI算力
分类： 人工智能 / 深度学习 / GPU服务器
前言
上一篇从硬件架构层面讲了GPU服务器和普通服务器的差异。今天换个实际的角度------从帮客户选GPU踩过的坑出发，讲讲A100/H100/H200到底怎么选。
GPU太贵了，选错一张卡浪费的不是几百块，是几万甚至几十万。而且选型不是"越贵越好"------我见过花大钱上H100结果利用率20%的，也见过为了省钱用A100结果显存不够跑不动的。
今天把最常见的6个坑讲清楚。
坑1：只看算力不看显存------卡买回来了模型装不上去
真实案例
一个客户要做70B模型的FP16推理，他的逻辑是：
"A100算力312 TFLOPS，H100算力990 TFLOPS，太贵了。用两张A100 40GB应该够了吧？"
我帮他算了一下显存需求：
70B模型 FP16精度：
模型参数：70B × 2字节 = 140GB
KV Cache（10并发、2K序列长度）：约25GB
框架开销：约5GB
合计：约170GB显存两张A100 40GB，总显存只有80GB。连模型参数的一半都装不下。
最后换了两张A100 80GB（总显存160GB），又改成了INT8量化才跑起来。
教训
选GPU的第一步永远是算显存需求，不是看算力。
显存不够，模型装不进去，算力再强也是摆设。
速算方法
python
# 简易显存估算公式
def estimate_vmem(param_billions, precision="fp16", concurrency=10, seq_len=2048):
"""
param_billions: 模型参数量（单位：B，即十亿）
precision: fp16 / int8 / int4
concurrency: 并发用户数
seq_len: 序列长度
"""
bytes_per_param = {
"fp32": 4,
"fp16": 2,
"bf16": 2,
"int8": 1,
"int4": 0.5
}
# 模型参数占用
model_size_gb = param_billions * bytes_per_param[precision]
# KV Cache估算（粗略）
kv_cache_gb = model_size_gb * 0.3
# 框架开销
overhead_gb = 3
total = model_size_gb + kv_cache_gb + overhead_gb
print(f"模型参数占用：{model_size_gb:.1f} GB")
print(f"KV Cache估算：{kv_cache_gb:.1f} GB")
print(f"框架开销：{overhead_gb:.1f} GB")
print(f"总显存需求：{total:.1f} GB")
return total
# 示例：70B模型 FP16
estimate_vmem(70, "fp16")模型参数占用：140.0 GB
KV Cache估算：42.0 GB
框架开销：3.0 GB
总显存需求：185.0 GB常用模型显存需求速查表（含KV Cache和开销，10并发/2K序列）：
| 模型规模 | FP16 | INT8 | INT4 |
|---|---|---|---|
| 7B | ~17GB | ~10GB | ~7GB |
| 13B | ~30GB | ~17GB | ~11GB |
| 30B | ~65GB | ~35GB | ~20GB |
| 70B | ~170GB | ~85GB | ~45GB |
坑2：忽视显存带宽------推理速度上不去
真实案例
一个客户跑7B模型推理，选了L40S（48GB GDDR6）。显存够用，模型跑起来了，但推理速度只有40 tokens/s，预期是100+。
问题出在显存带宽上。
各GPU显存带宽对比：
| GPU | 显存类型 | 显存带宽 |
|---|---|---|
| L40S | GDDR6 | 864 GB/s |
| A100 80GB | HBM2e | 2,039 GB/s |
| H100 SXM | HBM3 | 3,350 GB/s |
| H200 | HBM3e | 4,800 GB/s |
| H20 | HBM3 | 4,000 GB/s |
L40S的显存带宽只有A100的42%，只有H100的26%。
为什么带宽这么重要？因为大模型推理是memory-bound 任务------每生成一个token，GPU需要把模型的全部权重从显存读一遍。显存带宽直接决定了推理速度的上限。
推理速度估算公式
python
def estimate_tokens_per_sec(gpu_bandwidth_gb_s, param_billions, precision="fp16"):
"""
估算单用户推理的token/s（理论上限）
"""
bytes_per_param = {"fp16": 2, "int8": 1, "int4": 0.5}
# 理论上限 = 显存带宽 / (2 × 参数量字节数)
# 系数2是因为每个参数需要一次读操作
theoretical = gpu_bandwidth_gb_s / (2 * param_billions * bytes_per_param[precision])
# 实际大约打6-7折
practical = theoretical * 0.65
print(f"理论上限：{theoretical:.1f} tokens/s")
print(f"实际预估：{practical:.1f} tokens/s")
return practical实测对比（7B FP16模型）：
python
# L40S
estimate_tokens_per_sec(864, 7, "fp16")
# 理论上限：30.9 tokens/s
# 实际预估：20.1 tokens/s
# A100 80GB
estimate_tokens_per_sec(2039, 7, "fp16")
# 理论上限：72.8 tokens/s
# 实际预估：47.3 tokens/s
# H100 SXM
estimate_tokens_per_sec(3350, 7, "fp16")
# 理论上限：119.6 tokens/s
# 实际预估：77.8 tokens/s同样的模型，H100推理速度是L40S的3-4倍，差距主要来自显存带宽。
教训
| 任务类型 | 瓶颈在哪 | 关键指标 |
|---|---|---|
| 训练 | 计算密集（compute-bound） | 算力（TFLOPS） |
| 推理 | 访存密集（memory-bound） | 显存带宽（GB/s） |
推理场景下，显存带宽比算力更重要。
坑3：H100 SXM和H100 PCIe搞混了
真实案例
客户说要H100服务器，我问要SXM还是PCIe版本，客户一脸懵："不都是H100吗？"
区别非常大：
| 维度 | H100 SXM | H100 PCIe |
|---|---|---|
| 显存 | 80GB HBM3 | 80GB HBM3 |
| 显存带宽 | 3.35 TB/s | 2.0 TB/s |
| FP16算力 | 990 TFLOPS | 578 TFLOPS |
| 功耗 | 700W | 350W |
| NVLink | 支持（900GB/s） | 不支持/受限 |
| 多卡互联 | NVSwitch全互联 | 只能走PCIe（32GB/s） |
客户要做70B模型推理，需要2卡张量并行。选PCIe版本的话，GPU之间通信走PCIe（32GB/s），而SXM版本走NVLink（900GB/s），通信速度差28倍。
多卡并行训练/推理时，这个差距会直接导致PCIe版本的多卡加速比远低于SXM版本。
验证当前GPU互联方式
bash
# 查看GPU拓扑
nvidia-smi topo -m
markdown
GPU0 GPU1 GPU2 GPU3
GPU0 X NV18 NV18 NV18
GPU1 NV18 X NV18 NV18
GPU2 NV18 NV18 X NV18
GPU3 NV18 NV18 NV18 X
# NV18 = NVLink 18通道（高速直连）
# 如果显示 SYS 或 NODE = 走PCIe或跨NUMA（慢）
bash
# 测试GPU间实际通信带宽
# 需要安装NCCL
nccl-tests/build/all_reduce_perf -b 8 -e 1G -f 2 -g 2教训
- 多卡训练/推理 → 必须SXM + NVLink/NVSwitch
- 单卡推理 → PCIe版本够用，性价比更高
- 下单前一定要确认GPU的接口形态
坑4：A100/H100之间还有H800/H20，不要忽略
国内客户经常问："A100感觉不够用，H100又太贵，有没有中间选项？"
有的，而且选择比想象中多：
| 型号 | 面向市场 | 显存 | 显存带宽 | FP16算力 | 特点 |
|---|---|---|---|---|---|
| A100 80GB | 全球 | 80GB HBM2e | 2.0 TB/s | 312 TFLOPS | 上一代旗舰 |
| A800 80GB | 国内 | 80GB HBM2e | 2.0 TB/s | 312 TFLOPS | NVLink带宽受限 |
| H100 SXM | 全球 | 80GB HBM3 | 3.35 TB/s | 990 TFLOPS | 当代旗舰 |
| H800 SXM | 国内 | 80GB HBM3 | 3.35 TB/s | 990 TFLOPS | NVLink带宽受限 |
| H20 | 国内 | 96GB HBM3 | 4.0 TB/s | 148 TFLOPS | 大显存高带宽，算力受限 |
| H200 | 全球 | 141GB HBM3e | 4.8 TB/s | 990 TFLOPS | 超大显存 |
H20是一个非常特殊的型号，值得单独说。
它的算力只有H100的15%（148 vs 990 TFLOPS），但：
- 显存96GB（比H100多20%）
- 显存带宽4.0 TB/s（比A100快一倍）
这意味着：
| 场景 | H20表现 | 原因 |
|---|---|---|
| 训练 | 差 | 算力是瓶颈 |
| 推理 | 不差 | 带宽是瓶颈，H20带宽比A100高一倍 |
| 大模型单卡推理 | 有优势 | 96GB显存能装更大模型 |
教训
- 不要看到"特供"就觉得差。 要根据具体任务看哪个参数更重要
- 推理场景下H20的性价比可能比A100高
- 训练场景慎选H20，算力短板明显
坑5：租GPU时"卡时"算不明白，超预算
真实案例
一个创业团队租GPU做模型微调，拿到报价：
A100 80GB：18元/卡/时
H100 SXM：45元/卡/时预估4张A100跑3天：
ini
预算：18 × 4 × 72 = 5,184元实际跑了5天（中间调参、数据预处理、重启等）：
ini
实际：18 × 4 × 120 = 8,640元超预算67%。
GPU租用的计费逻辑
从开机开始计费，到关机结束。包括调试代码、等待数据加载、GPU空闲的时间。
省钱技巧
1. 先用便宜GPU调通代码
bash
# 开发调试阶段用T4或V100（便宜很多）
# 确认训练脚本能跑通、loss在下降、checkpoint正常保存
# 再换A100/H100跑全量2. 用checkpoint支持断点续训，配合竞价实例
python
import torch
# 每N个step保存checkpoint
if step % save_interval == 0:
torch.save({
'step': step,
'epoch': epoch,
'model_state_dict': model.state_dict(),
'optimizer_state_dict': optimizer.state_dict(),
'loss': loss,
}, f'checkpoint_step_{step}.pt')
# 启动时加载最近的checkpoint
if resume_from_checkpoint:
checkpoint = torch.load('checkpoint_step_xxx.pt')
model.load_state_dict(checkpoint['model_state_dict'])
optimizer.load_state_dict(checkpoint['optimizer_state_dict'])
start_step = checkpoint['step']竞价/Spot实例价格便宜50%-70%，但可能被中断。配合checkpoint断点续训，性价比很高。
3. 预留30%-50%的缓冲时间
实际用时通常比预估长。调参、debug、数据问题、重跑......都会消耗GPU时间。
4. 监控GPU利用率，及时释放
bash
# 实时监控GPU利用率
watch -n 1 nvidia-smi如果GPU利用率长时间为0%，说明在做CPU操作（数据加载、预处理等），这时候GPU在空转但还在计费。优化数据pipeline或者先释放实例。
坑6：多卡 ≠ 快N倍
真实案例
客户用8张卡训练，预期比1张卡快8倍，实际只快了4.5倍。
这不是被坑了，而是多卡并行天然有效率损耗：
| 损耗来源 | 说明 |
|---|---|
| 通信开销 | GPU之间同步梯度/中间结果需要时间 |
| 负载不均 | 不同GPU计算量可能不完全一致 |
| 内存冗余 | 每张卡都要存储优化器状态副本 |
多卡加速比的典型范围
| 互联方式 | 2卡 | 4卡 | 8卡 |
|---|---|---|---|
| PCIe Gen4 | 1.6x | 2.5x | 3.5x |
| NVLink 4.0 | 1.8x | 3.2x | 5.5x |
| NVSwitch + 优化 | 1.9x | 3.5x | 6.5x |
8卡环境下通常能达到5-6.5倍加速，达不到理论的8倍。
教训
- 多卡加速有上限，不要期望线性
- 单卡能力比堆卡数更划算------一张H100可能等于两张A100的推理能力，但只需要一份机柜/散热/运维成本
- 选PCIe版本多卡并行，加速比会更差
GPU选型决策树
把上面的坑总结成一个决策流程：
markdown
第一步：确定任务类型
│
├── 训练/微调
│ ├── 预算充足 → H100 SXM
│ ├── 预算有限 → A100 80GB
│ └── 国内环境 → H800 SXM 或 A800 80GB
│
└── 推理
├── 先算显存需求（见公式）
│
├── 单卡能装下？
│ ├── 高吞吐低延迟 → H100/H200（带宽高）
│ ├── 性价比优先 → A100 80GB 或 H20
│ └── 轻量级 → L40S 或 L20
│
└── 单卡装不下 → 多卡
├── 优先选大显存卡减少卡数
└── 多卡必须NVLink互联各型号一句话总结
| 型号 | 一句话定位 |
|---|---|
| A100 40GB | 入门AI卡，7B推理够用 |
| A100 80GB | 上一代性价比之选，大部分任务够用 |
| H100 SXM | 当代旗舰，训练推理都是最优解 |
| H100 PCIe | 单卡推理性价比选择，多卡不推荐 |
| H200 | 超大显存，超大模型推理 |
| H20 | 国内推理性价比之选，大显存高带宽，训练别用 |
| L40S | 推理/轻量训练，带宽偏低但便宜 |
| L20 | 国内推理入门 |
给采购的检查清单
下单前逐项确认：
□ GPU具体型号？（A100 40GB还是80GB？）
□ SXM还是PCIe？
□ 有NVLink/NVSwitch吗？互联带宽多少？
□ 实测显存带宽？（nvidia-smi或bandwidthTest）
□ 独占物理机还是虚拟化切分的GPU？
□ 机房供电和散热能支撑满载吗？最后一条容易被忽略。8卡H100满载功耗约6kW，如果机房供电不够，GPU可能降频。
bash
# 检查GPU是否被降频
nvidia-smi -q -d PERFORMANCE
python
Clocks Throttle Reasons
Active : None ← None正常，非None说明被降频如果显示 SW_THERMAL 或 HW_POWER_BRAKE，说明GPU因温度或功耗限制被降频了。
总结
| 坑 | 教训 |
|---|---|
| 只看算力不看显存 | 先算显存需求，显存不够什么都白搭 |
| 忽视显存带宽 | 推理场景下带宽比算力更重要 |
| SXM和PCIe搞混 | 多卡必须SXM + NVLink |
| 忽略中间型号 | H20推理性价比高，不要忽略 |
| 租GPU超预算 | 先用便宜GPU调通，预留缓冲时间 |
| 以为多卡线性加速 | 8卡通常5-6倍，选单卡强的比堆卡数更划算 |
选GPU的核心逻辑：先搞清楚任务类型（训练/推理）→ 算显存需求 → 选GPU型号 → 确认互联方式 → 核实预算。
不要上来就问"8卡H100多少钱"------可能2张A100就够了。
系列文章：
- 上一篇：GPU服务器和普通服务器到底差在哪？从硬件架构讲起
- 下一篇：租GPU还是买GPU？一张表帮你算清楚成本
如果觉得有帮助，欢迎点赞、收藏、评论。有问题可以在评论区交流。
版权声明： 本文为原创内容，基于实际工作中的GPU选型经验整理。转载请注明出处。