GPU 云服务器怎么选？训练与推理算力选型与避坑指南

GPU 云服务器怎么选？答案取决于你跑的是训练还是推理，更取决于你最可能先撞上哪一堵墙。最常见的误判是照着算力排行榜买卡，结果模型加载到一半才发现显存差一截。在绝大多数深度学习任务里，显存比浮点算力更早成为瓶颈——本文把训练和推理两条选型逻辑分开讲，再补上精度换算、CPU/网络配套、CUDA 兼容、竞价实例和多卡扩展，最后给你一套自己能动手的估算方法。

先分清：训练和推理要的从来不是同一种卡

训练和推理跑的是同一个模型，但瓶颈几乎相反。把这一点想清楚，能省掉一半的试错。

• 训练瓶颈在算力与显存带宽：满负荷矩阵乘，GPU 利用率常年在 90% 以上，并行度决定吞吐
• 训练要装下优化器状态：全参微调除权重外还要存梯度和动量，显存占用通常是纯推理的 5–8 倍
• 训练对卡间通信极敏感：多机训练有相当比例的时间花在 all-reduce 上，互联质量直接决定有效算力
• 训练可容忍中断：有 checkpoint 就能续，适合放在竞价实例上
• 推理瓶颈在显存容量与带宽：单请求解码本质是「把权重读一遍」的记忆带宽问题，不是算力问题
• 推理看并发与每卡吞吐：同样的总 QPS 下，一张大显存卡往往比多张小卡更省、更好运维

一句话概括：训练买算力，推理买显存和带宽。 用错方向最典型的情况是推理服务买了 8 张训练卡，其实瓶颈是并发时的 KV cache，显存不够；或者团队为了一次 7B 微调租了 8 卡 H100，其中 6 张在等通信。

显存是第一道墙：算力过剩之前你就撞满了

把 OOM 出现的顺序看清楚，就知道该买多少显存：

1. 推理第一步：模型权重加载不进显存。换卡，或者只能换更小的模型、更短的上下文
2. 推理第二步：权重放得下，KV cache 撑不住。表现为并发上不去，或长上下文请求被截断
3. 训练第一步：优化器状态放不下。被迫上 ZeRO / FSDP 分片，step 时间通常上升 30%–60%
4. 训练第二步：激活值吃满。被迫开 gradient checkpointing，用算力换显存，单步时间再涨 20%–40%

另一个常被忽略的量是有效显存带宽。单流解码速度的物理上限大致是：显存带宽 ÷ 权重体积。7B 模型 FP16 权重约 14GB，落在 2TB/s 级带宽的卡上，理论上限约 140 token/s，落到 80–120 token/s；落在 1TB/s 级的消费级卡上，理论上限约 70 token/s，实测常在 40–60 token/s。同样的模型，跨一个带宽档位，体验差一倍——但显存容量是及格线，带宽才决定速度。

GPU 类型对照：数据中心卡、消费级卡、推理卡

消费级卡便宜，但有四个硬限制，选型时要明确知道：

• 无 ECC 显存：长时间训练可能积累无法察觉的数据错误，表现为训练 loss 莫名发散
• 多数型号没有 NVLink：多卡只能走 PCIe，通信带宽可能差近 20 倍
• 不支持 MIG：无法把一张物理卡切成多个实例分给不同租户，多租户服务很难做
• 虚拟化与企业支持需额外授权：商用多租户场景要确认许可成本

精度怎么改写账：FP32 / FP16 / BF16 / INT8 / INT4

精度是你手上最有效的「显存折扣旋钮」，也是最容易踩坑的一环。先看它对显存的直接影响：

速度上，Ampere 及以后的卡在 Tensor Core 上 FP16 与 BF16 吞吐基本一致（所以选 BF16 不损失性能，只损失一点旧卡兼容性）；INT8 通常是 FP16 的 1.5–2 倍，INT4 在 Ampere 上可达 2–4 倍。但端到端不会线性加速：访存、kernel 支持和反量化开销会吃掉一部分，实测常见收益是 1.3–1.8 倍，不是理论值。

• 精度换显存是线性且可靠的，因为权重体积直接按字节数缩放
• 精度换速度不是线性的，取决于你的模型形状、batch 与 kernel 覆盖率
• 训练不要用 INT8/INT4：优化器状态、梯度尺度和小更新量在高动态范围下容易出问题

量化对效果的影响要分情况：INT8（对称/分组量化）在大多数任务上指标波动在 0.5% 以内，可以放心上生产；INT4（GPTQ、AWQ）要按任务测，代码生成、长链推理和数学题掉点明显，而闲聊、分类、检索类任务基本无感。量化前一定要在自己的评测集上跑一遍。

算一遍你自己的显存：拿模型估一次

下面三个公式能覆盖绝大多数场景，先套公式得出下界，再加 20%–30% 余量，这就是你的目标显存。

