PD分离和AFD系统探索

骏马能历险，力田不如牛；坚车能载重，渡河不如舟。 —— 清·顾嗣协《杂兴》

1 概述

大语言模型的推理服务已从单卡执行演变为跨节点的分布式系统。规模扩大之后，一个早先被掩盖的事实变得突出：同一模型内部，不同组件对算力、显存带宽、显存容量与网络的需求并不一致，有时彼此冲突。将资源需求相异的部件绑定在同一组加速器上，必然闲置其中的一种资源。近两年推理系统研究的相当一部分工作，正是沿着按特征分工这条线索展开的。

最先被拆开的是请求生命周期上的两个阶段。Prefill（预填充）将整段输入一次并行处理，生成 KV Cache 与首个输出 token，计算量随序列长度平方增长，属于计算受限；Decode（解码）以自回归方式逐 token 生成，每一步都要把全部模型权重和不断增长的 KV Cache 从显存读一遍，算术强度极低，属于带宽受限。二者分别决定首 token 延迟（TTFT）与逐 token 延迟（TPOT），却共享同一套并行配置与批处理策略：长 Prompt 的突发计算会拖慢正在流式输出的请求，反之亦然。PD 分离（Prefill-Decode Disaggregation）把两个阶段放到各自的资源池上，代价是在它们之间搬运一次 KV Cache。

拆到层一级，还有第二处错配。Attention 子层持有每个请求私有的 KV Cache，无论批处理多少请求都必须逐请求读取，始终落在带宽受限区；FFN 子层的权重为批内所有 token 共享，算术强度本可随批量线性增长，但稀疏 MoE 的路由把全局批次打散到数百个专家上，每个专家只分到几十个 token，反而退化为访存受限。AFD（Attention-FFN Disaggregation）把两类子层放到不同 GPU 池，让 Attention 以数据并行聚合请求、让专家以专家并行汇聚 token，代价是每生成一层、每个 token 都要往返传输两次激活值。

本文先用 Roofline 模型把这两处错配量化，再分别梳理 PD 分离与 AFD 的系统设计、通信机制与适用边界。文中所引性能数字多出自作者或厂商自报，缺少第三方复现，相应位置均已标明。

2 分析工具：算术强度与 Roofline 模型

2.1 自回归生成与 KV Cache

Decoder-only Transformer 的推理是自回归过程。给定输入 $\mathbf{x} = (x_1, \ldots, x_n)$，Prefill 阶段并行处理全部 $n$ 个 token，逐层计算 Key、Value 并缓存为 KV Cache，同时产出第一个输出 token $y_1$。此后第 $t$ 步以 $y_t$ 为输入，结合缓存中的历史 Key/Value 计算注意力，生成 $y_{t+1}$ 并追加新 token 的 Key/Value，直至遇到终止符。

Prefill 处理的是 $n \times d$ 的完整激活矩阵（$d$ 为隐藏维度），Decode 每步只处理 $1 \times d$ 的单 token 向量，却仍需读取全部权重与不断增长的缓存。前者是一次性的大规模并行计算，后者是串行的逐步迭代——这一形状上的差别，是后文全部推导的起点。

2.2 算术强度与 Roofline 模型

一个操作的算术强度（arithmetic intensity）定义为它执行的浮点运算次数与从内存读取的字节数之比：

它度量每搬运一字节数据能完成多少计算。算术强度高，说明数据被充分复用；低，则说明时间主要耗在数据搬运上，计算单元空转。Williams 等人在 2009 年提出的 Roofline 模型据此把硬件的两个上限——峰值算力 $\pi$（FLOPs/s）与峰值带宽 $\beta$（Bytes/s）——压缩成一个脊点：

算术强度低于 $I^$ 的操作受限于带宽，高于 $I^$ 的操作受限于算力。以 NVIDIA A100 SXM 的 FP16 Tensor Core 计，$\pi = 312$ TFLOPs/s，$\beta = 2039$ GB/s，脊点约 153 FLOPs/Byte。这个数字随后会成为一把尺子：只需把各组件的算术强度算出来，就能判断它们落在尺子的哪一侧，以及分离是否值得。

