很多开发者比较 GPU 时第一反应是看“每小时多少钱”。但对于训练、推理和渲染任务真正应该比较的是能否稳定跑起来、任务多久完成以及完成一次任务的总成本。本文不提供未经实测的性能排名而是给出一套可以复用的 GPU 选型和测试方法。型号、库存、区域和价格会变化具体配置请以创建页面当前显示的信息为准。一、先明确任务再选择 GPUGPU 没有脱离任务的“绝对最优解”。同一张卡用于模型微调、在线推理和图形渲染关注点完全不同。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 数量 × 运行时长 存储费用 数据传输费用 失败重试成本下面是一个简单的估算函数defestimate_cost(gpu_price_per_hour,gpu_count,runtime_hours,storage_cost0.0,transfer_cost0.0,retry_cost0.0,):gpu_costgpu_price_per_hour*gpu_count*runtime_hoursreturngpu_coststorage_costtransfer_costretry_cost costestimate_cost(gpu_price_per_hour0.0,# 替换为当前配置的实际价格gpu_count1,runtime_hours0.0,# 替换为实际运行时长)print(Estimated total cost:,round(cost,2))这里故意没有填入固定价格因为 GPU 价格、区域和库存会变化。正式比较时应把控制台当前显示的价格、实际运行时长和其他费用记录下来。一个价格更高但能把任务时间缩短一半的 GPU可能拥有更低的“单次任务成本”一个小时价格较低但频繁 OOM 或需要重试的配置最终成本可能更高。六、个人开发者的实际选择顺序如果你是个人开发者或小团队我建议按下面顺序决策先确认模型和任务能否在候选 GPU 上运行再确认显存是否有足够余量用小规模任务测吞吐和完成时间计算一次完整任务的总成本最后再考虑长期运行、自动扩容或多卡配置。如果只是开发验证不要一开始就租用长时间的大规格实例。先使用短时、低风险的配置完成验证再决定是否升级。七、在云平台上创建 GPU 实例前的检查清单创建前建议逐项确认GPU 型号和数量显存和互联方式区域和网络CPU、内存和磁盘系统镜像CUDA、PyTorch 和框架版本当前库存当前价格计费开始和停止条件数据是否会随实例释放而删除是否有 SSH、工单或人工支持。以起源算力origpu为例可以先查看 GPU 产品目录、选型指南和当前库存再创建一台短时测试实例。不要把宣传页上的理论参数直接当成自己的任务结果。八、总结A100、H100、H200 并不存在对所有人都最好的答案。开发验证更看重兼容性、稳定性和成本高吞吐训练更看重完成时间和卡间通信长上下文推理更看重显存和并发个人图像生成更看重显存、软件兼容和单位任务成本。真正可靠的选型方法是明确任务固定变量做小规模实测再用完整任务成本做决定。参考资料GPU 型号选型指南A100 与 H100 对比H100 与 H200 对比实时价格与库存以上页面中的价格、库存、区域和配置可能变化最终以创建实例时的当前信息为准。