• 7B 推理 FP16：7×10⁹ × 2 字节 = 14GB 权重 → 含预留约 17GB → 24GB 卡可跑，16GB 卡必须 INT8 或砍上下文
• 7B 推理 INT4：约 3.5GB 权重 → 起步 4.5GB → 一张 16GB 卡能扛几十路并发
• 70B 推理 FP16：140GB 权重 → 单卡无解 → 2×80GB 做张量并行（TP=2），或 141GB 卡勉强装下但没空间给 KV cache
• 7B LoRA 微调 BF16：权重 14GB + 少量优化器状态 + 激活 → 24GB 卡开 gradient checkpointing 能跑，40GB 更宽裕
• 7B 全参微调 Adam：7×10⁹ × 16 字节 = 112GB → 至少 2×80GB；ZeRO-3 分摊到 4×40GB 也能跑，但通信开销会明显拉长单步时间

推理侧还必须单独算 KV cache，这是长上下文场景真正的隐形杀手：

• Llama-2-7B（32 层、hidden 4096、无 GQA）：每 token 约 512KB，4K 上下文单请求约 2GB，32 并发就要 64GB
• Llama-3-8B（32 层、GQA 8 个 KV head）：每 token 约 128KB，4K 上下文单请求约 0.5GB
• 结论：同样权重体积，GQA 让你在相同显存上把并发翻数倍。评估服务容量时一定要把这个乘进去

还有一个高频翻车点：batch size 不是线性缩放显存。线性层和激活值是线性增长，但 PyTorch 默认会尽量复用显存，Attention 内部的中间张量是平方级增长。序列长度从 2K 提到 8K 时，激活值显存增长可能超过 4 倍。如果你的任务是长序列训练，先按 8K 上下文算显存，而不是按默认 512。

别只看 GPU：CPU、主存、存储与网络怎么配

GPU 决定上限，配套决定你能用到几成。很多「GPU 很便宜」的机器，实际利用率上不去，就是因为这里没配对。各机型的显存、CPU/内存配比与可选卡型，见 GPU 云服务器。

• CPU：数据加载、解压、增强都是 CPU 密集工作。每张 GPU 配 4 vCPU 是底线，2 vCPU 的机器会让 GPU 饿着，实测利用率常掉到 50%–70%
• 主存：至少装得下正在读的数据分片。经验值是主存 ≥ 全部 GPU 显存之和，并配合 pinned memory 加速主机到显存的拷贝
• 存储：本地 NVMe 顺序读通常 1–2GB/s；直接从对象存储读要靠高并发堆吞吐，单流往往只有几百 MB/s。做法是先把数据同步到本地 NVMe 再开始训练
• 网络：单机内网至少 10Gbps 起步。多机训练看网卡是不是 100Gbps RDMA（InfiniBand / RoCE）——用 25Gbps 共享网卡做梯度同步，往往比单卡算力还慢

推理侧的重点不一样：多并发请求下，CPU 负责解 token 后的调度、预处理和批处理合并。建议让 vLLM / SGLang 这类框架跑在 CPU 核数充足的机型上，再叠一张或几张大显存推理卡——GPU 少而 CPU 足的组合，对小模型高并发场景往往比堆卡更划算。

NVLink 与 PCIe：多卡训练时差距有多大

NVLink 3 的带宽约是 PCIe 4.0 的 18–19 倍，这个差距在张量并行里会被放大：每一层前向和反向都要做 all-reduce，通信量随层数线性增长。通信走 PCIe 时，通信时间可能吃掉 30%–60% 的单步时间，你的卡贵了一倍，有效算力反而没提升。

• 单卡任务：互联无所谓，直接选显存和算力都够用的型号
• 2–8 卡训练：优先同节点 NVLink / NVSwitch 机型，这是训练卡价格溢价的主要来源
• 跨节点：张量并行留在节点内，跨节点用数据并行，或用流水线并行把计算切开
• 消费级多卡：先跑 nvidia-smi topo -m 看拓扑。显示 PIX（走 PCIe）还是 NV#（走 NVLink），吞吐可能差几十个百分点

CUDA 与驱动兼容：最容易翻车的一环

规格选对了但跑不起来，多半是软件栈的问题。签约前把这几件事问清楚，比事后 debug 划算得多。

• 驱动向后兼容，但框架往往要求较新驱动：CUDA 12.x 运行时一般需要 r525 或更高版本的驱动
• PyTorch 官方 wheel 自带 CUDA 运行时，容器里的系统 CUDA 版本要和 wheel 匹配，不是升驱动就行
• cuDNN 与 NCCL 要对齐：打印不出 torch.cuda.nccl.version() 通常就是 NCCL 没装对，多机训练会挂在初始化阶段
• 架构支持是硬门槛：Turing 无 BF16，Hopper 起才有 FP8，Blackwell 起才有 FP4。新卡配老框架可能要源码编译扩展
• 典型报错 CUDA driver version is insufficient for CUDA runtime version，几乎都是驱动或镜像混装问题，不是代码 bug

