Sarathi-Serve 完全拆解：分块 Prefill 与无停顿批处理如何兼顾吞吐和尾延迟

分块不等于截断上下文#

设一个提示共有 $L$ 个 token，被切为 $K$ 个 chunk，边界满足：

第 $k$ 个 chunk 包含位置 $[s_{k-1},s_k)$ 的 query。对其中位置 $i$，因果注意力仍必须看到从 0 到 $i$ 的全部 key 和 value：

$q_i$、$k_j$、$v_j$ 分别是位置 $i$ 的 Query 与位置 $j$ 的 Key、Value，$d_h$ 是单个注意力头的维度。chunk 只限制本轮新生成哪些 query，不会把可见上下文限制在 chunk 内。因此它不是滑动窗口，也不会改变注意力语义。

处理第 $k$ 个 chunk 时，系统已经把前 $k-1$ 个 chunk 的 K/V 写入分页 KV Cache。本轮先为新 token 计算 Q/K/V，再让新 query 读取“历史页面 + 当前 chunk 页面”，执行带因果掩码的注意力。最后一个 Prefill chunk 完成后，整段提示的 KV Cache 与一次性 Prefill 应当一致，随后才能采样第一个输出 token。

线性层、归一化和逐 token MLP 对序列位置没有跨 token 依赖，天然可以分块；真正需要特殊处理的是注意力与位置元数据。执行引擎必须为每个序列携带：已经处理的提示长度、本轮 chunk 长度、绝对位置、KV block table 以及最后一个页面的有效长度。若绝对位置从零重新计数，RoPE 会错误；若注意力只读取当前 chunk，模型则等价于周期性失忆。

为什么总 FLOPs 近似不变，显存流量却增加#

一次性因果 Prefill 的注意力打分数约为三角形面积：

分块后，每个 query 仍与完全相同的历史 key 集合计算点积，所以数学上的注意力乘加数仍为 $C_{\text{full}}$。分块没有像重复计算整段前缀那样把 FLOPs 变成 $K$ 倍。

额外成本来自历史 KV 的重复装载。为了看清这一点，先假设 $L=Kc$ 且每个 chunk 都为 $c$。第 $k$ 轮要读取前面 $(k-1)c$ 个 token 的历史 KV，累计历史读取 token 数为：

这并不是额外计算，而是原本一次大注意力 kernel 内可以更好复用的数据，现在跨多个 kernel 边界反复从 HBM 取回。第一个 chunk 的 KV 会在后续 $K-1$ 轮被访问，第二个 chunk 会再访问 $K-2$ 轮，依此类推。chunk 越小，轮数 $K$ 越大，重复读取、kernel launch 和元数据准备的固定成本越明显。

但线性层的权重开销呈相反趋势。只要一个混合批的总 token 数足够大，Prefill chunk 与 Decode 可以共同摊销同一套权重读取，使原本带宽受限的 Decode 获得更多有效计算。Sarathi-Serve 的收益正来自两类成本的交换：接受适量的 KV 重读与启动开销，换取更稳定的 TBT、更高的 Decode 批利用率和更均匀的流水微批。

混合批不是把两类注意力强行做成同一个形状#

Prefill 和 Decode 虽能共享模型的一次逐层执行，但它们的注意力形状不同：Prefill 请求有多个 query，Decode 请求各有一个 query；每个请求的历史长度也不同。实现通常先把线性层输入在 token 维拼成一个 ragged batch，再通过 offset 数组和 block table 把注意力拆回各自的序列。

以官方开源实现为例，执行器分别构造 Prefill 与 Decode 的 qo_indptr、kv_page_indptr、kv_page_indices 和 kv_last_page_len。qo_indptr 描述每个请求在扁平 Query/Output 张量中的起止位置，KV 元数据则描述其分页缓存。线性层可对拼接后的 token 做大 GEMM，注意力 kernel 仍按请求边界读取正确的 KV 页面。因而“混合”发生在适合共享的算子上，“隔离”保留在必须按序列处理的注意力上。

这也解释了为什么 token budget 只是近似的工作量单位。两个批即使 token 总数相同，若序列历史长度、Prefill/Decode 比例、KV 页面碎片和并行配置不同，注意力成本仍可能不同。固定预算能显著收窄单轮延迟分布，却不能从数学上保证每轮耗时完全相等。

一个 512-token 预算的例子#

假设当前有 80 个活跃 Decode 请求，还有两个未完成 Prefill：P 已剩 300 token，Q 已剩 900 token。预算 $\tau=512$。

