DistServe：面向 goodput 优化的 prefill / decode 分离式大模型服务系统

1. 摘要与一句话判断

3 分钟速读

1. 问题：现有系统把 prefill 与 decode 共置在同一批 GPU 上连续批处理，导致两阶段互相干扰、排队延迟叠加，且资源与并行策略被耦合绑定，为同时满足 TTFT/TPOT 两套 SLO 只能过度配置 GPU P（第 1、3–4 页）。
2. 关键观察：prefill 处理整段 prompt、偏算力受限；decode 每步只处理一个新 token、偏显存带宽受限；两类计算特性与延迟目标天然不同，本就不该共享同一份并行配置 P（第 3 页 §2.1）。
3. 方案：按「实例」（一份完整模型权重所在的资源单元）粒度拆出 prefill 实例与 decoding 实例；用「模拟器 + 枚举搜索」在部署前求出每阶段的并行策略、实例数与物理放置（高/低节点亲和两套算法），运行期用 FCFS 加最短队列派发、KV Cache「拉取」传输与周期性重规划 P（第 4、6–8 页）。
4. 结果：在 OPT-13B/66B/175B、FP16、A100-80GB 集群、ShareGPT/HumanEval/LongBench 三类负载上，相对 vLLM 与 DeepSpeed-MII，SLO 达标 90% 约束下最多多服务 7.4× 请求、或承受 12.6× 更紧的 SLO；KV 传输时延占比不足 0.1% P（第 1、10–11 页；完整条件见 #experiments）。
5. 边界：论文自述在单 GPU/资源受限环境设计空间严重受限、离线吞吐优先场景可能不如 chunked-prefill、未实现抢占与容错 P（第 8、13 页）；实验全部基于 OPT（MHA）与合成泊松到达，SLO 为经验设定 P（第 9 页）。

2. 问题背景

双阶段计算与双延迟指标

LLM 服务一次请求分两段：prefill 一次性并行处理整段 prompt 生成首个 token；decoding 每步仅处理一个新 token、自回归地生成后续 token P（第 1 页 §1）。由此产生两个独立指标：TTFT（time to first token，prefill 阶段耗时）与 TPOT（time per output token，除首 token 外平均每 token 生成时间）；单请求总时延 = TTFT + TPOT × 解码 token 数 P（第 1–2 页，第 2 页脚注 1）。不同应用的侧重不同：实时聊天机器人重低 TTFT，TPOT 只要快于人的阅读速度（约 250 词/分钟）即可；文档摘要则重低 TPOT P（第 2 页）。

计算特性上，prefill 对算力要求随 token 数超线性增长，长 prompt 时趋向算力受限（13B 模型处理 512 token 即可打满一张 A100）；decoding 每步访存量与 prefill 相当，趋向显存带宽受限；两阶段都要把权重与中间状态在 HBM 与 SRAM 间反复搬运，并把 KV Cache 留在显存中供后续解码复用 P（第 3 页 §2.1）。

共置（colocation）服务的三重问题

1. prefill–decode 干扰：一个 prefill 步远长于 decode 步；连续批处理把两者混入同一批，decode 步被拉长（TPOT 恶化），decode 任务也推高 prefill 完成时间（TTFT 恶化），干扰随输入长度增大而加剧 P（第 2 页 §1、第 4 页图 2）。
2. 调度难以奏效：即使分开排队，两阶段仍争抢 GPU；优先任何一方都会牺牲另一方，优先级调度失效 P（第 4 页 §2.3）。chunked-prefill 加 piggyback（把长 prefill 切块并捎带 decode）能缓解但不能消除干扰：切得过小 prefill 执行时间变长，切到接近饱和又捎带不上 decode，且 N 个分块导致 O(N²) 次 KV Cache 的 HBM→SRAM 重复加载（非分块为 O(N)）P（第 3–4 页 §2.2–2.3）。
3. 资源与并行策略耦合：共置迫使两阶段共享同一套资源分配与并行配置，只能迁就更苛刻的一侧，结果常常是对两侧都过度配置 P（第 4 页 §2.3）。

论文用一组动机实验量化代价：13B 模型、输入 512 / 输出 64 token、单张 A100-80GB、合成摘要负载下，共置系统在 90% SLO 达标率下每 GPU 只能承载约 1.6 req/s，而独立服务的 prefill-only 与 decode-only 曲线分别达 5.6 与 10 req/s；按 2 卡 prefill + 1 卡 decode 组合可得整体 10 req/s（合 3.3 req/s/卡，2.1× 于共置）P（第 1–2 页图 1 及 §1；完整口径见 #experiments 表）。

