面试 · 场景排查型

TTFT 突然升高
├─ 检查 prompt 平均长度是否变长
│  └─ 是 → 业务侧 prompt 膨胀，考虑 Chunked Prefill
│
├─ 检查 KV Cache 命中率是否下降
│  └─ 是 → Prefix Cache 是否被禁用？system prompt 是否引入了动态字段？
│
├─ 检查 GPU 算力是否被抢占
│  └─ 是 → 是否有其他 prefill 任务抢占了 GPU？PD 分离可解决
│
├─ 检查 queue length 是否增加
│  └─ 是 → 请求排队，扩容或加限流
│
├─ 检查 batch size 是否过大
│  └─ 是 → 调小 max-num-batched-tokens
│
└─ 检查是否有长 prompt 请求堵死 batch
   └─ 是 → 开启 Chunked Prefill

TPOT 变慢
├─ 检查显存带宽是否饱和
│  └─ DCGM_FI_DEV_MEM_COPY_UTIL > 90% → decode 太多，扩容
│
├─ 检查 batch 是否太大
│  └─ max-num-seqs 设太大 → 单个 forward 太慢 → 调小
│
├─ 检查 GPU 是否降频
│  └─ DCGM_FI_DEV_SM_CLOCK 下降 → 温度/功耗限制 → 查散热
│
├─ 检查 KV Cache 读取量是否增大
│  └─ 上下文变长 → KV Cache 读取耗时增加 → 考虑 MLA/FP8 KV
│
└─ 检查是否开启了不必要的功能
   └─ 如 log-requests 全开 → 关闭

GPU 利用率 < 40% 但请求慢
├─ 可能是显存带宽瓶颈
│  └─ 查 DCGM_FI_DEV_MEM_COPY_UTIL，如果高 → Decode 瓶颈（不是算力瓶颈）
│
├─ 可能是 CPU 瓶颈
│  └─ tokenizer 慢 → 增加 --tokenizer-pool-size
│  └─ 数据预处理慢 → 优化 Python 代码
│
├─ 可能是网络瓶颈（如 KV 传输）
│  └─ PD 分离场景 → 查跨节点 NIC 带宽
│
├─ 可能是 batch 太小喂不饱 GPU
│  └─ 提高 max-num-batched-tokens
│
└─ 可能是 kernel launch overhead
   └─ 小 batch 下 launch overhead 占比高 → 开启 CUDA Graph

显存占用高但 QPS 低
├─ 检查 max-model-len 是否设太大
│  └─ 机制见 3-Q14：KV 池大小由 gpu-memory-utilization 决定，**不随 max-model-len 撑大**
│  └─ 设大主要抬高启动 profiling 预留 + 放行超长请求瞬间吃掉大块 KV；别把"调小它"当省显存主手段
│  └─ 按业务真实需求设（99% 场景 8K-32K）
│
├─ 检查 gpu-memory-utilization 是否留太多 margin
│  └─ 默认 0.9 → 调高到 0.92
│
├─ 检查是否有显存碎片
│  └─ PyTorch caching allocator 碎片 → export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
│
├─ 检查是否加载了不必要的 LoRA/模型
│  └─ 卸载不用的 LoRA adapter
│
└─ 检查 KV Cache 使用率
   └─ > 90% → KV 池子快满，新请求进不来 → 加 GPU 或降 max-model-len

Queue Length 持续 > 10
├─ 检查 num_running_requests 是否接近 max-num-seqs
│  └─ 是 → 并发槽位已满，需要扩容实例
│
├─ 检查 KV Cache 使用率
│  └─ > 90% → KV 池子快满，新请求进不来
│  └─ 加 GPU 或降低 max-model-len
│
├─ 检查是否有异常长请求（如 128K prompt）
│  └─ 长请求长期占 slot → 限流 + Chunked Prefill
│
├─ 检查是否有请求超时没释放
│  └─ 客户端不消费 streaming → 连接未关闭 → 检查客户端实现
│
└─ 检查是否扩容不及时
   └─ HPA/KEDA 未触发 → 检查扩缩指标和阈值

Streaming 中断
├─ 客户端侧
│  ├─ HTTP 连接超时 → 调整 client timeout
│  ├─ SSE 重连逻辑有 bug → 检查客户端重连实现
│  └─ 客户端主动断开 → 用户切走或关闭页面
│
├─ 服务端侧
│  ├─ vLLM/SGLang 进程异常重启 → 查 Pod 日志
│  ├─ OOM → 查显存是否被打满
│  └─ max_tokens 达到上限 → 检查是否设太小
│
└─ 网络侧
   ├─ 中间代理（Nginx/Ingress）超时 → 调整 proxy_read_timeout
   ├─ 代理 buffering → 关闭 proxy_buffering
   └─ 负载均衡器空闲超时 → 调整 idle_timeout

