云上 GPU 算力：成本模型与弹性架构
说明：本篇为综述/无第一手实验数据，采用公开定价口径与常见架构实践。
实验目标
自建集群（前面 14 章内容）是"重资产慢扩容"路线；云上 GPU 是"轻资产快弹性"路线。本篇目标不是争论孰优孰劣，而是给出在什么场景用云、怎么用最省的方法：三类计费模式（按需/竞价/包月）的成本模型与时间价值、训练与推理的弹性策略差异、以及"数据在自建、算力在云"的回源架构。读完能对一个具体作业回答：这个任务适合上云吗？按哪种模式买？弹性怎么设？
代码逐段拆解
第一段：成本核算脚本
python
def gpu_cost_scenarios(hourly, spot_discount=0.7, monthly_ratio=0.55, util=0.75):
"""三种计费模式 × 利用率，算单位算力成本（元/卡时）"""
per_spot = hourly * (1 - spot_discount) # 竞价约 3 折
per_month = hourly * 24 * 30 * monthly_ratio / (24*30) # 包月折算
def eff(h, u): return h / u # 实际工作时间摊薄
return {
'按需-低利用率(20%)': eff(hourly, 0.2),
'按需-高利用率(75%)': eff(hourly, util),
'竞价-弹性任务': eff(per_spot, 0.9),
'包月-持续训练': eff(per_month, 0.9),
}
# 例：某 GPU 按需约 20 元/卡时
for k, v in gpu_cost_scenarios(20).items():
print(f"{k}: {v:.1f} 元/有效卡时")要点：
- 算"有效卡时"而不是"挂牌价"：利用率低的按需任务，有效成本是挂牌价的 3-5 倍——因为机器在等你，钱没停。核算必须用
挂牌价 ÷ 利用率。 - 竞价（Spot）适合可中断任务：云厂商的竞价实例 3 折上下、但随时可能被回收。适合 checkpoint 频繁、可重启的弹性批处理；不适合长训练（中断丢进度）。
- 包月适合持续运行的推理/训练：月度折扣折算到卡时约 5-6 折，但要算上"没跑满的时段也付钱"——利用率低于 50% 时包月反而不划算。
第二段：弹性伸缩配置（以 K8s + Cluster Autoscaler 为例）
yaml
# cluster-autoscaler 片段：GPU 节点池弹性策略
nodeGroups:
- name: gpu-on-demand
instanceType: gpu-24g
minSize: 0
maxSize: 32
labels: { role: inference }
taints: [{ key: gpu, value: "true", effect: NoSchedule }]
# 空闲节点 10 分钟缩容
scaleDownUnneededTime: 10m
- name: gpu-spot
instanceType: gpu-24g-spot
minSize: 0
maxSize: 64
labels: { role: training }
# Spot 竞价上限，防价格波动
spotMaxPrice: 6.0要点：
- 按需池与 Spot 池分离：推理（要稳定）走按需，训练（可中断）走 Spot；弹性上限分别设，避免 Spot 回收时推理任务被波及。
scaleDownUnneededTime: 10m：空闲 GPU 10 分钟回收——GPU 是按分钟计费的，闲置即亏损。spotMaxPrice是成本护栏：竞价波动时超过心理价位就不加机器，宁可排队。
原理讲解
云 vs 自建的决策框架
| 维度 | 自建（前面各章） | 云上 |
|---|---|---|
| 扩容速度 | 周-月（下单/到货/装机） | 分钟级 |
| 单位成本（高利用率） | 低（摊薄后） | 中-高 |
| 单位成本（低利用率） | 高（闲置损耗） | 中（可弹性） |
| 突发能力 | 受采购周期限制 | 弹性上限内任意 |
| 数据主权 | 本地 | 需考虑数据出域 |
决策规则：稳定高利用率的持续训练/推理 → 自建或包月；突发峰值、波动负载、短期项目 → 云上弹性；两者混用 → "自建兜底 + 云上弹性溢出"是最常见的生产形态。
训练 vs 推理的弹性差异
- 训练：任务长、可 checkpoint、中断成本可控 → 适合 Spot/竞价 + 频繁 checkpoint（呼应 04 章 Checkpoint 设计）。弹性粒度是"作业级"——排队等算力。
- 推理：在线、延迟敏感、不可中断 → 按需为主 + 预测式扩容（按请求 QPS 提前拉起节点，冷启动要 5-15 分钟，必须提前）。弹性粒度是"实例级"——秒级扩缩副本。
数据回源架构
"数据在自建、算力在云"时，最忌把训练数据整个搬上云。标准做法：
自建存储 ──(异步同步热数据)──> 云对象存储 (只存热集/增量)
云上训练节点 ──> 挂载对象存储 (只读拉取) / 用缓存节点缓存重复读取要点：只同步作业需要的热数据，而不是全量镜像；训练过程的对象存储访问要走缓存（JuiceFS/云盘缓存层），否则对象存储的 GET 延迟和费用会拖垮训练。
实验结果
（估算口径，价格随市场波动，仅作方法演示）
| 场景 | 有效卡时成本 | 结论 |
|---|---|---|
| 按需 20% 利用率 | ~100 元/卡时 | 最贵，仅应急 |
| 按需 75% 利用率 | ~27 元/卡时 | 中规中矩 |
| 竞价（3 折） | ~7 元/卡时 | 可中断任务首选 |
| 包月（55 折、90% 跑满） | ~12 元/卡时 | 持续训练最优 |
工程启示
- 先算利用率再选模式：同样 20 元/卡时的卡，利用率决定它实际是"100 元"还是"27 元"——核算口径统一用有效卡时。
- 训练上云必须配套 Checkpoint：没有 04 章的两级 Checkpoint，Spot 回收一次就把省的钱全赔回去。
- 推理弹性要提前量：GPU 节点冷启动 5-15 分钟，只看当前 QPS 扩缩必然抖动；用"预测式扩容 + 缓冲水位"。
- 多云不解决成本问题，解决的是单点依赖：成本优化靠的是利用率与计费模式匹配，多云是保险不是省钱手段。
下一篇预告：从公有云回到异构算力现场——"国产加速卡 PyTorch 适配与迁移：从算子差异到性能对齐"。