你们的推理服务高峰期出现两个现象：(a) GPU 利用率只有 35%；(b) 一个 4000 token 的长输入请求进来后，同时在线的短对话请求 TPOT 从 25ms 抖到 200ms。当前配置是 static batching，batch=16、max_seq_len=4096，调度器每 100ms 组一批。请诊断这两个现象的共同根因，给出改造方案，并说明改造后你要盯哪些指标来判断改对了。
面试官在考什么
判断是否理解 static batching 的 padding 与组批等待浪费，以及长 prefill 与 decode 混批时阻塞 decode 的机制——也就是 chunked prefill 的动机与代价。
回答框架 · 前两步
- 共同根因是静态组批：按固定 100ms 窗口和最长时间组批，短请求为长请求 padding 买单（浪费算力 → 利用率低）；长 prefill 又和所有 decode 挤在同一批里执行（单个 iteration 耗时暴涨 → TPOT 抖动）。
- 改造一：continuous batching（iteration-level scheduling），每个 decode step 结束就回收已完成序列、补进新请求，消除 100ms 空等和 padding。
还有 3 条答案要点、 3 层追问、 5 个常见坑， 以及针对你简历的追问路径，在定制报告里。
同一能力域的其他题
- 解释一下 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 两个业务上带来的收益分别体现在哪里、哪个业务上收益相对不明显，为什么。