Sarathi-Serve：以 chunked-prefills 与 stall-free batching 驯服 LLM 推理的吞吐—延迟权衡

• 生命周期：推理服务
• 部署形态：单机 TP / 跨节点 PP
• 目标硬件：NVIDIA A100 / A40
• 核心资源：GPU 算力 · HBM / KV Cache · 网络
• 证据状态：P 主导（性能数字全部为论文报告）

一句话判断

对需要「同时守住交互式尾延迟与 GPU 吞吐」的在线 LLM 服务，Sarathi-Serve 用切块 prefill（chunked-prefills）与不停批调度（stall-free batching）把吞吐—延迟从二选一变成一个可调的 token 预算旋钮；代价是 prefill 效率的小幅折价（图 14：Yi-34B / TP-2，最小块 512 时 prefill 计算开销 ≤约 25%、2048 块近零，相对不切块归一化，精度论文未明确披露）与按部署调参的运维成本。P I（判断为编辑观点）

3 分钟速读

1. 问题：prefill 并行算整个 prompt、计算受限；decode 一次每请求只算 1 个 token、内存受限。现有调度要么 prefill 优先（vLLM/Orca）——长 prefill 迭代把运行中请求的 decode 卡住数秒（generation stall）；要么 decode 优先（FasterTransformer）——小批量浪费算力。P
2. 洞察：prefill 吞吐在序列长约 512 token 就饱和，把长 prompt 切成近等计算量的块，既不损失 prefill 效率，又让每次迭代时长有上界。P
3. 机制：stall-free batching（算法 3）每迭代先打包全部运行中 decode，再续算未完成 prefill 块，最后在剩余 token 预算内接纳新请求；预算由 TBT SLO 推导（评测取 strict 512 / relaxed 2048）。P
4. 结果：相对作者复现的 vLLM/Orca 基线，服务容量（sustained QPS）：Mistral-7B / 1×A100 最高 2.6×，Yi-34B / 2×A100 最高 3.7×，Falcon-180B / 2 节点×4×A100（TP4-PP2）端到端最高 5.6×；负载为 openchat_sharegpt4（输入/输出中位 1730/415 token）与 arxiv_summarization（7059/208 token），strict/relaxed SLO；精度论文未明确披露。P
5. 边界：数字不可与其他论文横比；chunk 有开销（图 14：Yi-34B / TP-2，≤约 25%@512 块）；与 disaggregated 方案（DistServe 等）的定量对比论文明确留白（第 13 页 §6）；仓库为科研原型、非完整 vLLM 功能对等（第 18 页附录 A）。P R

论文声称的主要结果

问题背景

两阶段天然不对称

LLM 推理分 prefill（一次并行处理全部 prompt token，产出首 token）与 decode（每迭代每请求只处理 1 个 token）两阶段。prefill 计算受限、吞吐对批量几乎不敏感；decode 内存受限、批量越大越摊薄权重读取成本，吞吐随批量近似线性提升。论文图 3/图 4（Mistral-7B、单张 A100、prompt/输出长度均 1024）实测了这一点，并指出线性层占两阶段总时间 80% 以上（第 1 页摘要、第 3 页 §2.2、第 5 页 §3.1 与图 3/图 4）。P

两类现有调度都有硬伤

• prefill 优先（vLLM、Orca 的迭代级调度）：急切准入新 prefill。一个长 prompt 的 prefill 迭代可执行数秒，期间所有运行中请求的 decode 被卡住——论文称为 generation stall。图 1 实测 vLLM 服务 Yi-34B（2×A100、128 请求、arxiv-summarisation trace）时出现持续数秒的 stall，且负载升高时 P99 TBT 显著恶化（第 1 页图 1、第 2 页 §1）。P
• decode 优先（FasterTransformer、Triton 等请求级批处理）：批内全部 decode 完成才准入新请求，TBT 有保障，但先完成的请求不能退出、批规模持续缩水直至最慢请求结束，吞吐因此严重受限（第 2 页 §1、第 4 页 §2.5 与算法 1）。P

流水线放大问题

