面试题

Q1：为什么说万卡训练的瓶颈是可靠性而不是算力？

要点：用规模律与一手数据回答。作业 MTBF = 单节点 MTBF / N：Meta 1,024 卡作业 MTTF 仅 7.9 小时（Kokolis HPCA'25），Llama 3 在 16,384 卡上 54 天中断 466 次（每 2.78 小时一次）、78% 为非预期硬件故障。8,192 卡规模若走 60 分钟冷修复路径，可用率跌破 50%（Mini Demo 场景 1）。同时给出经济学：16K 卡每天成本约 144 万美元，ETTR 0.6 ≈ 每天蒸发 58 万美元（TrainMover）。算力可以花钱买，可靠性不工程化就是买来了也烧掉。

Q2：fail-stop、fail-slow、SDC 有什么区别？各自怎么检测？

要点：三态模型。fail-stop 有显式信号（Xid、crash、超时），检测靠 watchdog/巡检/心跳，秒-分钟级；fail-slow 一切正常但变慢（光模块劣化、CPU 抢占），同步训练的 step=max 语义让单个慢节点拖垮全员，检测靠 step 计时基线 + 多轮投票（FALCON >99% 准确）；SDC 结果错误但无任何信号（位翻转），检测必须靠冗余——ECC、确定性负载双跑逐位对比、checkpoint 副本对账、loss 尖刺事后统计，四层纵深缺一不可（Llama 3 实测 6 次 SDC；EUD 召回率仅 ~70%）。难度与危害都按 fail-stop < fail-slow < SDC 递增。

Q3：checkpoint 间隔怎么定？为什么不能无限加密？

要点：经典权衡。间隔 T 越大，故障回滚损失期望越大（T/2）；T 越小，checkpoint 开销 C 吃掉越多算力。最优解由 Daly 公式给出 T* ≈ sqrt(2CM)（C 为单次开销、M 为 MTBF），直觉是两道成本打平。Mini Demo 场景 2 实测：MTBF 7.9 h、阻塞 240 s 时 Daly 给 123 步、网格精确解也是 123 步，效率上限 87.45%；差量 checkpoint（C×0.3）后最优 67 步、92.18%。无限加密的问题：阻塞式 checkpoint 的算力开销线性增长，且 checkpoint 本身有写坏风险——必须配原子提交、保留 N 版与异步/分层/差量手段把 C 先压下来。

Q4：一次训练故障的恢复时间花在哪里？怎么优化？

要点：TrainMover 对 8,192 卡冷重启的拆解：总 6.47 分钟 = 停机清理 0.52 + 重调度 1.50 + 初始化 4.45（ckpt 加载 1.56 + NCCL 初始化 1.09 + 冷 warmup 1.80），初始化占 69%。优化按杠杆排序：in-memory checkpoint 压加载；两阶段 delta 建链把 NCCL 初始化 51 s 压到 7 s（-86%）；沙箱预热把 JIT/warmup 提前到备机休眠期；热备免重调度。组合效果：ByteRobust 热更新 46-65 s（比全量 requeue 快 11.04 倍），TrainMover 通用热备 ~20 s。

Q5：什么是 ETTR？和"可用率"有什么区别？

要点：ETTR（Effective Training Time Ratio）= 有效训练时间 / 墙钟时间，是训练侧的总账本；可用率 = MTBF/(MTBF+MTTR) 只看故障-修复循环。差异在于 ETTR 还计入可用率不算的三项：回滚损失（故障点到上个 checkpoint 的进度）、checkpoint 开销、计划内维护停机。16K 卡作业可用率 99% 但 ETTR 可能只有 90% 出头。公式化：ETTR = MTBF / (MTBF + MTTR + 回滚损失)，再叠加 checkpoint 开销与维护项。标杆：ByteRobust 97%（9,600 卡三个月，非生产时间 <50 min）；Llama 3 >90%。

Q6：热备池应该配多大？拍脑袋 5% 行不行？

要点：按概率模型配，不按百分比拍脑袋。N 节点、单节点故障率 p，同时故障 k 台服从二项分布，备机数取"覆盖同时故障"的 P99 分位。ByteRobust 实测：9,600 卡 P99 只需 2-4 台热备（32 台同时故障概率 <1%）——约 0.03% 的闲置，远低于拍脑袋的 5%。同时两个工程要求：备机常驻自检（防幽灵劣化）+ 调度预留配额（防被借走）；P99 还是 P999 是成本与风险的显式旋钮。经济学校验：32K 规模一台 20 s 完成替换的热备机等效多买约 2,400 张卡（TrainMover）。

Q7：SDC 为什么危险？防线怎么设计？

要点：危险在于零信号 + 可毁模：硬件给出错误结果但不报错，ACL 2025 用真实不健康节点证明 SDC 可让模型收敛到不同最优或引发 loss 尖刺；Llama 3 在 54 天里命中 6 次。防线必须纵深：ECC（硅片层，覆盖单比特）→ 上线筛选（确定性负载逐位验证；注意 EUD 召回率 ~70%，不充分）→ 运行时冗余（双跑对比零漏报但 2 倍算力，建议抽样；副本对账低成本全量；通信内嵌 checksum 是成本趋势）→ 事后统计（5 倍 loss/grad-norm 尖刺，但必须有配套回滚动作，否则等于没防线）。检测 suspect 后：回滚可信 checkpoint + 隔离节点 + 双跑复测（SDC 复现 notoriously 难，ByteRobust 案例需 8 小时离线压测）。

