深夜十一点，算法工程师小林收到了公司通知：下个月要用 30 万预算，把一个大语言模型的训练从头跑完。他翻遍服务器报价，越看越没底——同样一张 GPU，有人说 10 万一台，有人说 2 万就能搞定。无奈之下，他拨通了 AWS 顾问老李的电话。老李笑道：“别慌，你这就是要来我们'云租车行'挑辆能拉重货的超级卡车。车不止一种，计费方式也不止一套，包你省钱，也包你不翻车。” AI 训练就像跑长途运输：数据是货物，GPU 是发动机，训练框架是车队调度。而 AWS EC2 就是一座巨大的“云租车行”，里面停满了从“省油小轿车”到“八挂重型卡车”的各色实例。这篇文章，就带你跟小林走一遍完整的“选车、租车、发车”之旅——搞懂 GPU 实例怎么挑参数、怎么对号入座，以及竞价款这辆“特价车”到底能不能放心开。

岗位关联

掌握 EC2 GPU 选型与竞价策略，等于给 AI 团队装上“算力理财”技能——同样的模型，别人花 100 万，你花 30 万照样跑完。

目录
  1. 可视化演示
  2. 云计算基础设施
  3. GPU实例家族
  4. 实例规格解析
  5. 竞价实例原理
  6. 选型方法论
  7. 成本优化策略
  8. 工程实践要点
  9. 实战故障处理
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

三步展示AWS EC2 GPU实例：P训练/G推理/Trn专用实例系列、vCPU/GPU/显存协同架构、以及竞价实例Spot的成本节省与中断风险权衡。

本节配有交互动效（进入视口后自动加载，约 3KB）。

GPU实例系列 P系列：训练 H100/A100 G系列：推理 A10G Trn: 训练专用芯片 按工作负载选型 匹配训练/推理/渲染。

云计算基础设施

小林走进“云租车行”时，老李先带他上了观景台。视野里是一望无际的停车场，但停车楼之间由高速路连接。老李说：“你不是买卡车，你是'租'卡车。按小时、按天租，车行负责保养、加油、上保险。你在车行门口把货卸下，剩下的交给调度中心。”这就是云计算的本质——把计算资源像共享停车场一样出租，省去自建机房的巨额固定成本。

概念落到技术上，AWS 的 EC2 就是那个“租车柜台”。它在全球设置了多个“区域”（Region），每个区域是独立的一片停车楼群；区域内又分为多个“可用区”（Availability Zone），相当于互不影响的独立停车楼。聪明的小林立刻明白了：如果担心某栋停车楼停电，就把车分散停到不同楼里，这就是高可用架构的雏形。

EC2 的计费，就像租车行按天收租金，用多久付多久。假设某实例每小时租价是 P，你租了 T 小时，总费用就是二者相乘。这是整个选型决策里最基本的账本。

\[\text{费用} = P \times T\]

老李拍拍小林：“记住，这台车的租金不只是车本身，还包含车上的油（CPU）、货厢（内存），以及挂在车尾的移动仓库（EBS 存储）。”小林点点头——租车行的事，先看清场地，再摸清柜台。

费用=P实例单价×T运行时长\text{费用} = P_{\text{实例单价}} \times T_{\text{运行时长}}
一张 GPU 卡每小时 3 美元，跑 1000 小时，账单就是 3000 美元。简单乘法，却是所有省钱的起点。
  1. 实例单价 P每小时租车价格，按秒计费后折合成小时。
    P实例单价P_{\text{实例单价}}
  2. 运行时长 T实例从启动到关停的累计时长，测试忘记关机也会计费。
    T运行时长T_{\text{运行时长}}
  3. 相乘求积价格与时长相乘得到总花费，这正是成本估算的基本公式。

GPU实例家族

老李把小林领到车型展示区。一排“车”从低到高排列，车头写着不同的型号：T4、V100、A100、H100。老李说：“GPU 就是发动机，一辆卡车的马力全看它。你的货物是几百 GB 的文本数据，发动机马力不够，拉不动；马力太大，又白烧油。”

