tech/知识/微信公众平台/小哥人工智能笔记/2026-08-05_当PD分离成为标配_推理的未来在AFD.md

当 PD 分离成为标配，推理的未来在 AFD

来源：微信公众平台（小哥人工智能笔记）
作者：小哥人工智能笔记
发布日期：2026-08-05（原文未标注明确日期，按下载日占位；解读论文 arXiv:2605.28302 为 2026-05）
原文链接：https://mp.weixin.qq.com/s/5YsLOl4oIfHzNdi8pbmURQ

---

推荐理由：在 PD 分离已经成为集群分布式推理标配的时候，推理系统未来的方向走向了 AFD，这篇文章不是从 AFD 方案本身入手，而是从 AFD 的建模配比入手，给出指导。

过去两年，大模型推理系统的（disaggregation）浪潮走得比大多数人想象得更快。先是 chunked-prefill 把 prefill 和 decode 塞进同一个批次；接着 prefill–decode（P/D）分离把计算密集的 prefill 与访存密集的 decode 拆到不同机器池；而现在，Georgia Tech、Intel、Google、Google DeepMind 联合的一篇工作（arXiv:2605.28302《How Far Can Disaggregation Go?》）把解聚的刀进一步切进了每一个 Transformer 块内部——把 Attention（注意力）和 FFN（前馈网络）也拆到不同的 GPU 组上执行。这种被称为 Attention–FFN Disaggregation（AFD，注意力–前馈解聚） 的算子级解聚，正是继 PD 分离之后，MoE（混合专家）大模型推理最值得关注的基础设施方向。

这篇文章不是又一篇「我做了一个系统」的论文，而是用一套建模框架 AIC++，系统地把「到底要不要解聚、解到哪一层才划算」这件事算清楚了。它的结论对做智算中心、推理 Infra、以及所有关心 MoE 模型规模化部署的人，都有很强的指导意义：**AFD 在严格延迟 SLO 下能撑起约 4k tokens/s 的系统吞吐，而在非 AFD 部署根本无法运行的 1M 前缀长上下文场景里，AFD 是唯一可行的解。**换句话说，AFD 的价值不只是「更快」，更是在特定战场上「能不能跑」。

零、为什么「解聚」是智算中心绕不开的命题

在谈 AFD 之前，得先说清一个更底层的判断：为什么「解聚」会成为大模型推理系统的主流范式？根本原因是 Transformer 推理天然是两段式、且两段瓶颈完全不同的。Prefill 阶段要处理整段输入、一次性生成全部 KV 缓存，算力（FLOPs）主导，理论上限由 GPU 的算术吞吐决定；Decode 阶段逐 token 自回归生成，每一步只算一个 token 却要读写整份 KV 缓存，瓶颈在显存带宽（memory bandwidth），GPU 的算力在这里大量闲置。把这两段塞在同一张卡上，要么 prefill 占着算力把 decode 饿着，要么 decode 占着带宽把 prefill 拖慢，气泡（bubble）巨大。

PD 分离的本质，就是把这两段按各自瓶颈拆到不同硬件池，让 prefill 池专心吃算力、decode 池专心喂带宽，再通过 KV 缓存的跨节点传输把两段衔接起来。这套思路已经在 vLLM、SGLang、TensorRT-LLM 等主流引擎里成了默认配置。但论文敏锐地指出：PD 分离仍然把每个 Transformer 块当作一个「不可分割的整体」，而 MoE 这类模型在块内部，Attention 和 FFN 的异质性就已经大到不能忽略——于是解聚的下一刀，自然落在了块内部。这也是为什么 AFD 被定义为「叠在 PD 之上的下一级解聚」，而不是它的替代者。

一、解聚的三级跳：从 chunked-prefill 到 AFD

