AI Infra 高频问题¶

回答技术问题时用“定义 → 为什么 → 关键路径 → 权衡 → 验证”的结构，通常比堆术语更有说服力。

训练¶

DDP 和 DataParallel 有什么区别？¶

DDP 通常是一进程一设备，通过 process group 做梯度同步，可跨节点；DataParallel 是单进程多线程/多设备的封装。PyTorch 官方推荐 GPU 训练优先使用 DDP。回答时补充：DDP 不负责自动切分输入，用户通常配合 DistributedSampler。

DDP 为什么要做 all-reduce？¶

每个 rank 在不同 mini-batch 上得到局部梯度。all-reduce 聚合梯度并让所有 rank 获得一致结果，随后各 rank 独立执行同样的 optimizer step，模型副本保持一致。bucket 允许梯度计算与通信重叠。

FSDP 解决什么问题？代价是什么？¶

它分片参数、梯度和优化器状态，降低单 rank 常驻显存；计算前后通过 all-gather/reduce-scatter 取回和重新分片。代价是通信、wrap/checkpoint/恢复复杂度和潜在 CPU 内存峰值。

TP、PP、DP 怎么选？¶

模型单卡能放下先考虑 DP；状态放不下用 FSDP；单层或整体仍太大时引入 TP/PP。把通信敏感的 TP 放在节点内快互连域，跨节点做 DP 是常见起点，但最终由拓扑与 profile 决定。

为什么 GPU 多了扩展效率会下降？¶

计算分摊变小而通信/同步相对变大；straggler、网络拓扑、数据供给和 global batch/算子形状也会改变。用 step breakdown、per-rank timeline、collective 带宽和 scaling efficiency 验证。

GPU 与通信¶

GPU utilization 95% 是否表示性能很好？¶

不一定。它可能只表示采样窗口内 kernel 经常活跃。还要看 SM/Tensor 活跃、显存带宽、kernel 效率、功耗、通信等待，以及端到端 tokens/s 或 step time。

PCIe、NVLink、RDMA 分别是什么角色？¶

PCIe 是通用设备互连；NVLink/NVSwitch 提供 GPU 间更高带宽的专用互连；RDMA 让网络设备以低 CPU 参与访问远端内存，GPUDirect RDMA 可在满足条件时直接连接 NIC 与 GPU 内存路径。回答要落到拓扑和数据路径，不只比较标称带宽。

NCCL hang 怎么查？¶

先找首个异常 rank，确认 collective 序列与 tensor shape 一致；再查进程/GPU/NIC 健康和网络。用单机/跨机 nccl-tests 将底层通信与模型代码隔离，避免只调大 timeout。

推理¶

TTFT 和 TPOT 的区别？¶

TTFT 是到首 token，主要包含接入、排队和 prefill；TPOT/ITL 描述首 token 后生成速度，主要受 decode 调度与资源影响。两者需要独立 SLO。

KV Cache 为什么会限制并发？¶

自回归解码为每层保存历史 token 的 Key/Value，容量随层数、KV heads、head dim、token 数、并发和数据类型增长。显存还要容纳权重与 workspace；达到上限后请求会排队、抢占/重算或 OOM。

Continuous batching 为什么提升吞吐？¶

不同请求输出长度不一，静态 batch 要等最慢请求。Continuous batching 在每个调度步加入新请求、移除完成请求，提高活跃槽位利用率；代价是调度复杂性以及吞吐与单请求延迟权衡。

为什么不能只按 GPU 利用率自动扩容？¶

利用率可能高但队列稳定，也可能利用率不高却因长 prompt 或显存/KV 限制导致延迟。LLM 扩容还存在模型加载滞后；应结合 queue time/depth、running/waiting sequences、token rate、TTFT/TPOT 与预测余量。

Kubernetes 与稳定性¶

Kubernetes 如何调度 GPU？¶

厂商 Device Plugin 向 kubelet 注册并上报扩展资源，例如 nvidia.com/gpu；scheduler 根据 Pod 的 limits 与节点 allocatable 放置。GPU 扩展资源是整数、默认不可超卖，request/limit 有特定规则。

Readiness、liveness 和 startup probe 如何分工？¶

startup 防止慢启动期间被过早判死；readiness 决定是否接流量；liveness 检测无法自愈的卡死并重启。模型“进程起来”不代表权重已加载和 warmup 完成，readiness 应覆盖真正可服务状态。

如何为 LLM 服务定义 SLO？¶

按输入/输出长度或请求类别限定工作负载，分别定义 TTFT、TPOT、E2E、错误与可用性；用 goodput 表示满足 SLO 的有效产出。只给总体平均延迟会掩盖长尾和混合流量。

如何控制 Prometheus 指标基数？¶

label 只放有界、可枚举且确实用于聚合的维度，例如 model/revision/status。request ID、user ID 和 prompt 放在 trace/log，并做采样和敏感数据治理。

设计题回答骨架¶

遇到“设计一个多租户 LLM 平台”时：

1. 澄清模型规模、流量、SLO、租户、安全与预算。
2. 画请求数据面：gateway、admission、router、scheduler、worker、cache。
3. 画控制面：模型 registry、发布、扩缩、配额、调度、回滚。
4. 做显存、token 与故障余量的容量账。
5. 定义隔离、权限、限流和供应链安全。
6. 定义 SLI、告警、trace、故障演练和降级。
7. 说明从简单方案演进的触发条件，避免一次性过度设计。

易混淆术语¶

官方资料入口¶

• PyTorch Distributed Overview
• Kubernetes GPU Scheduling
• vLLM Documentation
• Prometheus Instrumentation