真实面经题目 · 原创解析

LLM 推理中 Continuous Batching 和 Prefix Caching 如何影响请求切分、batch 维度和吞吐/延迟取舍?

这题考 LLM 推理调度中的 Continuous Batching 和 Prefix Caching,回答重点是请求在 prefill/decode 阶段如何切分、按什么维度组 batch,以及吞吐和延迟如何取舍。

出现于:阿里巴巴 · C/C++

60 秒回答模板

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 提高复用,但会消耗显存和带来缓存管理复杂度。

考点 动态批处理
难度 真实面经题
回答目标 讲清推理调度和吞吐/延迟取舍

深入解析

01

先区分 prefill 和 decode

LLM 推理不是一个均匀计算过程。prefill 阶段处理完整 prompt,计算量和输入 token 数相关,能较好并行;decode 阶段每次生成一个或少量 token,需要反复读写 KV cache,单步计算小但调度频繁。Continuous Batching 和 Prefix Caching 都要围绕这两个阶段设计。

02

Continuous Batching 动态维护活跃请求

静态 batch 会让同一批请求一起开始、一起等待最慢请求结束,造成 GPU 空转和队头阻塞。Continuous Batching 在每个调度周期把已结束请求移出,把新请求插入,把不同生成进度的请求放在同一轮 decode 中执行,从而提升吞吐。

03

batch 不是只按请求数切

LLM 推理真正受限的往往是 token 数、显存、KV cache、序列长度和调度步数。一个 batch 里请求数相同,prompt 长度和输出长度不同,成本可能差很多。因此调度要看总 token、最大序列长度、剩余生成长度、优先级和 SLA,而不是只数请求个数。

04

Prefix Caching 复用共享前缀计算

很多请求共享系统提示、工具说明、few-shot 示例、会话历史或同一文档前缀。Prefix Caching 把这些前缀的 KV cache 保存下来,后续请求命中时可以跳过重复 prefill 的一部分,降低首 token 延迟和 GPU 计算。

05

缓存命中和显存占用要平衡

Prefix Cache 不是免费收益。缓存占用 GPU 或主机内存,需要哈希匹配、生命周期管理、淘汰策略和隔离策略。长前缀、高复用、高成本场景收益大;短前缀、低复用或多租户敏感场景可能不值得缓存。

06

吞吐和延迟取舍是面试关键

Continuous Batching 可以提高整体吞吐,但调度窗口过大可能让新请求等待;prefix 复用可以降低 prefill 成本,但缓存管理会增加复杂度。优秀回答要能说出按 token 预算、显存预算、优先级、prefix 命中率和 SLA 做调度,而不是只背两个名词。

易错点

  • 把 Continuous Batching 说成普通把请求凑一批,没有说明动态加入和移除。
  • 没有区分 prefill 和 decode,导致无法解释请求切分和调度依据。
  • 只按请求数谈 batch 大小,忽略 token 数、序列长度和 KV cache 显存。
  • 把 Prefix Caching 说成复用最终答案,而不是复用共享前缀的 KV 计算结果。
  • 只讲吞吐提升,没有讨论排队延迟、优先级和 SLA。
  • 忽略多租户隔离、缓存淘汰、prefix 哈希匹配和缓存污染风险。

面试官追问

Continuous Batching 为什么比静态 batch 更适合 LLM?

因为 LLM 请求到达时间、prompt 长度和输出长度差异大。动态加入和移除请求可以减少等待最慢请求造成的 GPU 空转。

Prefix Cache 命中后省掉的是什么?

主要省掉共享前缀的 prefill 计算,并复用对应 KV cache。后续新增 token 和 decode 仍然需要继续计算。

batch 维度为什么不能只按请求数?

因为请求数相同但 token 长度、KV cache 占用和 decode 步数可能完全不同。调度更应该按 token 和显存预算来约束。

动态 batch 会不会影响单请求延迟?

会。调度窗口、优先级和队列策略会影响排队时间,所以要在吞吐提升和 P95/P99 延迟之间做权衡。