要理解 AFD 为什么重要，得先看清推理解聚的演进脉络。现代 LLM 推理天然分成 prefill（处理整段输入、生成 KV 缓存，计算密集）和 decode（逐 token 自回归生成，访存密集，受 KV 缓存带宽制约）两个阶段。早期的 chunked-prefill（Sarathi, 2023）只是把长 prefill 切成块塞进 decode 批次，减少气泡；PD 分离（DistServe, 2024；Splitwise, 2023）则把两个阶段放到独立硬件池，各自按自己的瓶颈扩展。

但 PD 分离仍然把每个 Transformer 块当作一个「不可分割的整体」。而论文指出，对于 MoE 这类模型，同一个块内部的异质性就已经非常显著：Attention（尤其是 MHA/GQA/MLA 变体）主要是访存密集、状态密集（KV 缓存读写主导）；FFN（特别是 MoE 的 expert FFN）则是计算密集（被稠密 GEMM 主导）。MegaScale-Infer（2025）已经证明，在巨大的异构模型上，粗粒度抽象会失效。AFD 就是把 Attention 和 FFN 算子也分开部署，让「状态重的注意力」和「无状态的计算密集 FFN」各自拥有独立伸缩的 GPU 池。

论文把这套层级画在 Figure 1 的 AIC++ 框架总览里：设计空间同时覆盖 token 级并行（DP/SP/TP/PP/EP）、阶段级 P/D 分离、以及算子级 A/F 解聚。换句话说，AFD 不是 PD 的替代品，而是叠在 PD 之上的下一级解聚。

表：推理解聚的三级跳对比（演进逻辑，非论文原表）

解聚层级	切分对象	主要解决	典型收益	主要代价
chunked-prefill	长 prefill 切块	批次内气泡	GPU 利用率提升	无独立伸缩
P/D 分离	prefill vs decode	算力 vs 带宽瓶颈错配	TTFT/TPOT 各自优化	KV 跨节点传输
A/F 解聚（AFD）	Attention vs FFN	块内访存 vs 计算错配	rate-matching + 显存切分	层内 A2F/F2A 通信

二、为什么 Attention 和 FFN 必须分开算：异构性的量化证据

AFD 的合理性，根植于 Attention 与 FFN 在执行特性上的根本差异。论文用 Figure 3 把四种代表性架构在四种上下文长度下的运行时占比和显存占比做了分解，结论非常直观：

• 稠密 GQA 架构（如 GPT-OSS-120B、Qwen3-235B）：在长上下文下高度 Attention 主导——4K 上下文时 Attention 占运行时约 41%/59%，到 0.5M 上下文时 Attention 占比飙到 87%/96%。
• 稀疏注意力架构（DeepSeek-V3.2，MLA + 稀疏注意力）：短上下文 FFN 主导，但随上下文变长越来越 Attention 受限。
• 状态空间模型（Nemotron3-120B，Mamba-2 + GQA）：因为线性时间注意力特性，运行时 decisively 倒向 FFN（128K 上下文时 FFN 占 81%）。

关键观察：Attention/FFN 的运行时比例随上下文长度单调上升（KV 缓存越来越大），且不同架构斜率完全不同。这意味着「给 Attention 和 FFN 分配多少算力」没有统一答案，必须按工作负载和模型架构动态决定——这正是 AFD 存在的根本理由。显存侧也是同理：Figure 3(b) 显示权重与 KV 缓存的占比随上下文剧烈变化，长上下文下 KV 缓存能吃掉 40%–77% 的显存。

顺带一提，这种「块内异构」对 MoE 尤其刺眼。MoE 的 FFN 是专家混合，参数规模常占整个模型权重的 80%–90% 以上，是名副其实的算力黑洞；而 Attention 在长上下文下又被 KV 缓存的读写带宽牢牢绑死。把这两者捆在同一个 GPU 上，你要么用一个超大 FFN 池去迁就一个很小的 Attention，要么用一个够大的 Attention 片去浪费 FFN 算力——两种都会留下明显的效率缺口。AFD 的解法不是「折中」，而是把两者解耦到各自最合适的硬件配比。

