深度调研（Probe）：多节点 MoE 解码中的专家级弹性与 P2P 重配置

阅读提示

混合专家模型（Mixture of Experts，MoE）：每个词元只激活少量专家网络，但全部专家权重仍需被放置、复制或按需搬运。
专家并行（expert parallelism，EP）：把专家分散到多张加速卡，词元经分发与合并通信访问远端专家。
数据并行（data parallelism，DP）：复制非专家计算路径并处理不同请求批次；部分弹性系统通过联合调整 DP 与 EP 改变资源规模。
张量并行（tensor parallelism，TP）：把同一层计算和参数切分到多张设备；部分系统固定 TP，只调整 DP 与 EP。
**图形处理器（graphics processing unit，GPU）**与进程编号（rank）：前者执行模型计算，后者表示分布式实例中的通信成员。
中央处理器（central processing unit，CPU）与网络接口卡（network interface card，NIC）：CPU 可代理通信控制，NIC 负责设备间网络传输。
点到点远程直接内存访问（peer-to-peer remote direct memory access，P2P RDMA）：源设备直接向目标设备搬运数据，不要求所有成员共同进入同一个集合通信。
GPU 直接远程内存访问（GPUDirect RDMA）：网卡直接读写 NVIDIA GPU 显存的数据路径，减少主存中转。
专家并行负载均衡器（Expert Parallelism Load Balancer，EPLB）：按专家热度复制或重新放置专家的常用策略与实现类别。
重配置：在线改变专家副本、专家位置或 EP 成员集合。它不仅包含搬权重，还包含通信成员、路由表和执行图的切换。
路由漂移：输入领域、租户组合或批次变化使专家热度随时间改变，导致离线放置计划过期。
第 99 百分位（P99）延迟：99% 请求不超过的延迟，用于观察少数慢请求造成的尾部影响。
服务等级目标（service-level objective，SLO）：系统承诺满足的延迟、吞吐或可用性边界。
SGLang 与 vLLM：两个开源大语言模型推理引擎；产业实现可在其专家并行路径中执行周期性负载均衡。
PPLX：由 CPU 发起的专家并行通信方案，UEP 论文将它作为跨设备传输基线。
CUDA 与 ROCm：分别面向 NVIDIA 与 AMD GPU 的软件栈；跨软件栈结果用于判断机制可移植性。

一页结论

该方向形成四条路线：预算约束下的专家放置、利用执行窗口隐藏或避免搬迁、专家级服务弹性，以及可编程 P2P 通信。
最近的关键转折是专家位置与 EP 成员开始成为可变运行时状态。ElasticMoE 的全文公开稿描述在线 DP/EP 扩缩与虚拟页重映射；Expert-as-a-Service 的公开稿描述可独立扩缩的专家服务；EEP 的摘要描述故障后的成员、专家覆盖和执行图修复。三者的证据复核深度不同，不能合并成同一强结论。
覆盖较广的共同缺陷是生产路由轨迹不足、单一阶段与单一拓扑外推，以及重配置性能与正确性分开评估；各缺陷的适用集合、命中成员和反例在后文列明。
最值得全文复核的候选争议是路由偏斜究竟应被消除、利用还是绕开。MoE-Serving-Tax-MLSys26 的待复核页面报告小批解码中偏斜可能减少活跃专家并加速，而复制、迁移和跨层执行摘要通常把偏斜视为等待长尾；当前证据不足以把它升级为正式争议。
当前最需要的是用同一组多租户解码轨迹测量四类策略的适用边界；否则“动态迁移一定优于静态复制”仍是未经条件化的判断。

范围与证据

本 probe 纳入多节点 MoE 推理中与专家复制、迁移、EP 成员变化、专家服务拆分和 P2P 数据通路直接相关的工作，共 19 篇。11 篇仓库论文中，UEP、UCCL-Tran、Aegaeon 和 Nixie 为 complete/full-text，其余 7 篇为 needs-review/full-text。外部 ElasticMoE 与 Expert-as-a-Service 有全文但本次未完成逐节复核，记为 needs-review/full-text；MoEless、Director、FreeBalance、EasyBalance、EEP 和预测式复制工作只按公开摘要定位，记为 abstract-only。

