跳到主要内容

面试实战话术

目录​

自我介绍类​

Q: 你做过分布式训练吗？具体用过哪些并行方式？​

满分回答：

我熟悉 3D 并行架构。用过基于 DDP/ZeRO 的数据并行解决数据和显存瓶颈；了解基于 Megatron 的张量并行（TP）处理单机内的大矩阵；也了解流水线并行（PP）处理跨机器的深层网络调度。在实际项目中，我曾针对 XX 规模的模型，设计过混合并行策略，在 XX 张 GPU 上实现了 XX 的 MFU。

分布式训练类​

Q: DDP 和 FSDP 的主要区别是什么？​

满分回答：

DDP 核心是全量参数复制，它通过 Ring-AllReduce 同步梯度，优点是速度快，缺点是模型不能超出单卡显存。FSDP（基于 ZeRO-3）是参数切片，模型被拆解到各个卡上，运算时实时 All-Gather 拿回来，算完丢掉，极大地省了显存，牺牲了一点网络通信。

Q: 为什么模型越大，通信问题越突出？​

满分回答：

第一，大模型的显存装不下，逼迫我们使用 TP 和 PP，这两种并行自身就带有海量的通信。第二，模型增大使单卡上的 Batch Size 被迫缩小，导致计算时间变短，无法有效 Overlap（掩盖）越来越大的参数同步通信时间。

Q: 流水线并行为什么会有 bubble？​

满分回答：

因为有依赖关系。GPU-2 必须等 GPU-1 算完前向才能开始算，这就造成了初期的气泡；同理反向传播时也要等后面的卡传回梯度。业界现在用 1F1B 交错调度机制，让前后向穿插，尽量把这段闲置时间填满。

Q: 如果 8 张卡扩到 64 张卡，吞吐上不去，你怎么分析？​

满分回答：

这是典型的扩展性折损问题。首先用 Nsight 看通信占比，64 卡跨机 RDMA 速度远不如机内 NVLink，可能全在等网络 All-Reduce；其次，看 Global Batch Size 有没有等比例放大，如果没有，单卡分到的数据少了，GPU 就吃不满了。

性能优化类​

Q: 你怎么判断一个训练任务的瓶颈在算力、通信还是数据？​

满分回答：

一看 top，CPU 满就是数据加载瓶颈；二看 Nsight Systems 的 Timeline：如果 GPU 呈现大块绿色的 Kernel 执行，就是算力瓶颈；如果大块红色的 NCCL Wait 或 cudaMemcpy，那就是通信或访存瓶颈。

Q: 混合精度为什么能提速？为什么有时候又会不稳定？​

满分回答：

FP16 将显存开销减半，并激活了 Tensor Core。但不稳定是因为 FP16 范围只有 6 万多，而且下限很高，前向计算时大激活值容易 Overflow（NAN），后向计算时极小的梯度容易 Underflow（变成 0）。通常得靠动态 Loss Scaling 来救，或者直接用范围更大的 BF16。

Q: 训练显存爆了，你会从哪些方向解决？​

满分回答（按优先级）：

  1. 调小 Batch Size + 开启梯度累积
  2. 开启 Activation Checkpointing（立竿见影）
  3. 提升 ZeRO 等级（Stage 2 升到 3）
  4. ZeRO-Offload（把优化器状态赶到 CPU 内存）
  5. 采用 FlashAttention 省略注意力矩阵显存

推理优化类​

Q: 什么是 Continuous Batching？为什么重要？​

满分回答：

传统 Static Batching 必须等最长的句子生成完毕，导致提前生成完的短句子对应的 GPU 算力空转。Continuous Batching 打破了请求级的边界，实现了 Token 级调度。当某个请求遇到 <EOS> 时，调度器会立刻将它踢出，并从等待队列中塞入新请求参与下一次 Token 的生成。它将 GPU 的吞吐量提升了数倍，是 vLLM、TensorRT-LLM 等现代推理引擎的标配。

Q: PagedAttention 解决了什么问题？​

满分回答：

LLM 解码时 KV Cache 随序列动态增大，传统框架按最大长度预分配连续显存，导致内部碎片和外部碎片，超一半显存被浪费。PagedAttention 借鉴操作系统虚拟内存分页机制，将 KV Cache 划分为固定大小的 Block，逻辑连续但物理离散存储，通过 BlockTable 记录映射。这彻底消除了外部碎片，让 GPU 能扛住 3-4 倍的并发请求。

Q: 为什么很多系统要做 PD 分离？​

满分回答：

Prefill（Compute-bound）和 Decode（Memory-bound）算力特征冲突。Prefill 是一次性处理长 Prompt，做 GEMM，能轻易打满 SM；Decode 每次只吐一个 Token，做 GEMV，算力利用率极低。如果把它们混部，新请求做 Prefill 时会瞬间抢占算力，导致正在 Decode 的请求被"卡住"，引起严重的尾延迟抖动。PD 分离将它们拆分到不同 GPU，保障了 P99 延迟的稳定性。