这排卡车背后是 NVIDIA 的加速卡家族。T4 是省油的小轿车，适合“送外卖”——在线推理服务，显存占用小、功耗低，20 瓦到 70 瓦的电费让人安心；V100 是标准厢式货车，当年训练 ResNet、BERT 的法宝，至今是中型训练的中坚；A100 是重卡头，8 卡组合就是 8 节车厢的超级列车，大模型预训练的事实标准；H100 则是刚出厂的限定款烈马，配了 Transformer 引擎，在大模型时代一路狂飙。

在 EC2 租车行里，这些发动机被搭配成了整车系列：P 系列装 V100/A100（训练车），G 系列装 T4/A10G（推理与图形车）。选车时除了看发动机型号，还要看显存——显存就是卡车驾驶室里的“移动工作台”，模型参数和中间激活值都要摊在工作台上，工作台太小，模型直接“放不下”。

“你训练 130 亿参数，显存是关键瓶颈。”老李指着 A100 说，“8 张 A100 每张 80GB 显存，模型并行切分后刚好装下。”小林这才懂，为什么大家总说“先看显存再看算力”——发动机再猛，工作台放不下模型，照样没法开工。

显存带宽=显存频率×显存位宽8\text{显存带宽} = \text{显存频率} \times \frac{\text{显存位宽}}{8}
显存带宽决定了数据从“工作台旁边的货架”搬上“工作台”的速度。A100 的 2TB/s 带宽，是 T4 的四倍还多。
  1. 显存频率显存颗粒的时钟速度，好比货架的转速，单位 MHz。
    显存频率\text{显存频率}
  2. 显存位宽 / 8把位宽从 bit 换算成 byte。位宽 5120 bit 变成 640 byte，是每次搬运的“车道数”。
    显存位宽8\frac{\text{显存位宽}}{8}
  3. 乘积车道数乘上转速，就是每秒钟能从货架搬上工作台的数据量。
    带宽=频率×位宽8\text{带宽} = \text{频率} \times \frac{\text{位宽}}{8}

实例规格解析

小林站在一台 p4d.24xlarge 面前，老李递过一张“车辆配置单”：96 个 vCPU，1152 GB 内存，8 张 A100，每张 80GB 显存。小林看得眼花。老李拆开讲：“vCPU 是发动机的档位数，负责把数据搬运到位；内存是驾驶室，临时放调度指令；GPU 显存才是真正的施工台。”

实例规格的命名像车牌号：p4d.24xlarge 中，p 代表训练型车系，4d 代表第四代，24xlarge 表示“超大号”。同理，g4dn 是推理型车，p3 是上一代。规格越大，vCPU、内存、GPU 卡数等比例放大，当然“油耗”（每小时价格）也水涨船高。

选规格时要算清“单卡成本”这个关键指标。同样是 8 卡 A100 的车和老款 8 卡 V100 的车，单价差好几倍，但单看每张卡每小时的价格，才能公平对比不同整车的性价比。这也是“租卡车”比“买卡车”更讲究精算的地方。

老李补充：“网络带宽是车与车之间的高速路，EBS 存储是随车的冷库。”训练时 8 张卡要频繁通信，若带宽不足，就会出现'几头驴拉车，绳子互相绊'的窘境。小林把配置单折好塞进口袋——参数都是为“任务”服务的。

单卡小时成本=实例每小时价格GPU卡数\text{单卡小时成本} = \frac{\text{实例每小时价格}}{\text{GPU卡数}}
一台 8 卡 A100 实例时价 32.77 美元，单卡成本约 4.1 美元/小时；相比单卡 V100 的 3.06 美元，性能却高出数倍，账一下子算清楚了。
  1. 实例时价整车按小时计费的租金，p4d.24xlarge 约 32.77 美元。
    实例每小时价格\text{实例每小时价格}
  2. GPU 卡数车内搭载的张卡数，8 卡车意味着一次可并行 8 个运算工人。
    GPU卡数\text{GPU卡数}
  3. 相除总价平摊到每张卡，消除“整车虚胖”的干扰，便于横向对比。
    单卡成本=P整车N卡数\text{单卡成本} = \frac{P_{\text{整车}}}{N_{\text{卡数}}}

