大模型推理变慢时，如何从序列长度、batch、KV Cache、量化、FlashAttention 和 GPU 资源排查？｜高频面试题解析

60 秒回答模板

我会先把慢定义清楚：是 TTFT 变高、每 token 延迟变高、吞吐下降、P99 变差，还是某些长 prompt 或高并发场景才变慢。然后按链路拆开排查。第一层看服务侧排队和调度，确认是不是请求堆积、batch 过大、动态 batching 等待时间过长或优先级策略导致。第二层拆 prefill 和 decode：prefill 主要受输入长度、attention 计算、FlashAttention 是否生效和显存带宽影响；decode 每步生成一个 token，更受 batch 内活跃序列数、KV Cache 读写、调度和采样开销影响。第三层看 KV Cache，确认是否命中 prefix cache，是否因为上下文过长、并发过高或显存碎片导致 cache eviction、分页开销或 OOM 回退。第四层看 batch 和序列分布，过小 batch 会让 GPU 吃不满，过大 batch 会增加排队和单请求延迟，长短请求混在一起也会造成尾延迟。第五层看模型和算子：量化是否真的用了高效 kernel，FlashAttention 或 fused kernels 是否匹配当前 shape、dtype 和硬件，是否存在 CPU 后处理或 tokenizer 成为瓶颈。最后用 profiler 和线上指标验证：GPU utilization、memory bandwidth、SM occupancy、显存占用、cache hit rate、tokens/s、TTFT、TPOT 和 P95/P99。修复后要做质量回归，因为量化、截断和 batching 策略可能改变输出质量或稳定性。

考点 先量化症状

难度 真实面经题

回答目标 让候选人能给出一条从指标定义到瓶颈定位、从 prefill/decode 到 KV Cache/batching/kernel/GPU 证据、再到回归验证的 LLM 推理慢排查链路。

深入解析

先定义慢的症状

推理慢不是一个指标。TTFT 高说明首 token 前的排队、tokenize、prefill 或调度可能有问题；TPOT 高说明 decode 阶段逐 token 生成慢；吞吐低可能是 GPU 没吃满；P99 高可能是长请求、cache 抖动或调度不公平。先分症状，后面排查才不会乱。

先排服务队列和请求分布

很多慢不是模型算子慢，而是请求在队列里等。要看并发量、动态 batching 等待窗口、batch size、优先级、限流、流式响应 flush、上游重试和长短请求比例。若 TTFT 高但 GPU 利用率不高，可能是调度、tokenizer、网络或服务框架阻塞，而不是 attention kernel。

prefill 主要受输入长度影响

prefill 要处理完整 prompt，标准 attention 对序列长度非常敏感。prompt 越长，计算和显存越重，尤其多轮历史、RAG 长上下文、多图 token 或模板冗余会直接推高 TTFT。排查时要统计输入 token 分布，而不是只看平均值；少量超长请求往往决定 P99。

decode 主要受活跃序列和 KV 读写影响

decode 每一步只生成新 token，但要读取历史 KV Cache，并对 batch 中未结束的序列反复调度。生成长度、停止条件、采样策略、batch 内长短不齐、beam 或多候选都会影响 TPOT。若输出很长，即使 TTFT 正常，用户仍会感到整体响应慢。

KV Cache 要看命中、容量和布局

KV Cache 能避免重复计算历史，但它占用大量显存。要检查 prefix cache 是否命中，cache 是否因上下文过长或并发过高被频繁淘汰，paged cache 是否碎片化，GQA/MQA 是否降低了 KV 容量压力，以及显存不足时是否触发 offload、重算或更慢路径。

batch 不是越大越好

增大 batch 可以提高 GPU 吞吐，但会增加排队时间和单请求延迟。batch 太小 GPU 利用率低，batch 太大 P99 变差；长短请求混批还会让短请求等待长请求。需要区分吞吐目标和交互式延迟目标，用动态 batching、continuous batching、优先级和最大 token 预算平衡。

量化和 FlashAttention 要确认真实生效

量化不一定必然更快，如果 kernel 不匹配、反量化开销大、batch/shape 太小或瓶颈在内存和调度，收益会很有限。FlashAttention 也要求 dtype、head dim、mask 形式、硬件和框架路径匹配。排查时要看实际 kernel trace，而不是配置里写了就默认生效。

GPU 指标要和 profiler 对齐

GPU utilization、SM occupancy、memory bandwidth、显存占用、kernel 时间、CPU-GPU 同步、H2D/D2H 拷贝都要一起看。GPU 利用率高但 tokens/s 低可能是内存带宽或低效 kernel；GPU 利用率低可能是 CPU tokenizer、网络、调度、锁或 batch 不足。profiler 能把猜测落到证据上。

优化后要做质量和稳定性回归

截短 prompt、改 batch、开启量化、换 attention kernel、调整 cache 策略都可能影响输出质量、确定性、OOM 风险和尾延迟。上线前要比较 TTFT、TPOT、吞吐、显存、错误率和任务质量，避免用质量或稳定性换表面速度。

易错点

一上来就说用量化、FlashAttention 或 vLLM，没有先定位慢在 TTFT、TPOT、排队还是 P99。
只看平均延迟，不看输入 token、输出 token、并发和长尾分布。
把 batch size 越大越好当成定律，忽略排队时间和交互式延迟。
认为 KV Cache 只会加速，不会带来显存容量、碎片、eviction 和 offload 问题。
配置里打开 FlashAttention 或量化就默认生效，没有查看实际 kernel trace。
忽略 CPU tokenizer、后处理、网络 flush、日志和上游重试等非 GPU 瓶颈。
通过截断上下文或激进量化提速后，没有做输出质量和稳定性回归。
用单条短 prompt 的本地测试代表线上高并发、长上下文和混合请求场景。

面试官追问

TTFT 很高但生成速度正常，优先查什么？

优先查排队、tokenizer、prompt 长度、prefill attention、prefix cache 命中和动态 batching 等待时间。TPOT 正常说明 decode 路径可能没问题。

GPU 利用率低就一定是模型太小吗？

不一定。可能是 batch 太小、请求断续、CPU tokenizer 或后处理慢、网络 flush 阻塞、调度锁竞争、频繁 CPU-GPU 同步，也可能是服务限流让 GPU 等请求。

量化后为什么可能没有变快？

量化收益依赖高效 kernel 和合适 shape。如果反量化开销大、kernel 不支持、batch 太小、瓶颈在 KV Cache 读写或服务调度，延迟可能不降甚至上升。

FlashAttention 对 decode 也总是收益很大吗？

不一定。FlashAttention 对长序列 prefill 常常更明显；decode 每步 query 长度很短，瓶颈可能转向 KV 读写、batch 调度或采样。需要分 prefill 和 decode 看 profiler。

如何处理长短请求混在一起导致的 P99 问题？

可以按输入长度或预估 token 预算分桶，限制单 batch 最大 token 数，对短交互请求设优先级，使用 continuous batching，并对超长请求做单独队列、摘要或异步策略。