2.3 Prefill 与 Decode

以线性投影为例可以看得最清楚。Prefill 阶段输入 $\mathbf{X} \in \mathbb{R}^{S \times d}$，权重 $\mathbf{W} \in \mathbb{R}^{d \times d}$，计算 $\mathbf{X}\mathbf{W}$ 需 $2Sd^2$ 次浮点运算，权重读取量为 $d^2 b$ 字节（$b$ 为每参数字节数），于是

取 $S = 4096$、$b = 2$（FP16），得 4096 FLOPs/Byte，比 A100 的脊点高出一个数量级以上。Prefill 的瓶颈在算力，提高 FLOPS 能直接缩短 TTFT。若再计入注意力的 $O(S^2)$ 项，长上下文只会把算术强度推得更高。

Decode 阶段输入退化为 $\mathbf{x} \in \mathbb{R}^{1 \times d}$，运算量降为 $2d^2$，权重读取量却不变：

每步还要读取 KV Cache。第 $l$ 层若有 $H_{kv}$ 个 KV 头、每头维度 $d_h$，已生成 $t$ 个 token 时的缓存读取量为 $2 t H_{kv} d_h b$ 字节，对应的运算量只与 $t$ 成线性关系。实测的 Decode 核心算术强度大致落在 1–10 FLOPs/Byte，远在脊点左侧；此时增加算力几乎无效，只有提升带宽或减少搬运量才能改善 TPOT。

两个阶段在 Roofline 图上分居两端。把它们绑在同一块 GPU 上，一方忙碌时另一方的资源必然闲置，这正是 PD 分离要消除的浪费。

2.4 Attention 与 FFN

Decode 阶段的 Attention 需要读取当前请求自己的 KV Cache。由于缓存按请求私有，增加并发并不能让多个请求共用同一份读取，算术强度不随批量变化，Attention 在任何批量下都保持带宽受限。FFN 则不同：权重为批内全部 token 共享，算术强度近似

其中 $B$ 为批内 token 数。只要批量足够大，FFN 就能跨过脊点。Attention 有状态、随序列长度和并发数扩展，FFN 无状态、只取决于到达的 token 数，二者的扩展维度本就不在同一方向上。

稀疏 MoE 打破了后一个前提。设每个 token 激活 $k$ 个专家、专家总数为 $E$，则全局批次 $B$ 分摊到单个专家的平均 token 数为 $B k / E$。MegaScale-Infer 给过一个便于核对的算例：A100 上 bfloat16 GEMM 至少需要 156 个 token 才进入计算受限区；Mixtral 8×22B 采用 top-2 路由、8 个专家，156 个 token 打散后每个专家只分到约 39 个，理论利用率 25%。DeepSeek-V3 每 token 激活 256 个专家中的 8 个，稀释更甚。靠增大全局批量来补偿又受限于延迟目标和 KV Cache 的显存占用，而这部分显存恰与庞大的专家权重相争。于是 FFN 从本应计算受限的算子退回访存受限区，与 Attention 一起把 GPU 的两端资源轮流浪费掉。AFD 的动机即在于此。

3 PD分离

3.1 同址部署的资源竞争

传统同址部署让 Prefill 与 Decode 共享同一组 GPU，在规模不大时并无不妥。并发量与序列长度上来之后，矛盾便一处接一处地显现。

一次长输入 Prefill 会瞬间占满算力，使同批次中正在 Decode 的请求出现尾延迟；反过来，大量并发 Decode 的访存压力也会推迟新请求的 Prefill，抬高 TTFT。两个阶段的延迟目标又彼此独立——TTFT 决定用户等待首字的时间，TPOT 决定流式输出的连贯性——同址系统只能顾此失彼，或者靠过量配置同时兜住两者。并行策略同样被绑定：Prefill 偏好较大的张量并行度以加速 GEMM，Decode 偏好较小的并行度以减少通信、留出更多显存放 KV Cache。硬件选型上也难两全，Prefill 要高 FLOPS，Decode 要大容量高带宽，同构集群只能迁就其一。