1. 先放入 80 个 Decode token，剩余预算 432。
2. 若 P 的优先级更高，给 P 分配 300 token，剩余 132。
3. Q 本轮只获得 132 token，批总量正好为 512。
4. 下一轮仍先放入所有活跃 Decode；P 完成 Prefill 后会转入 Decode，Q 再继续下一个 chunk。

这个例子说明“一个批只放一个 Prefill chunk”是解释机制时常用的简化。论文算法允许在预算内接纳一个或多个 Prefill chunk，官方实现也可把剩余预算依次给多个请求；真正不变的是 Decode 优先和总 token 上限。若把“恰好一个 chunk”当作硬规则，就会误解短提示与最后一个残块的调度行为。

为什么不能只设 max batch size#

max batch size 限制的是序列条数，不限制每条序列本轮贡献多少 token。64 个 Decode 请求只产生 64 个 token，而 1 个完整 Prefill 请求可能产生 8000 个 token；两者都只占一个“请求槽”，工作量却相差两个数量级。token budget 直接约束前向中的 token 数，因此比 request count 更接近 GPU 工作量。

它仍不完美：注意力复杂度与上下文长度相关，MoE 路由会改变每个 token 的专家负载，多模态编码器还有独立成本。生产调度器可以在 token budget 之上加入 cost model，但 Sarathi-Serve 的贡献在于先找到一个足够简单、可测量、又能消除最严重 Prefill 尖峰的控制变量。

先从 TBT SLO 反推预算#

设离线 profile 得到批执行时间函数 $T(n_p,n_d,\ell)$，其中 $n_p$ 是本轮 Prefill token 数，$n_d$ 是 Decode token 数，$\ell$ 概括各请求上下文长度。给定 P99 TBT 目标 $S_{\text{TBT}}$，理想预算应满足：

实际系统很难直接拟合完整高维分布。论文采用一次性 profiling，并借助 Vidur 模拟器，在候选预算中选择不违反 TBT SLO 且容量最大的值。工程上可以先固定模型、精度、TP/PP 拓扑和注意力后端，扫描 max_num_batched_tokens，记录每种 Prefill/Decode 比例下的 P50、P95、P99 迭代时间，再用线上轨迹复核。

只看平均时间会犯两个错误。第一，长上下文 Decode 读取更多 KV，成本高于短上下文 Decode；第二，最后一个 Prefill 残块和多个短 Prefill 拼接会改变 ragged batch 形状。预算应当对目标流量分布做尾部校准，而不是拿单一方阵 GEMM benchmark 代替。

太小的 chunk 为什么会拖慢 Prefill#

预算变小时，完整提示需要更多轮才能完成，TTFT 包含更多调度、kernel launch、通信与 KV 元数据准备。前文推导的历史 KV 重读也随 chunk 数增加。论文在 Yi-34B、两张 A100、TP=2 上测得：chunk size 512 相比不切分的 Prefill，最坏约增加 25% 的 Prefill 时间；chunk size 2048 的额外开销则几乎可忽略。

注意，这个 25% 不是通用常数。FlashAttention 版本、Paged KV 布局、GQA 的 KV 头数、上下文长度和 GPU 代际都会改变重读与计算的比例。模型使用 MQA/GQA 时历史 KV 字节数下降，小 chunk 的重读惩罚可能减轻；但若 kernel 对小 query 块支持不好，启动和 tile 利用率又可能主导。

257 为什么可能比 256 慢 32%#

GPU GEMM 以 tile 为单位分配 thread block。若 token 维正好是 tile 大小的整数倍，最后一个 block 可以满载；若多出一个 token，就可能再启动一整排 block，其中绝大多数 lane 做无效工作。论文报告的极端例子是 chunk size 257 相比 256 可使 Prefill 时间增加 32%。

因此预算并不是连续可调的光滑旋钮，而是带有性能台阶。候选值应优先从 128、256、512、1024、2048 等与 kernel tile、分页块和 CUDA Graph 捕获尺寸对齐的集合中选择，再通过实测确定。官方仓库的动态 chunk 代码也把候选尺寸对齐到 32 的倍数；这不是模型语义要求，而是硬件执行形状要求。

Decode 数增大时，Prefill 余量会自动缩小#

固定 $\tau$ 并不意味着每轮都有 $\tau$ 个 Prefill token。活跃 Decode 数 $D_t$ 上升时，Prefill 可用预算为：