排除单机专家卸载作为主要问题，也不讨论专家权重与键值缓存联合分层；FluxMoE-arXiv26 与 PopFetcher-ATC25 仅用于界定权重搬运和预测的相邻路线。该边界与 moe-kv-cache-offload probe 保持分离：这里研究多节点专家执行位置和运行时配置，后者研究不同状态争用同一内存与存储层级。

研究版图

研究路线	核心问题	代表工作	当前边界
预算约束的放置与迁移	在显存和搬运代价下怎样分配专家副本	CRAFT-MLSys26、LatencyOptimal-MoELB-INET4AI25、Director	从离线配置延伸到摘要所述的预测式在线迁移；生产漂移和尾延迟证据不足
利用执行窗口隐藏或避免搬迁	能否在路由前隐藏有限搬运，或不搬专家也消除等待	Libra-ICLR26、FreeBalance、EasyBalance、MoE-Serving-Tax-MLSys26	预填充证据强于解码；收益依赖批次、层间窗口和路由形态
专家级服务弹性	能否让专家或 EP 成员独立扩缩，或在成员故障后恢复	ElasticMoE、Expert-as-a-Service、MoEless、EEP	扩缩、服务拆分和故障修复使用不同模型与指标；跨方案口径不一致
可编程 P2P 通信	怎样在动态、细粒度通信下兼顾性能、可移植性与拥塞控制	UEP-OSDI26、UCCL-Tran-OSDI26	EP32 和特定硬件证据较多；更宽 EP、故障与 CPU 长尾仍待验证

这四条路线不是可直接拼接的模块表。第一条显式改变专家位置，第二条利用计算窗口隐藏有限搬运或完全避免搬运，第三条改变服务或故障成员的管理方式，第四条提供数据通路；它们的目标函数和正确性边界不同。

时间脉络

总体阶段

静态专家均分 → 成本感知复制与迁移 → 预测式在线调整 → 专家或 EP 成员成为独立可变状态 → 故障中的成员与路由修复。

放置与迁移路线

2025 — LatencyOptimal-MoELB-INET4AI25：把专家搬运代价纳入均衡目标，改变了“越均衡越好”的单一目标，但只在单节点评测。
2026 — CRAFT-MLSys26：证明统一副本预算会浪费显存，转向按层分配；运行时仍依赖离线轨迹。
2026 — Director：摘要描述用当前请求预测激活、在计算阶段迁移并进行多模型实验；预测输入、完整基线、P99 和失败行为尚未全文复核。

利用执行窗口隐藏或避免搬迁

2026 — MoE-Serving-Tax-MLSys26：把预填充与解码的 MoE 税分开，并给出“偏斜可能帮助解码”的反例。
2026 — Libra-ICLR26：用相邻层隐藏状态预测下一层专家，在单机预填充中把分片与复制规划藏入本地计算窗口。
2026 — FreeBalance：摘要描述在路由前预测负载，并只迁移可被前置计算隐藏的专家。
2026 — EasyBalance：不改变专家映射，跨层合并不同微批的专家工作，说明迁移并非唯一的在线均衡手段。

服务弹性路线

2025 — BlitzScale-OSDI25 与 Aegaeon-SOSP25：分别把稠密模型扩缩降到层粒度和词元粒度，建立“扩缩不能等完整实例冷启动”的前提，但没有提供专家级抽象。
2025 — Expert-as-a-Service：公开稿描述把 MoE 模块拆为无状态专家服务，并评测细粒度扩缩、P2P 通信与模拟故障；证据状态为 needs-review/full-text。
2025 — ElasticMoE：公开稿通过持久化显存管理、P2P 搬运和虚拟页重映射实现在线 DP/EP 扩缩；本次证据状态为 needs-review/full-text。
2026 — MoEless：摘要描述无服务器专家、负载预测和位置规划；完整机制与边界尚未复核。
2026 — EEP：摘要把部分 rank 故障定义为 EP 有效性问题，并声称修复成员、专家覆盖、通信可达性和执行图；本 probe 不据此推断正常扩缩或版本切换语义。

