云 GPU 选型指南：显存、算力与价格怎么看
从显存容量、计算精度、GPU 利用率、CPU 与内存搭配和总成本出发，为目标检测、LoRA 微调、文生图等任务选择合适的云 GPU。
选择云 GPU 时，型号名称只能提供一部分信息。真正决定任务能否顺利运行的是显存容量，决定完成速度的是算力与数据吞吐，决定最终支出的是整个任务的完成时间和附加存储费用。
本文提供一套与平台无关的选型方法。云 GPU 的基本概念可参阅《什么是云实例与云 GPU》，创建实例与 SSH 操作可参阅《云实例使用指南》。
先看显存，再看速度
训练时，显存通常包含以下部分：
- 模型参数；
- 梯度；
- 优化器状态；
- 前向传播保存的中间激活；
- 输入数据、标签和临时计算空间；
- CUDA 上下文与框架缓存。
模型参数量可以帮助估算参数本身的体积：
参数显存约等于参数量 × 每个参数的字节数
FP32：每个参数约 4 字节
FP16/BF16：每个参数约 2 字节
INT8：每个参数约 1 字节
INT4：每个参数约 0.5 字节
例如，70 亿参数模型以 FP16 加载，仅参数权重就约占 70 亿 × 2 字节 ≈ 14 GB。推理还需要缓存和框架开销，训练还会加入梯度、优化器状态与激活，因此实际需求会继续上升。
视觉模型的激活显存与 batch size、输入分辨率和网络结构密切相关。输入图片边长翻倍后，像素数量约变为四倍，中间特征图也会显著增长。
给显存留出余量
建议在试跑峰值基础上预留约 10% 至 20% 的余量，用于框架缓存、验证阶段和偶发的大样本。选型时可以遵循：
目标显存 = 实测峰值显存 × 1.1 至 1.2
已有本地 GPU 时，可以先用少量数据运行几个 step，通过 nvidia-smi 或框架分析工具查看峰值。项目还未运行时，可从模型官方说明、同类实验和下文的任务分档开始估算，再用短时云实例验证。
常见显存优化手段
当任务接近显存上限时，可以按下列顺序调整：
- 减小 batch size、输入分辨率或序列长度；
- 使用 FP16 或 BF16 混合精度；
- 使用梯度累积维持有效 batch size；
- 开启梯度检查点，以更多计算换取更低激活显存；
- 使用 8-bit 优化器、LoRA 或 QLoRA；
- 将部分参数或优化器状态卸载到 CPU；
- 采用多卡并行或更大显存的 GPU。
这些方法会改变训练速度、数值稳定性或实现复杂度。每次调整一个因素，并记录吞吐、显存峰值和最终指标，最容易判断收益。
算力应该怎么看
显存决定任务容量，算力决定每一步计算速度。比较 GPU 时应关注任务实际使用的精度：
- FP32：传统科学计算和部分对精度敏感的任务；
- TF32：现代 NVIDIA GPU 上常见的矩阵计算路径；
- FP16/BF16：深度学习训练与推理的常用精度；
- INT8/INT4：量化推理和 QLoRA 等场景。
厂商标注的理论峰值代表特定条件下的上限。实际速度还会受到显存带宽、Tensor Core、功耗限制、散热、框架版本和数据供给影响。最可靠的比较方式，是在候选实例上运行同一段短任务并记录：
每秒样本数 / 每秒 token 数
单 step 时间
峰值显存
GPU 利用率
每小时价格
最终可计算单位工作成本：
训练成本 = 每小时价格 × 完成训练所需小时数
每百万样本成本 = 训练成本 ÷ 处理样本数 × 1,000,000
单价较高但速度提升更大的 GPU，可能拥有更低的任务总成本。
如何理解 GPU 利用率
nvidia-smi 中的 GPU-Util 表示采样窗口内 GPU 忙于执行计算的时间比例。训练任务中的利用率经常随数据加载、前向传播、反向传播和参数更新上下波动。
可以持续观察：
watch -n 1 nvidia-smi
常见现象与优化方向如下：
| 现象 | 可能原因 | 优化方向 |
|---|---|---|
| GPU 利用率长期较低，CPU 接近满载 | 数据解码或增强成为瓶颈 | 增加 CPU、数据加载进程或缓存 |
| GPU 利用率周期性掉到零 | 数据读取间歇或同步等待 | 提高磁盘吞吐、预取数据、合并小文件 |
| 显存占满，GPU 利用率仍较低 | batch 太小或模型并行通信较多 | 调整 batch、计算图和通信策略 |
| GPU 利用率高且训练稳定 | 计算资源得到充分使用 | 继续对比单位任务成本 |
| 多卡中部分 GPU 利用率低 | 数据分配或通信不均衡 | 检查分布式采样、负载与互联方式 |
利用率是诊断线索，吞吐和总训练时间更适合作为最终评价指标。部分小模型会在很短时间内完成计算，采样值可能低于真实峰值。
CPU、内存和磁盘怎样搭配
CPU
CPU 负责读取文件、解码图片、数据增强、分词、编译扩展和准备 batch。目标检测与图像增强通常需要较多 CPU 资源，大语言模型微调在预先分词后对 CPU 的压力相对平稳。
可以从每张 GPU 配置 4 至 8 个 CPU 核开始试跑。大量图片解码、视频处理或复杂增强任务可提高到 8 至 16 核，再根据 GPU 等待情况调整。
内存
内存需要容纳操作系统、Python 进程、数据加载队列和缓存。入门训练实例可以从 16 GB 或 32 GB 开始；大型数据集缓存、多进程加载、CPU offload 和多卡训练通常需要 64 GB 或更多。
内存需求可以通过运行监控确认：
free -h
系统频繁使用交换空间时，数据吞吐会明显下降，此时可以减少加载进程、降低缓存或增加内存。
磁盘
磁盘容量应覆盖：
数据集 + 解压后的副本 + Python 环境 + 预训练权重
+ 多个训练检查点 + 日志 + 临时缓存 + 预留空间
大量小图片和视频训练还依赖随机读取性能。将数据打包为适合流式读取的格式、使用本地高速盘或平台高速存储，通常能提高 GPU 利用率。
按任务选择显存档位
下表用于首次筛选，实际需求以模型实现、输入大小、batch size 和精度为准。
| 显存档位 | 典型用途 | 选型提示 |
|---|---|---|
| 8 GB 至 12 GB | 小型分类模型、轻量目标检测、基础推理、低分辨率文生图 | 适合入门和代码验证，训练时采用较小 batch |
| 16 GB 至 24 GB | 主流视觉训练、中型目标检测、Stable Diffusion 微调、7B 模型量化推理与参数高效微调 | 个人项目和竞赛中较灵活的档位 |
| 32 GB 至 48 GB | 高分辨率视觉、大 batch、较大模型 LoRA、多模型流水线 | 为激活、缓存和复杂工作流提供更多余量 |
| 80 GB 及以上 | 大模型训练或微调、长上下文、多卡研究任务 | 重点比较多卡互联、通信和单位 token 成本 |
目标检测如何选
目标检测的显存主要受到模型规模、输入分辨率、batch size 和数据增强影响。小型 YOLO 类模型使用 640 像素输入时，8 GB 至 12 GB 显存通常适合学习、推理和小 batch 训练。中大型检测模型、更高分辨率或更大 batch 常采用 16 GB 至 24 GB。
遥感、医学影像和工业检测经常使用高分辨率图片。此时可以选择更大显存，也可以通过切片训练、随机裁剪、混合精度和梯度累积控制需求。
推荐的选型流程：
- 用目标分辨率和 batch size 1 运行短测试；
- 逐步增加 batch，记录吞吐和显存峰值；
- 观察 CPU 数据增强是否让 GPU 等待；
- 在候选 GPU 上比较每个 epoch 的时间与价格。
LoRA 与 QLoRA 如何选
大语言模型微调的显存需求取决于参数量、权重精度、序列长度、LoRA rank、batch size、优化器和梯度检查点。
粗略估算权重体积时，7B 模型的 FP16 权重约 14 GB，4-bit 权重约 3.5 GB；运行时还会加入量化元数据、LoRA 参数、激活和框架缓存。因此，权重体积只是估算起点。
常见入门组合如下：
| 任务 | 建议起步显存 | 说明 |
|---|---|---|
| 7B 模型 4-bit 推理 | 8 GB 至 12 GB | 上下文长度和推理框架会影响 KV Cache |
| 7B 模型 QLoRA | 16 GB 至 24 GB | 小 batch、梯度检查点和较短序列更容易落入此范围 |
| 7B 模型 FP16 LoRA | 24 GB 至 32 GB | 权重本身约占 14 GB，还需激活与训练状态 |
| 13B/14B 模型 QLoRA | 24 GB 至 48 GB | 序列长度和 batch 对结果影响明显 |
| 更大模型或长上下文 | 48 GB、80 GB 或多卡 | 需要结合切分、卸载和互联方式评估 |
KV Cache 会随 batch、层数和上下文长度增长。面向长文本推理时，即使模型权重可以装入显存，也要为 KV Cache 预留空间。
文生图如何选
文生图任务包括推理、LoRA 训练、DreamBooth 和从零训练，显存跨度很大。
- 基础推理：8 GB 至 12 GB 可覆盖许多常见工作流；
- SD 1.x LoRA：12 GB 至 16 GB 是常见起点；
- SDXL 推理与 LoRA：16 GB 至 24 GB 更从容；
- 高分辨率、多 ControlNet、多模型同时加载：24 GB 至 48 GB 可提供更大工作空间；
- 视频生成与大型扩散模型：通常从 24 GB、48 GB 或更高档位开始评估。
分辨率、批量生成数量、注意力实现、VAE 是否切片、是否启用 CPU offload 都会改变显存需求。先使用最终工作流生成少量样本，记录单张耗时和峰值显存，再决定长期租用配置。
价格应该怎样比较
创建一个候选表格，记录平台控制台的实时价格：
| 候选实例 | GPU 与显存 | CPU/内存 | 小测试速度 | 每小时价格 | 预计完成时间 | 预计总费用 |
|---|---|---|---|---|---|---|
| A | 待填写 | 待填写 | 待测试 | 待填写 | 待估算 | 单价 × 时间 |
| B | 待填写 | 待填写 | 待测试 | 待填写 | 待估算 | 单价 × 时间 |
总费用还应加入：
- 环境安装与数据准备期间的开机费用；
- 数据盘、文件存储和镜像费用；
- 失败重跑和调参实验的预算；
- 多卡任务的 GPU 数量与通信开销。
例如 GPU A 每小时 2 元、任务需要 10 小时，总计算费用为 20 元；GPU B 每小时 3.5 元、任务需要 5 小时，总计算费用为 17.5 元。GPU B 的小时单价更高，任务总成本更低。
一套实用选型流程
- 根据模型、精度、输入尺寸和 batch 估算显存；
- 选择显存高于估算峰值 10% 至 20% 的候选 GPU；
- 检查候选 GPU 支持的计算精度和框架版本；
- 为每张 GPU 搭配足够的 CPU、内存和高速磁盘；
- 在两个候选实例上运行相同的短测试；
- 记录吞吐、峰值显存、GPU 利用率和每小时价格；
- 计算完成整个任务的时间与总费用；
- 选择满足容量要求且单位任务成本更低的实例。
选型完成后，还需要确认驱动、CUDA 与 PyTorch 的版本关系。下一篇《深度学习环境版本关系》会介绍这条软件依赖链。