目标工作负载与约束

目标是在在线、有严格 TTFT/TPOT 双 SLO 的场景下最大化每 GPU goodput——在 SLO 达标率目标（论文主口径 90%）内每张已配置 GPU 可承载的最大请求速率；goodput 越高，达标前提下的单查询成本越低 P（第 1–2 页）。基线系统为采用连续批处理与共置架构的 vLLM、以及 chunked-prefill 方案 DeepSpeed-MII P（第 10 页 §6.1）。

3. 核心机制

实例化分离

论文以实例（instance）为基本单元：管理恰好一份完整模型权重的资源单元，应用模型并行时可横跨多张 GPU。分离后分为 prefill 实例（只做预填、产出首个 token 与 KV Cache）与 decoding 实例（承接 KV Cache 与首 token，做后续逐步解码）；因 decode 的 GPU 利用率低，常见配置是多台 prefill 实例对应一台 decoding 实例 P（第 4 页 §2.3）。

控制面与数据面职责

每阶段的批处理与并行策略（离线分析）

• prefill 批处理：先对目标模型+GPU 做性能画像，找出打满 GPU 的临界输入长度 Lm（13B 模型为 512 token / A100）；仅当请求输入短于 Lm 才合并批处理，否则逐请求调度，prefill 批量总体保持较小 P（第 4–5 页 §3.1、图 3(a)）。
• prefill 并行：分离后的 prefill 实例近似 M/D/1 排队（FCFS、单请求即饱和 GPU）。低到达率下执行时间占主导，算子内并行（intra-op，含速度系数 K，1<K<2）更优；高到达率下排队时延占主导，算子间流水（inter-op，可线性扩速率容量）更优；SLO 越紧、通信越好（K 越小）越偏向 intra-op P（第 5 页 §3.1、式 1–3、图 4）。
• decoding 批处理：单任务严重带宽受限，大批量是提高利用率的关键；分离后可用大批量而不牺牲 TPOT，批量上限受 KV Cache 显存约束，PagedAttention 与 GQA 等可进一步放大批量 P（第 5–6 页 §3.2、图 3(b)）。
• decoding 并行：TPOT SLO 紧时用 intra-op 压低单步时延（收益递减）；吞吐优先时用 inter-op 近线性扩容；模型能放进单卡时，多副本复制同样线性扩速率并降低排队时延，代价是多份权重显存 P（第 5–6 页 §3.2、图 5）。
• 非均匀长度与气泡：真实负载输入长短不一，会使 inter-op 流水出现气泡；系统通过按「批内新 token 数」（批执行时间的可靠指标）平衡各流水批来缓解 P（第 6 页 §3.3、第 8 页 §4.3）。

两个放置算法（部署前求解）

• 高节点亲和（Alg.1）：面向跨节点高速网（如 InfiniBand）集群，prefill 与 decoding 可放任意节点。分别枚举两阶段并行配置、用模拟器评估 SLO 达标下的最大速率，再按 n = ⌈R / goodput⌉ 复制到目标流量；复杂度 O(NM²)（N 为实例节点数上限，M 为每节点 GPU 数，如 8），最大设置下求解不足 1.3 分钟 P（第 7 页 §4.1、算法 1、第 12 页 §6.5）。
• 低节点亲和（Alg.2）：面向跨节点带宽受限集群。利用 inter-op 把实例切成「段」，把同一 stage 的 prefill 段与 decoding 段共置于同一节点，强制中间状态只走节点内 NVLINK；每节点内枚举配置求最优后复制 P（第 7–8 页 §4.2、算法 2）。
• 模拟器：基于附录 A 的 GEMM/attention 算力-访存模型（A100-80GB 上算术强度 >156 判定算力受限）与历史 trace 拟合的负载分布重采样，预估 SLO 达标率；实测对比误差小于 2% P（第 7 页 §4.1、第 12 页表 2、第 17 页附录 A）。

在线调度要点

运行期保持简单 FCFS：集中控制器把请求派给最短队列的 prefill 实例，prefill 完成后交由负载最轻的 decoding 实例；prefill 按 Lm 凑批（多个短 prompt 合批或单个长 prompt 独占），decoding 以最大批量为凑批目标；KV Cache 用拉取式传输防止突发把 decoding 实例显存打爆 P（第 8 页 §4.3）。