路由不均衡
├─ 检查路由策略
│  └─ simple-shuffle → 可能碰巧分布不均，换 usage-based-routing
│
├─ 检查是否有模型在 cooldown
│  └─ allowed_fails > 阈值 → 模型被冷藏 → 调整熔断阈值
│
├─ 检查各模型资源配置是否对称
│  └─ 模型 A 的 max-num-seqs=256，模型 B 的 =64 → 容量不对等
│
├─ 检查是否有业务绕过路由直接调特定模型
│  └─ 审计日志里按 model 维度查 QPS 分布
│
└─ 检查 model alias 配置
   └─ alias 指向单一模型而非多模型轮询

Fallback 频繁触发
├─ 检查主模型是否不稳定
│  └─ 错误率是否升高 → 查主模型的日志/GPU 状态
│
├─ 检查超时时间是否太短
│  └─ timeout=30 → 长 prompt 可能在 prefill 就超过 30s
│
├─ 检查 allowed_fails 和 cooldown 配置
│  └─ allowed_fails=1 → 一次抖动就触发 → 调大到 3-5
│
├─ 检查 fallback 目标模型是否还能承受
│  └─ fallback 模型可能被打爆 → 监控 fallback 模型的 QPS
│
└─ 检查主模型是否在灰度
   └─ 灰度版本不稳定 → 暂停灰度或回滚

成本升高
├─ 按模型维度查 Spend → 找到哪个模型成本飙升
├─ 按 Team/Key 维度查 → 找到哪个业务线
├─ 按 token 类型查 → input 涨还是 output 涨
├─ 定位场景：
│  ├─ input token 涨 → prompt 膨胀或调用量上升
│  ├─ output token 涨 → max_tokens 设大了或回复变长
│  └─ RPM 涨 → 恶意调用或业务爆发 → 查审计日志
├─ 检查是否有闲置 GPU
│  └─ DCGM 利用率 < 20% 持续 30min → 回收或 scale-to-zero
└─ 检查是否用了更贵的模型
   └─ 路由配置变更导致流量流向贵模型

专家路由不均衡
├─ 确认是 MoE 模型（DeepSeek/Mixtral）
├─ 查各 GPU 的显存使用率分布
│  └─ 差异大（如某卡 95%，某卡 25%）→ 路由不均
├─ 开启 EPLB（Expert Parallelism Load Balancer）
│  └─ 动态重映射 expert 到 GPU
├─ 检查是否所有 expert 都加载了
│  └─ 某些 expert 未分配到任何 GPU
├─ 检查 EP 拓扑配置
│  └─ expert 分配策略是否合理
└─ 长期方案：调整 EP 拓扑 + 监控 expert 级负载

PD 分离 KV 传输瓶颈
├─ 检查跨节点网络带宽
│  └─ NIC 流量是否打满 → DCGM + NIC metrics
│
├─ 检查 KV 传输格式
│  └─ 是否可以用 FP8 KV Cache 减少传输量（减半）
│
├─ 检查 prefill/decode 节点比例
│  └─ prefill 太少 → KV 产生量 > 消费量，堆积
│
├─ 检查 KV-aware routing 是否生效
│  └─ 请求是否被路由到已有缓存的 decode 节点
│
├─ 检查 NCCL/RDMA 是否退化到 TCP
│  └─ NCCL_DEBUG=INFO 看 Channel 类型
│
└─ 检查 KV 传输是否同步阻塞
   └─ 改为流式传输（prefill 边算边传）

冷启动超时
├─ 模型加载时间：70B 模型约 3-5 分钟
├─ 优化方案：
│  ├─ 权重预缓存到本地 NVMe（不从 NFS 加载）
│  ├─ keep-warm 至少 1 副本（不完全 scale-to-zero）
│  ├─ startupProbe 给足够时间（failureThreshold > 60）
│  ├─ 客户端 timeout 匹配（不要 30s 就超时）
│  └─ 预热请求（启动后先发一个短 prompt 预热 KV Cache 和 CUDA Graph）
├─ 检查权重加载源
│  └─ 从 NFS/EFS 加载慢 → 改为本地 NVMe
└─ 权衡：不完全 scale-to-zero vs 冷启动延迟

长上下文拖慢
├─ 确认瓶颈：128K prompt 的 prefill 吃光 GPU 算力
├─ 分级 KV 方案：
│  ├─ 开启 LMCache/HiCache
│  ├─ 确保系统 prompt 稳定 → L1/L2 命中
│  ├─ 配置 KV-aware routing → 请求路由到缓存节点
│  └─ 目标：命中率越高、可复用前缀越长，省下的 prefill 越多（比例视前缀占比而定，别套固定百分比，见 3-Q12）
├─ 配合 Chunked Prefill 防止单请求堵死 batch
├─ 按上下文长度分流：长上下文单独集群 / 单独引擎
└─ 限流：对超长 prompt 设上限或单独队列

灰度效果变差
├─ 立即措施：回滚到上一 production 版本（网关切流量）
├─ 排查：
│  ├─ 评测是否通过？→ 检查 Eval Pipeline 结果
│  ├─ 是否量化版本精度损失？→ 对比 FP16 vs INT4 输出
│  ├─ 是否 tokenizer 不一致？→ 检查是否用错 tokenizer
│  ├─ 是否 prompt 需要适配新模型？→ system prompt 调整
│  └─ 是否 KV Cache 命中率下降？→ system prompt 变了导致缓存失效
└─ 长期方案：完善评测流水线（安全评测 + 业务 benchmark + 在线采样）