竞价实例原理

回到柜台，老李指着一块电子屏说：“这是我们的'特价档口'——竞价实例（Spot Instance）。每天供需变化，GPU 像机票一样实时浮动。人多时涨价，人少时跳水，最低能比按需便宜 70%。”小林心动了，但老李话锋一转：“特价车有个规矩：一旦车行临时缺车，你的车可能被'召回'，系统提前 2 分钟通知你下车。”

这就是竞价实例的本质：AWS 把闲置的算力库存以浮动的市场价出租。你报一个“最高可接受价”（出价），只要当前竞价价低于你的出价，车就归你；当供需紧张、竞价价飙升超过你的出价，AWS 就会回收实例。回收前的 2 分钟通知，是给你“靠边停车、带上检查点”的缓冲时间。

财务上，竞价实例把按需价格打了个“动态折扣”。节省率可以直接用一个减法公式表达。小林算了笔账：p4d.24xlarge 按需 32.77 美元/小时，竞价经常只要 9.83 美元/小时，一下就省了 70%。

“特价车适合什么货？”小林追问。老李答：“不怕打断的货。比如点云训练、批量图片推理、超参数搜索——每 20 分钟存一次检查点，车被召回换个停车楼继续跑。但核心数据库、实时交易，千万别上特价车。”小林默默记下这条铁律。

节省率=1−P竞价P按需\text{节省率} = 1 - \frac{P_{\text{竞价}}}{P_{\text{按需}}}
竞价价是按需价的 30% 时，节省率就是 70%。价格越低，省得越多，但被“召回”的风险也越高。
  1. P\_竞价当前特价档口的实时价格，随供需波动，可能低至按需价的两折。
    P竞价P_{\text{竞价}}
  2. P\_按需常规柜台价，即按需实例的小时价格，稳定不变。
    P按需P_{\text{按需}}
  3. 比值与补数先求竞价占按需的比例，再用 1 减掉，得到的就是“省下的比例”。
    1−P竞价P按需1 - \frac{P_{\text{竞价}}}{P_{\text{按需}}}

选型方法论

小林拿出自己的“货物清单”：130 亿参数大模型预训练、每天上万次的在线问答推理、以及偶尔的微调实验。老李递过一张决策表：“选车如选人，先问四个问题：跑什么任务？多大模型？多少预算？要不要 7×24 小时服务？”

任务类型决定车型：预训练是“长途重货”，必须上 A100/H100 重卡；微调是“中途补货”，V100 甚至 A10G 就够了；在线推理是“同城急送”，T4 小车油耗低、响应快。模型大小决定显存：130B 参数至少需要 8×80GB 显存，而 7B 模型单张 A100 就能微调。预算决定计费方式：预算紧就上竞价款，但要有“中途换车”的预案。

让小林眼前一亮的是“加权评分法”：把显存、算力、带宽、成本四个指标统一量化为 0-100 分，按照任务需求分配权重，算出每辆车的综合得分。这样，“感觉 A100 更好”就变成了“A100 总分 92，T4 总分 71”，选型不再拍脑袋。

老李最后总结决策流程：先给任务画像，再圈定候选车型，然后按评分排序，最后用预算锁定计费方式。小林恍然——这不是挑贵车，而是挑“最合适的车”。租车行里没有最好，只有最匹配。

综合评分=∑i=1nwi×Ni\text{综合评分} = \sum_{i=1}^{n} w_i \times N_i
训练任务给显存权重 0.4、算力 0.3、带宽 0.2、成本 0.1；推理任务则反过来，成本权重提到 0.4，显存降到 0.2。
  1. 权重 w\_i每项指标的重要程度，所有 w\_i 之和为 1。训练和推理的权重分配完全不同。
    wiw_i
  2. 归一化指标 N\_i把显存、带宽等原始值等比例缩放到 0-100，让不同量纲可相加。
    NiN_i
  3. 求和权重乘指标后求和，得到一张“能力画像”分数，供多家车型横向对比。
    ∑i=1nwi×Ni\sum_{i=1}^{n} w_i \times N_i