这形成了一种天然反馈：系统输出压力大时优先保持流式生成；Decode 请求少时，空余预算自动转给 Prefill。若 $D_t\ge\tau$，仅靠固定预算就无法让所有 Decode 在一轮内推进，调度器必须扩大预算、限制并发序列数、改变 SLO，或在多副本之间重新分流。

更进一步，稳定性要求长期 Prefill 到达工作量不能超过可分配余量。以每秒迭代数 $f$ 粗略估算，Prefill 服务能力约为：

若到达流量带来的平均 Prefill token 率持续高于 $\mu_p$，等待队列仍会发散，哪怕每个运行请求的 TBT 都很好看。因此 token budget 解决的是批内干扰，不替代准入控制、负载均衡和容量规划。

图源：Sarathi-Serve 论文图 9(a)。图中比较纯 Decode、混入完整 Prefill、混入固定预算 Prefill chunk 的相对单轮成本。完整 Prefill 会使小 Decode 批的迭代时间陡增；固定 chunk 把增量限制在较窄范围，而且随着 Decode batch 增大，新增 Prefill 的相对成本下降。

实验口径比最高倍数更重要#

论文评测了四种模型与多种拓扑：Mistral-7B 在单张 A100 上，Yi-34B 使用两张 A100 做 TP=2，LLaMA2-70B 使用八张 A40 做 TP=4、PP=2，Falcon-180B 使用两台各四张 A100 的服务器做 TP=4、PP=2，节点间为 100 Gbps Ethernet。工作负载来自两个真实长度分布：

这组数据揭示了一个重要边界：文章摘要任务的输入明显更长，Prefill 干扰更强，但输出较短。若用“固定 512 输入、固定 128 输出”的合成请求复现，很可能低估分块的价值，也看不到长提示对 P99 TBT 的伤害。

论文定义的 capacity 不是不顾延迟的最大 tokens/s，而是在 P99 TBT SLO 下仍能稳定服务的最大 queries/s，同时要求中位调度延迟不超过 2 秒，避免用无限排队制造虚假的设备利用率。严格/宽松 P99 TBT 目标依模型而异：Mistral-7B 为 0.1/0.5 秒，Yi-34B 为 0.2/1 秒，LLaMA2-70B 与 Falcon-180B 为 1/5 秒。

在严格 SLO、Yi-34B、openchat_sharegpt4 上，Sarathi-Serve 相比 Orca 可承载最高 4.0 倍负载，相比论文当时的 vLLM 可达 3.7 倍。对使用流水并行的大模型，LLaMA2-70B 在同一工作负载下相对 Orca 最高 6.3 倍、相对 vLLM 最高 4.3 倍。这里的“倍数”同时包含尾延迟不再先违规与流水空泡减少，不能解释为某个 kernel 快了 4 倍。

图源：Sarathi-Serve 论文图 12。横向比较时要保持模型和 SLO 相同。Mistral-7B 在 100 ms 严格 SLO 下，512-token 预算的 Sarathi-Serve 相比 vLLM 容量提高 3.5 倍；Yi-34B 在 1 秒宽松 SLO 下，2048-token 预算仍提高 1.65 倍。预算随 SLO 放宽而增大，说明性能来自可控地交换 Prefill 效率与 TBT，而不是一个配置统治所有负载。

消融实验说明两项机制缺一不可#

论文在两张 A100 上运行 Yi-34B，用 128 个请求和 1024-token 预算，分别关闭分块或混合批：

仅混合批的 TTFT 较好，因为新请求能快速整体进入，但长 Prefill 仍把 P99 TBT 拉高。仅分块能保护 TBT，却把 Prefill 拆成多轮且没有利用混合批的互补资源，TTFT 明显变差。两者结合后，TTFT 接近仅混合批，P99 TBT 又优于仅分块。这组消融比“容量提高数倍”更能证明设计因果链。

流水并行收益来自方差，不只来自均值#

跨节点 TP 每层都需要 AllReduce，慢网络会直接进入 Decode 关键路径；PP 只在 stage 边界传激活，更适合把 TP 限制在单节点内。但 PP 怕微批时长不均：一个 stage 遇到长 Prefill，其他 stage 处理短 Decode，就会出现空泡。

