Papers
Topics
Authors
Recent
Search
2000 character limit reached

Sparse Expert Synchronization (SPES)

Updated 4 July 2026
  • SPES is a decentralized framework that partitions expert parameters across nodes while maintaining a shared parameter block for efficient MoE pretraining.
  • It utilizes sparse synchronization and an expert-merging warm-up strategy to lower GPU memory usage and communication costs by up to 65% compared to full-model methods.
  • Empirical results demonstrate that SPES achieves competitive convergence and downstream performance while significantly reducing resource overhead in large-scale MoE training.

SParse Expert Synchronization (SPES) is a memory-efficient decentralized framework for pretraining mixture-of-experts (MoE) LLMs in settings where each node cannot train the full model locally. It was introduced in “Pretraining A LLM using Distributed GPUs: A Memory-Efficient Decentralized Paradigm” (Zhang et al., 12 Feb 2026). The central idea is to assign each node ownership of only a subset of experts while keeping the shared dense parameters trainable on every node. Nodes perform local optimization on their owned experts and the shared block, then periodically synchronize without transmitting the full parameter set. The framework also includes an expert-merging warm-up strategy intended to accelerate early convergence by exchanging knowledge among experts during the initial training phase.

1. Formal structure of the framework

SPES is defined over an MoE model with shared parameters ψ\psi and expert parameters Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}, where MM is the total number of experts and NN is the number of nodes. The experts are partitioned into disjoint owner subsets P1,,PNP_1,\ldots,P_N, and node ii owns experts jPij \in P_i. A block-mask matrix UiU_i is used to zero out updates to all parameters except the shared block ψ\psi and the experts owned by node ii (Zhang et al., 12 Feb 2026).

At communication round Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}0, node Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}1 begins from the globally broadcast model

Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}2

then performs Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}3 local update steps over its local data Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}4:

Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}5

Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}6

with Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}7. By construction, gradients for all non-owned experts are masked out.

This parameterization makes expert ownership explicit and turns expert training into a sparse update problem. The design differs from fully replicated decentralized training in that local computation is concentrated on node-owned experts rather than the entire expert set. A plausible implication is that MoE architectures are particularly well suited to this regime because expert parameters admit a natural partition across nodes.

2. Sparse synchronization and expert merging

After Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}8 local steps, SPES performs a sparse synchronization step. The shared block is aggregated by averaging:

Φ={ϕ1,,ϕM}\Phi = \{\phi_1,\ldots,\phi_M\}9

Experts are not averaged. Instead, each expert is updated solely from its owner node:

MM0

where MM1 denotes the owner of expert MM2 (Zhang et al., 12 Feb 2026).

The framework optionally applies an expert-merging warm-up for MM3. Similarity between experts is computed using the cosine similarity of input weights:

MM4

For each expert MM5, the top-MM6 similar peers MM7 are selected, and the expert is updated by

MM8

where MM9 is a mixing coefficient that linearly decays to zero by step NN0.

The algorithmic workflow includes server broadcast, node-local sparse updates, optional warm-up merging at synchronization time, transmission of updated shared parameters and owned experts, shared-block aggregation, owner-based expert replacement, and decay of NN1. The key hyperparameters are the synchronization interval NN2, the merge coefficient NN3, the merge horizon NN4, and the merge fan-in NN5. Although the method is described as decentralized, the reported implementation includes a parameter server for broadcast and aggregation; this indicates that the defining sparsity property lies in expert ownership and synchronization semantics rather than in the elimination of all coordinating infrastructure.

3. Memory, communication, and convergence properties

SPES is motivated by the observation that decentralized methods based on federated optimization still require each node to train the entire model, which remains constrained by GPU memory limitations. The framework’s memory analysis distinguishes a full-model baseline from the sparse expert regime. A fully decentralized FedAvg node requires approximately

NN6

floats, reflecting optimizer states and gradients for all parameters. In SPES, node NN7 stores

NN8

where NN9 is the parameter count of locally owned experts and the P1,,PNP_1,\ldots,P_N0 term remains because the node stores read-only copies of all experts (Zhang et al., 12 Feb 2026).

Under the assumption P1,,PNP_1,\ldots,P_N1, the per-node memory scales as P1,,PNP_1,\ldots,P_N2. Communication exhibits a similar asymmetry. Each round, node P1,,PNP_1,\ldots,P_N3 uploads at most P1,,PNP_1,\ldots,P_N4, yielding uplink of approximately P1,,PNP_1,\ldots,P_N5, while the download is approximately P1,,PNP_1,\ldots,P_N6. Full-model schemes exchange P1,,PNP_1,\ldots,P_N7 in both directions.

The convergence statement is given as a sketch under standard P1,,PNP_1,\ldots,P_N8-smoothness and bounded variance assumptions. The appendix’s Theorem 1 yields

P1,,PNP_1,\ldots,P_N9

Here ii0 and ii1 denote variances on shared and expert gradients, ii2 captures data heterogeneity across owners, and the merge term vanishes if ii3 is small. The stated interpretation is that shared-block variance shrinks by ii4 as the number of nodes increases, while expert blocks remain owner-only and are aided by merging warm-up.

4. Experimental configuration and model regimes

The reported experiments cover from-scratch pretraining and upcycling regimes. The 2B-parameter runs use ii5 nodes, each with one NVIDIA L40S (48 GB) GPU, connected by 17 Gbps Ethernet to a parameter server with a 64-core Xeon and 720 GB RAM. The 7B-parameter runs use ii6 nodes, each with ii7 NVIDIA A800 GPUs connected by NVLink, with 13 Gbps Ethernet to a server with a 96-core Xeon and 1.4 TB RAM. The 9B upcycling setup uses the same 4-node A800 configuration and initializes from a 1.7B dense checkpoint (Zhang et al., 12 Feb 2026).