3.2 系统架构

PD 分离把两个阶段放到独立的 GPU 资源池上，各自伸缩、各自调度、各自选择并行度。Prefill 池由若干 Worker 组成，专职编码输入并生成 KV Cache，适宜部署高算力卡；Decode 池持有传输来的缓存并完成全部自回归生成，适宜部署大显存高带宽卡。前端路由器把 Prompt 派给某个 Prefill Worker，待其完成后选定 Decode Worker 交接，此后由后者流式返回直至结束。两池之间的 KV Cache 传输层是这套架构新增的、也是最要紧的一环。

一次请求的路径是：路由 → Prefill（生成 KV Cache）→ 传输 → Decode（自回归输出）→ 响应。表面上只多了一步搬运，调度、并行度与硬件选型却都从此解耦。

3.3 KV Cache 传输

3.3.1 传输量

设模型有 $L$ 层、$H_{kv}$ 个 KV 头、每头维度 $d_h$，FP16 精度下长度 $S$ 的 KV Cache 为

LLaMA-2-70B 取 $L = 80$、$H_{kv} = 8$、$d_h = 128$、$b = 2$，$S = 4096$ 时约为 1.3 GB。在 200 Gbps 的 InfiniBand 链路上，理论传输下限约 54 ms；实际可达带宽低于标称值，开销还会更大。Prompt 短时这笔开销可能吃掉分离的全部收益；长 Prompt 下传输时间相对 Prefill 计算时间的占比下降，分离才划算。这也解释了为何 PD 分离最先在长文档、RAG 一类负载上落地。

3.3.2 隐藏传输延迟的做法

SplitWise 采用逐层流水：不必等整个 Prefill 结束，第 $l$ 层算完即异步发送该层 KV，末层完成时前序各层多已抵达，传输被计算盖住大半。Mooncake 的 Transfer Engine 走的是另一条路，用 RDMA 直接在对端显存间搬运，绕过 CPU 中转，并按拓扑在 NVLink、InfiniBand、RoCE 与以太网之间选路，还允许多网卡聚合带宽。NVIDIA 的 NIXL 把这类搬运抽象成统一接口，供 vLLM 等引擎按后端接入，省去每家各写一套。

Mooncake 进一步把 KV Cache 提升为可调度的资源：集群中各节点的 HBM、DRAM 与 NVMe 组成分级池，请求结束后的缓存不立即丢弃，供共享前缀的后续请求复用。全局调度器 Conductor 依据缓存所在位置派发请求，能命中前缀时连 Prefill 也一并省去。据项目报告，Kimi 真实流量下有效请求容量提升约 75%，长上下文场景的仿真结果更高；这组数字尚无第三方复现。

3.3.3 交接约束

两端 Worker 必须对缓存的内存布局、分页粒度、数据类型、注意力变体（MHA、GQA、MQA、MLA）及附加元数据达成一致。量化 KV Cache、视觉编码器状态、投机解码缓存等异构类型会让这份契约变得繁琐，也是工程实现中最容易出错的地方。

3.4 资源分配与并行策略

分离之后，Prefill 与 Decode 的 GPU 数量和并行配置可以分别求解。DistServe 把这件事写成了一个优化问题。设 Prefill 实例用 $K_p$ 块 GPU、配置 $c_p$，Decode 实例用 $K_d$ 块 GPU、配置 $c_d$，总预算 $N_{\max}$；以 goodput 记在 TTFT、TPOT 达标率不低于 $\alpha$ 的条件下每 GPU 可维持的最大请求速率：

