ZeRO-Prefill: Zero Redundancy Overheads in MoE Prefill Serving #

Zhaoyuan Su et al. (UVA, Snowflake AI Research, Harvard) | 2026-05 | https://arxiv.org/abs/2605.02960 Category: framework | Tags: MoE, prefill-only, expert-parallelism, weight-streaming, prefix-caching, serving, throughput-optimization

§1 Core Contribution #

MoE prefill serving 的三重冗余（计算、内存、通信）根源于「expert 放置与 activation 路由的耦合」。ZeRO-Prefill 提出 AsyncEP，将 expert 从 "按 activation 路由" 反转为 "按 weight 流入"——用后台 D2D AllGather 替代每层同步 AllToAll，配合 frontend 强制的饱和阈值 T 保证 overlap，在 Qwen3-235B-A22B 上实现 1.35–1.37× 吞吐提升和 4× 部署弹性。

§2 Summary #

Figure 1: 匿名生产集群中 prefill-only 工作负载占 65.3% 的 input token 流量。

生产 LLM 工作负载中 65.3% 的 input tokens 属于 prefill-only（分类、推荐、验证等判别式任务），其答案完全由单次 prefill 的 logits 决定，无需自回归解码。这类工作负载面向吞吐、大 batch、长 compute-bound forward、丰富 prefix sharing——但现有 MoE 分布式策略（EP/TP/PP）为了装下模型引入了三重冗余：计算（sub-saturated GEMMs + routing 不均衡 stragglers）、内存（全驻留 expert weights + k 倍 activation 膨胀 + 重复 prefix KV）、通信（每层两次同步 AllToAll）。

ZeRO-Prefill 的核心观察：大 batch prefill 的长 compute window 足以在后台完成 expert weight 的 AllGather。因此反转传统 EP 的数据流方向——不再把 activation 路由到 expert 所在的 GPU，而是把 expert weight 流式搬运到计算所在的 GPU，使每个 GPU 在每层都持有完整 expert 集合，所有 top-k dispatch 变为本地操作。Backend 侧的 AsyncEP 用 D2D AllGather（可选 H2D offload）替代 AllToAll；Frontend 侧强制饱和阈值 T = t_EP × F_GPU × γ，通过 prefix-aware routing、true-FLOPs tracking、overlap-aware balancing 三规则保证每 GPU batch 的 compute window 足够大。

§3 核心三问 #

Q1 痛点：MoE prefill serving 的三重冗余 #

Figure 2: MoE 模型总参数量 vs 单 GPU HBM 容量。即使 FP8 下，结构性 gap 持续存在。Qwen3-235B 需 235 GB FP8 / 470 GB BF16，超出任何单卡。

MoE 总参数量增速远超单 GPU HBM，迫使运营商使用分布式执行。但所有现有策略都在 prefill 关键路径上引入冗余：

策略	计算冗余	内存冗余	通信冗余
DP×DP	无	每卡全量 weights（不可行）	无
DP×EP	routing 不均衡→straggler	1/N experts + k 倍 activation	2× AllToAll / 层，~4kBSHb
DP×TP	全卡 expert 重复	冗余 expert 存储	AG+RS / 层，~4BSHb
TP×EP	两者叠加	叠加	AllReduce + 2× AllToAll
PP×PP	pipeline bubble	阶段间不均	2× Send/Recv

量化结果：在 8×A100 上，所有主流策略 MFU < 16%，多个 baseline 在 4 GPU 以上 plateau 或退化。

Figure 4: Qwen3-30B-A3B 的 expert routing 不均衡。(a) 聚合 48 层的 expert load，max/min 达 16.15×；(b) 单层内的 expert load 分布更加偏斜。不均衡使 per-expert GEMMs 碎片化，最重 GPU 成为 per-layer straggler。

根因：EP 的同步 AllToAll 将 expert 放置与 activation 路由耦合——这是 decoding 时代的设计遗产，decoding 时每 step 只处理 1 token 没有足够 compute window 来 overlap 任何传输。但 prefill 不同。

Q2 方法：AsyncEP — 按 weight 聚集，而非按 activation 路由 #

Figure 6: 传统同步 DP+EP（4 GPUs）。每 GPU 持有 1/N experts，每层两次同步 AllToAll 在 critical path 上。

