1. 统一放置为什么会产生资源错配

在传统按层切分的 MoE serving 中，同一组 GPU 同时承载 attention 权重、KV cache、共享层、专家权重和专家通信。attention 侧需要持续保存会话状态、在 decode 中快速读取历史 KV；专家侧需要容纳大量稀疏权重、处理随 router 变化的 all-to-all 和大规模 grouped GEMM。两侧对显存、网络、并发与调度的最优点常不相同。

为了容纳专家权重而增加 GPU 时，attention/KV 资源可能闲置；为了长上下文增加 attention 副本时，专家权重又会重复装载。Attention/Expert 分离（A/E disaggregation）把两类算子和状态放进不同资源池，让它们按各自瓶颈扩缩容。它改变放置，不改变 token 的模型语义。

2. 先按数据依赖划分，而不是按“模块名称”划分

一个 Transformer MoE 层近似为：归一化、attention、残差、router、专家 FFN、残差。attention 需要读取和更新该请求的 KV；专家 FFN 需要访问目标专家权重。若把两者分到不同池，层间 hidden state 必须在 attention pool 和 expert pool 之间来回传递。共享专家、dense MLP、norm 或输出 head 放在哪一侧，要由它们的依赖、权重大小和计算占比决定，不能机械地按名字归类。

这意味着 A/E 分离不是一次 P/D transfer，而可能是层内反复交换。若 hidden state 大、层数多或链路弱，新增数据流足以吞掉专家池带来的收益。设计开始前应明确每层交换的张量 shape、精度、是否可 pipeline，以及是否存在可安全合并的连续算子。

3. 两池架构中的状态归属

attention pool 通常拥有请求会话、KV page table、prefix cache 和与 decode deadline 相关的调度状态；expert pool 拥有专家 shard、路由执行、token bucket 和 EP communicator。请求元数据可以由一个全局控制面维护，但数据面必须有明确 owner：谁负责 admission、谁在断连时回收 KV、谁判定一个 token 的所有专家分支已完成、谁为跨池 RPC 选择目标。

如果两个池都以为对方会持久化状态，故障后就会出现幽灵会话；两边若各自缓存可变 route 或 token offset，也可能错误合并。KV 与请求顺序由 A-pool 持有权威副本，专家权重与 EP layout 则由 E-pool 持有。跨池消息应携带可追踪的 request id、layer id、token range、版本号和取消语义。

4. 新增流量怎样估算，何时值得交换

设 hidden size 为 H、每个元素 b 字节、每层跨池往返一次，单 token 的额外激活流量约为 2 × H × b，再乘以层数和 scheduled token 数。实际还有对齐、header、量化 scale、复制和协议开销。相对于 EP 内部只在专家层交换 token，A/E 分离把跨池流量从“稀疏专家路径”扩展为“几乎每个层的隐藏状态路径”。

bytes_AE_per_step ≈ 2 × L_moe × N_tokens × H × bytes_per_element T_layer_AE ≈ T_attention_pool + T_cross_to_E + T_expert_pool + T_cross_to_A

A/E 分离值得采用的条件很直接：独立扩容、减少权重复制、提高两池利用率和改善 EP 放置所省下的成本，要高于新增激活通信、同步与系统复杂度。这个条件只能在目标请求分布上验证，总模型 FLOP 或参数比例给不出答案。

5. A-pool 的核心是 KV 生命周期与交互延迟

attention pool 的并发上限主要受 KV 容量、paged allocator、上下文长度和 decode TBT 驱动。它应把相同前缀路由到相同 cache 域，避免跨池请求移动破坏命中；对长 prompt 可用 chunked prefill，防止一次写入挤掉交互 decode。A/E 拆分不会消除 KV 问题，只是使 KV 容量和专家容量可以分别规划。

当 expert pool 拥塞时，A-pool 不能无限积压已完成 attention 的 hidden state，否则会占用 activation/buffer 并拖慢后续 token。需要设置跨池 in-flight 上限与取消传播。一个已取消请求的 KV 可以按策略留作可复用前缀，但其在 E-pool 的未完成 token 必须明确丢弃或 drain，不能悬挂在队列里。

6. E-pool 的核心是专家权重、EP 和不均衡

expert pool 以专家 shard 为主要常驻资产，内部仍需要 router、dispatch、grouped GEMM 和 combine。把 attention 拆出去不会自动使 EP 更快，但允许把 E-pool 的 GPU、NIC 连接和并行度专门为 all-to-all 调优。它还使专家副本与 attention 副本的扩容比例可不同：高上下文负载可主要扩 A-pool，高 MoE token 密度可主要扩 E-pool。

不过 E-pool 仍面临 router 热点。一个 A-pool worker 发出的 token 可能集中到少数 E-pool owner，使跨池请求的排队和 EP 的排队叠加。调度器应观察 per-expert 和 per-E-rank 队列，而不是只看 E-pool 总 GPU 利用率。详情可衔接 EP 与 DeepEP。

7. 跨池协议必须兼顾顺序、回压和故障