The model architectures are summarized in the paper’s Table 3. The 2B MoE uses 16 layers, 24 heads, hidden size 1,536, ii8 experts, and ii9 active experts. The 7B MoE uses 16 layers, 16 heads, hidden size 2,048, jPij \in P_i0 experts, and jPij \in P_i1 active experts. The 9B upcycled MoE uses 28 layers, 16 heads, hidden size 2,048, jPij \in P_i2 experts, and jPij \in P_i3 active experts.

The training data and hyperparameters are likewise specified.

Regime Data mixture Core optimization settings
2B, 7B from scratch Ultra-FineWeb (64.2%), SlimPajama (27.2%), StarCoder (6.6%), arXiv (0.7%), OpenWebMath (0.4%), Pes2o (0.5%), Algebraic Stack (0.4%) Qwen v1 tokenizer; AdamW jPij \in P_i4
9B upcycling Nemotron-CC v2 (63.3%), Nemotron-Math (16.4%), code (11.9%), SFT-style (8.4%) same tokenizer and optimizer family

The learning-rate schedules are jPij \in P_i5 for 2B, jPij \in P_i6 for 7B, and jPij \in P_i7 for 9B, each with linear warm-up over 2,000 steps. The per-node token batches are jPij \in P_i8MjPij \in P_i9 for 2B, UiU_i0MUiU_i1 for 7B, and UiU_i2MUiU_i3 for 9B. Synchronization uses UiU_i4 for 2B and 7B, while 1B ablations use UiU_i5 late. The merge configuration is UiU_i6, UiU_i7, UiU_i8 steps, with merging every 500 steps.

5. Empirical results

The reported memory and communication results directly quantify the sparse synchronization design. For the 2B model on UiU_i9 GB GPUs, FedAvg and DiLiCo require approximately 55 GB per GPU, whereas SPES uses approximately 35 GB, corresponding to a 36% reduction. For the 7B model on 4ψ\psi0A800, SPES keeps per-GPU memory under 48 GB without intra-node sharding. Per communication round, SPES requires approximately 9.8 GB uplink versus 28.6 GB for a full-model scheme, a 65% reduction (Zhang et al., 12 Feb 2026).

Training throughput is compared against a centralized baseline. Centralized 7B FSDP on 8ψ\psi1A800 with InfiniBand HDR 200 Gbps yields 3.79k tok/s/GPU, while SPES with 13 Gbps Ethernet achieves 3.67k tok/s/GPU. Figure 1 is reported to show that, after an initial lag, SPES converges to similar or slightly better validation scores than centralized training and DiLiCo when averaged over ARC-E, ARC-C, PIQA, SciQ, OBQA, BoolQ, SIQA, and WinoGrande.

Downstream evaluations are given in the main text and appendix. SPES-2B trained on 500B tokens matches or outperforms MobiLlama-0.8B, TinyLlama-1.1B, and OpenLM-1.1B. SPES-7B trained on 500B tokens obtains 89.9 on SciQ, 74.7 on PIQA, 44.8 on SIQA, 62.7 on BoolQ, 72.1 on ARC-E, and 43.8 on ARC-C, and is reported as being on par with MoE++, which was trained on 1T tokens. SPES-9B, trained for 400B tokens from a strong dense initialization, reaches 95.3 on SciQ, 78.9 on PIQA, 47.5 on SIQA, 77.3 on BoolQ, 81.5 on ARC-E, and 57.3 on ARC-C.

Ablation results attribute part of the observed performance to the merge strategy and synchronization schedule. Expert merging improves the average score from 50.5 to 51.3, a gain of 0.8 points. Varying ψ\psi2 shows the best performance at ψ\psi3, with larger ψ\psi4 degrading results. Varying the number of nodes from 2 to 8 leaves performance relatively stable, with average score changing from 50.6 to 49.5. Among merge hyperparameters, ψ\psi5, ψ\psi6, and ψ\psi7k are reported as optimal.

6. Limitations, operating regimes, and prospective extensions

The paper identifies three principal advantages of SPES: major reduction in per-node GPU memory, substantially lower communication suitable for Internet-connected heterogeneous clusters, and competitive convergence and final quality relative to centralized baselines despite sparse expert updates (Zhang et al., 12 Feb 2026). These properties make the method especially relevant in memory-constrained environments, under low-bandwidth cross-node links in the 10–20 Gbps range, and for MoE architectures with large expert counts, where expert partitioning is natural.

The reported limitations are correspondingly specific. SPES shows slightly slower initial convergence due to sparse token utilization. It requires careful tuning of the synchronization interval ψ\psi8 and the merging schedule to balance divergence against communication cost. Heterogeneous data across nodes, represented in the theory by ψ\psi9, can introduce bias; merging is stated to mitigate but not eliminate this effect. These observations address a likely misconception that sparsifying expert updates is cost-free: the method reduces memory and communication pressure, but it does not remove optimization trade-offs.

Several extensions are proposed. These include combining SPES with intra-node FSDP or ZeRO to move beyond 10B MoE on commodity cards, adaptive ii0 or event-triggered synchronization based on divergence thresholds, more advanced expert mixtures such as clustering or knowledge distillation in place of simple cosine merging, application to multimodal MoE or encoder–decoder architectures, and theoretical treatment of non-IID client distributions and asynchronous updates. This suggests that SPES is best understood not as a single fixed training recipe, but as a sparse synchronization paradigm for distributed MoE pretraining under severe memory and bandwidth constraints.

Definition Search Book Streamline Icon: https://streamlinehq.com
References (1)

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to SParse Expert Synchronization (SPES).