真实面经题目 · 原创解析
LLM 推理中 Continuous Batching 和 Prefix Caching 如何影响请求切分、batch 维度和吞吐/延迟取舍?
这题考 LLM 推理调度中的 Continuous Batching 和 Prefix Caching,回答重点是请求在 prefill/decode 阶段如何切分、按什么维度组 batch,以及吞吐和延迟如何取舍。
真实面经题目 · 原创解析
这题考 LLM 推理调度中的 Continuous Batching 和 Prefix Caching,回答重点是请求在 prefill/decode 阶段如何切分、按什么维度组 batch,以及吞吐和延迟如何取舍。
Continuous Batching 解决的是 LLM 推理请求长度和到达时间不一致导致 GPU 利用率低的问题。传统静态 batch 要等一批请求一起跑完,短请求会被长请求拖住;Continuous Batching 会在每个 decode step 或调度周期动态加入新请求、移除完成请求,让 GPU 持续有活干。Prefix Caching 解决的是多个请求共享相同系统提示、历史上下文或文档前缀时,重复计算 prefill 的浪费,可以复用已算好的 KV cache。请求切分通常按 prefill 和 decode 分开:prefill 计算量大、可并行 token 多,decode 每步 token 少但要反复调度。batch 维度要看 token 数、KV cache 显存、序列长度、优先级、到达时间、prefix 命中率和 SLA。取舍是:更大的动态 batch 提高吞吐,但可能增加排队和单请求延迟;更激进的 prefix cache 提高复用,但会消耗显存和带来缓存管理复杂度。
LLM 推理不是一个均匀计算过程。prefill 阶段处理完整 prompt,计算量和输入 token 数相关,能较好并行;decode 阶段每次生成一个或少量 token,需要反复读写 KV cache,单步计算小但调度频繁。Continuous Batching 和 Prefix Caching 都要围绕这两个阶段设计。
静态 batch 会让同一批请求一起开始、一起等待最慢请求结束,造成 GPU 空转和队头阻塞。Continuous Batching 在每个调度周期把已结束请求移出,把新请求插入,把不同生成进度的请求放在同一轮 decode 中执行,从而提升吞吐。
LLM 推理真正受限的往往是 token 数、显存、KV cache、序列长度和调度步数。一个 batch 里请求数相同,prompt 长度和输出长度不同,成本可能差很多。因此调度要看总 token、最大序列长度、剩余生成长度、优先级和 SLA,而不是只数请求个数。
很多请求共享系统提示、工具说明、few-shot 示例、会话历史或同一文档前缀。Prefix Caching 把这些前缀的 KV cache 保存下来,后续请求命中时可以跳过重复 prefill 的一部分,降低首 token 延迟和 GPU 计算。
Prefix Cache 不是免费收益。缓存占用 GPU 或主机内存,需要哈希匹配、生命周期管理、淘汰策略和隔离策略。长前缀、高复用、高成本场景收益大;短前缀、低复用或多租户敏感场景可能不值得缓存。
Continuous Batching 可以提高整体吞吐,但调度窗口过大可能让新请求等待;prefix 复用可以降低 prefill 成本,但缓存管理会增加复杂度。优秀回答要能说出按 token 预算、显存预算、优先级、prefix 命中率和 SLA 做调度,而不是只背两个名词。
因为 LLM 请求到达时间、prompt 长度和输出长度差异大。动态加入和移除请求可以减少等待最慢请求造成的 GPU 空转。
主要省掉共享前缀的 prefill 计算,并复用对应 KV cache。后续新增 token 和 decode 仍然需要继续计算。
因为请求数相同但 token 长度、KV cache 占用和 decode 步数可能完全不同。调度更应该按 token 和显存预算来约束。
会。调度窗口、优先级和队列策略会影响排队时间,所以要在吞吐提升和 P95/P99 延迟之间做权衡。