通信路线

2026 — UEP-OSDI26：把词元级通信发起留在 GPU，把 NIC 管理交给 CPU 代理，建立跨 GPU 与 NIC 的 P2P EP 接口。
2026 — UCCL-Tran-OSDI26：把路径选择与拥塞控制移入软件传输层，说明跨机架收益主要来自避免路径碰撞，而不是单链路更快。

各类工作的演化

预算约束的放置与迁移

共同目标：以更少副本和更少搬运降低热点 rank 的等待。

演化与分歧：LatencyOptimal-MoELB-INET4AI25 优先少搬，CRAFT-MLSys26 优先把副本预算投向高收益层；Director 的摘要描述提前预测未来路由并迁移。它们在“预测错误是否值得付搬运代价”和“均衡代理是否对应端到端尾延迟”上仍未统一。

共同边界：缺乏同一多租户生产轨迹下的长期闭环评测；迁移失败、旧路由与新权重并存时的正确性通常不在主结果中。

相关工作：CRAFT-MLSys26、LatencyOptimal-MoELB-INET4AI25、Director

利用执行窗口隐藏或避免搬迁

共同目标：利用路由前计算、层间或批间并行，把有限搬运藏入现有窗口，或完全避免改变专家映射。

演化与分歧：Libra-ICLR26 仍会动态复制，重点是提前预测和两阶段执行；FreeBalance 的摘要描述只搬运可被前置计算隐藏的专家；EasyBalance 的摘要描述完全不改映射；MoE-Serving-Tax-MLSys26 则说明小批解码下减少活跃专家可能本身有利。

共同边界：需要足够的微批、层间窗口或本地计算来隐藏重排。严格逐词元解码、低并发和强尾延迟目标下是否仍有可用窗口，尚无统一答案。

相关工作：Libra-ICLR26、MoE-Serving-Tax-MLSys26、FreeBalance、EasyBalance

专家级服务弹性

共同目标：避免为少量负载变化启动或重启整个大模型实例，并在专家或 rank 变化时继续服务。

演化与分歧：Expert-as-a-Service 的公开稿与 MoEless 的摘要把专家拆成独立服务；ElasticMoE 的公开稿保留整体推理实例，但将显存状态与执行进程分离；EEP 摘要聚焦故障后的可变成员、专家覆盖和执行图修复。服务扩缩与故障恢复是相邻但不同的问题。

共同边界：各工作使用不同硬件、模型、故障与服务等级目标，无法直接比较细粒度扩缩的额外网络税、稳态税和恢复税。

相关工作：Expert-as-a-Service、ElasticMoE、MoEless、EEP

可编程 P2P 通信

共同目标：承载由路由动态决定的细粒度词元流，并把硬件差异、路径碰撞或拥塞控制从上层执行逻辑中分离。

演化与分歧：UEP-OSDI26 以 CPU 代理换硬件可移植性，UCCL-Tran-OSDI26 用主机软件换可编程路径与拥塞控制。前者更贴近低延迟词元传输，后者更强调大流集合通信。

共同边界：两者都把更多关键状态交给主机软件；CPU 抢占、代理挂起、队列恢复和重配置期间的顺序语义尚未被端到端弹性系统系统检验。

相关工作：UEP-OSDI26、UCCL-Tran-OSDI26

跨工作共同缺陷

以下分母只包含该缺陷适用的工作；成员名称列全，便于复算。abstract-only 工作只能扩大候选模式，不能单独把模式升级为共同缺陷。

缺少长期、逐层的生产路由轨迹（候选共同缺陷）

分母（12）：CRAFT、LatencyOptimal-MoELB、Libra、BlitzScale、Aegaeon、ElasticMoE、Expert-as-a-Service、MoEless、Director、FreeBalance、EasyBalance、MoE-Serving-Tax。
候选命中（4，需全文复核）：CRAFT、LatencyOptimal-MoELB、Libra、MoE-Serving-Tax。其 wiki 页面记录没有长期、多租户、逐层解码路由轨迹，但 review status 尚不足以作为正式共同缺陷证据。
反例或部分缓解（2）：Aegaeon 有模型市场生产流量，BlitzScale 使用生产来源的突发轨迹；两者都不是逐层专家路由反例。Libra 的混合数据集实验是短期漂移缓解，不是生产轨迹。
未知（6）：ElasticMoE、Expert-as-a-Service 尚未完成全文复核；MoEless、Director、FreeBalance、EasyBalance 只有摘要，不能因摘要未提及就判定缺失。

