面试 · 岗位分支面试题

Checkpoint 产出 → Model Registry 注册（MLflow + 元信息）
→ Eval Pipeline 自动评测（Argo Workflows）
→ 准入门禁（评测达标 + 安全评测通过 + 备案材料就绪）
→ 灰度发布（网关层按比例分流：10% → 50% → 100%）
→ 全量上线（Registry 标记 production，老版本归档）
→ 持续监控（质量漂移检测 + 成本归因 + 效果劣化自动回滚）

触发器：新模型上传 → Argo Workflows DAG
  ├─ Step 1：部署临时推理实例（加载权重）
  ├─ Step 2：通用 Benchmark（MMLU、HumanEval、C-Eval）
  ├─ Step 3：业务专属评测（真实 prompt 集 + 自动评分 + 人工抽检）
  ├─ Step 4：安全评测（Prompt Injection、有害内容拒答率）
  ├─ Step 5：性能基准（TTFT/TPOT/QPS/显存 vs baseline）
  ├─ Step 6：合规评测（违法内容生成测试、敏感词检测）
  └─ Step 7：汇总 → 写入 Registry → 自动准入判定

灰度系统设计
├─ 灰度策略
│  ├─ 按比例（10% → 50% → 100%）
│  ├─ 按租户（先内部团队 → 再小客户 → 最后大客户）
│  └─ 按地域（先小地区 → 再大地区）
├─ 监控指标
│  ├─ 性能：TTFT/TPOT/P95 延迟不恶化
│  ├─ 质量：在线采样评估 + 用户反馈
│  └─ 错误率：5xx 不飙升
├─ 回滚机制
│  ├─ 网关层秒级切回老版本
│  ├─ Registry 标记新版本 rolled-back
│  └─ 保留最近 3 个 production 版本
└─ 自动化
   ├─ 效果劣化自动回滚（质量漂移 > 阈值）
   └─ 灰度推进需人工审批

基线建立（压测取 baseline）
↓
显存参数调优
├─ gpu-memory-utilization：0.9 → 0.92（多出并发槽位）
├─ max-model-len：从模型上限调到业务实际（8K-32K）
└─ 量化：FP16 → FP8（KV Cache 减半）
↓
调度参数调优
├─ max-num-seqs：256（高吞吐）/ 64（低延迟）
├─ max-num-batched-tokens：8192-16384
└─ enable-chunked-prefill：长上下文场景
↓
前缀优化
├─ enable-prefix-caching（vLLM）
└─ RadixAttention + schedule-policy lpm（SGLang）
↓
评估：TTFT/TPOT/QPS/P99 是否达标

LiteLLM Gateway（统一入口）
├─ 模型 alias：fast-small / fast-medium / smart / local-only
├─ Virtual Key 体系：每个业务线独立 Key + 配额
├─ 限流：RPM + TPM + 月度预算
├─ 熔断：连续失败 N 次进入冷却，自动切换 fallback
├─ 降级：fast-small → fast-medium → smart（容量降级）
│         context 超限 → 自动切大上下文模型
└─ 监控：Prometheus + Grafana + 成本报表

Dynamo 编排：
├─ 声明 prefill 节点组（高算力 GPU）+ decode 节点组（高显存带宽）
├─ Dynamo 自动分配请求：
│   ├─ prefill 请求 → prefill 节点
│   ├─ KV 自动传输到 decode 节点（400Gbps InfiniBand）
│   └─ decode 请求 → decode 节点（KV-aware routing）
├─ 动态调整：高峰期加 decode 节点
└─ 监控：prefill/decode 节点的负载 + KV 传输延迟

MoE 部署要点
├─ 引擎选择：SGLang（MLA/MoE 优化最深度，DeepSeek 官方推荐）
├─ 并行策略：TP + EP 组合
│  ├─ TP 切 attention 层（单机 NVLink 域）
│  └─ EP 切 expert 层（expert 分布到多卡）
├─ EPLB：必须开启，解决专家路由不均衡
├─ MLA：压缩 KV Cache，为 expert 权重腾显存
├─ 显存计算：全部 expert 权重都要加载（1.6T × 1 byte FP8 = 1.6TB）
└─ 监控：各 GPU 显存/SM 分布（EPLB 效果验证）