Q: 投机解码适合所有场景吗？​

满分回答（反套路）：

绝对不适合所有任务。投机解码是用小模型猜、大模型判，它产生收益的前提是"长输出"且"系统处于低并发状态（算力有富余）"。审核业务的输出通常极短（可能不到 10 个 Token），且线上通常是打满并发的高 QPS 状态。强行上投机解码，不仅小模型命中率没保证，它反而会挤占主模型的显存空间和带宽，导致整体吞吐量下降。

Q: 量化为什么能提速？为什么有些方案掉点厉害？​

满分回答：

LLM 推理（尤其是 Decode）是 Memory-bound，算力空转等待权重从 HBM 搬运。量化把数据体积缩减 2-4 倍，极大降低了访存延迟。掉点厉害是因为 LLM 参数量超过 6.7B 后，激活值中会出现极大量的 Outliers（异常极大值），朴素 PTQ 会截断这些值。解决办法是 SmoothQuant 或 AWQ。

系统设计类​

Q: 多模态训练和纯 LLM 训练相比，系统层面最大的差异是什么？​

满分回答：

差异在长序列内存管理和动态负载不均衡。比如高分辨率视频塞进来几万个 Token，极度吃 KV-Cache 显存；而且图文比例不一时，有些卡在处理轻量文本，有些在啃沉重的视频 ViT，很容易造成分布式同步时的短板卡顿。

Q: RL 训练为什么通常更难做效率优化？​

满分回答：

因为 RL（比如 PPO）不仅有训练引擎，更重度依赖推理引擎（Actor 生成经验）。生成需要极快的自回归解码能力，而训练需要高吞吐的梯度反向。把 vLLM 的生成能力和 DeepSpeed 的训练能力捏合在一个显存池里并且不冲突，工程难度极大。

Q: 如果让你做一个训练优化项目，你会怎么设计实验验证收益？​

满分回答：

控制变量法与 A/B Test。首先跑一个 Baseline 锚定 Loss 和 MFU。加入优化后，首先要验证**"数学等价性"**（在相同 seed 下跑到第 1000 步 Loss 是否能对齐小数点后三位）。如果正确，再去对比 Tokens/sec 的吞吐提升，以及通过 Profiler 证明瓶颈点真的被消除了。

价值观类​

Q: 吞吐最大化和工程稳定性哪个更重要？​

满分回答：

工程稳定性绝对优先。大集群一次崩溃或异常停机的财务成本极高（几十万算力费废掉）。不能稳定运行 24 小时的极致吞吐是毫无意义的，只有在保证容错、Checkpoint 健康的前提下，再去抠 MFU。

Q: 如何看待"先保证能训起来，再追求极致性能"？​

满分回答：

非常认同。分布式系统排错极其困难。先跑通小规模 Baseline，确保 Loss 正常收敛、梯度正确。在这个可复现的基础上，每次只引入一个优化（比如加 ZeRO，加融合算子），如果 Loss 对不上立刻回滚。这是顶尖 Infra 工程师的必修准则。

Q: 如果吞吐提升了 20%，但 P99 时延恶化了，你会怎么看？​

满分回答：

在商业审核场景下，这项优化大概率是不可接受的。吞吐提升 20% 只是省了一点机器成本，但 P99 恶化意味着在流量晚高峰时，有 1% 的广告无法在规定时效内过审，这会直接导致广告投放超时，损失客户体验和真实广告收入。我会去剖析为什么 P99 恶化，如果是 Batch Size 过大导致的，会尝试引入动态 Batching 阈值或快慢车道隔离，在保证 P99 绝对不劣化的红线之上，再去抠那 20% 的吞吐收益。

Q: 什么样的提升才算有"业务价值"？​

满分回答：

能够在不掉精度的前提下，切实降低大模型每 Token 训练成本（降低云账单）；代码侵入性低，算法工程师切换无痛；以及具备扩展性，模型参数量翻倍时该优化依然有效。

Q: 汇报训练优化成果展示的核心指标？​

满分回答：

  • 业务层：Time-to-converge（收敛时间）
  • 吞吐层：Tokens/sec/GPU 或 Samples/s
  • 系统层：MFU/HFU（模型算力利用率）
  • 稳定层：故障重启次数/持续运行时间 (Uptime)

面试技巧总结​

分层回答问题​

  1. 是什么 - 先给定义
  2. 为什么 - 解释原理/痛点
  3. 怎么做 - 具体方案
  4. 优缺点/Trade-off - 展现深度思考

多用对比和数字​

  • 不要只说"更快"，要说"提升了 3-4 倍"
  • 不要只说"省显存"，要说"从 X GB 降到 Y GB"

体现业务 Sense​

  • 技术优化要回归到业务价值
  • 强调稳定性、成本、用户体验

遇到不会的问题​

  1. 诚实承认不了解
  2. 尝试从相关知识点推导
  3. 表达学习意愿："这部分我了解不深，但我推测可能是...，面试后我会深入调研"