KV Cache 命中率 < 30%
├─ 检查 system prompt 是否稳定
│  └─ 是否包含时间戳、随机 ID 等动态内容
│  └─ 把动态字段移到 user message，system prompt 固定
├─ 检查请求的前缀是否真的相同
│  └─ 是否有多个 system prompt 版本混用
├─ 检查 prefix cache 是否被禁用
│  └─ --enable-prefix-caching 是否开启
├─ SGLang 检查 schedule-policy
│  └─ 应该是 lpm（longest prefix match）
└─ 检查 radix tree 是否因并发飙升大面积淘汰
   └─ 预扩容避免缓存过期

vLLM 启动失败
├─ 检查 Pod 日志
│  ├─ CUDA OOM → 模型太大，TP size 不够或 gpu-memory-utilization 太高
│  ├─ 模型文件不存在 → 检查权重路径和 PVC 挂载
│  ├─ tokenizer 加载失败 → tokenizer 文件不匹配
│  └─ 端口冲突 → 检查 --port 配置
│
├─ 检查 GPU 资源
│  └─ nvidia.com/gpu request 是否满足
│  └─ GPU 节点是否有足够显存
│
├─ 检查 TP size 配置
│  └─ TP size 必须能被 num_attention_heads 整除
│  └─ TP size > 单机 GPU 数 → 需要跨机 + Ray
│
├─ 检查模型文件完整性
│  └─ safetensors 文件是否下载完整
│  └─ config.json 是否正确
│
└─ 检查软件栈版本
   └─ vLLM / PyTorch / CUDA 版本是否兼容

模型加载慢
├─ 检查权重存储位置
│  ├─ NFS/EFS → 慢（网络带宽限制）→ 改为本地 NVMe
│  └─ 对象存储 → 慢（下载）→ 预同步到本地
│
├─ 检查权重精度
│  └─ FP16 140GB → FP8 70GB（加载量减半）
│
├─ 检查加载方式
│  └─ 单线程加载 → 多线程加载（VLLM_WORKER_MULTIPROC_METHOD=spawn）
│
├─ 检查磁盘 IO
│  └─ NVMe 读取速度 < 1GB/s → 硬件问题或 RAID 配置
│
└─ 检查是否有 lazy loading
   └─ 按需加载权重（vLLM 0.6+ 支持）

租户调用量异常
├─ 查审计日志 → 是正常业务爆发还是异常
│  ├─ 正常业务爆发 → 临时提升配额
│  └─ 异常（bug/恶意）→ 限流或封禁 Key
│
├─ 检查 Virtual Key 配额
│  └─ rpm_limit / tpm_limit 是否生效
│  └─ 未配限流 → 立即配置
│
├─ 检查是否有死循环调用
│  └─ Agent 重试逻辑 bug → 客户端修复
│
├─ 检查是否绕过网关直调
│  └─ 审计日志 vs 引擎侧 QPS 对比
│
└─ 评估对其他租户的影响
   └─ 资源争抢 → 限流保护 + 扩容

推理 OOM
├─ 检查模型权重 + KV Cache 是否超过显存
│  └─ 权重固定；KV 池按 gpu-memory-utilization 预分配且封顶（≠ max_model_len × 并发，见 3-Q14）
│  └─ 真正主杠杆：降 gpu-memory-utilization / 量化 / 加 TP；max-num-seqs 限并发，max-model-len 仅抬启动预留
│
├─ 检查 gpu-memory-utilization 是否过高
│  └─ 0.95+ → 留 buffer 不足，降到 0.90
│
├─ 检查是否有显存碎片
│  └─ PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
│
├─ 检查是否加载了多个模型/LoRA
│  └─ 卸载不必要的模型
│
├─ 检查是否量化
│  └─ FP16 → FP8 显存减半
│
└─ 检查 TP size 是否足够
   └─ 单卡装不下 → 增大 TP size

NCCL 通信失败
├─ 启动 hang 在 ncclCommInitRank
│  ├─ 检查 NCCL_SOCKET_IFNAME → 是否选到虚拟网卡（docker0/calico）
│  ├─ 检查防火墙 → 跨节点端口是否放通
│  └─ 检查 Ray 集群 → ray status 是否正常
│
├─ 运行中错包
│  ├─ 查 ibstat / ibv_devinfo → IB 链路是否正常
│  ├─ 查交换机日志 → 是否有 CRC 错误
│  └─ 检查 GPU Direct RDMA 是否开启
│
├─ 性能退化（掉速 50%+）
│  ├─ NCCL_DEBUG=INFO 看 Channel 类型 → 是否退化到 TCP
│  ├─ 检查 NCCL_IB_DISABLE → 是否误设为 1
│  └─ 检查 NCCL_P2P_LEVEL → 单机是否走 NVLink
│
└─ 跨机 TP 掉速
   └─ 跨机 TP 不推荐，改用 PP（跨机）+ TP（单机内）