三、AIC++：把「解聚到哪一层」变成可求解的设计空间

为了系统研究 AFD，论文构建了 AIC++（AIConfigurator++）协同设计框架：它把 NVIDIA AIConfigurator 的算子级计算建模（实测 GPU 集群代价数据库）与 AstraSim 的高保真网络仿真（包粒度拥塞感知）融合起来，并基于一个定制化的 vLLM AFD 原型验证全对的全双工 Attention–FFN 执行路径的正确性。

AIC++ 的精髓在于：它显式地把「算子级计算异构性」和「跨节点通信代价」放进同一个优化目标里，从而能回答一个此前没人算清的问题——在多大规模的集群上、对什么样的负载、Attention 该配几个 GPU、FFN 该配几个 GPU？

在 MoE 上做 AFD，通信形态会发生质变。非 AFD 部署里，MoE 的 Dispatch/Combine 通信只在参与 EP（专家并行）的 GPU 之间、源目数量匹配；而 AFD 下 Attention 和 FFN 跑在不同物理 GPU 组上，导致非对称的扇出/扇入：例如 8 GPU 上 EP=8 的 MoE 在所有 8 卡间交换 token，而「2 个 Attention GPU + 6 个 FFN GPU」的 AFD 配置会产生扇出——Attention GPU 生成的 token 要被分发到更多 FFN GPU。A2F（Dispatch）是扇出，FFN 侧入口拥塞成为瓶颈；F2A（Combine）是扇入，Attention 侧入口成为瓶颈。AIC++ 把这两种传输展开成完整的双部流量矩阵，喂给 AstraSim 的分层拥塞感知网络模型。

四、四阶段微批重叠：AFD 吞吐的关键技巧

AFD 把每个 Transformer 层的执行拆成四个阶段，分别映射到不同的计算或通信资源：① Attention GPU 上的注意力计算；② 把后注意力隐状态、token id、每专家路由元数据 dispatch 给 FFN；③ FFN GPU 上的 MoE-FFN 计算；④ 把专家输出聚合回 Attention 侧进入下一层。现代数据中心 GPU 普遍提供全双工互联（NVLink、InfiniBand），因此返回通信可以走专用通道与正向通信并发，形成流水线。

论文给出了稳态流水线延迟的闭式表达（公式 1）：把每步 token 预算 T_budget 切成 M 个微批，在半双工链路上 M=3、全双工链路上 M=4。稳态下瓶颈阶段背靠背处理全部 M 个微批，非瓶颈阶段只承担一次性的管道填充/排空开销 s_i/L。最终端到端延迟 t_pipe = M·s_max + Σ(s_i/L)。**第一项是瓶颈资源决定的稳态吞吐，第二项是管道气泡。**这一公式让 AIC++ 能在 prefill 和 decode 两阶段都精确推理计算–通信代价。

值得强调的是，这个闭式模型的价值不在于「算出一个数字」，而在于它把 AFD 的吞吐上限显式地绑定到了瓶颈资源的稳态速率。换言之，只要你能定位到瓶颈是 Attention 计算、FFN 计算、还是 A2F/F2A 通信，就能直接知道该往哪一侧加 GPU、加多少，而不是靠拍脑袋调比例。这也是 AIC++ 与单纯「跑一遍搜索」最本质的区别：它把经验性的部署决策，变成了可解释、可外推的模型驱动决策。

五、位置感知 GPU 放置：把最频繁的通信绑到最快的链路

AFD 与 P/D 分离叠加后，会同时存在两种不同粒度的通信：① 每层都发生的 MoE Dispatch/Combine（O(层) 每请求），频率高、随层数线性增长；② 每个请求只发生一次的 KV 缓存传输（prefill 把 KV 发给 decode）。AIC++ 的策略是频率驱动的：把最频繁的层内 A2F/F2A 流量绑定到最高带宽的 scale-up 域（节点内 NVLink），而把较少的 KV 传输推迟到 scale-out 域（节点间 InfiniBand）。