跨节点部署常用流水线并行（PP）：通信少、只需点对点。但混合长短 prefill/decode 的微批执行时间差异巨大，产生三类流水线气泡（prefill 长度差、prefill/decode 计算差、decode 间 KV 上下文差）。论文以 Falcon-180B 举例：一个 4k prompt 的 prefill 迭代约 1150ms，而 batch 32 的纯 decode 迭代约 200ms，二者交错即可产生约 950ms 的气泡（第 7 页 §3.3、图 8；该示例未指明所用 GPU 配置与精度，均按论文未明确披露处理）。P

指标与约束

论文采用 TTFT（time-to-first-token，取中位）与 TBT（time-between-tokens，取 P99）为延迟指标，Capacity 为「在延迟目标内可持续服务的最大请求负载（QPS）」——吞吐与延迟被统一进一个容量口径（定义见第 4 页 §2.4，容量实验见第 10–11 页 §5.1）。P

核心机制

1 · chunked-prefills：把长 prefill 切成近等计算量的块

依据两条：其一，prefill 吞吐在序列长约 512 token 即进入饱和（图 4 实测：Mistral-7B、单张 A100、长度 1024；第 5 页图 4、第 8 页 §4.1），把千级 token 的 prompt 切成 512 量级的块几乎不损失 prefill 效率；其二，每次迭代的计算量因此有了硬上界，不再取决于 prompt 总长。P

2 · stall-free batching：控制面的迭代编排（算法 3）

1. 先打包当前批中所有运行中请求的 decode token；
2. 再续算未完成的 prefill 块；
3. 最后在剩余 token 预算内准入新请求（按预算切出其第一个块）；
4. 提交混合批执行，过滤已完成请求，进入下一迭代。

关键不变量：decode 永远在批内、每迭代 token 总量 ≤ token budget = f(TBT SLO)。因此新请求的 prefill 永不推迟运行中请求的 decode——「stall-free」由此得名。P

3 · token 预算的三个约束

• 切太碎的代价一（GPU 利用率）：块小于计算饱和点后线性层效率下降；
• 切太碎的代价二（KV 重读）：分 N 块时第 i 块的注意力需重读前 i−1 块的 KV，增加 HBM 读取流量（计算量不变）；
• tile 量化：GPU 矩阵按 tile 分块，257 token 的块可比 256 多耗 32% prefill 时间（第 9 页 §4.3；该 32% 为论文给出的 tile 量化示例，对应模型/硬件/精度论文未明确披露）——预算应取 2 的幂附近。P

论文用 Vidur 仿真器对目标部署做一次性剖析来选预算（第 9 页 §4.3）；评测取 strict 512 / relaxed 2048（LLaMA2-70B relaxed 用 1536 以压流水线气泡）（第 11 页 §5.1 末段）。P

4 · 实现与控制面/数据面边界

系统实现于 vLLM 开源版之上：新增 paged chunk prefill 支持，接入 FlashAttention v2 与 FlashInfer kernel（评测统一用 FlashAttention 后端，因其支持的模型更广），扩展了调度策略、流水线并行与遥测系统，TP/PP 通信使用 NCCL（第 9 页 §4.4、第 10 页 §4.4 末段）。P

按论文事实区分：控制面=迭代级调度器（算法 3 的编排与预算执行）；数据面=执行引擎（GEMM、注意力 kernel、KV cache 读写、采样与 NCCL 通信）。「调度器只做编排、不碰张量数值」是本站对其结构的编辑概括。I

GPU / 系统数据路径

端到端文字序列

