在线推理服务，请求长度长尾严重：输入 p50 800 token、p99 24K，输出 p50 200、p99 3K。已经用了 continuous batching，max_num_seqs=256，但实测 GPU 利用率只有 60%，P99 TTFT 高达 8s。请诊断原因并给出方案，同时说明为什么不能靠简单调大或调小 batch 解决。
面试官在考什么
能否识别 prefill 与 decode 在同批中互相干扰的本质，并在调度、部署架构、SLA 分级上给出系统性方案，而不是把 batch size 当唯一旋钮。
回答框架 · 前两步
- 诊断结论：长 prefill 和 decode 混在同一批里，一个长 prefill 就把整个 step 时间拉长，decode 的 ITL 被拖垮；新请求又在队列里等，TTFT 恶化；batch 内长短请求互相拖累，所以利用率也上不去。
- 方案一 chunked prefill：把长 prefill 切片与 decode 交错，控制单 step 计算量，代价是实现复杂、需要按 ITL 目标调 chunk size。
还有 3 条答案要点、 3 层追问、 4 个常见坑， 以及针对你简历的追问路径，在定制报告里。
延伸阅读
想看这个方向的整体准备路线？ 进入「AI Infra 与 Harness 工程」方向页
同一能力域的其他题
- 解释一下 KV Cache 是什么、为什么能加速推理，以及它带来的显存代价怎么算。
- 推理服务里 continuous batching 和静态 batching 有什么区别？为什么前者吞吐更高？
- 模型量化你了解哪些方案？训练后量化（PTQ）和量化感知训练（QAT）怎么选？量化后精度掉了怎么定位？
- 显存优化除了量化还有哪些手段？请按"省的是什么"把它们分类。
- 线上大模型服务的延迟怎么拆解？哪些部分你能优化、哪些是硬上限？
- 你有单卡 A100 80G，要上线一个 7B decoder-only 模型，同时承接两个业务：业务 A 是长 prompt（约 4k tokens）短输出（约 100 tokens）的摘要，业务 B 是短 prompt（约 200 tokens）长输出（约 1k tokens）的代码补全。团队让你在 vLLM 和 TensorRT-LLM 之间二选一。请给出你的选择和判断依据，并具体说明 PagedAttention 在 A、B 两个业务上带来的收益分别体现在哪里、哪个业务上收益相对不明显，为什么。