$g_p$ 与 $g_d$ 由离散事件仿真在给定负载和 SLO 下估出，再枚举显存允许的全部并行组合，取使 $G$ 最大者。带宽有限的集群还需带宽感知放置：把往来频繁的 Prefill 与 Decode 实例排在高速互联可达的节点上，压低交接延迟。

配置比例最终由负载形状决定。长输入短输出（摘要、抽取）偏向多配 Prefill，短输入长输出（代码生成、长推理链）偏向多配 Decode。SplitWise 的测量表明，最优比例随平均输入长度与输出长度连续移动，并不存在一个通用定值。

3.5 代表性系统

3.5.1 DistServe（OSDI 2024）

DistServe 最早把 TTFT 与 TPOT 列为彼此独立的优化目标，为两阶段分别选定张量并行与流水并行度，并以带宽感知放置控制分离引入的通信。论文正式版报告，在 90% 以上请求满足延迟约束的前提下，可比同址系统多承载 7.4 倍请求，或将 SLO 收紧 12.6 倍；分场景结果中，摘要负载的 goodput 约为 vLLM 的 4.48 倍。arXiv 初版摘要曾以 4.48 倍请求量、10.2 倍 SLO 作为总体数字，引用时需注明版本。

3.5.2 SplitWise（ISCA 2024）

SplitWise 从硬件成本切入：Decode 用不到顶级算力，何必为它付顶级卡的价钱。把高 FLOPS 卡（H100）留给 Prefill、高带宽卡（A100）留给 Decode，在等性能下可降约两成成本，等成本下可得约 1.4 倍吞吐；在等功耗预算下，论文报告最高 2.35 倍吞吐。除了前述逐层流水传输，这项工作还给出了按输入/输出长度配比两池规模的经验规律。

3.5.3 Mooncake（FAST 2025）

Mooncake 是 Moonshot AI 支撑 Kimi 服务的生产系统，获 FAST 2025 最佳论文。它以 KV Cache 为中心组织整个调度栈：分级缓存池、按缓存位置路由的 Conductor、前缀复用，以及预测性准入控制——在接纳请求前先估计其是否会拖累既有请求的 SLO，不满足则提前拒绝，宁可干净地回绝一个，也不让全体变慢。其 Transfer Engine 于 2024 年 11 月开源，同年 12 月被 vLLM 纳入连接器选项。

3.5.4 工程生态与后续工作

到 2026 年，PD 分离已进入主流引擎：vLLM 通过 NIXL 与 Mooncake 风格连接器提供（仍属实验性的）解耦 Prefill，SGLang 把 RadixAttention 的前缀树与 RDMA 传输结合，TensorRT-LLM 与 NVIDIA Dynamo 分别提供引擎层与编排层支持。也有工作反向利用分离后的闲置资源：Adrenaline 注意到 Prefill 实例显存利用率偏低、Decode 实例算力利用率偏低，遂把 Decode 阶段的部分 Attention 计算卸载到 Prefill 实例，同时抬高两端的利用率，报告约 1.68 倍整体吞吐。国内亦有厂商提出 Prefill、RelayDecode、MainDecode 三级分离的架构，公开资料尚未给出完整评测。

3.6 适用边界

PD 分离是一种延迟隔离与资源分配手段，并不天然带来吞吐提升；vLLM 文档对此有明确提醒。收益来自消除干扰、独立伸缩与异构适配，代价是缓存搬运。适用的负载通常是输入长、并发高、TTFT 与 TPOT 都要求严格，或集群本就混布着不同代际的卡。输入短而输出长的轻量对话、低并发的离线批处理，以及互联带宽不足的环境，同址部署反而更简单也更划算；有实测报告称，规模偏小或配比未调优时分离会损失 20%–30% 性能。

4 AFD（Attention-FFN Disaggregation）

4.1 动机