Figure 7: AsyncEP 执行模型。(a) D2D-only：每 GPU 为第一层复制全部 experts，后续层通过后台 NVLink AllGather 收集，与当前层 compute overlap。(b) 带 offloading：仅保留 upcoming 几层的 1/N shards on GPU，H2D PCIe 预取与 D2D AllGather 并行两通道流水。

核心反转：

传统 EP:  activation → AllToAll → 远端 GPU 上的 expert → AllToAll → 回传
AsyncEP:  expert weights → AllGather(后台) → 本地 GPU 完整 expert → 本地 dispatch

饱和阈值 T（物理量，启动时一次性标定）：

$$T = t_{\text{EP}} \times F_{\text{GPU}} \times \gamma$$

• $t_{\text{EP}}$：最慢 EP 传输延迟（D2D AllGather 或 H2D PCIe）
• $F_{\text{GPU}}$：GPU 峰值 FLOP rate
• $\gamma \geq 1$（默认 1.2）：安全余量

含义：只要每 GPU 每 batch 的 FLOPs ≥ T，当前层 compute 一定覆盖下一层 weight AllGather。Prefill-only 的大 batch 天然满足此条件，frontend 进一步强制。

Figure 5: ZeRO-Prefill 系统架构和端到端 workflow。Frontend 将任务标准化为 prefill-only 并按 saturation 规则组 batch；Backend 以 DP attention + AsyncEP 执行，返回 logits，不进入任何 decode 循环。

Frontend 三规则（co-design 闭环）：

1. F1 Prefix-aware routing：按 block-level 最长前缀匹配路由，同前缀请求聚合到同一 GPU，prefix KV 只算一次
2. F2 Compute-aware tracking：用 true-FLOPs 计量负载——N 个同 prefix 请求的 cost = 1× prefix pass + N× suffix pass，而非 N× 全量
3. F3 Overlap-aware balancing：每 GPU 累计 FLOPs 达到 T 即标记 saturated，停止接收新请求。load balance 作为 saturation 的结构副产品自动涌现



Figure 8: Frontend 调度三阶段。(1) Prefix-aware routing 选最长 block-level cache 匹配的 GPU；(2) Compute-aware tracking 按 true-FLOPs（扣除 prefix sharing credit）更新负载；(3) Overlap-aware balancing 在负载达到 T 时标记 GPU 为 saturated。

Memory knobs（正交可组合）：

• Hybrid offloading：每 GPU 仅保留 upcoming 几层的 1/N expert shards，其余从 CPU pinned memory H2D 预取。D2D AllGather 与 H2D PCIe 并行两通道流水
• KV-cache-free：对 prefix-sparse workloads 关闭 KV 存储，释放 HBM 给更大 batch

Q3 结果 #



Figure 9: 端到端吞吐（聚合真实 workload）。四个 panel 分别对应 8×A100 BF16、8×H100 BF16、8×H100 FP8、8×H200 FP8。ZeRO-Prefill 在每个 (hardware, precision, parallel degree) cell 均为最优。



Figure 12: MFU（H100 FP8, synthetic no-prefix-reuse）。N/A cells 表示 baseline 因内存不足无法运行——仅 ZeRO-Prefill 可在 1–2 GPU 上部署 Qwen3-235B-A22B。全 sweep 最差值（29.84%）仍高于所有 baseline 的最佳值（20.09%）。

指标	数值	条件
Throughput vs best baseline	1.35–1.37×	Qwen3-235B-A22B, 聚合真实 workload, 4 hw/precision configs
Throughput (long context)	up to 1.59×	32K–128K synthetic, 无 prefix 共享
MFU (per-GPU)	29.8–36.2%	1–8 GPUs, H100 FP8
Deployable envelope	1–8 GPUs (vs ≥4)	4× 更宽硬件范围
Frontend 增量贡献	+16–18%	backend-only → full co-design, 8 GPU



Figure 10: 两层设计的增量贡献分解。DP+AsyncEP（backend-only）已解决通信瓶颈，Frontend 在此基础上额外贡献 +16–18%（8 GPU），且增益随 parallel degree 增长。

Prefill-only 精度	±3.6 pp on 7/9 tasks	vs AR decoding, 生产分类 harness
同模型 decode mode gap	~1 pp	IMDB 25K, gpt-oss-120B
Implementation	vLLM v0.11.0 上单 flag 启用	—

