本文是AI Infra 面试题系列的 Level 6，覆盖 Q65-Q74。重点是可观测性、hang/straggler/OOM、恢复、数据、放置、过载与 RL 系统。
上一篇：Kernel、编译与性能工程 · 系列总索引 · 下一篇：项目答辩与高压追问
7. Level 6：生产集群、可靠性与 RL Infra
Q65. 如何为千卡训练任务设计可观测性？
高分回答要点
- 训练层：step/phase time、tokens/s、MFU、loss、gradient norm、loss scale、data cursor、checkpoint 状态。
- GPU/rank 层：每 rank kernel/collective 时间、显存、温度/功耗/时钟、ECC/Xid、heartbeat、straggler score。
- 网络/存储层：每 NIC/rail throughput、拥塞/重传、collective size、数据与 checkpoint IO、metadata latency。
- 所有指标带 job/rank/node/parallel-group/step 标签和统一时钟；保留低开销连续指标，并支持触发式抓取 trace。
- 告警围绕用户影响和自动诊断：step 卡住、rank skew、loss 异常、SLO/MFU 持续下降、checkpoint 过期，而不是单纯 GPU busy 低。
追问：怎样控制高基数标签和 trace 成本？如何在一个 rank 变慢时快速定位其同组 peer？
Q66. 一个大训练任务卡住，所有 GPU utilization 看起来仍为 100%，怎么查 NCCL hang？
高分回答要点
- 先冻结现场：记录最后完成 step、各 rank stack/heartbeat、NCCL log、GPU Xid、网络 counters，避免直接重启丢证据。
- 判断是真 deadlock、极慢 collective 还是某 rank 未进入 collective；比较各 rank 当前 op、sequence number、tensor shape 和 process group。
- 常见根因包括不同控制流/collective 顺序、一个 rank OOM/异常退出、网络链路故障、数据 loader 卡住导致 peer 等待，以及超时配置掩盖。
- 用 watchdog/async error handling 与独立健康通道检测，超时后协调终止整个 job，避免残留 rank 占卡；从最近一致 checkpoint 恢复。
- 最小化到具体 group/rank/node 后做替换节点、pair test 和代码 replay，区分硬件与逻辑错误。
Q67. 训练 step 出现长尾 straggler，如何定位？
高分回答要点
- 先按 step 计算每 rank phase duration 和 barrier/collective wait，把“被迫等待的 rank”和“真正先变慢的 rank”分开。
- 检查 GPU 时钟降频/ECC、CPU 抢占/NUMA、data shard、文件系统、网络拥塞、kernel shape、MoE token imbalance 和 Python GC。
- 关联同节点、同 NIC、同 TP/DP group 是否共同异常，利用拓扑缩小故障域。
- 短暂噪声可通过调度隔离、数据预取缓冲缓解；持续硬件慢节点应驱逐，算法不均衡则需 repartition/load balance。
- 报告 p50/p99 step time 和有效 MFU，平均值会掩盖同步系统的尾部成本。
Q68. 训练或推理发生间歇性 OOM，你如何区分原因？
高分回答要点
- 区分 allocated、reserved、active、inactive split 和非框架分配；查看峰值发生的 phase 与 allocation stack。
- 训练可能来自变长 batch、prefetch/FSDP AllGather 重叠、临时 workspace、未释放 graph、梯度累积或 checkpoint 保存。
- 推理可能来自 prompt/output 长度尾部、KV block 碎片、过量并发、prefix 引用未释放、compile/CUDA Graph pool 或 preemption 峰值。
- 先构造触发输入并记录 memory snapshot，再调整单一变量；
empty_cache可能缓解 reserved memory，但不是修复泄漏。 - 生产方案包括 token budget/admission、显存水位、长度限制、分片/重计算和内存泄漏回归测试。
Q69. 千卡任务的 checkpoint 与故障恢复策略怎么定？
高分回答要点
- 根据故障率、checkpoint 写入时间和可接受丢失工作量选择间隔；规模越大，任一组件故障概率越高，不能沿用单机频率。
- 分片并行写、异步 staging、限流避免压垮训练网络/存储；manifest 原子提交并保留至少一个已验证版本。
- 自动检测故障、释放旧进程、替换坏节点、重建 groups，再从 checkpoint 恢复；记录恢复时间 RTO 和丢失训练量 RPO。
- 定期验证 checksum 与真实 restore，并测试不同 world size/并行配置 reshard；checkpoint“写成功”不代表“能恢复”。
- 数据游标、RNG 和 optimizer 语义必须一起恢复，否则 loss 能继续下降也可能重复/漏训练数据。
Q70. 数据管道如何把 GPU 持续喂满，同时保证可恢复性？
高分回答要点
- 分解 object store/文件系统读取、解压/解析、tokenize、shuffle、packing、host memory、H2D；对每级设置队列和 backpressure 指标。
- 使用分片、顺序大块读取、异步预取、缓存、pinned memory 和 worker 并行，但避免所有 rank 同时打热点对象。
- global shuffle、去重、样本权重与 packing 要有确定语义；每 rank shard 必须避免无意重复，并能记录可恢复 cursor。
- 数据坏样本/超长样本需可观测和隔离，不能让一个 rank 跳过而其他 rank 不跳过导致 collective 不匹配。
- benchmark 应测 steady-state、冷 cache、存储故障和 checkpoint restore 后的数据连续性。
Q71. 怎样做 topology-aware placement 和故障域设计？
高分回答要点
- 收集 GPU-NVLink/NVSwitch、PCIe/NUMA、NIC/rail、机架/交换机和电源故障域，形成可供 scheduler 使用的资源图。
- 把 TP/CP/EP 等高频 critical-path group 放在高带宽低延迟域；PP 相邻 stage 优先近邻；DP 跨更大故障域获得副本扩展。
- 不能只追求通信最短：同一机架放完所有 pipeline 可提高性能，却让单交换机/电源故障损失整个 job。
- 通过 placement 候选的成本模型和实际 collective calibration 选择，并持续检查硬件降级后拓扑是否改变。
实验锚点：本机 PIX/PHB/SYS 差异提供了单节点校准方法；生产扩展需要增加 GPU-NIC 和交换网络层级。
Q72. 在线推理过载时，怎样保护 SLO 和多租户公平性？
高分回答要点
- 在入口按租户做 token-aware rate limit、并发上限、长度/预算校验和优先级；请求成本不能只按 req/s 估算。
- scheduler 做 deadline/priority、prefill chunk、decode reservation 和 KV 水位保护；超过能力时应尽早排队/拒绝，避免完成吞吐尚高但 goodput 为零。
- 资源池可按模型/优先级隔离，cache key 与指标按租户隔离；防止 noisy neighbor 占满 KV 或发送超长 prompt。
- autoscaling 要使用 queue、token arrival、KV 和 SLO 预测，考虑模型加载/compile/warm cache 延迟，不能只看 GPU utilization。
- 定义降级策略：降低 max output、切换量化/小模型、关闭低价值功能，且对调用方返回明确状态。
Q73. RL/后训练 Infra 为什么比普通 SFT 更复杂？
高分回答要点
- 同时存在 rollout inference、reward/critic、训练和数据处理，资源特征不同且要编排；生成端常受 decode 限制，训练端偏大 batch compute/communication。
- actor 权重持续更新，rollout worker 需要版本同步；必须定义 policy staleness、样本版本和 on-policy/off-policy 容忍度。
- colocate 可减少权重/KV 传输和空闲，但训练与推理争显存；disaggregate 易独立扩缩，却增加权重广播、队列和故障状态。
- 需要处理变长 episode、过滤/奖励、数据 lineage、可重复性、partial failure 和 backpressure。
- 指标包括 rollout tokens/s、训练 tokens/s、GPU idle、样本年龄、权重同步时间、队列深度、有效样本比例和最终 reward/time-to-quality。
追问：训练比 rollout 快或慢时，分别怎样动态分配 GPU？权重更新途中 worker 失败怎么保证版本可追踪？
Q74. 一次框架/驱动升级后性能和数值都发生变化，你如何组织发布？
高分回答要点
- 使用兼容矩阵和锁定镜像，先跑 kernel correctness、确定性/误差、单机性能、分布式 scaling、checkpoint restore 与真实 workload canary。
- 性能变化按 kernel selection、compile graph、collective algorithm、allocator 和数据路径分解；数值变化按 dtype、reduction 顺序、随机数、fused kernel 定位。
- 采用小规模/少数 job 灰度，保留自动 rollback 和旧 checkpoint 可读性；记录每个 artifact 的软件/硬件元数据。
- 若性能改善但 loss/质量不可比，不可发布；若平均快但尾延迟/故障率恶化，也要按用户目标决定。
- 事故后把最小复现、监控缺口和回归测试加入发布门禁，而不只写一次性复盘。