只验证单一阶段或有限拓扑（候选共同缺陷）

分母（15）：CRAFT、LatencyOptimal-MoELB、Libra、UEP、UCCL-Tran、BlitzScale、Aegaeon、ElasticMoE、Expert-as-a-Service、MoEless、Director、FreeBalance、EasyBalance、EEP、MoE-Serving-Tax。
候选命中（5，需全文复核）：CRAFT、LatencyOptimal-MoELB、Libra、BlitzScale、Aegaeon。其 wiki 页面显示主要结果集中在单一阶段、单机或有限硬件；目前只有 Aegaeon 达到 complete/full-text，不足以升级为正式共同缺陷。
反例或部分缓解（3）：UEP 覆盖多种 GPU 与网卡，UCCL-Tran 覆盖跨机架，MoE-Serving-Tax 分开预填充与解码。
未知（7）：ElasticMoE、Expert-as-a-Service 尚未完整复核；MoEless、Director、FreeBalance、EasyBalance、EEP 只有摘要。

重配置性能与正确性分离（候选共同缺陷）

分母（8）：CRAFT、LatencyOptimal-MoELB、ElasticMoE、Expert-as-a-Service、MoEless、Director、FreeBalance、EEP。
候选命中（2，需全文复核）：CRAFT、LatencyOptimal-MoELB 的 wiki 页面主要关注放置和迁移性能，但尚未达到正式共同缺陷所需的完整证据门槛。
候选命中（1）：ElasticMoE 公开稿主要报告扩缩性能，但尚未完成逐节复核。
反例或部分缓解（2）：Expert-as-a-Service 的公开稿包含模拟故障实验；EEP 摘要明确处理故障后的成员、通信可达性、专家覆盖和执行图修复。两者都不能据此支撑正常扩缩的原子版本语义。
未知（3）：MoEless、Director、FreeBalance 只有摘要，无法判断正确性覆盖。

局部代理目标未覆盖请求级尾延迟（候选共同缺陷）

分母（12）：CRAFT、LatencyOptimal-MoELB、Libra、UEP、UCCL-Tran、ElasticMoE、Director、FreeBalance、EasyBalance、MoE-Serving-Tax、BlitzScale、Aegaeon。
候选命中（5）：CRAFT、LatencyOptimal-MoELB、Libra、UEP、UCCL-Tran。前三篇仍需全文复核；UEP 与 UCCL-Tran 达到 complete/full-text，但两篇不足以独立满足共同缺陷门槛。
反例或部分缓解（4）：ElasticMoE 公开稿报告服务等级达成，BlitzScale 与 Aegaeon 报尾延迟或 SLO，MoE-Serving-Tax 明确区分阶段税；仍缺同一请求轨迹的跨方案 P99 分解。
未知（3）：Director、FreeBalance、EasyBalance 只有摘要，摘要没有足够 P99 分解信息，但不能据此判定全文缺失。

关键争议

当前证据尚未形成由完整全文支撑的正式争议。以下三项保留为候选争议或条件性未知，待相关论文全文复核后再升级。

候选争议：路由偏斜应被消除还是利用

CRAFT 与 Director、FreeBalance 的摘要把偏斜视为热点和等待；MoE-Serving-Tax-MLSys26 的待复核全文页则报告解码中偏斜可能减少被激活的专家集合，从而降低权重读取。条件化解释是：预填充的大专家批次更容易受最慢 rank 支配，低并发解码可能先受总权重流量支配。需要同时测活跃专家数、最大 rank 负载、通信量和词元间尾延迟，不能只报均衡比。

候选争议：在线迁移是否值得