§4 逻辑故事还原 #

时代定位 #

2026 年中，MoE 已成为开放权重 LLM 的默认架构（Qwen3、DeepSeek-V3、Mixtral、gpt-oss），同时判别式 LLM 用例（分类、审核、推荐、验证）在生产集群中占据 >65% 的 input token 流量。这些任务只需一次 prefill 即可出答案，但运营商仍用为 autoregressive serving 设计的引擎来处理它们——这是一个系统架构与工作负载形态之间的结构性错配。

背景 #

Prefill-only workload 有三个与 AR serving 截然不同的特征：(1) 吞吐导向而非延迟敏感；(2) 大 batch 产生长 compute-bound forward pass；(3) 丰富的 prefix sharing（同模板、同用户画像、同文档头）。这三个特征恰好是 MoE 分布式执行最需要但从未被利用的——大 compute window 可以 overlap 传输，prefix sharing 可以消除冗余计算，吞吐导向允许更激进的 batch。

约束推导 #

为什么 EP 不行？ EP 在每层强制两次 AllToAll，将 activation 送到 expert 所在 GPU 再送回。通信量 ~4kBSHb / 层，与 batch size × seq length 成正比。更致命的是 routing 不均衡：max/min expert load 可达 16.15×（Qwen3-30B 实测），最重 GPU 成为 per-layer straggler，且 AllToAll 是 barrier——所有 GPU 必须等最慢的。

为什么 TP 不行？ TP 在每 GPU 上冗余存储全部 experts（HBM 被 weights 占满，挤压 KV cache 和 batch size），且每层仍需 AllReduce。对于 MoE 模型，TP 的 weight 冗余尤为严重——experts 占总参数的 ~90%。

为什么 PP 不行？ Causal attention 在 pipeline 各 stage 间造成固有 load imbalance（early stages 处理短 context，late stages 处理完整 context），pipeline bubble 随层数增长。

核心约束：所有策略的问题都源于一个假设——expert weights 是静态放置的，activation 必须路由到 weight 所在位置。这个假设在 decoding 时代合理（每 step 只 1 token，compute window 太短无法 overlap 任何传输），但在 prefill 大 batch 时代不成立。

破局 #

反转数据流方向：不把 activation 送到 expert，而是把 expert weight 搬到 activation 所在的 GPU。具体地：

1. 每 GPU 仅为第一层复制全部 experts（warm start）
2. 当前层 compute 时，后台 D2D AllGather 收集下一层的完整 expert 集合
3. AllGather 完成后，GPU 用本地完整 expert 做全部 top-k dispatch——无 AllToAll、无 routing straggler、无 activation 扩展

为什么可行？因为 prefill 大 batch 的 compute window 足够宽。T = t_EP × F_GPU × γ 是一个可以在启动时精确标定的物理量——只要 frontend 保证每 GPU batch 的 FLOPs ≥ T，overlap 就得到保证。

核心技术壁垒 #

1. 物理量导出的 T 而非启发式调参：T 从 GPU FLOP rate 和 AllGather 延迟直接推导，用 profile run 中 layer-0（纯 compute）和 layer-i（compute + transfer 的 max envelope）的 wall-clock 比值标定。这使得系统对硬件/精度/模型变化具有自适应性，无需人工调参。
1. Frontend-backend 三接口 co-design：T 由 backend 定义、frontend 强制；prefix KV affinity 由 frontend routing 决定、backend block table 执行；true-FLOPs cost model 精确匹配 backend 实际 workload。三个接口使调度器和执行引擎不再是独立可调的组件，而是一个物理一致的系统。
1. 正交可组合的 memory knobs：D2D-only AsyncEP（解决 C2/C3）+ hybrid offloading（解决 C1 on weights）+ KV-cache-free（解决 C1 on KV）三者正交叠加。最激进配置下，每 GPU HBM 仅保存 attention weights + 几层 expert shards + activation workspace——足以在单个 80 GB GPU 上跑 235B 模型。

设计绑定批判 #