成本优化策略

小林算了笔账：全用按需跑 30 天，光 p4d.24xlarge 就要 2.3 万美元，预算直接爆表。老李甩出三张“会员卡”：“按需是到店现租，灵活但贵；预留是办年卡，一次承诺 1 年或 3 年，价格最多打 72 折；竞价是特价秒杀，便宜但看运气。”

聪明的做法是“组合拳”：把基线的、雷打不动的训练任务用预留实例兜底；把弹性突发的推理波峰用按需实例扛住；把可以断点续跑的长尾任务丢给竞价实例。老李给小林画了个时间轴：一个月 720 小时里，400 小时给预留，200 小时给按需，120 小时给竞价，成本立减一半。

这与 AWS 的“成本优化支柱”一脉相承：用自动扩缩容让实例数量跟随队列长度伸缩，GPU 空转超过 5 分钟就自动关停；用预算告警在月度消费超过 80% 时发邮件预警。此外，EC2 的“节省计划”（Savings Plans）与预留实例类似，但更灵活——按每小时承诺消费金额计费，只要总承诺额度达标即可。

“记住，省钱的前提是守住可用性。”老李叮嘱，“预留 + 竞价的比例要边跑边调，监控里看到竞价中断率高了，就把流量挪给按需。”小林第一次觉得，成本优化不是抠门，而是算力资源的精装修。

C组合=t1×P预留+t2×P按需+t3×P竞价C_{\text{组合}} = t_1 \times P_{\text{预留}} + t_2 \times P_{\text{按需}} + t_3 \times P_{\text{竞价}}
预留价 0.28 倍、按需 1 倍、竞价 0.3 倍，三种计费时长配比得当，月度总成本可降至全按需的 55% 左右。
  1. t\_1 与 P\_预留承诺期内的固定时长与折扣价，占比越高，成本地板越低。
    t1×P预留t_1 \times P_{\text{预留}}
  2. t\_2 与 P\_按需突发弹性时段的原价开销，占比越低越好。
    t2×P按需t_2 \times P_{\text{按需}}
  3. t\_3 与 P\_竞价可中断时段的特价开销，是省钱的“进攻手”。
    t3×P竞价t_3 \times P_{\text{竞价}}
  4. 求和三种模式的费用相加，得到混合部署的月度总成本。
    C组合=∑tiPiC_{\text{组合}} = \sum t_i P_i

工程实践要点

拿到车钥匙后，小林面临“怎么把车开起来”的问题。老李给他一张发车检查单：第一步，用预置的深度学习镜像（如 AWS 官方 Deep Learning AMI），里面已装好 CUDA、cuDNN、PyTorch/TensorFlow 全家桶，免去手动装驱动的折腾，就像新车已贴好膜、配好脚垫。

第二步是“排队装货”：训练数据从 S3 对象存储传送到与实例同一个可用区的 EBS 里。老李强调：“数据没靠近计算，卡车就会在高速上反复空跑。把数据放在同区、甚至同一停车楼的仓库，训练吞吐能提升 30%。”小林还学会了用 S3 挂载工具（如 Mountpoint for S3）把对象存储直接映射成目录，边训边读。

第三步是“多车编队”：8 卡 A100 同步训练时，每张卡负责模型的一个分片，通过 NVIDIA NCCL 库做 GPU 间通信。但编队不是人越多越好——通信开销随着卡数增长，加速比存在天花板。这个天花板就是阿姆达尔定律：即使并行部分无限提速，整个训练里串行部分（比如每轮的初始化、模型同步）仍然是不可绕过的瓶颈。

小林感慨：“原来 8 卡不是 8 倍速，能有 6.5 倍就要烧高香。”老李点头：“所以训练脚本里要开梯度累积和混合精度（AMP），把通信次数降下来，编队效率才能上去。”发车前的大检查，就是让每辆车都保持最佳状态。