1. ① 请求进入：客户端请求到达 API 前端（vLLM 服务进程）入队，遥测系统记录到达时间。P
2. ② 调度编排（控制面）：每轮迭代，调度器按算法 3 依次打包运行中 decode → 续算未完成 prefill 块 → 在剩余额度内准入新请求（第 9 页算法 3）。P
3. ③ 混合批成形：D 个 decode token + 1 个 prefill 块，批内 token 总数 ≤ token budget（strict 512 / relaxed 2048），每迭代计算量近均匀。P
4. ④ GPU 前向：混合批进入执行引擎逐层计算——线性层 GEMM 与注意力 kernel（FlashAttention v2 / FlashInfer 的 paged chunk prefill 路径）。P
5. ⑤ 显存访问：线性层从 HBM 读模型权重（按批摊薄）；注意力经 PagedAttention 页表读写 KV cache——prefill 块追加新 KV，decode 读写全部历史 KV；跨块注意力重读同 prompt 先前块的 KV（第 i 块重读 i−1 次）。P
6. ⑥ 并行通信：TP 每层两次 all-reduce（节点内 NVLink）；PP 在流水线 stage 间点对点传激活（论文跨节点为 100 Gbps 以太网，第 4 页 §2.3、第 10 页表 1），近均匀微批使气泡最小。P
7. ⑦ 采样回传：decode 请求采样出新 token 追加到输出序列；prefill 请求算完首块不产出用户可见 token，等待后续块（最后一块产出首 token）。P I（首 token 产出时点为编辑按 chunked 机制推演）
8. ⑧ 流式响应：token 经 API 前端流式返回客户端；首 token 到达即 TTFT，相邻 token 间隔即 TBT——stall-free 保证 TBT 无 prefill 干扰尖峰。P

架构权衡

云上部署映射

本节为部署映射：论文硬件事实标 P，云产品对应标 E（仅作厂商中立示例，参数与价格以云厂商文档为准，本站未核验实时价格），运维建议标 I。

成本 / 性能 / SLO

SLO 口径（论文定义）

为剔除模型/硬件固有差异，P99 TBT 的 SLO 定义为「无 prefill 干扰的 decode 迭代执行时间」（4k prefill 长度、batch 32 基准）的 5×（strict）/ 25×（relaxed）；绝对阈值见表 D。容量实验同时限制中位排队延迟 ≤2s（第 10 页 §5.1、表 3）。P

容量规划变量

• SLO 松紧（5×/25× 倍数）→ 直接决定 token budget 与容量上限；
• 长度分布（prompt/输出中位与 P90，表 2）→ 长 prompt 收益更大但 strict 预算下 prefill 折价更多；
• 并行策略（TP 度、PP stage 数）与跨节点带宽 → 气泡量级；
• 判稳口径：中位排队延迟 ≤2s。P

成本模型（参数化，非论文结论）

论文不含任何成本数据。架构师可用下式估算单副本单位成本（I，价格项为参数）：

每百万输出 token 成本 ≈ p_gpu × N_gpu × t_hour ÷ ( C_slo × L_out ) ÷ 10⁻⁶ …（公式 1）

• p_gpu：单卡时租价（按查询日云价代入，E）;
• N_gpu：副本卡数（1/2/8）；
• C_slo：目标 SLO 下的容量 QPS（用论文图 10–13 按比例估，或实测）；
• L_out：平均输出 token 数（表 2 口径）。

敏感项：SLO 从 relaxed 收紧到 strict 时容量普遍明显下降（各档具体数值见图 10–11，第 11–12 页；「约减半」为本站编辑对图中差值的概括，非论文结论 I）；长 prompt 占比上升时 strict 下容量下降更明显（arxiv_summarization 各系统容量普遍低于 openchat_sharegpt4，第 11–12 页）。P

安全与可运维性

论文披露范围

• 实现含「extensive telemetry system」遥测系统，可用于延迟与调度观测（第 9–10 页 §4.4） P；
• 仓库为 vLLM fork 的科研原型，「与开源 vLLM 不具备完整功能对等」（第 18 页附录 A） R；
• 依赖栈：CUDA 12.1、A100/A40、FlashAttention v2、FlashInfer、NCCL（第 9–10 页 §4.4、第 18 页附录 A） P R。

论文未披露、部署方必须自行覆盖的项

适用 / 不适用场景

适用（触发条件 → 理由）

