LLM Prefill/Decode 分离架构工程 2026
把 Prefill 的算力密集型与 Decode 的访存密集型特征拆到不同 worker,经 KV cache over RDMA 跨节点传输,把 P99 TTFT 与 TPOT 同时压到单引擎极限之上——这是 2026 年 LLM serving 的核心架构升级,DistServe/Splitwise/Mooncake/vLLM/SGLang 各家路径详评。
约 35 分钟阅读10,341 字16 次阅读博主
把 Prefill 的算力密集型与 Decode 的访存密集型特征拆到不同 worker,经 KV cache over RDMA 跨节点传输,把 P99 TTFT 与 TPOT 同时压到单引擎极限之上——这是 2026 年 LLM serving 的核心架构升级,DistServe/Splitwise/Mooncake/vLLM/SGLang 各家路径详评。
过去三年 LLM 推理优化的主线,一直围绕着单引擎内部的微观改造——FlashAttention 让 attention kernel 更快、Continuous Batching 让显存调度更密、PagedAttention 让 KV cache 按页分配。这些优化在不改变"Prefill 和 Decode 共享同一组 GPU 资源"这一前提的情况下,把单卡的吞吐推到了物理上限的 70-80%。但当我们把视野拉到生产集群(数百卡、混合负载、长短请求共存)时,一个回避不了的事实浮现:Prefill 和 Decode 的计算特征是天然互斥的,强行让它们共用资源,等于让一辆油罐车和一辆跑车挤同一条车道,谁也跑不快。
DistServe 在 2024 年初把这层窗户纸捅破:把 Prefill 和 Decode 拆到不同的 worker pool,中间用 KV cache transfer 桥接,首次在公开 benchmark 上把 P99 TTFT(time to first token)和 P99 TPOT(time per output token)同时压到了单引擎极限之上。随后 Splitwise(Microsoft)、Mooncake(Moonshot)、vLLM disaggregation、SGLang HiCache 沿着相近的思路把这条路径工程化。截至 2026 年 8 月,这条路径已经从学术论文变成了大厂生产推理平台的事实默认——Anthropic、xAI、字节、阿里、DeepSeek 的 serving 栈都已全面或部分地采用分离架构。
本文从架构层面切入这一范式,覆盖 DistServe/Splitwise/Mooncake 的设计动机与差异、vLLM 与 SGLang 的工程落地、KV cache over RDMA 的传输层抽象、跨节点调度的排队论视角,以及面向 SRE 与平台工程师的可观测性清单。
Prefill 阶段处理整个 prompt 的所有 token,计算密度高(compute-bound),GPU 利用率常达 90% 以上,延迟随 prompt 长度近似线性增长,典型算力特征是 large GEMM 操作占主导。Decode 阶段每个 step 只生成一个新 token,访存密集(memory-bound),瓶颈在权重加载与 KV cache 读写,GPU 计算单元利用率常跌到 5-15%,延迟对 batch size 高度敏感。
两者放在同一组 GPU 上的核心矛盾有三个层面:
算力-访存互相干扰。一个长 prompt 的 Prefill 任务会瞬间把整张卡的 SM 占满,导致同卡上正在 Decode 的请求被排队等待,TPOT 出现毛刺。在 trace 上表现为"TPOT 偶发飙高"——这不是 Decode 慢,而是被 Prefill 抢资源。Continuous Batching 在共享模型权重的层面缓解了这个问题,但没有根治,因为它仍然要求 Prefill 和 Decode 复用同一份 CUDA kernel launch pipeline。
显存分配互相挤压。Prefill 阶段会为 prompt 分配 KV cache,但因为 prompt 长度差异极大,分配颗粒度很难统一。Decode 阶段则稳定地为每个活跃请求保留 KV cache 页。当 Prefill 任务到达时,如果当前显存水位已经较高,系统要么等待 Decode 任务完成腾出空间,要么触发抢占(preemption)。这两种策略都让 P99 延迟显著恶化。
调度策略互相矛盾。Prefill 适合"大而少"的 batch(把多个短 prompt 合并成一个大矩阵乘),Decode 适合"小而多"的 batch(用大 batch 摊薄权重加载延迟)。一个 scheduler 试图同时优化两者,等于在两个相反的目标函数之间反复横跳,最终哪个都做不好。Chunked Prefill(Sarathi-Serve 的核心思想)是一种折中——把 Prefill 切成小块,塞进 Decode batch 之间的间隙——但这只是缓解,不是根治。
把这三个层面的矛盾形式化,可以写成一个目标函数:最小化 α · TTFT + β · TPOT,其中 α, β 是 SLO 权重。当 α ≈ β 时,共享架构的最优解恰好是"既不偏向 Prefill 也不偏向 Decode",也就是"两者都跑不到极限";当 α >> β(交互式应用,用户等首个字符)或 β >> α(批处理应用,总吞吐优先)时,共享架构可以通过调整 batch 策略部分优化,但代价是另一边的 P99 飙升。分离架构的本质,就是把 α · TTFT 和 β · TPOT 的优化解耦到两个独立的资源池,让各自池内部的 scheduler 只优化自己那一侧的目标。
DistServe 的核心抽象是"两个 worker 角色 + 一条 KV cache 通道"。Prefill worker 接到请求后,先在本地完成 Prefill,生成完整的 KV cache,然后通过高速互连(通常是 RDMA)把 KV cache 序列化传输到 Decode worker;Decode worker 接收后,从下一个 step 开始执行 Decode。整个过程对用户透明,客户端只看到"请求发出-响应到来"的端到端延迟。
DistServe 的两个关键工程决策值得深入拆解。第一是 KV cache 传输的 chunked 模式:不必等 Prefill 完整结束才传输,而是按 layer 分块,在某个 layer 的 Prefill 完成后立刻传输该层的 KV cache,Decode worker 端在收到该 layer 后就开始 prefill 那一层的 attention 依赖。这种 pipeline 化的传输把"Prefill 时间 + 传输时间"近似压成了 max(Prefill, 传输),而不是 Prefill + 传输。第二是 request migration 的代价模型:DistServe 明确指出,迁移一个请求的代价 ≈ RTT + KV cache size / bandwidth,并据此设计 admission control——当 Decode 池的负载已经接近饱和时,新请求的 Prefill worker 应该选择排队而不是立即调度,因为迁移到饱和 Decode 池只会让 P99 TPOT 进一步恶化。
Splitwise 的设计思路略有不同,更强调 Prefill/Decode 在网络拓扑上的非对称部署。Microsoft 的工程团队观察到:Prefill 任务短而猛,适合放在靠近请求入口的边缘节点(快速响应);Decode 任务长而稳,适合放在 GPU 资源密集的核心节点(高吞吐)。这两个角色通过数据中心网络(他们的内部叫"token 高速公路")连接,Prefill 完成后 token + KV cache 沿这条高速路流到 Decode 节点。Splitwise 在 Azure 上的实验数据显示,这种非对称部署比"对称部署 + 共享引擎"在 P99 TTFT 上改善 2.5-3.5 倍,在 P99 TPOT 上改善 1.5-2 倍。
两者在工程实现上的最大差异是 KV cache 传输的协议抽象。DistServe 把 KV cache 当成一阶公民,worker 之间通过显式的 RDMA write/recv 同步;Splitwise 则在用户态实现了类似 gRPC 的流式协议,把 KV cache 切成多个 segment 用 HTTP/3 + QUIC 传输。前者延迟更低但耦合性强(必须使用相同的硬件/驱动),后者灵活性高但需要在每条 segment 上做 checksum 和重传。在生产选型时,这一选择往往由公司现有的网络栈和硬件决定——有自研 RDMA 库的公司倾向 DistServe 风格,沿用 k8s + service mesh 的公司倾向 Splitwise 风格。
调度粒度的另一个差异在于 request migration 的频度。DistServe 假设一个请求 Prefill 完成后会稳定地待在某个 Decode worker 直到完成(长生命周期绑定),这种假设对长输出请求友好但对短输出请求造成资源浪费。Splitwise 引入了一种 "decode-side shedding" 机制:Decode worker 在 batch size 达到阈值时,可以把一部分请求的 KV cache 序列化到另一个 Decode worker,腾出资源给新请求。这种 worker-to-worker 迁移的代价远高于 Prefill-to-Decode 迁移(Splitwise 内部数据显示约为 3-5 倍),但比抢占(preemption)重建 KV cache 的代价低一个数量级。生产中两种策略通常并存:DistServe 风格作为默认路径,decode shedding 作为短请求高峰期的应急手段。
更细粒度的差异在 failure domain 的设计。DistServe 把 Prefill 和 Decode 视为对称的两个角色,任何一端失败都会导致请求失败,系统通过 supervisor 进程做 failover。Splitwise 的设计则把 Decode 视为 "有状态服务"(持有 KV cache)、把 Prefill 视为 "无状态服务"(每次重算代价可控),因此 Prefill worker 失败后系统可以选择让 Decode worker 重新 Prefill(代价是新延迟但正确性有保障),而 Decode worker 失败后系统必须先 eviction 掉该 worker 上的请求(通过 KV cache 重传或重算)。这两种 failure semantics 在生产事故处理时表现差异巨大:DistServe 风格的事故恢复路径短但耦合强,需要严格的 health check;Splitwise 风格的恢复路径长但每一步都可以 partial degrade。
vLLM 在 2025 年 Q3 把 disaggregation 合并进主分支,标志着这条路径从"学术实验"走向"开箱即用"。vLLM disaggregation 的实现要点有四个层面。
第一是 frontend API 的解耦。原本 vLLM 的 LLM 类既负责调度又负责执行,disaggregation 把它拆成 PrefillScheduler 和 DecodeScheduler,两者通过 KVCacheTransferEngine 通信。对用户而言,LLM.generate() 接口不变,内部自动选择走本地路径还是分离路径。
第二是 KV cache 的内存表示。vLLM 的 KV cache 用 PagedAttention 风格的 block table 管理,每个 block 16-128 个 token,跨 worker 传输时按 block 对齐传输而不是按 tensor。Block 对齐的好处是:(1) 传输单位固定,容易做 zero-copy; (2) Decode 端可以按需加载,不需要一次接收完整序列; (3) 校验粒度细,某 block 传输失败只需重传该 block。代价是首字节延迟略有增加,因为需要等第一个完整的 block 才能开始 Decode。
第三是 传输引擎的抽象层。vLLM 定义了 KVCacheTransferEngine 接口,内置了三种实现:NcclEngine(基于 NCCL 的 RDMA,延迟最低,要求同集群同网络)、MoriEngine(基于 Mooncake 的 transfer library,跨数据中心友好)、FileEngine(基于共享文件系统,适合小规模或调试)。这种 plug-in 设计让 vLLM 可以适配不同的硬件栈——比如 NVIDIA 的 Grace Hopper 集群用 NCCL 跑满 400Gbps,AMD MI300 集群用 RCCL,Cerebras / Groq 的 wafer-scale 系统甚至可以走 on-chip DMA。
第四是 scheduler 的协调协议。Prefill scheduler 调度一个请求时,需要先查询 Decode pool 的容量;Decode pool 需要维护一个"已分配但尚未开始的 slot 池",Prefill scheduler 在选定目标 Decode worker 后,先 reserve slot 再启动 Prefill;Prefill 完成后,KV cache 抵达 Decode worker,worker 在收到 KV cache 后才把 slot 标记为 active。这种 reservation 协议避免了"Prefill 完成但 Decode 满载,KV cache 没地方放"的死锁。
在 vLLM 官方 benchmark 上,分离架构对短请求(输入 < 256 token, 输出 < 128 token)的 P99 TTFT 改善约 1.5-2 倍,对长请求(输入 2K-8K token)的 P99 TTFT 改善 3-5 倍。TPOT 改善相对温和,但在混合负载下 P99 TPOT 改善约 1.3-1.8 倍。值得注意的是,分离架构的优势在小模型(7B-13B)和大模型(70B+)上都成立,但中模型(30B-40B)由于显存边界卡得紧,优势主要体现在 Prefill 长尾场景。
SGLang 把 disaggregation 的工程推到了另一条路径:RadixAttention + HiCache。RadixAttention 在 prompt 前缀重复的场景下,通过 radix tree 把多个请求共享的 KV cache 段复用,避免重复 Prefill。HiCache 把这个 radix tree 扩展到跨节点:多个 Decode worker 共享一个"远端 KV cache 池",节点之间通过 RDMA 读取需要的 cache 段。HiCache 的精妙之处在于,它不要求请求"完整地在某个节点上",而是可以分段——比如 Prefill 的前 10 层在一个节点完成,后 20 层在另一个节点完成,Decode 又在第三个节点开始——通过 radix tree 把 KV cache 串起来。
Mooncake(Moonshot AI 开源)的视角更激进,核心思想是 "以 KV cache 为中心重新设计整个 serving 栈"。Mooncake 不再把 Prefill worker 和 Decode worker 看作两个对称的角色,而是把 KV cache 看作第一公民:每个请求的 KV cache 在生成后立即被推送到一个分布式 KV cache 池(类似 CDN 的边缘缓存),后续的 Decode worker 可以从这个池里按需拉取。Mooncake 的传输层用了自研的 RDMA + async I/O,据官方报告在 Kimi 的生产环境上把 GPU 利用率从 60% 推到了 90%+。
这两个系统的工程差异反映在三个维度。第一,共享粒度:SGLang 的 HiCache 共享粒度是"段"(固定 token 数),Mooncake 是"页"(可变的 KV cache 块)。粒度越细,调度越灵活,但元数据开销越大。第二,副本策略:SGLang 默认单副本,HitMiss 时重新计算;Mooncake 默认双副本,通过 erasure coding 降低成本。第三,传输层:两者都用 RDMA,但 SGLang 复用 NCCL,Mooncake 用自研 Transfer Engine 集成 GPUDirect RDMA 和 NVMe-oF,在大模型(>100B)上延迟更低。
跨节点调度的另一个工程难题是 token 路由的全局一致性。当一个请求在 Prefill 节点 A 完成,但 Decode 节点 B 的 batch size 已经接近上限时,系统需要决定:是等待 B 腾出 slot,还是把请求改路到 Decode 节点 C。Mooncake 在生产中实现了一种 "two-phase routing":Prefill 完成后先在中间 staging buffer 暂存 KV cache,scheduler 异步选出一个 Decode 节点(可能是 B 也可能是 C),然后再传输。这种异步路由的关键是 staging buffer 的设计——它必须能容纳 5-30 秒内的所有 in-flight KV cache,在高峰期可能高达数百 GB,因此 staging 层通常用 NVMe SSD 而不是 GPU 显存。
进一步说,SGLang 和 Mooncake 在 "KV cache 生命周期管理" 上的哲学差异反映了两种不同的可观测性倾向。SGLang 的 HiCache 把 KV cache 的生命周期严格绑定到请求生命周期,cache 段随请求完成或失效而立即释放,优点是显存利用率高,缺点是无法跨请求复用(同一个 prefix 的两个请求必须等到第二请求再次 Prefill 才能复用 KV)。Mooncake 则把 KV cache 视为 "软状态",允许它在请求完成后在 cache 池中保留一段时间(TTL 通常 5-60 分钟),等待后续同 prefix 请求复用。这种设计在长 prompt 重复场景(代码补全、文档问答)上有显著收益,但需要额外的 cache eviction 策略(类似 CDN 的 LFU + recency 混合策略)。生产选型时,长 prompt 重复率 > 30% 的应用倾向 Mooncake,反之倾向 SGLang。
跨节点调度还要解决一个棘手问题:expert parallelism 与 PD 分离的冲突。MoE 模型(如 Mixtral、DeepSeek-V3)在 Prefill 时每个 token 路由到 8 个 expert,在 Decode 时同样需要路由到 8 个 expert,但 expert 是分布在不同 GPU 上的。如果 Prefill worker 和 Decode worker 看不到同一组 expert,KV cache 里存储的 expert ID 就对不上号。DeepEP(DeepSeek 开源)和 Wide-EP 协议就是为这个问题设计的:它们把 expert 路由信息嵌入到 KV cache metadata 里,Decode worker 在加载 KV cache 时根据 metadata 动态从 expert pool 拉取所需的 expert weights。这一抽象让 MoE 模型也能享受 PD 分离的红利,代价是 Decode worker 需要预留一份"影子权重表",显存开销增加约 5-8%。
把 PD 分离架构形式化,可以用一个三层的图来描述:请求层(用户请求的到达过程,通常用泊松分布或重尾分布建模)、资源层(Prefill pool 和 Decode pool 的容量,以及它们之间的传输通道带宽)、缓存层(KV cache 在传输通道上飞行的中间状态)。整个系统的状态空间是 (Prefill queue, in-flight KV cache, Decode queue) 的三元组。
在稳态下,系统的吞吐量受限于 min(Prefill pool throughput, Decode pool throughput, transmission bandwidth)。Prefill pool 的吞吐取决于 GPU 数量 × 单卡 Prefill 速度,主要受算力约束;Decode pool 的吞吐取决于 GPU 数量 × 单卡 Decode 速度,主要受访存带宽约束;transmission bandwidth 取决于 RDMA 网络容量 × 单请求 KV cache 大小。在典型生产配置(8 卡 Prefill pool + 32 卡 Decode pool + 400Gbps RDMA)下,transmission 往往不是瓶颈,但当 Decode pool 扩展到 64 卡以上,单条 KV cache 传输可能撞到 NIC 的 PCIe 带宽上限,这时 transmission 会反向制约 Prefill pool 的吞吐。
排队论视角给出一个反直觉的洞察:Decode pool 不是越大越好。当 Decode pool 扩大时,每个 worker 分到的请求减少,batch size 下降,单卡利用率下降,TPOT 反而恶化。这种"集群规模不经济性"在 Prefill pool 上不明显(因为 Prefill 是 compute-bound,GPU 越多越好),但在 Decode pool 上显著。一个经验法则是:Decode pool 的容量应该匹配稳态下的 batch size 目标,通常比 Prefill pool 小 4-8 倍。这个比例和 DistServe 论文里的最优配置吻合。
更深一层,Prefill-Decode 之间的传输通道可以建模成 flow shop scheduling:每个请求是一个 job,需要先在 Prefill 机器上加工,再在 Decode 机器上加工,中间有一个传输"工序"。Flow shop 的 makespan 优化问题没有多项式解,但有一些启发式规则可用:(1) 同号请求优先(同 prefix 的请求尽量在同一个 Decode worker 处理,共享 KV cache);(2) 短请求优先(减少 P99 TTFT 的尾延迟);(3) 平衡传输通道的双向流量(避免 RDMA 的某个方向拥塞)。这三条规则在 vLLM 和 SGLang 的 scheduler 里都有体现。
对负责 LLM serving 平台的工程师而言,分离架构的选型可以按以下决策树推进:
第一步:你的负载是 Prefill-bound 还是 Decode-bound?用一个月生产 trace 统计 (input token 数, output token 数, 请求到达率) 三元组的分布。如果平均 input:output 比 > 1:5,大概率 Prefill-bound;反之 Decode-bound。Prefill-bound 的应用(文档摘要、长 prompt 问答)优先分离,Decode-bound 的应用(短对话、代码补全)可以先用 Chunked Prefill 缓解,等规模再上分离。
第二步:你的 Prefill worker 和 Decode worker 应该放在同一台机器还是分机器?同一台机器的好处是传输走 NVLink,延迟 < 100μs;分机器的好处是资源调度灵活,可以根据负载独立扩缩容。经验法则:当模型 ≤ 13B 时,同机分离更优(传输是主要瓶颈);当模型 > 70B 时,分机分离更优(资源池独立调度收益更大)。
第三步:传输引擎选哪个?如果你的集群是 NVIDIA Hopper/Blackwell 独享,NCCL 即可;如果是异构(AMD + NVIDIA)或跨数据中心,选 Mooncake transfer engine 或 NIXL;如果只是几百 QPS 的中等规模,HTTP/3 + QUIC 也能跑(但延迟会比 RDMA 高 5-10 倍)。
第四步:如何处理 Prefill worker 的请求调度?核心原则是短请求优先 + 容量感知。短请求优先降低 P99 TTFT;容量感知避免 Prefill worker 拼命 Prefill 但 Decode pool 已满,KV cache 堆积在传输通道上。DistServe 的 admission control 给出了一个简单公式:if (Decode pool occupancy > 0.8) then throttle Prefill worker。
第五步:如何处理 KV cache 传输失败?RDMA 偶发的传输错误在生产集群是常态(每周 1-3 次,常见原因是 NIC 抖动或 PCIe 错误)。处理策略:(1) block-level checksum + retry(vLLM 默认);(2) 跨 worker 副本(Mooncake 风格,代价是双倍网络带宽);(3) fallback 到同机共享引擎(成本是丢一些延迟收益,但保证 SLA)。生产中通常三者并存:小流量走 fallback,中等流量走 retry,大流量走副本。
第六步:可观测性埋点。三个核心指标必须监控:(1) Prefill 池利用率 (2) Decode 池利用率 (3) KV cache 传输 P99 延迟。三者任何一个异常都会迅速反映到用户体验——Prefill 利用率高导致 TTFT 恶化,Decode 利用率高导致 TPOT 恶化,传输延迟高导致端到端延迟恶化但单边利用率正常(最容易被忽略)。
分离架构不是银弹,它有三个明显局限。
第一个局限是显存开销。KV cache 在传输通道上飞行时,Prefill worker 必须保留一份(否则传输失败没法重传),Decode worker 必须预留一份 slot(否则 KV cache 到了没地方放),中间还可能有 network buffer。三份拷贝叠加,在 70B 模型 + 8K context 下,额外显存开销约 15-20%。对显存紧张的部署(单卡 / 双卡),这个开销是显著的。
第二个局限是跨请求的 KV cache 复用被削弱。分离架构下,Prefill worker 完成的 KV cache 飞到 Decode worker,如果同一 prefix 的另一个请求恰好落在另一个 Decode worker 上,KV cache 复用就 broken 了。HiCache 这类 radix-based 方案能部分缓解,但需要 Decode worker 之间共享 cache 池,工程复杂度上升。
第三个局限是 admission control 的难度。共享架构下,scheduler 只需要一个队列;分离架构下,需要协调 Prefill scheduler、Decode scheduler、传输 scheduler 三个队列,任何两个之间的不一致都会导致死锁或抖动。生产中通常引入一个 central coordinator,但 coordinator 自身就成为单点瓶颈——分布式 coordinator(如 SGLang 的 HiCache coordinator)可以缓解,但增加了系统复杂度。
与"完全分离"相对的另一个流派是"柔性分离"——即保留单引擎架构,但在引擎内部动态调整 Prefill/Decode 的资源比例。比如 Sarathi-Serve 的 chunked Prefill + decode batching,TGI 的 prefill-decode 模式切换,字节的 HybridFlow。这些方案的工程代价低,但优化上限也低。经验法则:日均请求量 < 100 万次用柔性分离,> 1000 万次用完全分离,中间区间根据团队工程能力选择。
最后一节是给运维同学的可执行清单。监控面板上至少要暴露以下指标:
Prefill 池指标:Prefill 任务 P50/P99 延迟、Prefill 池 GPU 利用率、Prefill worker 数(应支持自动扩缩容)、Prefill 队列深度(超过阈值触发 admission control)。
Decode 池指标:Decode 任务 P50/P99 TPOT、Decode 池 GPU 利用率、Decode worker 数、活跃请求数(per worker)、batch size 分布(P50/P99 batch size,过小说明 worker 太多或请求稀疏)。
传输通道指标:KV cache 传输 P50/P99 延迟、传输带宽利用率(双向)、传输失败率 + 重试次数、传输通道的拥塞窗口大小(NCCL/TCP 都有这个指标)。
端到端指标:TTFT P50/P99、TPOT P50/P99、总 QPS、有效吞吐(output token / 秒 / 卡)、SLO 命中率(TTFT < 500ms 的请求比例、TPOT < 50ms 的请求比例)。
告警阈值建议:Prefill 利用率持续 > 80% 超过 5 分钟(考虑扩容);Decode 利用率持续 > 85% 超过 10 分钟(同上);KV cache 传输 P99 > 50ms(检查 RDMA 健康度);传输失败率 > 0.1%(检查 NIC/光模块);TTFT P99 突破 SLO 阈值 1.5 倍(立即触发 admission control 收紧)。
故障演练:每月一次 chaos test,模拟 Prefill worker 全部宕机 / Decode worker 半数宕机 / RDMA 通道丢包率 1% / NIC 单边故障 四种场景,验证系统的 graceful degradation 行为。每次演练后更新 runbook,记录实际恢复时间(MTTR)。
一句话摘要:把 Prefill 的算力密集型特征与 Decode 的访存密集型特征分离到不同 worker,通过 KV cache over RDMA 跨节点传输,把端到端 P99 TTFT 与 TPOT 同时压到单引擎极限之上——这是 LLM serving 在 2026 年的核心架构升级。
Conversation
0 条