4. GPU/系统数据路径

端到端文字序列（与图中编号一致）

1. ① 请求接入：客户端调用 OpenAI 兼容的 RESTful API 提交 prompt 与采样参数（最大输出长度、温度等）P（第 9 页 §5）。
2. ② 派发：集中控制器按 FCFS 将请求派给当前队列最短的 prefill 实例 P（第 8 页 §4.3）。
3. ③ 预填执行：prefill 实例的 GPU worker 从 HBM 读权重与 prompt token，经 FlashAttention kernel 与 GEMM（HBM→SRAM 访存密集）整段并行计算，产出首个输出 token，并逐层写入该请求的 KV Cache P（第 3 页 §2.1、第 9 页 §5、第 17 页附录 A）。
4. ④ KV 传输：KV Cache 不立即搬运，而是留在 prefill 实例显存中充当排队缓冲；目标 decoding 实例按需「拉取」对应请求的 KV（同节点走 NVLINK 上的异步 cudaMemcpy，跨节点走 NCCL）P（第 8 页 §4.3、第 9 页 §5）。
5. ⑤ 逐 token 解码：decoding 实例将请求并入 continuous batching 批次，每步只喂入一个新 token（显存带宽受限），并把新增 KV 追加到 HBM；直至终止符 P（第 1 页 §1、第 5 页 §3.2、第 9 页 §5）。
6. ⑥ 流式返回：已生成 token 与结果由编排层回传、流式送达客户端 P（第 2 页 §2、第 9 页 §5）。
7. ⑦ 权重加载（控制面触发）：每台实例持有一份独享的完整权重副本，实例启动时从权重文件加载一次；prefill 与 decoding 实例各持一份 P（第 4 页 §2.3 实例定义、第 8 页 §4.3 权重重载）。
8. ⑧ 画像与重规划（控制面闭环）：workload profiler 持续监测平均输入/输出长度、到达率；检测到显著模式漂移即重跑放置算法（秒级）并重载权重（分钟级），完成扩缩容或策略切换 P（第 8 页 §4.3、第 12 页 §6.5）。

5. 架构权衡

• 吞吐—延迟

  得：消除干扰后，两阶段可各自逼近 SLO 约束下的最大速率，per-GPU goodput 上升 P（第 2、10–11 页）。
  失：目标函数从「总 token 吞吐」改为「SLO 内 goodput」；若无 SLO，共置+chunked-prefill 的原始吞吐可能更高 P（第 13 页 §7）。

• 算力—内存

  得：prefill 用满算力、decoding 用大批量摊薄带宽受限，各自最优 P（第 4–6 页 §3.1–3.2）。
  失：两台实例各存一份完整权重，KV Cache 又要在 prefill 显存多驻留一段排队时间；大模型（175B＝350 GB）连单节点放一对实例都困难 P（第 4、7–8 页）。

• 复杂度—收益

  得：放置算法把「GPU 数 × 并行策略 × 复制数」的组合搜索自动化，单次求解不足 1.3 分钟，可随负载自动重规划 P（第 7、12 页）。
  失：相比单系统共置，多实例编排、KV 传输管理、画像与重规划显著抬高运维与排障复杂度 I（基于第 6–9 页组件面的编辑判断）。

• 扩展性—故障域

  得：两阶段独立复制、独立扩缩容，inter-op 近线性扩速率容量 P（第 3、5–6 页）。
  失：跨实例 KV 依赖把 prefill 与 decoding 绑成依赖图，单个 decoding 实例故障可能波及映射其上的全部 prefill 实例；跨节点带宽不足时扩展还受放置约束 P（第 6–8 页）。

• 一致性/精度—效率

  得：分离不改变计算图，输出与共置执行等价（论文以同样 FP16 口径评测质量负载）P（第 9 页 §6.1）。
  失：KV 传输量与精度和上下文长度直接挂钩：FP16 下 512-token/66B 单请求即 1.13 GB，长上下文线性放大传输压力（论文未涉及 KV 量化，此为编辑推断边界）P+I（第 6 页 §3.3；第 13 页 §7 长上下文讨论）。

6. 云上部署映射

以下映射厂商中立；具体产品仅作示例并标 E（规格与命名以各云厂商当时目录为准，本页未逐一在线核验）。云实例规格与论文硬件的一致性需在 PoC 中复核 I。