• 绑定 prefill-only：AsyncEP 依赖大 compute window，对 latency-critical interactive serving 或极 bursty arrival 不适用。如果 workload 是混合 prefill+decode，需要 disaggregated serving 架构（Splitwise/DistServe）来隔离 prefill tier
• 绑定高速互联：低带宽互联下 t_EP 增大导致 T 暴涨，可能无法满足。在 PCIe-only 拓扑（无 NVLink）上 D2D AllGather 远慢于 NVLink，部分传输可能 re-expose 到 critical path
• 绑定静态标定：T 启动时一次标定，若 workload 剧烈漂移（如从 short-context burst 切到 long-context），短暂窗口内部分层可能退化为同步行为（论文承认但认为 prefill-only batch 补充速度快）
• 绑定 vLLM 生态：实现在 vLLM v0.11.0 上，对 SGLang/TRT-LLM 等其他引擎需要重新集成 weight streaming engine 和 prefix-aware DP router

§5 Key Findings #

• 在 8×A100/H100/H200 全部 4 个硬件/精度组合中，ZeRO-Prefill 在每个 parallel-degree cell 都是最优——1.35–1.37× 提升跨精度稳定（FP8 双倍绝对吞吐但相对增益不变，因为 AllToAll 通信量与 element size 无关）
• Frontend 贡献随 parallel degree 增长：2 GPU 时 ~8%，8 GPU 时 +16–18%——因为更多 GPU 下 random dispatch 更多散射 prefix，prefix-aware routing 的边际价值更高
• 即使无 prefix sharing（random prompts synthetic workload），backend-only AsyncEP 仍提升 1.30–1.59×——验证通信冗余消除（P3）独立于计算冗余消除（P1）产生增益



Figure 11: 无 prefix sharing 的 synthetic workloads（8×H100 FP8）。四个 context regime：short(256), medium(4K), long(32K), ultra-long(128K)。AsyncEP 在 long context 下优势更大（1.52×），因 baseline 的 AllToAll 通信量与 B·S 成正比。

• MFU 1–8 GPU 范围内仅波动 1.03–1.09×：baseline 的最佳 8-GPU cell（TP+TP 128K, 20.09%）低于 ZeRO-Prefill 全 sweep 最差值（29.84%）
• AsyncEP 的 weight 传输完全隐藏——deployment 从 "≥4 GPU 才能装下 Qwen3-235B" 扩展到 "1 GPU 即可"（hybrid offloading + KV-cache-free），不牺牲 MFU
• Prefill-only logit scoring 与 AR decoding 的精度差仅 ~1 pp（同模型同 prompt 下），decoding mode 贡献远小于 prompt design 贡献

§6 Limitations #

• 仅适用于 prefill-only：autoregressive serving 的 per-token decode step compute window 不足以 overlap weight AllGather；需要前端 PD disaggregation 才能与 AR serving 共存
• 互联带宽假设：NVLink 是 D2D AllGather 高效的前提。PCIe-only multi-GPU 或 cross-node Ethernet 拓扑下 t_EP 显著增大，T 可能超出 workload 自然 FLOPs 范围
• 静态 T 标定：workload 剧变时有短暂不匹配窗口。虽然论文论证 prefill batch 快速补充缓解了此问题，但未提供 T 动态调整机制
• 模型覆盖：仅在 Qwen3-235B-A22B（128 experts, top-8）上评估。对 top-2 routing 或 expert 数 <64 的 MoE 模型，routing imbalance 程度和 compute window 需重新评估
• Dense 模型不适用：无 expert stack 时 AsyncEP 无意义；attention 部分始终是 DP
• 实现绑定 vLLM v0.11.0：虽然声称单 flag 启用，但 weight streaming engine、prefix-aware DP router、event channel 三层修改的可移植性未验证

§7 Infrastructure Impact #

• Serving: AsyncEP 的 "按 weight 聚集" 范式挑战了 MoE serving 中 "expert 静态放置 + activation 动态路由" 的固有假设。核心 insight（expert weights 是可调度资源而非静态参数）对 DeepEP、Lancet、MoE-Lightning 等 MoE 通信优化工作提出了替代方向
• Framework: Frontend-backend co-design 通过物理量 T 建立的强耦合接口，展示了调度器与执行引擎不应独立调参的设计原则。vLLM/SGLang 当前的 scheduler 与 engine 松耦合可能需要重新审视
• Algorithm: Prefix-aware routing + true-FLOPs tracking 将 prefix caching 从被动 cache effect 转为主动调度决策，且 load balance 作为 saturation 的副产品自动涌现而非显式优化目标——简化了调度策略设计
• Hardware: 论文证明 NVLink D2D AllGather 在 prefill compute window 下可被完全隐藏，暗示 NVLink 的价值不仅在于降低延迟，更在于提供可被 overlap 的异步传输通道。这对 GPU 互联拓扑选型有直接参考意义
• Workload: 形式化了 prefill-as-a-service 原子操作和 multi-selection 分解方法，为 prefill-only serving 建立了 workload 分类和 benchmark 框架