S(p)=1(1−f)+fpS(p) = \frac{1}{(1 - f) + \frac{f}{p}}
f 是任务中可并行的比例，p 是 GPU 数量。当 p 趋近无穷，最大加速比也只有 1/(1-f)，这就是“多卡省时间但省不到零”的原因。
  1. 可并行比例 f整个训练中被拆到多张卡上并行执行的比例，数据并行和模型并行都属于 f。
    ff
  2. 串行比例 1-f无论如何都无法并行化的部分，如参数广播、梯度聚合的等待。
    1−f1 - f
  3. 处理器数 pGPU 卡数，p 越大，并行部分耗时被压得越短。
    pp
  4. 加速比 S串行时间与并行总时间的比值，反映多卡带来的真实“提速倍数”。
    S(p)=T串行T并行S(p) = \frac{T_{\text{串行}}}{T_{\text{并行}}}

实战故障处理

发车第三天凌晨，意外来了。小林收到一条告警：“竞价实例 p4d.24xlarge 将在 2 分钟后回收。”他吓得从床上弹起——训练已跑了 60 个小时，如果从头再来，这周就白干了。好在老李早已让他启用了“检查点”机制：每 30 分钟将模型权重、优化器状态、步数保存到 S3。回收前，系统自动做完最后一次落盘，然后把任务提交到另一可用区的竞价款实例上续跑，整个过程只损失了 2 分钟。

“这就是竞价实例的保命符。”老李说，“检查点不是可选项，是必选项。中断概率越低，就可以把检查点间隔拉得越长，但间隔太大会浪费算力。”小林记录下经验公式：平均中断间隔 T，检查点间隔选 T 的一半最平衡。

多区域容灾是第二道保险。老李让小林的训练调度器同时盯着三个可用区的竞价池：哪边便宜调度到哪边，哪边被回收立刻换路。这就像快递公司同时走三条高速，哪条堵车马上切换，保证“货不等人”。

小林把两小时前的检查点从 S3 拉回来，模型在 15 分钟后恢复了训练。他长舒一口气：这辆“特价车”虽然会中途被召回，但有了检查点、多区域调度和监控告警三条安全带，比想象中稳得多。老李笑着补了一句：“开车的人，永远要把 ' 备用方案 ' 放进后备箱。”

E[T浪费]=T检查点间隔2+T重启E[T_{\text{浪费}}] = \frac{T_{\text{检查点间隔}}}{2} + T_{\text{重启}}
如果每 30 分钟存一次检查点，中断后平均最多浪费 15 分钟训练 + 10 分钟重启。相比 60 小时的训练，损失小到可以忽略。
  1. 检查点间隔 T两次保存模型状态的间隔时间，间隔越大，重复计算越多。
    T检查点间隔T_{\text{检查点间隔}}
  2. 间隔的一半中断发生在两个检查点之间的任意时刻，平均浪费半个间隔的进度。
    T检查点间隔2\frac{T_{\text{检查点间隔}}}{2}
  3. 重启时间 T\_重启从新实例启动、加载模型到恢复训练的总耗时。
    T重启T_{\text{重启}}
  4. 期望浪费把两类损失相加，得到一次中断平均浪费的总训练时间，用于评估容灾策略。
    E[T浪费]E[T_{\text{浪费}}]

AI 应用场景

大模型预训练前的选型评估

阶段：基础设施规划与资源选型

解决的问题：传统做法是“先买服务器再评估”，导致预算超支 3 倍或显存不足无法训练。AI 工程师用选型方法论先对模型参数、数据量、训练时长画像，再用加权评分和单卡成本公式从 EC2 车型表中筛出最优组合。

具体案例：某 AIGC 公司预训练 130B 参数模型，通过对比 p4d.24xlarge 与 p5.48xlarge 的单卡成本、显存带宽，最终选择 16 台 p4d.24xlarge 混合竞价部署，训练成本从预估的 120 万压到 68 万。

在线推理服务的成本压缩

阶段：模型部署与推理优化

解决的问题：在线问答若全用按需 A100 推理，单价高且 GPU 利用率低。改用 T4/G5 实例承载低并发时段、A10G 承载波峰，通过自动扩缩容让 GPU 利用率从 15% 拉升到 60%，同时竞价实例兜底无状态推理任务。

