定位一句话：Waterfill/LPLB 是 SGLang 在 DeepEP/EPLB 之上、运行时（dispatch-time） 的 MoE 负载均衡层——它既不像 EPLB 那样离线搬权重做placement，也不像 DeepEP/MORI/fabric-lib 那样做通信底座，而是坐在两者之间，在不改 logical top-k 的前提下决定"哪个物理落点"执行每个 token/shared-expert 请求 [blog-waterfill-lplb]。
把这簇论文按"它们在 MoE-EP 栈里管哪一层"分成三组，Waterfill/LPLB 的坐标就清楚了。
A. 同层竞品——运行时 LB 决策（最贴近）
B. 下层底座——被 Waterfill/LPLB 依赖或并列的通信/placement 设施
C. 相邻系统——同为 MoE serving 但换了问题维度
delta-1｜相对 moe-lb-interai25：把"搬权重的 min–max"降级为"分流量的 min–max"，换来关键路径可承受。
moe-lb-interai25 的核心贡献是把 migration cost 纳入 min–max 联合优化、避免 rebalance 本身变瓶颈，heuristic 达 O(E·D·K) 多项式、比前人频繁 2×，减 latency ≤12.5% [moe-lb-interai25]。LPLB 的 delta 不在"更聪明的优化"，恰恰相反——它把问题缩小到"只在已有 redundant 副本间重分配流量"，从而 (a) 完全省掉 migration cost 这一项（不搬权重）；(b) LP 规模只随 redundant expert 数与 rank 数增长、不随全 expert 数 [blog-waterfill-lplb]；(c) 靠"所有 rank 一次 all-reduce → 各自独立解同一 LP → 无需广播结果" + on-GPU IPM kernel + 三次 kernel launch，把每 batch 求解压进推理关键路径 [blog-waterfill-lplb]。净差异：moe-lb-interai25 是"每 N batch 做一次较重的 placement 调整"，LPLB 是"每 batch 每层做一次极轻的流量再分配"。
delta-2｜相对 2412.19437（EPLB 源头）：从"离线均分"到"在线 min–max"。
DeepSeek-V3 的 redundant expert + 默认均分策略，只有当离线标定分布 == live traffic 时才最优 [2412.19437]。LPLB 精确指出并修补了这个缺口：单 batch 集中、数据集漂移、rebalance 周期长使 placement 事实上静态，此时均分仍留残余不均衡 [blog-waterfill-lplb]。这是一个干净的增量改进 + 前提继承关系：LPLB 建立在 EPLB placement 之上，red0（无副本）时 LPLB 无可为、实测净负 [blog-waterfill-lplb]。
delta-3｜相对 2605.02960（ZeRO-Prefill）：一个"消除不均衡影响"，一个"消除不均衡本身"——且 stage 不同。
两篇都承认 EP routing imbalance 是核心痛点，但 ZeRO-Prefill 反转数据流让 dispatch 全本地、不均衡不再重要，代价是绑定 prefill-only 大 compute window [2605.02960]。Waterfill/LPLB 保留同步 EP dispatch 框架、直接把负载摊平，适用于含 decode 的常规 serving（评测即 max_tokens=1 的 prefill-heavy 但走标准 DeepEP normal mode）[blog-waterfill-lplb]。矛盾点：ZeRO-Prefill 主张"expert weight 是可调度资源"、暗示 DeepEP 式 activation 路由是需要被替代的旧范式 [2605.02960]；Waterfill/LPLB 则押注"DeepEP 式路由继续存在、只需在其上补 dispatch-time LB"。根源：二者面向不同 workload——ZeRO-Prefill 的前提是判别式 prefill-only（生产 65.3% token）[2605.02960]，Waterfill/LPLB 不假设 compute window 足够宽，因而在互联受限或 decode 场景仍适用。
delta-4｜相对 2605.06113（BalanceRoute）：同一"barrier 最忙者定延迟"直觉，两处不同的作用面。
BalanceRoute 把 min–max 病放在 DP decode 的 request→worker 层、用 O(1) 分段线性 F-score 贪心求解、优势随 G 超线性到 +34.5% [2605.06113]；LPLB 放在 EP 内 token→replica 层、用 LP 精确解。二者可叠加而非竞争（一个管 request 落哪个 DP worker，一个管 token 落哪个 replica）。delta：BalanceRoute 为进关键路径选择了"闭式贪心"，LPLB 选择了"GPU 上真解一个 LP"——后者敢用更重的求解器，是因为它把 LP 结构块离线预算、在线只换 RHS [blog-waterfill-lplb]。
delta-5｜相对 ROCm-mori / 2510.27656：不同栈层，零竞争。
MORI 与 fabric-lib 提供 dispatch/combine 的通信实现与带宽/延迟 [ROCm-mori] [2510.27656]；Waterfill/LPLB 不碰 kernel、不碰 transport，只改"目的地选择"。delta 是维度正交：把 Waterfill/LPLB 的决策接到 MORI-EP 或 fabric-lib 之上理论上可行（都暴露 per-token 目的地），blog 未验证。
攻击-1｜"dispatch-time LB 是必要的独立层"——但两组增益都可能被更强 placement 吃掉。
blog 承认 LPLB 收益呈"中间最大"：流量均衡且 batch 巨大时残余不均衡本就少、near-zero 收益 [blog-waterfill-lplb]。而 moe-lb-interai25 主张"更频繁（2×）的在线 placement 调整"能持续追上分布漂移 [moe-lb-interai25]。若 placement 层足够敏捷，LPLB 修补的"rebalance 周期长使 placement 事实静态"这一前提可能被削弱，其适用窗口进一步收窄。blog 未与"高频 placement 调整"这一 baseline 对比。
攻击-2｜red0 净负 + 中等区间才最强 = 收益脆弱。
LPLB 在 red0 三数据集全为负（−0.95%~−1.61%，纯 all-reduce+solve 开销）[blog-waterfill-lplb]。这意味着它的净收益强依赖运维正确配置 redundant experts，且最优区间窄（中等规模、适度相关主题）。对比 Waterfill——它每行都为正、与是否有副本无关——LPLB 的"高方差收益"是明显软肋。反驳预期：blog 诚实标注负值行并以 §4 退化检查解释，属自洽，但不改变"部署鲁棒性弱于 Waterfill"这一事实。
攻击-3｜"各 rank 独立解同一 LP 得同解"依赖数值可复现性。
blog 声称所有 rank 用相同全局分布独立解 LP 得同解、故无需广播 [blog-waterfill-lplb]。但 IPM 是迭代数值法，跨 rank 若存在浮点非确定性（归约顺序、kernel 调度差异）理论上可能得到略不同的 log2phy_prob，进而不同 rank 对同一 logical expert 的采样分布不一致。blog 未讨论该正确性对"跨 rank 位一致"的敏感度——这是一个可攻击的隐含假设。fabric-lib 处理无序完成时就专门论证过跨设备 ordering 的正确性边界 [2510.27656]，反衬本篇此处论证的缺失。
攻击-4｜Waterfill 的"通信保守候选集"把平衡自由度让给了通信，最优性未证。
Waterfill 默认只允许 token 已访问过的 rank 承接 shared slot，理由是"通信通常比额外 shared 计算更贵" [blog-waterfill-lplb]。这是一个未量化的启发式取舍——在通信便宜的拓扑（如 NVL72 单机架 NVLink 域）上，all-rank 模式可能显著更优而默认反而次优。blog 给了 all-rank 开关但未给选择准则。相较之下，moe-lb-interai25 把通信成本显式写进目标函数联合优化 [moe-lb-interai25]，Waterfill 的"填谷"则是无 comm-cost 项的纯负载启发式。
攻击-5｜评测 max_tokens=1，decode 场景的 LB 价值未验证。
V3/R1 矩阵与 V4 验证均为 max_tokens=1 [blog-waterfill-lplb]，本质是 prefill-dominated 打法。而 BalanceRoute 的整篇论证都指向 decode 阶段（KV 单调增长、barrier 累积空闲才是 DP decode 的病根）[2605.06113]。Waterfill/LPLB 在长 decode、小 batch、HBM-bound 的 decode 阶段能否保持正增益，blog 无数据。
范式定位：不是"新范式"，而是给既有 DeepEP+EPLB 范式补上缺失的运行时环节。
这簇论文里，2605.02960（反转数据流）和 2604.26881（serverless 化）才是范式挑战者；Waterfill/LPLB 是范式内的精修——它接受"EPLB 静态 placement + DeepEP 同步 dispatch"这一主流栈，只补"单 batch 残余不均衡"这一最后一公里 [blog-waterfill-lplb]。这种定位的好处是采用成本极低：Waterfill 一个 flag（--enable-deepep-waterfill）、LPLB 一个 flag（--ep-dispatch-algorithm lp）即可启用 [blog-waterfill-lplb]。
采用证据：本簇里采用信号最强的一篇。
思想血缘：DeepSeek 系的连续演化。
EPLB/redundant experts 源自 DeepSeek-V3 [2412.19437]，LPLB 的 LP 公式又直接受 deepseek-ai/LPLB 启发 [blog-waterfill-lplb]。Waterfill/LPLB 因此是 DeepSeek MoE serving 血脉在 SGLang 侧的工程延续，而非独立发明——生态位是"把开源社区已有的 LP 想法产品化进主流引擎"。
方向-1｜Waterfill × LPLB × placement 的三层联合优化。
当前 Waterfill（shared expert）与 LPLB（routed replica）互补但各自独立求解 [blog-waterfill-lplb]。可把 shared-expert slot 也纳入 LPLB 的 min–max LP，作为额外的"可自由落点的伪副本"，一次求解同时摊平 dense + sparse 负载。更进一步，把 moe-lb-interai25 的 placement 变量与 LPLB 的流量变量合成双时间尺度优化（慢层搬权重、快层分流量）[moe-lb-interai25]，理论上比二者独立更优。
方向-2｜自适应候选集与 comm-cost-aware Waterfill。
把 moe-lb-interai25 显式的通信成本项 [moe-lb-interai25] 注入 Waterfill 的 waterline，使候选集在"通信保守"与"all-rank"之间按实测链路带宽自适应，而非二选一开关 [blog-waterfill-lplb]。在 NVL72 大 NVLink 域 vs 跨节点 IB 的异构拓扑上，最优候选集半径本应不同。
方向-3｜跨 DP-worker 路由 + EP 内 replica 分派的堆叠。
BalanceRoute 管 request→DP worker、LPLB 管 token→replica，二者作用面正交 [2605.06113] [blog-waterfill-lplb]。堆叠后，上层用 F-score 把 request 送到预期 EP 负载更轻的 DP 组、下层用 LP 在组内再摊平，是一个未被任一篇覆盖的两级 LB。挑战在于两级目标是否会互相抵消（上层已均衡时下层收益趋零，正对应 LPLB 的"均衡区间收益低"）。
方向-4｜decode 阶段与长上下文的 dispatch-time LB。
现有评测全在 max_tokens=1 [blog-waterfill-lplb]。把 Waterfill/LPLB 的 per-batch 求解接到长 decode 上，需与 BalanceRoute 揭示的"KV 随步增长"动态耦合 [2605.06113]——每 decode step 重解 LP 的开销/收益比是空白。
方向-5｜跨厂商底座上的 dispatch-time LB 移植。
LPLB 的求解器绑定 cuSOLVERDx/cuBLASDx（NVIDIA）[blog-waterfill-lplb]。要在 AMD 栈上复现，需把 on-GPU IPM kernel 移植到 ROCm，并把目的地决策接到 MORI-EP 的 dispatch 接口 [ROCm-mori]；类似地，fabric-lib 的 EFA 可移植 dispatch [2510.27656] 为"跨云、跨 NIC 的 dispatch-time LB"提供了通信基础。把 LB 决策与 transport 解耦成可插拔层，是让这簇成果脱离单一厂商的未探索工程方向。