VLM 部署要点
├─ 结构：vision encoder（ViT）+ projector + LLM，图片先编码成 image token 再拼进 prompt
├─ 引擎：vLLM / SGLang 均支持主流 VLM（Qwen-VL / InternVL / Llama-Vision）
├─ 容量估算变了：
│  ├─ 一张高清图展开成几百~几千 image token → 按图像 token 重估 max-model-len 和显存
│  ├─ image token 一样进 KV Cache，长图/多图请求 KV 占用大
│  └─ 对高分辨率图设 token 上限，防单请求爆 KV
├─ 瓶颈：vision encoder 是独立 compute-bound 段，TTFT 里多一块视觉编码；
│        encoder 通常不与 LLM 一起 continuous batching → 易成独立瓶颈，可单独扩容/批处理
├─ 缓存：文本前缀可命中；图片只有"同一张图"按 hash 命中，多轮追问同图可复用视觉特征/KV
└─ 监控：分别看 encoder 段与 LLM 段耗时，别只看总 TTFT

Multi-LoRA 服务
├─ 场景：一个 base 模型 + 成百上千个 LoRA adapter（各业务/租户微调版），共享 base 权重与 KV 池
├─ 开启：--enable-lora --max-loras N --max-lora-rank R，请求里指定 adapter 名
├─ 显存管理：adapter 小（几十~几百 MB）可驻留很多；冷/热 adapter 按 LRU 动态换入换出
│  └─ S-LoRA 的 Unified Paging：统一显存池同时管 adapter 权重 + 不同长度 KV，减碎片
├─ 性能注意：
│  ├─ 同一 batch 混不同 adapter 靠异构批处理 kernel，混得太杂会掉 kernel 效率
│  ├─ max-loras（同时活跃 adapter 数）设太大增加调度/显存压力
│  └─ 高频 adapter 尽量常驻，避免频繁换入换出
└─ vs 独立部署：N 个满血实例 → 显存/成本爆炸；Multi-LoRA 边际成本接近单模型，适合多租户

资源池设计：
├─ Volcano 层级队列
│   ├─ root → ai-org（总配额 256 GPU）
│   ├── team-nlp（guarantee=64, weight=30）
│   ├── team-recommend（guarantee=64, weight=30）
│   ├── team-research（guarantee=32, weight=20）
│   └─ emergency（guarantee=16, weight=100, 不可抢占）
├─ PriorityClass：emergency > high > normal > low
├─ 借用机制：空闲队列资源可被其他队列借用（reclaimable）
└─ 碎片治理：binpack + anti-affinity

弹性伸缩方案
├─ 节点级弹性：Karpenter + Spot Instance
│  ├─ 按需拉起 GPU 节点
│  ├─ 空闲时自动释放
│  └─ Spot Instance 降本 60%
│
├─ Pod 级弹性：KEDA + GPU 指标
│  ├─ 按 vllm:num_requests_waiting 扩缩
│  ├─ minReplicas / maxReplicas
│  └─ scale-to-zero（低频模型）
│
├─ 调度级弹性：Volcano/Kueue 抢占
│  ├─ 紧急推理抢占实验训练
│  └─ 配合 checkpoint 机制
│
└─ 容量规划
   ├─ 历史数据预测增长
   ├─ 峰值前预扩容
   └─ 闲置回收

1. 看 NCCL 通信是否正常
   ├─ NCCL_DEBUG=INFO 确认拓扑
   ├─ 检查是否退化到 TCP
   └─ 检查错包数（> 0 立刻告警）
2. 看 GPU 状态
   ├─ nvidia-smi：显存、温度、功耗
   └─ DCGM：ECC 错误（不可修复 = 硬件故障）
3. 看训练日志
   ├─ loss NaN → 学习率/梯度爆炸
   ├─ OOM → batch size 太大 / gradient accumulation 不够
   └─ timeout → 某个 rank 慢了（straggler）
4. 看 CPU/内存
   └─ DataLoader 慢 → num_workers 不够 / I/O 瓶颈

MoE 训练优化
├─ 并行策略：4D 并行 = DP × TP × PP × EP
│  ├─ TP 切 attention 层（单机 NVLink 域）
│  ├─ PP 跨机（层间切分）
│  ├─ EP 切 expert 层（expert 分布到多卡）
│  └─ DP 扩吞吐（多副本）
│
├─ Expert 路由优化
│  ├─ 负载均衡 loss（防止路由倾斜）
│  ├─ Shared Expert（DeepSeek，保证基础计算）
│  └─ Top-K 路由（K=2 或 K=8）
│
├─ 通信优化
│  ├─ EP 的 all-to-all 通信（expert 路由分发）
│  ├─ 通信融合（多个小 all-to-all 合并）
│  └─ NVLink/RDMA 利用
│
└─ Checkpoint
   ├─ 全部 expert 权重都要保存
   └─ 恢复时 expert 到 GPU 的映射要一致