论文用 2A2F（等价于 EP=4）配置、两个 8-GPU 节点做了对照（Table 2）：隔离放置下 KV 传输跨节点走 InfiniBand（25 GB/s），配对放置下 KV 留在 NVLink（450 GB/s），带来 18× 的 KV 传输加速。这一结论对任意多级网络层级都成立——始终让最频繁的通信模式占用最快的可用链路。

六、集群级评估：吞吐与交互性，谁说了算？

论文在 128 张 B200 SXM（TensorRT-LLM 后端）上，对 Qwen3-235B、GPT-OSS-120B、Nemotron3-120B、DeepSeek-V3.2 四款架构，在 Chat/Coding/Agentic Coding 三类负载下做了穷举式设计空间搜索（副本数 2–128 GPU，动态组合 TP/DP/EP 与 A/F GPU 组）。

两个核心结论（Key Takeaways）非常重要，值得做智算/推理 Infra 的人反复读：

结论 1（系统吞吐）：聚合部署靠数据并行并发胜出大多数面板。 用 16 个单节点 8-GPU 副本、通过 EP 持有专家 FFN 的聚合 serving（chunked-prefill），靠把 chunked-prefill 气泡摊到整个副本舰队、并行吞掉很多不相交 token 批次，在大多数面板上吞吐最高。解聚只在「更宽的搜索暴露出非对称副本形状」时才赢——比如「少数大 8-GPU decode worker 喂很多小 2-GPU prefill worker」，或解聚+AFD 下把 Nemotron 的吞吐翻倍。

结论 2（用户交互性）：AFD 在每个面板上都赢。 AFD 通过按负载和模型定制 Attention/FFN 比例、用 AFD 专属的微批重叠技术榨干计算–通信重叠，始终把延迟做到最低。例如在 DeepSeek-V3.2 上，MLA + 稀疏注意力把 KV 缓存压缩得极狠，使得整个 524K 前缀能塞进 2 张 GPU 的 HBM，于是 2A+126F（2 个 Attention + 126 个 FFN）这种「反直觉」布局反而最优——AFD 把所有显存让给 FFN，只留极少 Attention GPU 跑大并发 decode 批次去匹配 126 卡 FFN 池的速率。

而在严格 SLO 下（TTFT<50/100/150ms，TPOT≤15ms），Figure 2 显示只有 AFD 类方案（Agg+AFD、P/D Disagg+AFD）能解锁可行配置，撑起约 4k tokens/s 的系统吞吐；非 AFD 部署直接不可行（红色叉号）。这正对应 agentic coding 这类长上下文、强 SLO 的真实生产场景。

AFD 何时「独赢」吞吐：不是所有面板都该解聚

很多人会误读结论 1，以为「AFD 输了吞吐」。论文其实给出了非常细的边界。首先，AFD 自己单独就赢下了一个面板：在 GPT-OSS-120B 的 chat 负载上，纯 AFD 配置拿下了吞吐前沿的最优；其次，在 Nemotron-3-Super 上，解聚+AFD 的「tiny xPyD 分片」把聚合部署的吞吐直接翻倍。这说明「解聚是否划算」高度依赖模型架构与负载组合。

更微妙的是注意力切片宽度对架构的强依赖。Qwen3-235B 这类稠密 GQA 模型，因为注意力本身算得重，需要更宽的注意力片：在 agentic coding 负载下出现 8A+120F 的布局。而 DeepSeek-V3.2 在 524K 前缀下，吞吐最优布局会「翻转」成注意力密集的 96A+32F；一旦 TTFT 预算更紧、瓶颈从状态传播转回计算，布局又回到 FFN 密集切分。这种随上下文长度和 SLO 预算来回翻转的最优 A/F 比，恰好证明了「固定比例部署」的脆弱，也印证了 AIC++ 这种建模驱动方法的必要性——人工拍出的比例，几乎不可能覆盖这种翻转。

