考察点
这是一道开放工程题，面试官想看的是排查方法论而不是手段清单：会不会先把延迟拆段（排队、prefill、decode、网络传输），用数据定位瓶颈，再对症下药。只背"上量化、上 vLLM"的是低分答案；能讲清"什么症状对应什么层的问题、验证手段是什么"才是高分。追问通常挑你提到的某个手段往深挖，或者给一个具体场景让你现场分析。
参考答案
第一步永远是拆段定位
LLM 请求的端到端延迟 = 排队时间 + TTFT（prefill）+ TPOT × 生成长度 + 网络传输。四段的优化手段完全不同，混在一起谈就是瞎猜。上线观测必须把这几个指标分开打点（P50/P95/P99），看到"延迟高"先问：是 TTFT 高还是 TPOT 高？是平均值高还是只有 P99 高？
- TTFT 高、GPU 利用率也高 → prefill 算力不足或 prompt 太长；
- TTFT 高、GPU 利用率不高 → 排队问题，调度或容量的事；
- TPOT 高 → decode 本身慢，batch 过大、模型太大或带宽不足；
- P99 毛刺 → 队头阻塞、长 prompt prefill 打断 decode、KV 换出抖动。
排队层：最常见也最便宜
高并发下延迟大头往往是排队而不是计算。手段：合理设 max batch size 和请求队列上限，超了快速失败而不是干等（用户等 30 秒拿到 429 比等 30 秒超时强）；按业务优先级分级队列；容量规划按 P95 流量而不是均值流量配。这一层不动模型不动硬件，先把调度理顺。
Prefill 层：TTFT 的主战场
- Prefix caching：system prompt、few-shot 示例这类公共前缀的 KV 缓存复用，多轮对话和固定模板场景命中率极高，TTFT 可降一个量级，vLLM 开启 APC 即可。
- Chunked prefill：长 prompt 切块插入 decode 间隙计算，消除对在线请求的队头阻塞，P99 立竿见影。
- Prompt 瘦身：业务侧往往有大头——RAG 塞了过多 chunk、system prompt 又臭又长。输入 token 数直接决定 prefill 成本，砍 prompt 是最便宜的优化。
- PD 分离：长上下文高并发场景把 prefill 拆到独立集群，TTFT 和 TPOT 分开保障。
Decode 层：TPOT 的主战场
- 投机采样：低并发延迟敏感场景 2-3 倍 TPOT 收益，高并发吞吐优先时别开。
- 量化：W4A16 减少每步要搬的权重，decode 是 memory-bound，带宽省多少延迟就降多少，注意验证精度。
- 换更小的模型 / 蒸馏：延迟的终极优化是模型本身。很多业务 7B 微调后不比 70B 差，先质疑"是不是真的需要大模型"。
- 控制生成长度：max_tokens 设合理上限，prompt 里引导模型简洁作答；输出 token 数是延迟的乘数，生成砍半延迟砍半。
- batch 别贪大：超过拐点后 TPOT 陡增，吞吐和延迟要按 SLO 平衡。
网络与应用层：容易被忽视的一环
- 流式输出（SSE）：不减少总耗时，但把用户的感知延迟从"端到端"变成"TTFT"，体验优化性价比之王，对话场景必上。
- 就近部署与专线：跨地域调 API 光网络 RTT 就几百毫秒；客户端到网关、网关到推理集群的每一段都要看。
- 连接复用：网关到推理服务 keep-alive，避免每个请求重建 TLS 连接。
- 并发调用拆分：应用层能并行的别串行，比如 RAG 的多路召回和 LLM 调用的依赖关系梳理清楚。
给个排查顺序
拿到"延迟高"的工单，我的顺序是：看 TTFT/TPOT 拆分 → 看 GPU 利用率和 KV Cache 占用 → 看队列长度 → 对比输入输出长度分布是否漂移。八成的问题在这一轮就能定位到层，然后才是上手段、灰度、验证。盲目换框架换量化，大概率优化错了地方。
可能的追问
- 用户抱怨"半天没反应"，但你看监控 GPU 很闲，可能是什么原因？ 排队：调度器 batch 上限太保守、长 prefill 阻塞、或前置网关限流；GPU 闲而 TTFT 高基本指向调度与排队，不是算力问题。
- 量化和投机采样都能降延迟，什么时候选哪个？ 量化省显存带宽，任何并发都有收益但要验精度；投机采样用算力换延迟，只在低并发有效。能两个一起上，但先量化（普惠）再看是否需要投机。
- 输入 8k 输出 100 的摘要业务延迟高，优先做什么？ TTFT 主导，优先 prefix caching（若有固定前缀）、chunked prefill、PD 分离；decode 段只占 100 个 token，优化 TPOT 收益小。