具体案例：某智能客服厂商将 200 路并发问答从 10 台 p3.2xlarge（按需）迁移到 6 台 g5.xlarge + 2 台竞价 p3.2xlarge 的混合池，月度推理成本从 3.8 万美元降至 1.5 万美元，P99 延迟保持在 380ms。

多区域竞价容灾调度系统

阶段：训练任务编排与容灾

解决的问题：单一可用区竞价实例中断会导致训练停顿。平台工程师构建了一个定时巡检竞价价格的调度器，自动在 us-east-1 和 us-west-2 的竞价池之间迁移训练任务，并用检查点保证迁移不损失进度。

具体案例：某自动驾驶数据团队每天跑 300 个点云训练任务，接入调度平台后，中断恢复时间从 2 小时缩至 8 分钟，整体 GPU 账单下降 73%。

Python 演示

python52 行
"""EC2 GPU 实例选型与成本对比工具：训练前评估车型与计费模式。""" INSTANCE_CATALOG = [    {"name": "g4dn.xlarge", "gpu": "T4", "cards": 1, "vcpu": 4, "mem": 16, "on_price": 0.526},    {"name": "g5.xlarge", "gpu": "A10G", "cards": 1, "vcpu": 4, "mem": 16, "on_price": 0.682},    {"name": "p3.2xlarge", "gpu": "V100", "cards": 1, "vcpu": 8, "mem": 61, "on_price": 3.06},    {"name": "p4d.24xlarge", "gpu": "A100", "cards": 8, "vcpu": 96, "mem": 1152, "on_price": 32.77},    {"name": "p5.48xlarge", "gpu": "H100", "cards": 8, "vcpu": 192, "mem": 2048, "on_price": 98.32},]  def monthly_cost(inst, hours_per_month=720, use_spot=False):    """按每月 720 小时计算单台实例成本，价格乘以时长。"""    price = inst["on_price"]    if use_spot:        price *= 0.3    return price * hours_per_month  def per_card_cost(inst):    """计算每张 GPU 卡的小时成本，便于跨车型对比。"""    return inst["on_price"] / inst["cards"]  def suggest(inst):    """根据 GPU 型号输出一句话选型建议。"""    gpu = inst["gpu"]    if gpu in ("T4", "A10G"):        return "适合轻量推理、图片生成"    if gpu == "V100":        return "适合中型训练与微调"    if gpu == "A100":        return "适合大模型预训练"    return "适合极致大规模训练"  def main():    print("=" * 76)    print("EC2 GPU 实例选型与月度成本对比（按月 720 小时）")    print("=" * 76)    print(f"{'实例型号':<16}{'GPU':<7}{'卡数':<5}{'单卡时价($)':<12}"          f"{'按需月度($)':<14}{'竞价月度($)':<14}选型建议")    for inst in INSTANCE_CATALOG:        on_cost = monthly_cost(inst)        spot_cost = monthly_cost(inst, use_spot=True)        print(f"{inst['name']:<16}{inst['gpu']:<7}{inst['cards']:<5}"              f"{per_card_cost(inst):<14.2f}{on_cost:<16.2f}"              f"{spot_cost:<16.2f}{suggest(inst)}")  if __name__ == "__main__":    main()
目的：给定实例目录，自动输出每款 GPU 实例的单卡时价、按需/竞价的月度费用及选型建议，帮你在采购前快速圈定候选车型。
  1. monthly_cost(inst, hours_per_month=720, use_spot=False)核心计费函数，用“价格 × 时长”公式计算月度账单，use_spot 开关模拟 30% 竞价的折扣价。
  2. per_card_cost(inst)对应正文“单卡成本 = 实例时价 / GPU 卡数”的量化实现，让 1 卡 T4 和 8 卡 A100 站在同一把尺子下比较。
  3. INSTANCE_CATALOG模拟 EC2 租车行的“车型目录”，每行是一辆车的完整配置单：GPU 型号、卡数、vCPU、内存与时价。
  4. if use_spot: price *= 0.3竞价实例的价格假设为按需价的 30%，相当于正文中特价档口的“动态折扣”。
  5. suggest(inst)用一个简单规则把车型映射到任务类型，对应选型方法论中“先给任务画像再选车”。

