A100、H100、H200 怎么选？个人开发者的 GPU 云服务器选型与成本估算

原创于 2026-08-22 01:47:04 发布 · 224 阅读

本内容遵循CC 4.0 BY-SA版权协议

很多开发者比较 GPU 时，第一反应是看“每小时多少钱”。但对于训练、推理和渲染任务，真正应该比较的是：能否稳定跑起来、任务多久完成，以及完成一次任务的总成本。

本文不提供未经实测的性能排名，而是给出一套可以复用的 GPU 选型和测试方法。型号、库存、区域和价格会变化，具体配置请以创建页面当前显示的信息为准。

一、先明确任务，再选择 GPU

GPU 没有脱离任务的“绝对最优解”。同一张卡用于模型微调、在线推理和图形渲染，关注点完全不同。

1. 模型微调

微调通常优先关注：

显存是否足够；
混合精度是否可用；
batch size 和序列长度；
数据读取速度；
训练时长和失败重试成本。

如果显存不够，可能需要降低 batch size、使用梯度累积、启用量化，或者把部分数据放到 CPU。这些方法可以解决“跑不起来”的问题，但也可能降低吞吐。

2. 推理部署

推理任务不能只看显存。还应该记录：

首 token 延迟；
平均延迟和 P95 延迟；
tokens/s；
并发请求数；
上下文长度；
KV cache 的显存占用；
单次请求成本。

低并发、短上下文的任务，不一定需要最高规格的 GPU；长上下文、高并发或多个模型同时运行时，显存和实际吞吐会更重要。

3. 图像生成和渲染

图像生成、视频生成和 3D 渲染通常要关注：

显存容量；
单张图片或单帧耗时；
软件和插件兼容性；
本地磁盘和数据传输；
批量任务的并发能力。

二、GPU 选型时不要只看型号

选择 GPU 时，建议至少检查下面六个维度。

1. 显存

显存不足时，任务可能直接报错，也可能因为 CPU offload 或显存交换而变慢。

模型显存并不只等于模型权重大小，还包括：

模型权重；
激活值；
KV cache；
优化器状态；
临时张量；
框架和 CUDA 的运行开销。

因此，“模型参数量乘以精度字节数”只能作为初步估算，不能代替真实测试。

2. 计算吞吐

理论 FLOPS 不是最终任务速度。实际吞吐还会受到模型结构、算子实现、精度、batch size 和软件版本影响。

比较 GPU 时，应该记录任务级指标，例如 samples/s、tokens/s、每张图片耗时或完整任务完成时间。

3. GPU 之间的互联

多卡训练时，卡间通信可能成为瓶颈。除了 GPU 型号，还要确认具体配置、互联方式、网络带宽和分布式框架支持情况。

单卡任务不需要为多卡互联支付额外成本；多卡任务则不能只按单卡价格相加来估算性能。

4. CPU、内存和磁盘

GPU 很快，但数据加载、解压、预处理或 checkpoint 保存可能被 CPU、内存和磁盘拖慢。

尤其是训练任务，建议同时确认：

CPU 核数；
系统内存；
磁盘读写速度；
数据集所在位置；
模型和 checkpoint 是否需要长期保存。

5. 区域和网络

如果数据集、代码仓库和用户请求都在不同区域，上传、下载和在线推理延迟可能会明显影响实际成本。

不要只写“低延迟”，应该用实际测试结果说明：

从主要用户所在地访问的延迟；
数据上传速度；
数据下载速度；
推理请求的 P50/P95 延迟；
网络中断后的恢复方式。

6. 价格和计费规则

需要确认价格对应的完整配置，而不是只看 GPU 名称：

是单卡还是多卡；
是否包含 CPU、内存和系统盘；
是否另计数据盘；
什么时候开始计费；
关机、停止和释放分别有什么区别；
失败重试期间是否产生费用。

三、A100、H100、H200 应该怎么比较

下面是一个决策方向，不是脱离任务的性能排名：

类型	更适合关注	选择前需要验证
A100	生态成熟、框架兼容、开发验证和成本平衡	显存规格、任务吞吐、当前库存
H100	高吞吐训练、推理和较高并发	实际 tokens/s、批量大小、总任务成本
H200	更大显存、长上下文和更高显存需求	更大显存是否真的转化为任务收益
消费级或专业图形卡	个人实验、图像生成、渲染和预算敏感任务	软件兼容性、显存、稳定性和数据盘

最合理的做法不是直接选择最贵的型号，而是先选两种候选配置，用同一任务做小规模对比。

四、如何设计一次公平的 GPU 实测

为了让结果有参考价值，至少固定以下变量：

相同模型和模型版本；
相同数据集；
相同 CUDA、PyTorch 和框架版本；
相同精度；
相同 batch size；
相同序列长度或图片分辨率；
相同并发设置；
相同区域和计费类型；
预热次数和正式测试次数。

建议记录下面这些结果：

指标	含义
启动时间	从创建资源到可以运行任务所需的时间
峰值显存	判断配置是否有余量
吞吐量	例如 tokens/s、samples/s
延迟	关注平均值和 P95
完成时间	完成同一个任务用了多久
失败次数	反映稳定性和重试成本
总成本	完成一次任务实际花费多少

不要只跑一次就下结论。至少进行预热，再运行多次正式测试，并记录异常情况。

五、用完整任务成本，而不是小时价格做决定

可以先用下面的公式估算：

总成本 = GPU 价格 × GPU 数量 × 运行时长 + 存储费用 + 数据传输费用 + 失败重试成本

下面是一个简单的估算函数：

def estimate_cost(
    gpu_price_per_hour,
    gpu_count,
    runtime_hours,
    storage_cost=0.0,
    transfer_cost=0.0,
    retry_cost=0.0,
):
    gpu_cost = gpu_price_per_hour * gpu_count * runtime_hours
    return gpu_cost + storage_cost + transfer_cost + retry_cost


cost = estimate_cost(
    gpu_price_per_hour=0.0,  # 替换为当前配置的实际价格
    gpu_count=1,
    runtime_hours=0.0,       # 替换为实际运行时长
)

print("Estimated total cost:", round(cost, 2))