05-Chunked-Prefills 问题反馈 & 课后思考题

[cr7258]

课后思考题

• chunked-prefills 对 TTFT（首 token 延迟）和 TBT（token 间延迟）的影响是怎么样的？
• 为什么要限制每轮调度的 chunk size?
• stall-free scheduling 的调度逻辑是怎么样的？

[cr7258]

chunked-prefills 对 TTFT（首 token 延迟）和 TBT（token 间延迟）的影响是怎么样的？

chunked-prefill 会略微增加 TTFT。原因在于原本可以一次性完成的 prefill 操作被拆分为多个 chunk，每个 chunk 的处理都伴随额外的调度开销。此外，后续的 chunk 需要依赖并访问前面 chunk 生成的 KV cache，导致 KV cache 被多次读取，从而引入额外的内存访问开销。

chunked-prefill 可以显著减少 TBT 尾延迟（P99）。通过将 prefill 拆分为多个小块，并与 decode 请求共同组成混合批次（hybrid batch）执行，避免了传统 prefill 优先调度策略中导致的 generation stall，从而提升 token 生成的连续性和响应的稳定性。

尾延迟（Tail Latency）是指在所有请求延迟中最慢那一小部分的延迟表现，通常用 P95、P99 或 P99.9 等百分位数来衡量。
以最常用的 P99 为例，它表示在 99% 的请求中，响应延迟都低于该数值，也就是说，只有最慢的 1% 请求的延迟会超过这个值。P99 衡量的是在绝大多数情况下的最差响应延迟，常用于评估系统在高负载或边缘场景下的性能表现。

[cr7258]

为什么要限制每轮调度的 chunk size?

通过限制每轮调度的 chunk size，可以避免 prefill 干扰 decode，防止 generation stall 的发生。这是因为 prefill 相较于 decode 计算开销更大、延迟更高（尤其在 prompt 较长时）。若一轮调度中包含过多 prefill tokens，可能拖慢整个 batch 的执行，阻塞 decode 请求。适当限制 chunk size 能确保 decode 按节奏进行，从而降低 TBT 的尾部延迟，提升整体响应的流畅性。

可以通过对不同 chunk size 的 batch 进行 profiling，可以找到在满足 TBT 延迟目标的前提下，系统吞吐量最高的最优 chunk size。

[cr7258]

stall-free scheduling 的调度逻辑是怎么样的？

在实际调度过程中，Sarathi-Serve 会优先调度正在进行的 decode 请求，因为每个 decode 仅消耗一个 token，且对延迟最为敏感，调度器会根据 KV cache 的容量判断是否仍可继续添加 decode 请求。随后，系统会在剩余的 token 预算范围内处理尚未完成的 prefill 请求，优先填满一个 prefill 请求中的 token，再继续处理下一个，在预算允许的情况下可连续处理多个 prefill 请求。若仍有剩余 token 预算，则进一步接纳新的 prefill 请求加入当前批次。 系统会确保当前调度轮次中 decode 和 prefill 的 token 总数不超过预设的 chunk size。