七、长上下文案例：AFD 是唯一可行解

论文还专门做了长上下文压力测试（ISL=500K+OSL=10K，以及 prefix=1M+ISL=4K+OSL=500），在 B200 上用 AFD + 4 阶段微批（M=4）。结果令人印象深刻：

• 大 prefill 场景（ISL=500K）：Agg+AFD M4 在 64 GPU 达 1346.5 tok/s、128 GPU 达 2693.0 tok/s，最优布局是 [28A+4F]（Attention/FFN 比 7:1）。
• 大前缀场景（prefix=1M）：非 AFD 模式直接不可行——因为每 GPU 显存需求 M_shared = W+A+K+N+O ≈ 298 GiB，超过 B200 的 180 GiB 上限。AFD 把权重和激活拆分到 Attention/FFN 两组，把有效每 GPU 需求降到 M_AFD = max(M_attn, M_ffn) ≈ 165 GiB，刚好塞进显存。Disagg+AFD M4 在 128 GPU 达 1858.9 tok/s（略胜 Agg+AFD 的 1843.0）。

这个数字揭示了一个常被忽视的事实：AFD 的内存切分收益，本质上是在「把权重/激活从 Attention GPU 上挪走、给 KV 缓存腾地方」。在 1M 前缀这种单 GPU 显存根本装不下模型+激活+KV 的场景里，AFD 不是「更快」，而是「能跑」。

八、生产落地与行业趋势：AFD 已经从论文走进系统

这篇论文不是空中楼阁，它点名的几个方向已经或正在成为真实系统：

• vLLM AFD PR #29772：社区已经在 vLLM 0.16 上实现 MoE 的 A/F 解聚运行时（NCCL P2P 传输、1:1 配对），论文在其基础上重构成 M×N 双部配对、把 MoE router 移到 Attention 侧、并引入零集合通信的 FusedMoE.forward_pre_routed 入口。
• StepMesh（StepFun, 2025）：专为 AFD 设计的通信库，采用与论文一致的 M×N 双部点对点发送/接收模式。
• 异构片上加速器：NVIDIA Groq 3 LPX、Rubin CPX、Intel SambaNova 这类「节点内异构计算单元」的出现，正是 AFD 成为有效策略的硬件土壤——高带宽 scale-up 互联让访存密集的 Attention 跑在内存富余的设备上，计算密集的 FFN 跑在算术吞吐高的加速器上。

论文也诚实给出了 AFD 的代价：每个 AFD 副本消耗更多 GPU，因此在「纯吞吐」维度，聚合部署在大多数面板上仍占优；AFD 的最大价值在延迟敏感点和超出单 GPU 显存上限的长上下文区间。这与「解聚不是银弹，而是要按负载画像决策」的工程常识一致。

对国产 AI 芯片与智算中心的启示

把视线拉回国内的智算建设，AFD 的启示格外现实。昇腾（Ascend）、沐曦（MetaX）、寒武纪、壁仞、昆仑芯等国产 AI 芯片，普遍在节点内提供高带宽的 scale-up 互联（如昇腾的 HCCS、昆仑芯的 XPU-Link），而跨节点走以太网或定制高速网。这与 AFD「层内高频通信绑节点内、低频 KV 走跨节点」的放置原则高度契合——国产芯片的异构互联拓扑，反而可能是 AFD 落地的一块好土壤。

更关键的是，国产大模型（如 DeepSeek 系列、Qwen 系列）几乎都是 MoE 架构，Attention 与 FFN 的异构性完全适用 AFD 的建模框架。对智算中心运营方而言，与其一味追求「单卡算力峰值」，不如按负载画像做 rate-matching：对长上下文、强 SLO 的推理业务，把 Attention 片与 FFN 片按 AIC++ 式建模动态配比，往往比堆更多同构副本更省卡、时延更低。

九、给我们的启示：推理 Infra 正在从「粗粒度放置」走向「算子级解聚」