在两节点、8 张 A100、Falcon-180B 的实验中，TP=8 的纯 Decode 中位 TBT 比节点内 TP=4、跨节点 PP=2 高 2 倍以上。换成混合并行后，普通 vLLM 在严格 SLO 下又受 Prefill 方差影响；Sarathi-Serve 通过统一 token budget 把微批时长拉齐，相比 vLLM 的同类混合并行配置，宽松 SLO 下容量提高 1.48 倍，严格 SLO 下提高 3.6 倍。

所以分块 Prefill 对 PP 的价值不是“让每个微批平均更快”，而是降低微批执行时间方差。流水线利用率近似取决于最慢 stage 和微批间不平衡，削掉长尾往往比缩短平均值更重要。

结果不能直接外推到今天的任意框架#

论文基线反映 2024 年的 vLLM 与 Orca 实现。今天的 vLLM 已在官方文档中支持 chunked prefill，并允许用 max_num_batched_tokens 调节 TTFT、ITL 与吞吐。因此，“Sarathi-Serve 比 vLLM 高 3.7 倍”不能表述成对当前最新版 vLLM 的普遍结论；更准确的技术遗产是：Sarathi-Serve 系统化证明了分块 Prefill、Decode 优先混合批和 token budget 的价值，这些思想随后进入主流推理引擎。

Sarathi-Serve 选择共置，而 P/D 分离选择隔离#

Sarathi-Serve 把 Prefill 与 Decode 放在同一模型副本、同一组 GPU 上，通过混合批利用两者的资源互补。DistServe、Splitwise 等 P/D 分离系统则把两个阶段放到不同 GPU 池：Prefill 池针对计算密集型大批量优化，Decode 池针对内存容量、带宽和稳定 TPOT 优化，Prefill 完成后把 KV Cache 传给 Decode 池。

两条路线解决的是同一个干扰问题，但支付不同代价：

短提示、请求规模不大或只有一组 GPU 时，P/D 分离的 KV 传输与资源碎片可能得不偿失，共置加分块更直接。超长上下文、高并发、严格的 TTFT/TPOT 双 SLO 或需要独立扩缩容时，物理分离能提供更强隔离。两者也不是互斥的：Prefill 池内部仍可对超长输入分块，Decode 池也需要连续批处理；分离解决池间耦合，分块解决单池内长任务的粒度问题。

P/D 分离的关键成本可以粗略写成：

$S_{\text{KV}}$ 是该请求已经生成的 KV Cache 大小，$B_{\text{net}}$ 是有效网络带宽，其余项分别对应序列化、排队和在 Decode 端注册缓存。若 $T_{\text{handoff}}$ 接近甚至超过一次 Prefill 干扰造成的延迟，分离不一定有利；若 KV 可经 RDMA 高速传输且两个阶段的资源需求长期失衡，分离更容易提高集群 goodput。

Sarathi-Serve 与今天的 vLLM 是思想继承关系#

Sarathi-Serve 官方仓库最初从 vLLM 分叉，补上分块 Prefill、混合调度、流水并行和遥测。它是研究原型，仓库也明确说明功能并不与完整 vLLM 对齐。评估论文时，应把“论文时点的 vLLM 基线”和“当前 vLLM”分开。

当前 vLLM V1 官方文档说明：chunked prefill 在条件允许时默认启用；调度器先放入所有待执行 Decode，再用 max_num_batched_tokens 的剩余预算安排 Prefill，放不下的 Prefill 自动切块。这与 Sarathi-Serve 的核心原则高度一致。官方调优建议同样呈现相同权衡：较小预算改善 ITL，较大预算改善 TTFT 与吞吐。

因此，在现代 vLLM 中应用这篇论文，通常不是部署一个独立的 Sarathi-Serve 服务，而是理解以下配置背后的系统含义：

1
from vllm import LLM
2

3
llm = LLM(
4
    model="meta-llama/Llama-3.1-8B-Instruct",
5
    max_num_batched_tokens=8192,
6
    max_num_seqs=256,
7
)

max_num_batched_tokens 控制每轮 token 工作量，max_num_seqs 控制并发序列及 KV Cache 压力。前者太小会增加 Prefill 轮数和 TTFT，太大可能伤害 ITL；后者太大会让 Decode token 本身吃满预算，还可能触发 KV 抢占。二者必须联合扫描，不能只调一个数字。

站内的vLLM Scheduler 源码拆解介绍了 V1 如何在统一 token budget 下处理分块 Prefill、前缀命中与抢占；Sarathi-Serve 提供的是这套调度逻辑背后的性能动机与经典实验证据。

先验证数值与状态正确性#