PD 分离在请求级别解耦了阶段，Decode 阶段内部 Attention 与 FFN 仍共处一卡。如 §2.4 所述，前者的容量随请求状态、序列长度与缓存压力扩展，后者的容量随 token 路由与专家负载扩展；前者承担调度、缓存协调与采样，后者只需激活值、路由元数据和一条把结果送回的通路。共享同一 Worker 拓扑，等于强迫两类负载接受同一套扩展与执行决策。

MoE 稀疏性把矛盾推到必须解决的地步。要提高专家利用率，就得把多个 Attention 副本的 token 流汇入同一个专家池；这在物理上先要求 Attention 与 FFN 分开部署。这一判断构成了 AFD 的出发点，也决定了它的通信代价必然出现在关键路径上。

4.2 系统架构

AFD 把每层的 Attention 子层与 FFN 子层放到两个 GPU 池。Attention 池保存注意力参数与 KV Cache，以数据并行复制副本来聚合请求，节点内辅以张量并行；FFN 池按专家并行铺开专家参数，同样可在节点内做张量并行。两侧各自选定 rank 拓扑，不必强求一致。

请求始终发往 Attention 侧的 API Server，调度器、KV Cache、批处理与采样路径都留在那里。FFN 侧没有请求流量，也没有调度器，只是一个由连接器驱动的守护进程：收到激活值与元数据，调用专家计算，把结果送回。在每个切分点上，连接器负责 Attention 输出到 FFN、FFN 输出回 Attention 的往返，同时把通信实现按后端隔开——CUDA 与昇腾的集合通信库、图运行时和 MoE 算子各不相同，共用一份连接器契约比共用一份实现更稳妥。vLLM 的 AFD 插件正是按这个思路接入的，通过插件入口与配置通道完成集成，未改动引擎源码。

4.3 乒乓流水线

若把整个批次在两池之间来回传，一侧计算与数据在途时另一侧只能空等。AFD 系统因此把全局批次切成 $m$ 个微批次错峰推进，让一个微批次在 Attention 的同时，另一个在 FFN，第三个在路上。记 $T_a$、$T_e$ 为单微批次在两侧的计算时间，$T_c$ 为单向通信时间，$T_f = \max(T_a, T_e)$，完全掩盖通信所需满足

链路足够快（$T_c < T_f/2$）时三个微批次即可，较慢的链路需要四个。MegaScale-Infer 的消融实验显示，$m$ 从 1 增到 2 带来约 1.9 倍吞吐，继续增加还能再得 1.10–1.38 倍。

流水线抬高的是利用率，不是单个微批次的速度，排队甚至可能略增延迟。Step-3 把 50 ms 的 TPOT 预算三等分给 Attention、FFN 与通信，61 层分摊下来每级每层只有约 272 μs，这个量级构成了通信库和弱侧硬件的硬约束。2026 年的几项分析工作把无气泡所需的最小重叠称为三批次重叠（3BO），并指出它同时收窄了系统对抖动的容忍度：任一阶段超时，气泡会沿两个方向往回传播。聚合式的大规模专家并行解码通常只需零到两批次重叠，稳健性反而更好。

4.4 通信

两侧的任意并行度叠加后，注意力侧 $M$ 块 GPU 与专家侧 $N$ 块 GPU 之间形成 M-to-N 的动态路由，而非规整的集合通信。NCCL 一类面向集合操作的库在这类模式下开销明显：GPU 到 CPU 的拷贝、每次调用的组初始化、以及同步等待。

MegaScale-Infer 为此写了 M2N 库：以 GPUDirect RDMA 的 write-with-immediate 直发对端显存，启动时预注册全部通信缓冲区，收发不启动 GPU kernel，把流多处理器完整留给计算。在 MoE dispatch 典型的 256 KB 消息上，报告吞吐为 NCCL 的 4.2 倍、中位延迟低 68.2%。StepFun 随 Step-3 开源的 StepMesh 思路相近，把 RDMA 操作放到 CPU 线程执行，预注册张量以免在关键路径上做序列化与拼接。两者都把”通信不抢计算资源”当作设计前提。