对做智算中心和推理平台的团队，这篇论文给出几条可直接落地的原则：

1. Attention/FFN 比例走 rate-matching：AFD 只分配「刚好匹配 FFN 输出速率」所需的 Attention GPU。便宜低显存的注意力（MLA+DSA、滑窗 GQA）用小 Attention 片就能喂大 FFN 池（90%+ 集群给 FFN）；重注意力或大 KV 则需放大 Attention 片。
2. 通信亲和度决定放置：最频繁发生的层内 A2F/F2A 绑到节点内 NVLink（18× KV 传输收益），低频 KV 传输才走跨节点 InfiniBand。
3. 长上下文是 AFD 的确定性战场：当 prefix 大到单 GPU 装不下时，AFD 的内存切分是唯一可行路径，应优先在此类负载上启用。
4. 建模驱动优于拍脑袋：AIC++ 这类「算子级计算建模 + 网络仿真」框架，才是规模化部署前该有的决策工具，而不是靠经验搜比例。

SLO 视角：AFD 的胜负手在「延迟预算」

把 Figure 2 的 SLO 结果拆开看，会发现一个朴素但常被忽略的道理：AFD 的优势是带约束的优势。论文把 TTFT 上限设成 50/100/150 ms 三档，TPOT 上限统一 15 ms。在「无 SLO、纯求吞吐」的目标下，聚合部署往往更能打；可一旦加上硬约束，聚合部署的大量面板直接变成红色叉号——搜索器根本找不到满足 SLO 的部署配置。所以对智算中心的启示是——先定 SLO，再谈解聚。如果你的业务对首字延迟和逐字间隔不敏感（比如离线批量摘要），聚合部署可能更省卡；但只要涉及实时对话、agentic 工具调用这类强 SLO 场景，AFD 就是绕不开的底座。

两个常见误区

误区一：「解聚层级越多越好」。论文明确给出反例——AFD 每个副本消耗更多 GPU，在纯吞吐面板上聚合常胜。解聚是按负载画像做的权衡，不是越细越优。误区二：「AFD 只能靠论文里的 AIC++ 才能用」。事实恰恰相反，vLLM PR #29772 已经把 MoE 的 A/F 解聚跑通，StepMesh 提供了通信库，意味着普通团队不必从零造轮子，只需要在现有运行时上把比例配好、把放置绑对链路即可上手。

十、小结与延伸阅读

AFD 代表了大模型推理解聚的第三级跳：从 chunked-prefill，到 P/D 分离，再到把 Attention 和 FFN 也拆开。它不会在所有场景都赢（纯吞吐仍常被聚合部署压制），但在严格延迟 SLO和超长上下文这两个越来越主流的战场上，AFD 已是不可替代的底座。随着 Groq 3 LPX、Rubin CPX、SambaNova 这类异构片上加速器的普及，算子级解聚会从论文走向默认的部署原语。

延伸阅读：PD 分离开山作 DistServe（arXiv:2401.09670）、Splitwise（arXiv:2311.18677）；MoE 解聚 MegaScale-Infer（arXiv:2504.02263）；vLLM AFD 实现 PR #29772；以及本工作的配套建模工具 AIConfigurator（arXiv:2601.06288）与网络仿真 AstraSim。同期值得关注的还有 ICML 2026 的《Theoretically Optimal Attention/FFN Ratios in Disaggregated LLM Serving》（arXiv:2601.21351），它从概率负载模型推导出最优 A/F 比的闭式解，与本文的实证结论相互印证。

本文由 arXiv 论文自动解读系统生成，基于 arXiv:2605.28302《How Far Can Disaggregation Go? A Design-Space Exploration of Attention–FFN Disaggregation for Efficient MoE LLM Serving》（Hanjiang Wu 等，Georgia Tech + Intel + Google + Google DeepMind，2026-05）。内容为对原论文的深度技术解读与工程点评，所有数据均引自原论文图表与正文。AI 辅助创作，转载请注明出处。