7. 成本 / 性能 / SLO

容量规划变量

• 到达率 R 与负载分布（输入/输出长度分布、到达过程；论文用泊松合成）P（第 7、9 页）。
• 临界输入长度 Lm 与 prefill 速度系数 K（依模型/带宽/放置而变，需画像）P（第 4–5 页）。
• SLO 目标（TTFT/TPOT 阈值与达标率 90%/99%）——直接决定可行并行配置与实例数 P（第 9–10 页）。
• 实例数：n = ⌈R / goodput(配置)⌉，prefill 与 decoding 分列，再乘复制数 P（第 7 页算法 1）。
• 显存下限：每实例完整权重 ×2 类实例 + KV Cache（含 prefill 侧排队缓冲）；175B 一对完整实例即需 >640 GB P（第 7 页 §4.2、第 9 页表 1）。
• KV 传输带宽：随到达率 × 单请求 KV 体积（如 66B/512-token 为 1.13 GB）线性增长 P（第 6 页 §3.3）。

成本公式（参数化，编辑推断）

8. 安全与可运维性

9. 适用 / 不适用场景

适用（各含触发条件与理由）

• 双 SLO 在线对话/编码助手：触发条件——TTFT 与 TPOT 均设硬阈值且要求 ≥90% 达标，集群有多台 80GB 级 GPU。理由——分离消除干扰并允许两阶段各自选并行策略，chatbot 场景相对 vLLM 可承载 2.0×–4.6× 速率 P（第 10 页 §6.2；条件见 #experiments）。
• 长输入摘要/RAG 类负载：触发条件——输入显著长于输出（如 LongBench 均值 1738/91 token）、TPOT 紧而 TTFT 相对宽松。理由——长 prefill 不再拖累 decode，相对 vLLM 速率 4.3×、SLO 容忍 12.6× P（第 11 页 §6.2）。
• 具备高带宽互连的集群：触发条件——节点内 NVLink 且跨节点 ≥ 数十 Gbps（RDMA/IB 更佳），或接受同节点分段放置。理由——带宽感知放置下 KV 传输占比 <0.1%、95% 请求传输 <30 ms P（第 11 页 §6.3、第 6–8 页 §3.3/§4.2）。
• 负载模式随时间漂移的生产服务：触发条件——小时级输入/输出长度或到达率变化明显。理由——profiler + 周期重规划自动跟随（求解秒级、生效分钟级）P（第 8 页 §4.3）。

不适用（各含触发条件与理由）

• 单 GPU / 极少卡环境：触发条件——总共 1–2 张卡、无法同时容纳两类实例与双份权重。理由——论文自述此时设计空间严重受限，采用非分离系统更简单有效 P（第 13 页 §7）。
• 无 SLO 的离线吞吐作业：触发条件——批处理式生成、只看总 token 吞吐。理由——goodput 优化目标退化；论文指出 chunked-prefill+piggyback 可能更优 P（第 13 页 §7）。
• 跨节点带宽极低且无法同节点放置：触发条件——跨节点带宽远低于 KV 传输需求（66B/512-token@10 rps 即需 ≈90 Gbps）且显存放不下同节点分段。理由——传输开销不可忽略，放置约束无法满足 P（第 6–7 页 §3.3/§4.2）。
• 极小流量且模型单卡可容：触发条件——低速率、单卡放得下模型。理由——多副本复制即可线性扩容并降排队，双实例编排的复杂度不划算 P+I（复制结论出自第 6 页 §3.2，成本判断为编辑推断）。

10. 实验与指标

实验环境与负载

基线

• vLLM：连续批处理 + PagedAttention，共置两阶段；仅支持 intra-op，13B/66B/175B 分别设 intra-op=1/4/8 P（第 10 页 §6.1）。
• DeepSpeed-MII：chunked-prefill（切块预填 + 按预算凑批捎带），intra-op 与 vLLM 对齐；因 kernel 要求 vocab_size/intra-op 为 8 的倍数且 intra-op=4 会显存溢出，无法服务 OPT-175B（vocab 50272）P（第 10 页 §6.1）。

主要定量结果（完整条件）

DistServe 自选放置（附录 B 表 3）

公平性限制与口径注意