常见误区

误区“我只用一个大模型训练脚本，买最贵的 H100 实例肯定最快，反正预算管够。”

正解H100 块头大、油耗高，就像用重型卡车跑同城急送——速度优势发挥不出来，油钱却翻了几倍。推理服务用 T4 或 A10G 反而更划算。选型必须按任务画像匹配：训练重活选 A100/H100，轻量推理选 T4，微调可选 V100/A10G。

为何常见：厂商发布会都拿旗舰卡做标杆，久而久之大家形成“贵 = 好”的思维惯性，忽略了实际工作负载与资源利用率。

误区“竞价款是别人挑剩下的资源，随时可能消失，我宁可贵一点也别用，不然业务中断就惨了。”

正解竞价实例在 2020 年后已经支持“2 分钟中断预警”，配合检查点与多可用区调度，完全可用于断点续训、批量推理、超参搜索等无状态场景。真正的生产险情，往往来自没有容灾设计，而不是用了竞价。AWS 官方数据显示，竞价实例中断率长期低于 5%，80% 以上场景根本不会中断。

为何常见：早期竞价实例确实“说没就没”，很多人吃过亏，便把当时的痛感延续成刻板印象，不去了解新的预警与恢复机制。

误区“96 个 vCPU 加 1TB 内存的实例，怎么也比 8 核 16GB 的跑得快，参数越多越有面子。”

正解深度学习训练的核心瓶颈在 GPU 算力与显存带宽，vCPU 主要承担数据预处理与调度。vCPU 和内存配置过高，就像给重型卡车装了超大驾驶室却配了个小发动机——花冤枉钱。真正要先看 GPU 型号、卡数、显存容量和 NVLink 带宽。

为何常见：大家熟悉 CPU 服务器的选型逻辑（核多内存大就是强），容易把惯性搬到 GPU 场景，而没有意识到计算主战场已经转移到 GPU 上。

误区“按需实例随时开机随时关机，没有承诺、不用锁死，一个月下来应该不会比那些复杂的预留和竞价方案贵多少吧？”

正解按需是“到店现租”的原价，没有任何折扣。一个稳定跑 400 小时的训练任务，用预留实例能省 40%-72%；用竞价能省 50%-90%。真正的最优解是混合部署：稳定基线用预留，弹性波峰用按需，可断任务用竞价。只按需，等于全年无休按原价住酒店。

为何常见：按需实例操作最简单、零承诺，账面上的“省心”掩盖了单价上的“最贵”，缺乏三位一体的成本对比视角。

误区“为了防止训练白跑，我每分钟都存一次检查点，存到本地磁盘最放心。”

正解检查点间隔太短，会把大量时间花在“存档”上，反而拖慢训练；存在本地磁盘，实例一回收数据就没了。正确做法是根据平均中断间隔设置检查点频率（通常 15-60 分钟），并保存到 S3 等持久化存储，同时开启自动恢复脚本，让新实例拉起后自动续跑。

为何常见：人对“丢失进度”的恐惧天然会让人过度保存，却没算清“保存本身的时间成本”；同时又忽略本地盘与共享存储的根本差异。

面试题

Q1. 竞价实例（Spot）的核心优势是什么？

单选题 · easy

  • A.运行绝不中断
  • B.价格省一大半← 正确答案
  • C.独享物理机器
  • D.显存自动翻倍

答案：B。竞价实例按供需浮动的市场价出租闲置算力，通常可比按需便宜 50%-90%，这是它最核心的价值。A 错在竞价可能被回收；C 是专用主机特性；D 是显存技术，与计费模式无关。

Q2. p4d.24xlarge 实例搭载了几块 A100 GPU？

单选题 · easy

  • A.2 块
  • B.4 块
  • C.8 块← 正确答案
  • D.16 块

