云上第一台 GPU 机器：选型、成本与止损线
在云上，最贵的错误通常不是选错机型，而是忘了关机。
上一章你学会了验证一台 GPU 机器，但那台机器从哪来？对大多数工程师，答案是云：小时级计费、免硬件采购、随开随关。本章解决三个问题——按用途选卡、看懂计费、设置止损线，最后用一个实验走完“开机到彻底清理”的完整闭环。这个闭环本身就是生产 GPU 平台运维的最小原型。
先问用途，再选卡
显存是硬约束（见显存管理），所以选卡的第一步是估算工作负载的显存需求，而不是比较 TFLOPS。以大模型场景为例：
| 用途 | 显存底线（估算） | 典型卡 | 计费直觉（按需，美东，仅供量级参考） |
|---|---|---|---|
| 学习、跑通流程 | 8–16 GiB | T4 / L4 | $0.5–1 /小时 |
| 7B 模型推理（bf16 权重约 14 GiB + KV Cache） | 16–24 GiB | A10 / L4 24G | $1 /小时左右 |
| 7B 模型 LoRA 微调 | 24–48 GiB | A10 24G 起步，A100 40G 从容 | $1–4 /小时 |
| 7B 全量微调（权重+梯度+优化器状态） | 80 GiB 或多卡 | A100 80G / 多卡 | $8 /小时以上 |
| 大规模预训练 | 数百 GiB，必须多机多卡 | H100/H800 集群 | $30 /卡/小时量级 |
两条经验：
- 推理看显存与带宽，训练看显存与互连。推理的性能物理层见LLM 推理物理层；多卡训练为什么必须关心 NVLink 与拓扑，见互连与集合通信。
- 能用小卡验证的，不要用大卡陪跑。工程流程（容器、调度、监控）的验证用 T4/A10 级别足够，验证完再上生产卡，这是成本治理的第一原则，系统的展开见容量经济。
另外注意消费级卡（GeForce）与数据中心卡的区别：ECC 显存、MIG 切分、NVLink、官方数据中心驱动支持，这些差异决定了生产负载不应跑在消费卡上，详见世代、模块与产品语言。
三大云的 GPU 实例形态
各家命名不同，但映射关系清晰。选择时优先考虑两点：是否自带 GPU 驱动镜像（省掉上一章的安装）、竞价实例折扣幅度。
| 云 | 入门（T4/L4 级） | 中档（A10/A100 级） | 高端（H100 级） |
|---|---|---|---|
| AWS | g4dn（T4）、g6（L4） | g5（A10G）、p4d（8×A100 整机） | p5（8×H100 整机） |
| Google Cloud | g2（L4） | a2（A100 单卡可开） | a3（H100） |
| Azure | NCasT4_v3 | NC A100 v4 | ND H100 v5 |
| 中国云厂商 | 阿里云/腾讯云均有 T4 系 | A10、A100 系（gn/GN 等命名） | H800/H20 系 |
三家都提供“GPU 优化镜像”（自带驱动与 CUDA），选它，开箱即得上一章的“环境基线卡”里除型号外的全部字段。价格随时区、可用区、供需浮动，上表只给量级，决策前以各云官网价格计算器为准。
计费模型与止损机制
| 模式 | 折扣 | 风险 | 适用 |
|---|---|---|---|
| 按需（On-demand） | 无 | 无 | 短期、不确定时长的使用 |
| 竞价/抢占（Spot/Preemptible） | 通常 50%–90% | 可能被回收，通知窗口只有约 2 分钟 | 无状态任务、可断点续跑的训练（需 checkpoint） |
| 包年包月/预留 | 视承诺而定 | 资金锁定 | 已验证的稳定负载 |
竞价实例的回收机制值得敬畏：回收前约两分钟通知，进程被直接终止。这意味着任何跑在 Spot 上的训练必须周期性 checkpoint——这件事的调度学代价（“你抢走的是已完成的有效工作”）在PyTorch 训练与Kueue两章会系统展开。
比选对计费模式更重要的是止损机制。三件套，缺一不可：
- 预算告警：AWS Budgets、GCP 预算提醒、Azure 成本警报，阈值设在“意外但可承受”的金额。
- 标签治理：所有实验资源打统一标签（如
project=gpu-infra-lab），事故后能按标签一键盘点与清理。 - 关机纪律：实验结束当次会话内关机；长期不用就销毁（terminate），不是停止（stop）。
动手实验：开一台竞价 GPU 实例并彻底清理
实验目标
完整走一遍“选机型 → 查现货价 → 开机 → 体检 → 销毁 → 确认零残留”。完成后，“云上 GPU”对你不再是控制台里的选项，而是一条可复现的命令流水线。
前置条件与成本预估
- 一个云账号与已配置好的 CLI（实验以 AWS CLI 为例，其他云流程等价）。
- 成本：以 g5.xlarge（单卡 A10G 24GiB）竞价为例，通常 $0.3–0.7/小时，实验全程约半小时，预算控制在 1 美元以内；价格随区域与供需浮动，以官网为准。
操作步骤
# 步骤 1：查询当前现货价，确认在预算内（us-east-1 为例）
aws ec2 describe-spot-price-history \
--instance-types g5.xlarge --product-descriptions "Linux/UNIX" \
--start-time "$(date -u +%FT%TZ)" --region us-east-1 \
--query 'SpotPriceHistory[0].[AvailabilityZone,SpotPrice]' --output text
# 步骤 2：选定一个自带驱动的 GPU AMI（Deep Learning AMI / NVIDIA GPU-optimized），
# 在控制台或如下查询最新版
aws ec2 describe-images --owners amazon --region us-east-1 \
--filters "Name=name,Values=Deep Learning AMI GPU*" \
--query 'sort_by(Images,&CreationDate)[-1].ImageId' --output text
# 步骤 3：一键开机（替换 key 与安全组；terminate 模式确保回收时自动清理）
aws ec2 run-instances \
--image-id ami-xxxxxxxxxxxxx --instance-type g5.xlarge \
--key-name my-key --region us-east-1 \
--instance-market-options '{"MarketType":"spot","SpotOptions":{"SpotInstanceType":"one-time","InstanceInterruptionBehavior":"terminate"}}' \
--tag-specifications 'ResourceType=instance,Tags=[{Key=project,Value=gpu-infra-lab}]' \
--query 'Instances[0].InstanceId' --output text
# 步骤 4：等实例 running 后 SSH 登录，执行上一章的体检流程
# lspci | grep -i nvidia && nvidia-smi
# 自带驱动的镜像应直接输出基线卡的全部字段
# 步骤 5：销毁（是 terminate，不是 stop）
aws ec2 terminate-instances --instance-ids i-xxxxxxxx --region us-east-1验证清单
- 步骤 1 的现货价在你预设的预算线内（先设线，再开机）
- SSH 后
nvidia-smi输出正常，型号与所选实例规格一致 - 已执行
terminate，实例状态变为terminated -
aws ec2 describe-volumes --filters Name=tag:project,Values=gpu-infra-lab无残留卷（默认 AMI 的根卷随实例删除，若输出非空，逐个删除） - 账单控制台里该实例的计费已停止（有几分钟延迟，稍后复查一次）
原理速览
竞价实例的底层是云厂商用折扣出售空闲容量，换回的是随时回收权：InstanceInterruptionBehavior=terminate 让回收即清理，避免“停在那里继续计费”。选择自带驱动的镜像是把“环境层”也交给镜像管理，与准备 GPU 运行环境“宿主机只管驱动”的结论一致——只不过这次连驱动安装也省了。
清理与止损
实验的最后两步就是清理本身。养成肌肉记忆：terminate 之后必须验证资源清零，并周期性按 project 标签盘点全账号资源。
总结
本章把“去哪里拿卡”变成了一条可复现的流水线：按显存需求选卡、用竞价价压低成本、用预算告警和标签兜底、以 terminate 加验证收尾。你现在拥有随时可开可关的 GPU 算力，以及一套止损纪律——这两者合起来，就是后面所有实验的资源前提。下一章用 Docker 运行 GPU 工作负载在这台机器上跨过第一道工程门槛：让容器合法地拿到 GPU。成本的系统性分析（自购 vs 云、利用率核算）见容量经济。