Director 与 FreeBalance 的摘要声称提前预测可把迁移藏入计算窗口；EasyBalance 的摘要声称跨层执行可在不改映射的情况下减少空闲；CRAFT 则用较少静态副本避免频繁控制。最优选择取决于漂移速度、可隐藏窗口、专家大小和网络争用，当前没有统一相图。

候选争议：CPU 代理还是 GPU 直接控制网络

UEP-OSDI26 以 CPU 代理获得跨硬件可移植性，并在多种平台接近 GPU 直连路径；它也让每块 GPU 最多占用四个 CPU 核，并把调度抖动与代理故障带入关键路径。多节点解码在 CPU 已承担分词、调度或卸载时，结论可能反转。

产业实践与学术缺口

SGLang、vLLM 和 DeepSeek EPLB 已支持周期性专家负载均衡，但公开接口主要表达副本和位置，较少公开切换期间的版本与失败语义。
NVIDIA DeepEP、PPLX 与 UEP 已提供逐词元 P2P 通信；这意味着“把集合通信换成 RDMA”本身已不是研究空白。
Huawei CloudMatrix 上的 ElasticMoE 公开稿描述在神经网络处理器（neural processing unit，NPU）集群中进行在线 DP/EP 扩缩；NVIDIA CUDA、AMD ROCm 两类 GPU 软件栈与普通以太网环境尚未在该工作中复现。
Expert-as-a-Service 公开稿描述专家级独立服务，MoEless 摘要描述无服务器扩缩；两者的生产运营数据、统一成本口径和长期故障轨迹尚未在本次证据中确认。

候选空白

统一的弹性策略适用相图：现有工作各自选择复制、迁移、跨层执行或服务拆分，尚无同一栈在同一轨迹上说明何时切换策略。该空白来自“迁移是否值得”的候选争议。
扩缩与故障修复的边界对照：ElasticMoE 公开稿研究正常配置切换，EEP 摘要研究成员故障后的修复；二者是否使用兼容的成员、路由和执行图语义尚未全文比较。这里不推断并发扩缩、在途词元或原子版本行为。
公开的多节点 MoE 解码漂移基准：缺少包含逐层专家选择、请求到达、拓扑事件和服务等级目标的可重放轨迹，因而难以复算静态、迁移和跨层执行的适用边界。

关键未知与测量

路由计划的有效半衰期是多少：在代码、对话、推理和工具调用混合的连续请求上，按层计算专家分布距离和静态计划的尾延迟退化；若退化时间长于重规划周期多个数量级，在线迁移价值会被推翻。
哪种策略在解码中真正赢：固定模型、EP 规模和请求轨迹，对比静态复制、预测迁移、跨层重排和专家服务扩缩；报告活跃专家数、最大 rank 负载、P2P 流量、迁移暴露时间、P99 词元间延迟与显存。
P2P 控制面是否制造新长尾：在 CPU 负载、非统一内存访问拓扑和网络拥塞扫描中，对比 CPU 代理与 GPU 直连路径；注入代理暂停、队列积压和重传，测恢复而非只测稳态带宽。
配置切换与故障修复分别修改哪些状态：从 ElasticMoE 与 EEP 全文抽取权重、路由表、通信成员和执行图的状态机，再决定能否设计共同故障注入；当前摘要证据不足以预设原子边界。

覆盖缺口

仓库尚未收录 ElasticMoE、Expert-as-a-Service、EEP、Director、MoEless、EasyBalance 和 FreeBalance 的 paper wiki 页；ElasticMoE 与 Expert-as-a-Service 记为 needs-review/full-text，其余记为 abstract-only，本次不执行 ingest。
预测式复制论文 Fast MoE Inference via Predictive Prefetching and Expert Replication 的质量保持与“接近 100% GPU 利用率”目前只按公开摘要记录，不支撑核心结论。
EEP、EasyBalance 与 FreeBalance 在 2026 年 5–8 月集中出现，方向变化很快；后续刷新 landscape 时应重新检索最近工作。
生产逐层路由轨迹、跨机架解码故障轨迹和专家扩缩成本明细仍未公开，无法验证各论文工作负载之间是否可比。