自己验证只要一条命令：nvidia-smi 看驱动和识别到的卡，python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available(), torch.cuda.get_device_capability())" 看框架侧是否就绪，再跑一次 NCCL 的 all-reduce 微基准（nccl-tests）确认通信正常。十台机器里有一台通信慢，你都会是那个倒霉的用户，所以要逐台验，不要抽样。

竞价 GPU：把训练成本打到按需的几分之一

竞价实例（Spot / 抢占式）常见的折扣区间是按需价格的 1/3 到 1/10，具体以官方实时报价为准。对训练这种「可重入」的负载，这是最直接的省钱手段。除了竞价，计费模式本身就决定了长期账单，五类配置的价位区间见 云服务器价格指南。

• 适合：超参搜索、批量数据标注、离线评测、checkpoint 间隔不超过 15 分钟的训练
• 不适合：在线推理服务、不可中断的长训练、状态存在本地且没有外部备份的任务
• 多卡必须放在同一台实例上：回收时整组一起释放。否则被回收后剩下 1/4 的卡继续计费，「长尾残留」是竞价实例最常见的隐形浪费
• 训练脚本要做到可重入：定期保存 checkpoint，框架侧通常有自动捕获和恢复的选项（如 PyTorch 的 elastic 模式）

数据也要跟着这个思路设计：数据集放对象存储（不要放在会被一起回收的实例本地盘），checkpoint 同步写回对象存储。这样任意时刻实例消失，你最多损失 15 分钟的计算进度，而不是一整晚。

多卡扩展怎么选：数据并行到流水线并行

选择顺序其实很固定，按「显存不够的原因」从上往下走：

1. 权重和优化器装不下 → ZeRO-3 / FSDP，显存随卡数近似线性下降，通信开销可接受
2. 单层权重装不下（通常 70B 以上）→ 张量并行，把每层权重切到多张卡，必须同节点 NVLink
3. 卡数超过单机容量 → 流水线并行，按层切分，配合 Slurm 或 Kubernetes 调度层
4. 参数规模还想继续涨 → MoE 把参数稀疏化，显存压力下降，但负载均衡和 All-to-All 通信是新的坑

推理侧的多卡思路不一样，通常优先张量并行把一个大模型塞进节点，再用多副本横向扩，而不是数据并行——推理没有梯度同步，数据并行的收益远不如训练场景。vLLM / SGLang 里对应的是 --tensor-parallel-size 与 --data-parallel-size 的组合。

选型避坑：最常踩的 8 个坑

1. 只看 TFLOPS 不看显存——最常见的误判，直接导致 OOM 或被迫上分片
2. 默认消费级卡能扛生产——无 ECC、无 MIG、许可受限；长训练有静默错误风险，商用要确认
3. 忘了算 KV cache——短上下文测试通过，上线后长上下文直接打满，扩容又来不及
4. 多卡只写卡数不看拓扑——nvidia-smi topo -m 里是 PIX 还是 NV#，差别是几十个百分点的吞吐
5. 混装不同代际的卡——最慢的一张决定所有集合通信速度
6. 用竞价实例跑在线推理——回收时服务直接挂，且没有优雅下线的窗口
7. 一上来就签长约——先按小时计费跑通真实负载，拿到 step 时间或 tokens/s 的实测值再转长约
8. 忘记 checkpoint 与数据备份——GPU 故障、误删实例、数据丢失的恢复成本远高于一个月的实例费用

这八条里，前四条与技术判断有关，后四条更多是运维习惯。真正让预算超支的通常是第 6 和第 7 条：该用便宜卡的用错了、该签长约的没先测。

下一步：24 小时内验证你的选型

选型不该靠猜。用下面五步，一个工作日就能拿到一个有实测数据支撑的决定。

1. 量显存峰值：在现有环境跑 50 步训练或 100 个推理请求，记下 nvidia-smi 里的最高占用和框架的 max_memory_allocated
2. 算出下界：用第 4 节的公式算权重 + 优化器 + KV cache，再加 20%–30% 余量，得到目标显存
3. 筛出 2–3 个候选型号：对照 GPU 类型表，核对 CUDA 驱动、镜像里的 PyTorch 版本和是否支持 NCCL
4. 按小时开一台最小规格：跑 30 分钟真实负载，记录单步时间（tokens/s）和总时间，换算成「每小时训练成本」或「每百万 token 成本」
5. 把结论写成对比表再签长约：训练主体用竞价 + 末段切按需，推理用按需 + 长约混合，两种模式的账要分开算

需要按你自己的模型和并发量算一遍，把参数量、精度、上下文长度、并发数、是否全参微调发过来，我们可以给出候选规格区间和显存估算；GPU 的具体报价以官方实时报价为准，不同区域和机型差异较大。