4.5 异构部署

异构是 AFD 最容易兑现的一项收益。MegaScale-Infer 在生产中把 Attention 放在大显存高带宽的 H20、把专家放在算力性价比更高的 L40S 上；相比全 H20 的 TensorRT-LLM 基线，单位成本解码吞吐提高 1.86 倍（含 Prefill 的端到端为 1.66 倍），单位功耗吞吐提高 1.80 倍（端到端 1.72 倍）。字节跳动称该系统已运行于近万卡生产集群，同等流量下服务成本降低 1.5–2.0 倍；这属公司自报口径。

4.6 代表性系统

4.6.1 MegaScale-Infer（SIGCOMM 2025）

MegaScale-Infer 提出解耦专家并行：Attention 以数据并行复制，专家以专家并行铺开，配合乒乓流水线与 M2N 通信库，并用性能模型自动求解给定硬件下的节点数与张量并行度。真实流量中专家激活频率不均，系统按历史热度为高频专家加设备冗余以平衡负载。在 Mixtral 8×22B、DBRX 与 317B ScaledMoE 上，解码吞吐较 vLLM、TensorRT-LLM 提高 1.28–2.56 倍；317B 模型上相对 vLLM 最高达 7.11 倍。论文摘要的概括口径是单卡吞吐较当时最优系统最高提升 1.90 倍，两组数字对应不同基线，不宜混用。

更早的 Lamina（2024）已从异构角度做过同类尝试：把 KV Cache 与注意力算子交给廉价的内存优化设备，其余算子留在高端加速卡上，在同等成本下报告 16.1%–90.1% 的吞吐增益。它验证了”注意力与非注意力部件可分置异构硬件”这一前提，只是尚未引入按专家并行的 FFN 池。

4.6.2 Step-3 与 StepMesh（2025）

Step-3 是围绕 AFD 约束反向设计模型的例子。这个 321B 参数、每 token 激活 38B 的视觉语言模型，用 Multi-Matrix Factorization Attention 压低 KV Cache 与注意力计算量，并把注意力算术强度与 MoE 稀疏度选成让两侧在 50 ms TPOT 内都贴近各自硬件的 Roofline 上限。Hopper GPU 上、4K 上下文、FP8、不启用多 token 预测时，报告解码吞吐 4,039 tokens/s/GPU，同条件下 DeepSeek-V3 为 2,324。模型与系统协同设计在这里不只是口号，而是把通信预算写进了架构参数。

4.6.3 vLLM AFD Plugin（2026）

vLLM 于 2026 年 7 月发布实验性 AFD 插件，保留原有请求生命周期与 OpenAI 兼容接口，把 FFN 路径拆成可独立扩展的服务。插件支持 NVIDIA GPU 与昇腾 NPU、同步与异步连接器、DeepSeek V2/V3 系列模型包装器，以及 eager、图与双批次执行路径；各后端的图行为与通信实现彼此隔离。项目自述仍需在不同硬件上做更大规模验证。

4.7 适用边界

AFD 的收益有明确的前提。它倾向于在 MoE 模型、以单用户延迟为首要目标、互联充裕的超节点硬件，以及可混布异构卡的环境里占优；在以原始吞吐为唯一目标、普通互联集群上的大规模专家并行聚合部署里未必划算。已发表的结果几乎都来自 MoE，稠密模型上能否成立仍是开放问题。2026 年出现的多项分析工作亦指出，AFD 提高的是延迟上限与单位成本效率，而非无条件的吞吐冠军。

5 两种分离的关系

PD 分离与 AFD 作用在不同粒度上，可以叠加。

前者沿请求的生命周期切，一次交接之后 Decode 池内闭环；后者沿每一层的执行切，激活值在每个 decode step 的每一层都要往返一次，因此必须与微批次流水线和专用通信库绑定讨论。二者叠加后，Decode 阶段的 Attention 与 FFN 分处不同 GPU，Prefill 与 Decode 也分处不同 GPU，资源分配的自由度更大，调度与容错的复杂度也更高。生产中的收益目前主要来自以 AFD 为主、以异构部署为手段的组合。