每一条跨池消息至少需要 request id、generation epoch、layer、token position、hidden payload、精度/scale、deadline 和取消标志。generation epoch 用于区分同一会话重试或迁移后的新一轮计算，防止迟到结果写回已被复用的 slot。接收方应可拒绝或延迟新任务，并将压力信号返回发送方，形成回压而非无界排队。

可靠传输并不等价于 exactly-once 计算。连接超时、worker 重启或重复投递时，系统必须决定是重放、丢弃还是从最近 checkpoint 重算。对 decode 而言，一次错误重放可能产生重复 token；对 prefill 而言，重算成本可能很大。协议需要将“请求可见输出”与“内部 speculative/in-flight 工作”分开管理。

8. 联合调度：两个池不能各自做贪心最优

A-pool 若只追求本地满载，会把过多 token 推到 E-pool；E-pool 若只按最短队列收任务，可能让有严格 TBT 的 decode 与大 prefill 混排。控制面应基于端到端 deadline 选择 token，而不是分别优化每池的利用率。可以为不同流量设 reservation，例如保留一部分 E-pool capacity 给 decode，剩余用于 prefill 或离线任务。

priority(token) = urgency(deadline) + cache_value - predicted_A_wait - predicted_cross_pool_wait - predicted_E_wait 接纳前检查：KV_headroom、A queue、E queue、in-flight bytes、deadline feasibility

预测不需要完美，但应保守、可校准，并带 hysteresis。频繁把请求在池间或副本间迁移会增加 KV/状态开销，甚至引发缓存雪崩。要让控制器在短暂波动中保持稳定，只有在收益持续、迁移成本可收回时才改变放置。

9. 数据中心放置：网络应按流量类型分层

A-pool 内部的 attention/TP 通信和 E-pool 内部的 EP all-to-all 都偏向高带宽、低延迟 scale-up 域；A↔E 之间则需要稳定的大吞吐、低抖动 cross-pool 连接。将 A-pool 和 E-pool 随意放到两个拥塞域，会在每层隐藏状态交换上支付多跳成本。最佳布局依赖于模型层数、hidden size、并发和网络结构。

实际规划先给出流量矩阵：A 内 TP、A 的 KV transfer、E 内 dispatch/combine、A↔E hidden transfer、控制面小消息。再把矩阵映射到 NVLink、NIC、交换机和机架。不要只根据“GPU 数量相同”切两个 pool；若通信域不同，等量 GPU 的可用吞吐可以相差很大。

10. 观测面：必须能把一次慢 token 分解到两池

端到端 trace 要有统一的 request/token id，记录 A attention 开始结束、A→E 发送排队与传输、E queue、EP dispatch、expert GEMM、E→A 返回和最终采样。除了均值，按请求类型观察 P95/P99。若只看 A-pool 或 E-pool 各自 dashboard，会把跨池等待误判为“对方慢”。

  • A-pool：KV block 利用率、prefix hit、decode TBT、A→E in-flight bytes。
  • E-pool：每 rank 接收 token、专家失衡、dispatch/combine、grouped GEMM、回压次数。
  • 跨池：RPC P50/P99、丢弃/重试、迟到响应、cancel drain time、不同 rack 路径。
  • 全局：SLO-goodput、重复/漏 token 检测、恢复时间和成本每完成 token。

11. 何时 A/E 分离会失效或得不偿失

模型太小或层数太少：新增 hidden transfer 与控制面开销超过资源池专门化收益。
跨池网络不够好：每层往返使 decode 的同步延迟累加，TBT 迅速恶化。
负载稳定且同构：统一池已经能高利用率，拆分只增加运维与故障面。
状态协议不完整：取消、重试、扩缩容和 KV 归属没有定义，会出现重复输出、泄漏或幽灵任务。
只按平均流量扩容：专家热点和长上下文尾部使局部池先拥塞，系统平均利用率仍可能很低。

12. 一个渐进式落地路径

  1. 先在统一池中分开 profile attention、EP、KV 与 hidden 激活流量，确认确有结构性错配。
  2. 实现单节点逻辑分离，用共享内存/本地链路验证跨边界协议和数值等价性。
  3. 扩到两个小池，建立端到端 trace、取消语义、backpressure 与容量保护。
  4. 在真实 trace 下扫 A:E 资源比、in-flight window、P/D 策略和网络布局。
  5. 做单 worker、单链路、整池不可用的故障演练，验证请求恢复和 KV 清理。
  6. 只有在同一 SLO 下 SLO-goodput 或成本显著改善时，才逐步扩大规模。

13. 放回 Mainline 的完整视图

A/E 分离同时涉及KV cache 与内存、并行放置、数据中心 KV 与 P/D和运行时调度器。“一个模型放在几张卡”要由状态、算子和通信流量在资源池之间的路径来回答。

14. 资料与事实边界

来源用途
AFD 预印本，2026attention–FFN disaggregation 的公开研究入口；具体结果应读原文。
Mainline：数据中心 KV 与 P/D服务状态、迁移与资源控制的独立解释。
Mainline：通信与拓扑流量矩阵映射到硬件的基础。

本页没有将 2025 标题中的实体或任何结果当作未经复核的事实。对生产设计，必须在目标模型、版本、集群和负载上测量跨池通信与 SLO。