1. 交互式对话 / 助手类在线服务：触发条件——TBT 有 P99 硬约束且并发高。理由——stall-free 调度直接消除 generation stall，strict SLO 下容量较 vLLM 最高 3.7×（Yi-34B / 2×A100 / openchat_sharegpt4，第 11 页 §5.1）。P
2. 长 prompt 工作负载（总结、文档问答、Copilot 类）：触发条件——prompt 中位在千级 token 以上。理由——长 prefill 是 stall 与气泡主因，切块后收益最大（arxiv_summarization，中位 7059 token，第 10 页表 2）。P
3. 无高带宽互联的跨节点大模型部署：触发条件——模型超单机 8 卡显存或 NVLink 域不可得。理由——TP4-PP2 + 均匀微批使跨节点 PP 可行，Falcon-180B（2 节点×4×A100）端到端容量最高 5.6×（第 1 页摘要、第 11 页图 11a）。P
4. 7B–180B 多模型统一服务底座：触发条件——同一服务栈承载多个模型规模。理由——论文在四个模型 × 两类并行 × 两数据集上一致取得容量增益（第 10–13 页 §5），机制不依赖特定模型结构。P

不适用（触发条件 → 理由）

1. 纯离线批量生成（吞吐唯一目标）：触发条件——无交互延迟要求。理由——chunk 切块对 prefill 有纯开销（图 14：Yi-34B / TP-2，512 块 ≤约 25%、相对不切块归一化，第 13 页 §5.4.1），无 TBT 收益可换。P
2. TTFT 极致优先且具备高带宽互联：触发条件——首 token 延迟权重远高于流式流畅度、且有 RDMA/NVLink 跨节点域。理由——论文自述 disaggregated 方案 prefill 效率与 TTFT 更优，但定量对比留作未来工作（第 13 页 §6）。P
3. 需要生产级功能完备 / 硬多租户隔离：触发条件——直接对外多租户、合规要求严。理由——官方仓库自述为非功能对等的科研原型（第 18 页附录 A）。R
4. 低负载 / 超短 prompt 场景：触发条件——QPS 远低于容量、prompt 数十 token。理由——decode 批小、prefill 本就不饱和，机制收益有限（编辑推断，论文未专门测此区间）。I

实验与指标

测试床与负载（复现实验的完整条件）

• 服务器：Azure NC96ads v4（4×A100 80GB、两两 NVLink），节点间 100 Gbps 以太网；A40 为 8×48GB 单机（第 10 页 Models and Environment 段）。P
• 负载：两数据集长度特征 + 泊松到达；总长分别截断于 8192 / 16384 token；指标取中位 TTFT 与 P99 TBT（第 10 页表 2、Workloads/Metrics 段）。P
• 基线：vLLM、Orca（论文自述两者为当时 SOTA，作者自行复现，第 10 页 §5）。P

关键结果（均带条件）

公平性限制

• 所有对比基于作者实现的基线复现，非原作者调优结果；I
• Orca 无 PagedAttention、批大小受限，vLLM 无混合批——代差部分来自系统能力差异而非纯调度；P
• 论文未明确披露模型精度（dtype）与量化设置；未测多租户与故障注入场景。P（缺口）

建议复现步骤

1. 获取官方仓库 microsoft/sarathi-serve，切换 OSDI 复现分支 osdi-sarathi-serve（第 1 页 §1、第 10 页 §4.4、第 18 页附录 A）；R
2. 准备 CUDA 12.1 + A100/A40 环境（/sarathi 源码、/csrc 自定义 kernel，第 18 页附录 A）；R
3. 使用 /data 中 trace 与 /osdi-experiments 脚本按图对应 README 跑容量与延迟实验（第 18 页附录 A）；R
4. 先复现图 9/图 14（微基准），再复现图 10–13（容量），最后表 4（消融）。I（顺序为编辑建议）

论文 / 代码 / 延伸链接

Splitwise、DistServe、TetriInfer、APIServe、Vidur、FlashInfer 等论文引用的关联工作仅据论文 §6/§4 转述，未核验到官方仓库的恕不提供链接。

给架构师的决策清单

证据台账

分级：P = 论文正文/图表；R = 论文给出的官方仓库；E = 外部/云文档（仅部署映射）；I = 编辑推断。定位均为真实 PDF 页码 + 章节/图表号：2026-09-14 以 pdftotext 逐页版式提取对全部 25 条逐条复核（第 15–17 页为参考文献列表、第 19 页无正文，经全文提取交叉覆盖）。完整字段（原文摘录、条件、状态）见 sources/sarathi-serve.evidence.json。最后核验日期：2026-09-14。