6 开放问题

两类分离能否回本，最终都取决于搬运延迟。无论传输的是 KV Cache 还是激活值，NVLink 与 CXL 一类更快的互联、更细的通信-计算重叠、以及缓存的量化压缩，仍是三条在推进的路线；其中量化传输还须先解决 §3.3.3 所述的交接契约问题。

静态配比只对某一时段的流量成立。实际负载里 Prefill/Decode 的比例、Attention/FFN 的压力都在漂移，而分队列调度、弹性伸缩与按负载实时再分配，目前仍缺成熟的控制器。

数据中心里多厂商加速卡共存已是常态，但通信规则、数据格式与性能特性各异。连接器抽象能否成为跨设备的稳定契约，比某一处单点优化更影响落地。

稠密模型缺少 MoE 稀疏性带来的那重错配，分离是否仍值得，尚无定论。再往下走，还可以在算子级甚至算子内部继续切分；前述三级分离架构已给出雏形，公开评测却不足。

投机解码、多 token 预测、KV Cache 压缩与量化都会改变每一步的计算量和传输量，与分离架构如何耦合尚未厘清。把算法假设写进系统设计，或按系统约束反过来设计模型，Step-3 提供了一个可参照的样本。

7 参考文献

[1] Williams S, Waterman A, Patterson D. Roofline: An Insightful Visual Performance Model for Multicore Architectures[J]. Communications of the ACM, 2009, 52(4): 65–76.

[2] Zhong Y, Liu S, Chen J, et al. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving[C]// Proceedings of the 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 2024). 2024: 193–210. arXiv:2401.09670.

[3] Patel P, Choukse E, Zhang C, et al. Splitwise: Efficient Generative LLM Inference Using Phase Splitting[C]// Proceedings of the 51st Annual International Symposium on Computer Architecture (ISCA 2024). 2024. arXiv:2311.18677.

[4] Qin R, Li Z, He W, et al. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving[C]// Proceedings of the 23rd USENIX Conference on File and Storage Technologies (FAST 2025). 2025. arXiv:2407.00079.

[5] Kwon W, Li Z, Zhuang S, et al. Efficient Memory Management for Large Language Model Serving with PagedAttention[C]// Proceedings of the 29th ACM Symposium on Operating Systems Principles (SOSP 2023). 2023: 611–626.

[6] Chen S, Xiao W, Lin Y, et al. Efficient Heterogeneous Large Language Model Decoding with Model-Attention Disaggregation[EB/OL]. arXiv:2405.01814, 2024. （系统实现 Lamina）

[7] Liang Y, Chen Z, Zuo P, Zhou Z, Chen X, Yu Z. Injecting Adrenaline into LLM Serving: Boosting Resource Utilization and Throughput via Attention Disaggregation[EB/OL]. arXiv:2503.20552, 2025.

[8] Zhu R, Jiang Z, Jin C, et al. MegaScale-Infer: Efficient Mixture-of-Experts Model Serving with Disaggregated Expert Parallelism[C]// Proceedings of the ACM SIGCOMM 2025 Conference. 2025: 592–608. arXiv:2504.02263.

[9] StepFun Team. Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding[EB/OL]. arXiv:2507.19427, 2025.

[10] StepFun. StepMesh[CP/OL]. https://github.com/stepfun-ai/StepMesh, 2025. Apache-2.0.

[11] vLLM Project. Announcing vLLM AFD Plugin: Disaggregating Attention and FFN for Flexible MoE Serving[EB/OL]. https://vllm-project.github.io, 2026-07-23.

[12] vLLM Project. Disaggregated Prefilling (V1)[EB/OL]. vLLM Documentation, 2025–2026.