分块 Prefill 最危险的错误往往不会崩溃，而是悄悄改变输出。实现至少要验证：

• 同一提示在一次性 Prefill 与不同 chunk size 下，第一个 token 的 logits 在允许的浮点误差内一致。
• RoPE 或其他位置编码使用全局绝对位置，不随 chunk 重置。
• 当前 chunk 的因果 mask 正确，既能看到全部历史，又不能看到本 chunk 内的未来位置。
• KV block table 在跨轮追加、抢占、恢复和最后一个非整块页面时保持一致。
• 采样只发生在完整 Prefill 结束后，而不是每个 chunk 末尾。

浮点归约顺序可能因 kernel 形状变化而改变，bitwise 相等通常不是合理目标。应比较 logits 的绝对/相对误差、固定随机种子下的贪心输出，以及长上下文边界位置的结果。若只跑短提示，位置偏移和跨页错误很容易漏掉。

观测四层指标，而不是只盯 GPU 利用率#

第一层是用户延迟：P50/P95/P99 TTFT、TBT/ITL、端到端延迟，以及满足双 SLO 的请求比例。第二层是队列稳定性：到达率、排队时间、等待队列长度与被准入拒绝的请求数。第三层是调度器状态：每轮 Prefill/Decode token 数、chunk 分布、活动序列数、抢占和重计算次数。第四层是 GPU 与并行效率：HBM 带宽、SM/Tensor Core 利用率、kernel launch 间隙、NCCL 时间和流水空泡。

“GPU utilization 99%”并不代表服务健康：一个 16K 完整 Prefill 可以让 GPU 满载，同时把所有 Decode 卡住。相反，较小预算可能略降吞吐，却显著提高 SLO 内 goodput。对在线系统，目标函数应写成：

$S_f$ 与 $S_b$ 分别是 TTFT 和尾部 TBT 目标，$\Delta t$ 是测量窗口。只有两个约束都满足的请求才计入有效吞吐。

一套可复现的调参顺序#

1. 固定模型、精度、注意力后端、TP/PP 拓扑和 KV Cache 容量，避免多变量同时变化。
2. 用真实 prompt/output 长度联合分布回放流量，而不是只用固定长度合成请求。
3. 从与 kernel tile 对齐的预算集合开始扫描，例如 512、1024、2048、4096、8192；同时扫描 max_num_seqs。
4. 对每个点逐步提升到达率，直到 P99 TBT、TTFT 或排队稳定性首先违规。
5. 画出 goodput—TTFT—TBT Pareto 前沿，并记录 Prefill 分块开销、抢占次数和显存余量。
6. 对白天/夜间、聊天/文档摘要等不同流量簇分别验证；若最优点差异很大，再考虑动态预算或分池路由。

预算调优应以服务曲线为单位，而不是一次 microbenchmark 的峰值。Prompt P90 从 2K 变成 20K 后，同一预算的 KV 重读、TTFT 和队列稳定性都会变化；GPU 从 A100 换到 H100/B200 后，计算与带宽比、tile 形状和 kernel 路径也会改变。

不能被固定 token budget 解决的问题#

第一，极端 Decode 并发可能占满预算，使 Prefill 饥饿。需要准入控制、优先级老化或为 Prefill 保留最小份额。第二，固定 token 数不能精确代表成本；长历史注意力、MoE 专家不均、多模态 encoder 和投机解码的多 token 验证都会破坏“一 token 一成本”的近似。

第三，共置仍然共享 HBM、L2、SM 和通信链路，不能提供硬隔离。即使总 token 数固定，某些请求的 KV 页面更长或命中率更差，TBT 仍会波动。严格多租户 SLO 可能需要 P/D 分离、优先级队列或独立副本。

第四，Prefix Cache 会改变 Prefill 的实际剩余长度。命中共享前缀后，只应把未命中的 suffix 纳入预算；缓存淘汰又会让相同请求在不同时间具有不同成本。分块调度与前缀缓存是互补机制，但 cost model 必须读取实时命中结果。关于缓存替换的生产轨迹特征，可参考前缀缓存淘汰完全拆解。

第五，较小 chunk 会增加 TTFT，尤其当系统没有足够 Decode 可供“搭车”时。低负载下强行维持很小预算，可能把本可一次完成的 Prefill 拆成许多轮，只得到更差延迟。生产实现应允许在没有活跃 Decode 或 SLO 余量很大时扩大 chunk，而不是把 512 当作永恒常数。