LLM 推理提速:Attention与FFN分离AFD方

---

Attention和FFN，这对“冤家”终于分家了！

你相不相信，同一个模型里的两个核心部件，脾气性格能差到像猫和狗？

前阵子有个同行问我：“PD分离还不够，还能不能再拆？Attention和FFN能不能各跑各的？”

我当时第一反应是——兄弟，你是不是想多了？

结果你猜怎么着？我随手翻了翻论文，又去社区逛了一圈——嚯，早有人动手了，都快落地了！

---

说到这事儿，我一开始的想法就是：这纯粹是没事找事。PD分离已经够折腾了，还要把模型的一层拆成两半？图啥啊？

后来我真下手试了试，才发现——Attention和FFN这俩家伙，性格差异大到离谱！

硬绑在一起跑，谁都憋屈。

不信？我给你讲个故事。

---

一个在啃带宽，一个在吃算力

我用NVIDIA Nsight蹲过几个模型，像狗仔队一样盯着它们的每一个动作。

Attention跑起来什么样？ 这家伙，抱着KV Cache不撒手，HBM带宽被它占得满满当当。算力利用率呢？低得可怜！说白了，它就是个大胃王，但它只吃“带宽”这道菜。

FFN呢？ 完全是反的！一到它上场，算力直接拉满，显卡冒烟那种拉满。HBM带宽反而轻轻松松。

你说说，这俩凑一块，是不是像一个人非要吃火锅喝啤酒，另一个只想吃轻食沙拉？硬往一张桌上凑，谁都不痛快。

MoE模型就更夸张了。

DeepSeek-V3的FFN有几百个专家，每次只激活几个。显存全囤着专家权重，几百号人挤在一个房间里等着叫号。Attention那边呢？长上下文的时候，KV Cache能吃掉几十个GB。

你想想，这两坨重量级选手挤在一块显卡上——两边都住在同一间出租屋里，一个想跑步，一个想睡觉，你说难受不难受？

AFD就是让他们分家！

Attention机器专心干KV Cache的活——它是“仓储型”选手。FFN机器专注算点乘和激活——它是“运动型”选手。

各回各家，各找各妈。皆大欢喜！

---

硬件混搭？我踩过两个大坑！

AFD最让我心动的一点是什么呢？

能用有代差的硬件混着用！

你算算，H20的HBM大，适合跑Attention；H800算力强，适合跑FFN。理论上H20+H800搭配，成本直接打下来。

省钱又高效，多美的事儿！

但现实给了我两巴掌，啪啪的。

第一巴掌——通信。

每层的Attention输出，要发到FFN机器上。算完了，再发回来。一层一次，几十层下来。

光通信延迟就够喝一壶的！

Step-3那篇论文写得明明白白的：他们用三阶段流水线把通信隐藏了。但那是H800集群里用NVLink啊！你换两代卡连PCIe试试？

我测试的时候，跨节点通信直接让TPOT暴涨，收益全被吃掉。

第二巴掌——配比。

Attention和FFN实例的比例，他们叫r。这个r不对，要么FFN空等输入，要么Attention排队堵死。

智源有个理论工作给了个公式，最优r是Attention延迟均衡、通信均衡和FFN峰值三者的最大值。

我当时不信邪，试了1:2、1:4、1:6。结果1:4确实比1:2好，但1:6性能反而掉了——FFN端饱和了！

最后老老实实用公式算了个接近的值，才算稳住。

那一刻我明白了一个道理：直觉在工程面前，有时候就是个弟弟。

---

几套方案，各有各的脾气

主流AFD方案有三家：Step-3、xDS和MegaScale-Infer。

我重点看了Step-3，因为公开资料最多。

Step-3的思路特别硬核：每层拆成Attention→通信→FFN→通信三段，然后用流水线压满。他们的目标是每输出一个token控制在50ms以内，三层流水拆下来每段16.6ms。

听起来很爽对不对？

我试着模仿搞了个小规模测试——结果在同步屏障那里翻车了。好几层同时跑完，数据交换乱成一片。

后来学乖了，严格按“micro-batch pipeline”来，加了一堆手动同步，才算跑起来。

说白了，有些坑你不亲自摔一次，永远不知道疼。

MegaScale-Infer的DEP方案我还没完整复现，但看了设计，核心是“解耦专家并行”，把FFN专家单独放一组机器，Attention放另一组。xDS更侧重于MoE和Attention的分离，思路类似但底层技术不同。

说实话，这几个方案——本质都是把原来绑在一起的活儿拆开，差别在于怎么拆、拆多细。

---

最让我开心的事：框架动起来了！

SGLang从某个版本开始加了AFD的实验性支持。vLLM的V1架构也预留了相关接口。

我试过在SGLang里配了个简单的AFD配置——结果因为A:F比例写反，性能直接对折。

查了半天发现是配置文件里“attention_instance”和“ffn_instance”的数量没对应好。

那一刻我差点想把电脑砸了，然后又觉得好笑：技术的尽头，果然还是配置文件。

细看SGLang的实现，它把Attention和FFN的部署信息写进模型配置，调度时按层分开发送。vLLM那边更激进，V1里把Scheduler改成能识别不同阶段的负载，给AFD留下了空间。

但两家目前都还没完全稳定，官方文档也不多。

如果你想试——建议先在小集群，就2-4张卡，配好日志，重点盯着跨节点通信时延。

别一上来就搞个大家伙，那是在给自己挖坑。

---

等等，不是所有场景都需要AFD！

我得说句实话：AFD不是万能药。

如果你跑的模型小，或者推理请求长度很均匀——PD分离已经足够。

AFD的优势在哪里？长上下文和MoE模型。尤其是当KV Cache能把显存撑爆，但FFN专家权重也下不来的时候。

Step-3用32块GPU搞定了DeepSeek-V3原本需要320块GPU做的解码实例。

这个数字对比，你品，你细品。

我目前只在实验环境里跑通了AFD，生产环境还没敢上。原因很简单：运维复杂。两个集群的扩缩容、网络拓扑的配置、监控指标的拆分……这些活儿比PD分离翻了一倍。

如果你想冲，建议先把PD分离玩明白，再考虑AFD。

别一上来就想越级打怪。

---

我想给你指几条路

如果你真想研究AFD——记住这个路线图：

理论： 智源那篇概率工作负载模型论文，先去读。公式能帮你算最优r，这是地基。

工程： Step-3的Tech Report是必读的。看他们怎么处理流水线调度和通信隐藏——这些都是血泪里总结出来的。

框架： 关注vLLM V1的AFD分支和SGLang的RFC。社区讨论区常有方案对比，看别人踩的坑，比自己踩值。

硬件： LPU这类专用芯片出来后，AFD可能会更自然。Attention跑在LPU上，FFN跑在GPU上——各取所长。

---

说到这儿，我想吐槽一句：现在的推理方案迭代太快了，月更都不够。

半年前还在研究PD分离，现在AFD就开始布道了。

但换个角度想——这不正说明AI Infra还有点意思吗？

至少我每次觉得“差不多了”，总有人再挖一层。

AFD这条路，值得跟。

但别盲从。下手前，先算清楚你的模型和硬件到底能不能吃到红利。

你想想，这世界上哪有什么银弹？每一次性能飞跃的背后，都藏着另一个维度的心酸。

但正是这种“再挖一层”的快感，才让技术这事儿，永远有意思。