• SLO 阈值为作者按应用经验设定，无业界标准可依 P（第 9 页 §6.1）。
• 到达过程为泊松合成，非真实 trace 时序 P（第 9 页 §6.1）。
• 模型为 OPT（MHA、最大上下文 2048）；GQA 类模型会改变 KV 体积与传输结论的量级 P（第 9 页 §6.1）。
• vLLM 不支持 inter-op，其消融对照（vLLM++）与 99% 达标组在模拟器中完成（模拟误差 <2%）P（第 10、12、18 页）。
• 端到端实验的批量/并发具体数值论文未明确披露；复现时须以自己画像为准，禁止脱离条件摘取倍数。

建议复现步骤 I

1. 从官方仓库（#links，R）获取代码；README 要求至少 2 块 GPU、依赖 Ray，后端为 SwiftTransformer，支持 GPT-2/OPT/LLaMA2。
2. 按论文口径准备 OPT 模型与 ShareGPT/HumanEval/LongBench 抽样请求，设定表 1 的 SLO 与 90% 达标目标。
3. 先跑放置算法得到并行配置与实例数（对照第 18 页表 3），再以泊松到达做速率扫描，记录五段时延与达标率。
4. 与 vLLM（按论文设置 intra-op）和 DeepSpeed-MII 对齐硬件与负载后对比；所有倍数必须连同条件一起报告。

11. 论文 / 代码 / 延伸链接

构建证据文件：sources/distserve.txt、sources/distserve.summary.json、sources/distserve.evidence.json（属于构建目录，不在公开导航中展示）。

12. 给架构师的决策清单

• 需求
  • 已写出业务的 TTFT、TPOT 阈值与达标率目标（如 90%/99%），并区分应用类型（对话/编码/摘要）P（表 1 口径，第 9 页）
  • 已确认负载确实在线且双 SLO，而非纯离线吞吐（后者不应选本方案）P（第 13 页 §7）
• 兼容性
  • 目标模型在支持列表内或已验证可移植（论文验证 OPT/LLaMA；仓库后端 SwiftTransformer 支持 GPT-2/OPT/LLaMA2）R
  • 已评估 KV 体积对传输的影响（MHA vs GQA）与上下文长度上限 P（第 6、9 页）
• PoC
  • 已用论文模拟器/放置算法离线预测本负载下的配置与 goodput，再上实验床验证 P（第 7、12 页）
  • PoC 覆盖 90% 与 99% 两档达标率，并复测五段时延分解 P（第 10–11、18 页）
• 容量
  • 已核算双份权重 + KV Cache 显存（含 prefill 排队缓冲）与 n=⌈R/goodput⌉ 卡数 P（第 4、7 页）
  • 已验证节点内 NVLink 可用、跨节点带宽满足 KV 传输需求（或已采用同节点分段放置）P（第 6–8 页）
• SLO
  • TTFT/TPOT 口径（P90 或均值）已与业务方一致，并写入监控 P（第 1–2、10 页）
  • 已确定 SLO 不满足时的降级策略（限流/排队/降配）I
• 成本
  • 已按参数化公式估算单查询成本，记录查价日期，并识别敏感项（SLO 紧度、输入长度、跨节点带宽）I（框架见 #cost-slo）
  • 已与共置基线（vLLM 类）在同一 SLO 口径下比较过单位成本，而非裸吞吐 P（第 2 页 goodput 动机）
• 安全
  • 已定义 KV/Prompt 数据驻留边界与实例回收时的显存清理流程 I（论文未披露，见 #security-ops）
  • API 与控制面鉴权、限流、审计已接入 I
• 运维
  • 已针对「论文未实现容错/抢占」制定补偿：健康检查、实例重建、限制 decoding 故障扇入、请求重试 P+I（第 8 页 §4.3）
  • 重规划阈值、版本化 placement 与一键回退已演练（求解秒级、权重重载分钟级窗口已纳入容量预案）P+I（第 8、12 页）
  • CUDA/NCCL/Ray/仓库 commit 版本矩阵已锁定并纳入镜像供应链管理 R+I
• 退出策略
  • 已验证可回退到共置系统（同硬件跑 vLLM 类基线）且权重格式/服务接口可迁移 I
  • 已设定退出触发条件（如 SLO 长期达标且流量模式证明分离无收益、或集群带宽无法支撑）P+I（适用边界见 #fit）

13. 证据台账

下表为核心结论的证据映射；逐条引文与在线核验记录见构建文件 sources/distserve.evidence.json。核验日期均为 2026-09-14。