答案：C。p4d.24xlarge 是专为大模型训练设计的“8 卡 A100 重卡”，配备 8 张 80GB 显存的 A100，总计 640GB 显存。这个规格与之类似的是 p5.48xlarge，也是 8 卡，但升级为 H100。

Q3. 以下哪款 GPU 最适合大模型预训练？

单选题 · mid

  • A.T4 推理卡
  • B.A10G 显卡
  • C.A100 加速卡← 正确答案
  • D.老款 K80

答案：C。大模型预训练是“长途重货”，需要大显存和高带宽，A100 的 80GB 显存与 2TB/s 带宽是行业事实标准。T4 和 A10G 面向轻量推理，K80 太老，算力与显存均不达标。

Q4. 竞价实例最大的风险是什么？

单选题 · mid

  • A.价格波动很小
  • B.可能随时被回收← 正确答案
  • C.无法并发运行
  • D.无法保存数据

答案：B。竞价实例使用闲置资源，当供需紧张、竞价价超过你的出价时，AWS 会回收实例（通常提前 2 分钟通知）。这个“可能中断”正是它的最大不确定性，因此需要检查点机制来兜底。

Q5. 下列哪些场景适合使用竞价实例？

多选题 · mid

  • A.断点续训的训练任务← 正确答案
  • B.无状态的批量推理← 正确答案
  • C.核心交易数据库
  • D.实时风控模型服务

答案：AB。断点续训任务有检查点，允许中断后恢复；批量推理对单次延迟不敏感，中断后重试即可。而核心交易库和实时风控要求 7×24 稳定运行，中断会造成真金白银的损失，必须用按需或预留，不能冒险。

Q6. 预留实例的主要特点是什么？

单选题 · mid

  • A.按秒计费最灵活
  • B.签一年或三年锁价← 正确答案
  • C.价格随市场波动大
  • D.只能按流量结算

答案：B。预留实例需要承诺 1 年或 3 年的使用时长，换取约 40%-72% 的折扣，相当于“办年卡”。A 是按需秒级灵活性；C 是竞价特征；D 是网络计费方式，与实例租赁无关。

Q7. 下列哪些属于 EC2 GPU 选型方法论的考量因素？

多选题 · hard

  • A.任务类型与负载← 正确答案
  • B.显存容量大小← 正确答案
  • C.单卡算力峰值← 正确答案
  • D.可用区降雨量

答案：ABC。选型方法论的核心是“先给任务画像，再匹配资源”：任务类型决定车型（训练 vs 推理），显存决定模型能否装下，算力决定训练快慢。降雨量是明显干扰项，硬件选型与天气无关。

Q8. 按需实例的计费方式是什么？

单选题 · easy

  • A.按小时随用随付← 正确答案
  • B.预付一年费用锁定
  • C.按市场价上下浮动
  • D.仅按流量出站计费

答案：A。按需实例就是“到店现租”，按秒/小时计费，随开随停，无需承诺，单价最高。B 是预留实例；C 是竞价实例；D 描述的是网络流量费用，不是实例租赁费。

Q9. 竞价实例被中断后，有效的恢复手段有哪些？

多选题 · hard

  • A.周期保存检查点← 正确答案
  • B.多可用区重新调度← 正确答案
  • C.将快照及时备份← 正确答案
  • D.提高按需配额上限

答案：ABC。检查点把训练进度落盘到 S3，中断后可从最近存档续跑；多可用区调度让任务在其他可用区的竞价池自动拉起；EBS 快照备份保证数据和环境可重建。提高按需配额与竞价中断恢复无关。

Q10. 阿姆达尔定律说明的核心结论是什么？

单选题 · easy

  • A.串行部分决定上限← 正确答案
  • B.GPU 加得越多越快
  • C.内存越大算力越强
  • D.网络延迟可以忽略

答案：A。阿姆达尔定律指出，即使并行部分无限提速，总加速比仍受串行部分限制。因此 8 卡训练不可能达到 8 倍速，必须优化梯度聚合、数据加载等串行环节，这正是分布式训练加速比有天花板的原因。