简报文章论文故事系列 v1 系列探索实践

31 · Sarathi-Serve — Chunked Prefill 免停滞调度

推理部署 Sarathi 2024
Agrawal et al., UC Berkeley · arXiv:2403.02310

迭代了什么

上一代的问题：All-or-nothing prefill：新请求必须完整 prefill（200-400ms）才能 decode，阻塞整个 batch。

这代改了什么：Chunked Prefill：长 prompt 切成小块与 decode 交错执行。四级优先级调度。

效果：吞吐 +65%，P99 延迟降低 40%，GPU 利用率 70% → 93%。已集成进 vLLM。

一、一句话总结

把长 prompt 的 prefill 阶段切成小块（chunk），与 decode 交错执行，彻底消除 head-of-line blocking。

二、解决的核心问题

LLM serving 中，prefill（并行计算，compute-bound）和 decode（逐个生成，memory-bound）的资源需求完全不同。传统调度做法是原子化 prefill——一个请求的 prefill 必须一次性全部做完，期间 decode 被阻塞。这导致 head-of-line blocking：一个长 prompt 请求的 prefill 让后面所有等待 decode 的短请求排队空等。

原子化 Prefill: |<--- prefill --->| decode | decode | ...
Chunked Prefill: |pre|dec|pre|dec|dec|pre|dec|...

三、核心创新

3.1 Chunked Prefill

将长 prompt 的 prefill 计算拆分为固定大小的 chunk（如 256 tokens），每生成完一个 chunk 就切换到 decode batch 或其他请求的 prefill chunk。

3.2 四级优先级调度

P0 - stall 告警：即将 stall 的请求（最高优先级）
P1 - decode：正在生成的请求
P2 - prefill chunk：长 prompt 的未完成 chunk
P3 - 新请求：尚未开始 prefill 的请求

3.3 统一 batch 执行

CPU scheduler 在每步迭代前决策：本轮 GPU 执行的是一个混合 batch（decode tokens + prefill chunk tokens），而不是纯 decode 或纯 prefill 的 batch。

四、具体效果

吞吐 +65%（vs 原子化 prefill 的 baseline）
P99 延迟降低 40%
GPU 利用率 70% → 93%
Tail latency 大幅改善，长 prompt 不再"惩罚"短请求

五、实现要点

5.1 Chunk 大小的影响

Chunk 越大，prefill 效率越高（因为 GPU 并行度高），但引入的延迟也越大。Chunk 越小，交错越细粒度，decode 响应越快。论文中推荐 256-512 tokens。

5.2 与 PagedAttention 的关系

Sarathi-Serve 的 chunked prefill 与 PagedAttention 正交互补：chunked prefill 解决调度层面的阻塞，PagedAttention 解决显存层面的浪费。两个可以叠加使用。

六、历史影响

Chunked Prefill 后来成为几乎所有主流推理引擎（vLLM / TensorRT-LLM / SGLang）的标准调度策略。Sarathi-Serve 的关键贡献是：明确指出了 prefill/decode 的资源冲突本质是调度问题，而非单纯的显存管理问题。