Q8：一个慢 20% 的节点对 1,024 卡训练影响多大？怎么处理？

要点：同步语义下 step = max（全部 rank)，所以影响是每个 step 都慢 20%，周级损失约 16.7% 有效算力——比大多数 MFU 优化收益都大。处理：检测用中位数基线离群法（单轮即可，Mini Demo 场景 4：检出 rank 7、替换后 step 精确回到基线；生产加多轮投票压误报）；缓解用换备（TrainMover 测算 1,024 卡 20% 慢节点：放任损失 ≈ 理想逐迭代 checkpoint，热备替换仅损 4.7%）、reroute（Google 付 0.5-8.6% 步时税不停机）、或作业内降级。反模式：用重启治慢节点——重启后还是慢，白花 6.47 分钟。

Q9：Gang 调度为什么加剧可靠性问题？elastic 解决了什么、没解决什么？

要点：Gang 语义要求所有 rank 同时就绪、步调一致，作业可用性 = 各节点可用性的乘积（1,024 个 99.9% 节点 → 作业 35.9%），且任何成员失败默认全员陪葬。torchrun elastic 解决的是"入口弹性"：rendezvous 成员同步、--max-restarts 重启上限、环境变量暴露重启计数；文档明确失败时"ALL surviving workers are killed immediately"，即原生语义仍是整作业重启 + checkpoint 恢复。没解决：进程内恢复（in-process）、状态一致性（优化器 shard 重切分、dataloader 对齐）、热备替换——这些由 nvidia-resiliency-ext 与自研控制面向"只杀故障者"演进。

Q10：设计一个万卡训练平台的 checkpoint 策略。

要点：按"目标-公式-架构-运维"四层答。目标：RPO（回滚损失）与开销预算（<2%）。公式：Daly 起步 T* = sqrt(2CM)，M 用知识库实测 MTBF 滚动修正。架构：分层（GPU→DRAM→本地 SSD→远端）+ 异步（de-stage 快照 + 后台线程，DCP async_save 标准件）+ 差量（只写变化分片，支撑每步 checkpoint，参照 ByteRobust <0.9% 开销、MFU 损失 0.71%）+ 冗余（跨 TP/PP/DP 组副本，防整组过度驱逐丢 ckpt）+ 原子提交（临时目录 + rename）+ N 版本保留。运维：定期恢复演练 + 恢复读限速错峰。加分项：优化器状态体积是参数数倍需单独定策略；RL 训练还有 rollout 状态（见 RL Post-Training）。

Q11：引用公开故障统计数字时要注意什么？

要点：口径三问：按设备还是按作业？含不含计划内维护？含不含 fail-slow？实例：Kokolis 的 1,024 卡 MTTF 7.9 h（研究集群、硬件口径）与 Llama 3 的 2.78 h（生产作业、全口径含 47 次计划内）差 2.8 倍；ByteRobust 的 17.3% 是人工实验操作不是平台故障。其次是年代与硬件代际（A100 vs H100 vs TPU），以及"中断"定义（fail-stop only vs 含 fail-slow）。引用时标注来源、口径与日期，宁可不引也不混引。

Q12：为什么要区分"计划内中断"和"非预期中断"？

要点：两者的工程对策完全不同。计划内中断（固件升级、维护驱逐，Llama 3 每天至少一次）是可调度事件：可以等到 checkpoint 边界优雅执行、可以提前预热备机、甚至可以主动利用（把维护窗口和故障恢复合并）。非预期中断才是可靠性工程的对手。混在一起统计会让 MTBF 失真、让改进动作打偏——复盘只对平台负责的部分追责，预算只花在不可预期的部分。

Q13：10 万卡集群的可靠性问题和万卡有什么本质不同？

要点：不是量的区别，是手段穷尽的区别。万卡：热备 + 高频 checkpoint + 秒级检测能把 ETTR 推到 95%+；十万卡（Mini Demo 场景 1）：即使 5 分钟热备，模型可用率也只有 42.55%——运行时手段到顶。必须叠加：降故障率（硬件筛选工厂化、RAS 设计）、架构级故障域（Google cube + reroute、DeepSeek 案例 DualPipe 的流水线切分）、以及建设期决策的运行期代价（xAI 122 天建设把早期失效转移给运行期，见 xAI 案例）。预算结构变化：MTTR 优化收益递减，故障率与架构成为主战场。

Q14：如何验证一个可靠性改进（比如新检测器）真的有效？

要点：借评估工程的思路（见 Benchmark + Evaluation）。指标化：ETTR、检测时延分布、误报率（误驱逐健康节点的频率）、恢复路径耗时 vs 预算。方法：历史回放（知识库里的故障样本重放，A/B 新旧检测器）+ 故障注入演练（随机杀节点/注入慢节点）+ 分阶段灰度（先低优作业后大训练）。护栏：误报率超标自动回滚（检测器误报的成本是驱逐健康节点）。可靠性改进最容易自欺——没有对照组的 ETTR 提升可能只是运气（故障是泊松过程，方差很大）。

小结

面试的考察主线是三条：能不能用一手数字锚定论证（7.9 h / 466 次 / 6.47 min / 97% ETTR）、能不能把权衡讲成公式（Daly、规模律、二项热备）、能不能把方案落成预算与流程（检测-定位-恢复时延预算 + 回滚动作）。答出这三层，就具备了设计生产级训练可靠性系统的思维框架。