训练容错机制
├─ 节点故障自动恢复
│  ├─ 健康检查（DCGM ECC 错误 / NCCL 超时）
│  ├─ 故障节点隔离（cordon + drain）
│  └─ 从最近 checkpoint 恢复到新节点
│
├─ 抢占容忍
│  ├─ Volcano/Kueue 抢占前 preStop hook 保存 checkpoint
│  ├─ 低优先级任务可被抢占
│  └─ 恢复后继续训练
│
├─ Straggler 处理
│  ├─ 检测慢节点（NCCL timeout）
│  ├─ 排除慢节点继续训练（减少 worker 数）
│  └─ 或等待慢节点恢复
│
└─ 数据一致性
   ├─ 所有 rank 同步 checkpoint
   ├─ data loader 种子可重现
   └─ RNG 状态保存

1. Nsight Systems 抓全局 timeline
   ├─ 找 kernel launch 间隔大的地方（launch overhead）
   ├─ 找 CPU-GPU 同步点（不必要的 sync）
   └─ 找 H2D/D2H 拷贝（数据传输瓶颈）

2. Nsight Compute 分析热点 kernel
   ├─ Occupancy 低 → 调整 block/grid size
   ├─ Memory throughput 低 → 优化访存模式
   ├─ Bank conflict → 调整 shared memory 布局
   └─ Stall reasons → 对症优化

3. CUDA Graph 消除 launch overhead
   └─ decode 阶段小 batch，launch overhead 占 20-40%

不融合：
  AllReduce 1 → 计算 → AllReduce 2 → 计算 → AllReduce 3
  
融合后：
  AllReduce(1+2+3) → 计算
  （多个小 AllReduce 合并为一次大 AllReduce）

收益：
  ├─ 减少 NCCL launch 次数
  ├─ 提高网络利用率（大包比小包效率高）
  └─ 减少 sync 开销

评估维度：
├─ 吞吐：同一 batch 下的 tokens/s
├─ 延迟：TTFT/TPOT P50/P95/P99
├─ 显存：同等并发下的显存占用
├─ 精度：同一批 prompt 的输出差异（ROUGE/BLEU/人工评估）
├─ 成本：每 1M token 的等效成本（算力租金 + 功耗）
└─ 稳定性：长时运行的波动/内存泄漏

方法：
1. 用同一版本模型权重
2. 用同一批真实业务 prompt
3. 同等并发压测 1 小时+
4. 对比关键指标，生成对比报告

多芯混部架构
├─ 统一 API 层（OpenAI Compatible）
│  └─ 业务侧无感知底层芯片类型
│
├─ 多芯路由层
│  ├─ 按模型可用性路由（某些模型只在特定芯片上部署）
│  ├─ 按成本路由（便宜芯片优先）
│  └─ 按延迟路由（低延迟芯片优先）
│
├─ 芯片池
│  ├─ 英伟达 GPU 池（vLLM/SGLang）
│  ├─ 昇腾 NPU 池（vllm-ascend/MindIE）
│  └─ 海光 DCU 池（ROCm + vLLM）
│
└─ 监控
   ├─ 各芯片池的 QPS/延迟/成本
   └─ 故障切换（某芯片池故障 → 切到其他池）

算子缺失处理流程
├─ 1. 确认算子是否真的缺失
│  ├─ 查 CANN 算子库文档
│  └─ 用 msprof profiling 确认
│
├─ 2. 替代方案
│  ├─ 用已有算子拼接实现（如用 matmul + element-wise 拼出某个 fused 算子）
│  ├─ 换等价的数学表达（如 SiLU → Sigmoid × mul）
│  └─ 降级到等价但不优的实现
│
├─ 3. 自定义算子
│  ├─ 用 CANN 的 Ascend C 开发自定义算子
│  └─ 注册到 torch_npu
│
├─ 4. 提交需求
│  ├─ 向华为提交算子需求
│  └─ 等待下一个 CANN 版本
│
└─ 5. 临时绕过
   └─ 该层回退到 CPU 计算（性能差但能跑）