§8 Comparison with Related Work #

维度	DP×EP (vLLM)	DP×TP (vLLM)	PP×PP (vLLM)	PrefillOnly	ZeRO-Prefill (DP×AsyncEP)
Expert 通信	2× AllToAll / 层 (on-path)	AG+RS / 层 (on-path)	Send/Recv	继承底层策略	1× AllGather / 层 (off-path, 后台)
Expert load balance	straggler 放大	无（全 GPU 冗余存储）	pipeline bubble	同底层	本地 dispatch，无 straggler
Expert weight 内存	1/N per GPU	全量 per GPU	1/stage per GPU	同底层	当前层全量 + 1/N 其余层（可 offload）
Prefix 利用	被动 cache	被动 cache	被动 cache	scheduler 级 shortest-first	主动 routing + true-FLOPs tracking
MFU (8×H100 FP8)	~17%	~20%	~15%	~18%	29.8–34.7%
Min GPU count (235B FP8)	4	4	4	4	1
Prefill-only aware	否	否	否	是（scheduler）	是（全栈 co-design）
On-path comm volume	~4kBSHb	~4BSHb	~2BSHb	同底层	≈ 0

vs DeepSeek-V3 EP (2412.19437)：DeepSeek-V3 使用 EP + auxiliary-loss-free load balancing 优化 training 时 routing 均衡，但 serving 时 routing 不均仍在。ZeRO-Prefill 从根本上消除了 routing imbalance 的影响——不是让 routing 更均匀，而是让不均匀不再重要（本地 dispatch）。

vs DynaServe (2504.09285)：DynaServe 通过动态 expert 放置和 migration 优化 serving，仍在同步 EP 框架内。ZeRO-Prefill 跳出此框架，用 weight streaming 替代 expert placement optimization。

vs PrefillOnly (2604.15039)：PrefillOnly 首次定义 prefill-only serving 并优化 scheduler（shortest-prefill-first, KV lifetime），但未触及 MoE 执行栈。ZeRO-Prefill 在 execution level 消除冗余，两者互补——PrefillOnly 的 scheduler 优化可叠加在 AsyncEP 后端上。

§9 Key Numbers with Evidence #

数值	含义	来源
65.3%	生产集群中 prefill-only 工作负载占 input token 流量比例	Fig. 1, 匿名生产集群测量
16.15×	Qwen3-30B-A3B 的 max/min expert token count（聚合 48 层）	Fig. 4(a), 8×A100 BF16, 64K tokens
<16%	所有主流策略在 8×A100 上的 MFU	§4 system analysis, vLLM baseline
T = t_EP × F_GPU × γ	饱和阈值公式	Eq. (1), §6.2
γ = 1.2	默认安全余量	§6.2
1.37×	A100 BF16 端到端吞吐提升	Fig. 9, 聚合 workload, 8 GPU, vs best baseline
1.36×	H100 BF16 端到端吞吐提升	Fig. 9
1.35×	H100 FP8 端到端吞吐提升	Fig. 9
1.37×	H200 FP8 端到端吞吐提升	Fig. 9
1.59×	最大吞吐提升（long context synthetic）	Fig. 11, 32K×320, 8×H100 FP8, backend-only
29.8–36.2%	全 sweep MFU 范围	Fig. 12, 1–8 GPU, H100 FP8, synthetic
+16–18%	Frontend co-design 增量贡献	Fig. 10, 8 GPU, 四个 hw/precision configs
1–8 GPU	部署信封（vs ≥4 GPU）	§8.5, hybrid offloading + KV-cache-free
±3.6 pp	7/9 分类任务 prefill-only vs AR 精度偏差	Table 3, 9-task harness
~1 pp	同模型下 decode mode 贡献的精度差	Table 4, IMDB 25K, gpt-oss-120B
73.8K req / ~37.9M tokens	聚合评估 workload 规模	Table 2, 6 个 benchmark 混合