Mixture-of-Parallelisms: Towards Memory-Efficient Training Stack for Mixture-of-Experts Models
Abstract: This paper showcases a memory-efficient training stack for Mixture-of-Experts (MoE) models. It is a training paradigm that combines and specializes various existing and novel parallelism techniques at different layers and stages of the Mixture-of-Experts (MoE) model training pipeline. It leverages these techniques to achieve maximal efficiency given the physical constraints of CPU, CPU memory, GPU HBM memory, and the CPU-GPU, GPU-GPU, and node-node communication bandwidth of the GPU cluster. It also contains a novel strategy for the optimizer step to achieve high throughput and memory efficiency, enabling practitioners to conduct lossless pre-training/fine-tuning of trillion-parameter scale models, at a million context length, with just under 12 8x H200 GPU nodes, with state-of-the-art throughput and memory efficiency. In our experiments, MoP delivers 4.7x--8.2x higher per-GPU throughput than a strongly-tuned FSDP2 baseline (with the gap widening at larger scale) and sustains training at context lengths up to 1M tokens, where the baseline runs out of memory beyond 64--128K.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
Explain it Like I'm 14
Overview: What this paper is about
This paper introduces a new way to train very LLMs called Mixture‑of‑Experts (MoE). These models can have trillions of parameters and handle extremely long inputs (up to about one million tokens), but they usually run into memory limits and slowdowns on GPUs. The authors propose “Mixture‑of‑Parallelisms” (MoP), a training recipe that carefully splits different parts of the model across machines in different ways so memory is used wisely and training runs faster—without changing the model’s results.
Goals and Questions
The paper focuses on a simple idea: different parts of a model cause different kinds of memory and speed problems, so why use the same training strategy everywhere?
They aim to:
- Find a way to train huge MoE models with very long inputs on a small number of GPUs.
- Reduce memory use in the most memory‑hungry places (like the optimizer, activations, and giant vocab layers).
- Keep training fast by overlapping communication and computation.
- Do all of this “losslessly,” meaning the training result is exactly the same as if you didn’t use these tricks.
How it works (in everyday terms)
Think of the model as a team project with many tasks. Instead of having everyone follow one plan, MoP assigns each task a plan that fits it best. Here are the main ideas, with analogies:
- MoE models (the “experts” idea):
- Imagine a school with many specialists (experts). Each piece of text (a token) is sent only to a few specialists who are best for it, not all of them. This makes the model very large (lots of specialists) without making each token very expensive to process.
- Splitting a long text across GPUs (sequence parallelism):
- A million‑word book is too big for one person to hold in memory. So, split the book into chapters and give each chapter to a different person (GPU). Each person only stores their part, which saves memory a lot.
- Handling the “dense” parts of the model (sharding weights):
- The shared rules and small layers that everyone uses are divided across people and quickly combined right before use, then discarded. Like keeping parts of a big toolbox stored separately and assembling only the tool you need when you need it.
- Managing the experts (hybrid expert parallelism + load balancing):
- If too many students line up for the same specialist, you move some students—and even temporarily lend the specialist’s notes—to less busy rooms. This keeps anyone from getting overwhelmed and reduces “peak” memory use while staying correct. The paper uses a method called LLEP (Least‑Loaded Expert Parallelism) and adds a memory‑savvy twist: it overlaps sending students with doing the work, so not everything sits in memory at once.
- Taming the giant vocabulary layer (sharded vocabulary projection):
- At the end, the model scores each token against a huge dictionary (vocabulary). Storing all these scores at once is like trying to hold a city‑sized spreadsheet in your backpack. Instead, MoP splits the dictionary across people and computes only the pieces needed at any moment, combining them to get the exact same answer—without ever holding the whole thing in memory.
- Keeping the optimizer state off the GPU (efficient optimizer pipeline):
- The optimizer (which updates the model’s weights) keeps big “notebooks” of running stats. Instead of stuffing these into the GPU’s limited memory, MoP keeps them in the computer’s main memory (like lockers in the hallway) and brings small pieces to the GPU as needed. It overlaps this “fetch and update” with other work so it doesn’t slow things down.
A key design detail: all these splits reuse the same group of devices in overlapping ways rather than multiplying device counts in a complex grid. This avoids wasting GPUs on a one‑size‑fits‑all plan.
Main findings and why they matter
In tests on large MoE models (120B, 600B, and 1T parameters), MoP:
- Ran 4.7× to 8.2× faster per GPU than a strong, carefully tuned baseline (called FSDP2), with bigger gains on larger models.
- Kept training even when the input length grew to 1,000,000 tokens, whereas the baseline ran out of memory around 64,000–128,000 tokens.
- Achieved this on a small cluster: just under twelve nodes, each with 8 high‑end GPUs (H200s), for the trillion‑parameter model.
Why this matters:
- Faster training and longer context on fewer GPUs means much lower cost.
- Long context lets models remember and reason over longer documents, codebases, or conversations—opening new possibilities for real‑world tasks.
- The approach is “lossless,” meaning it doesn’t approximate or change the math; it simply organizes the work better.
Implications and impact
This work shows that matching the right parallelism to each part of a model can unlock huge memory savings and speedups, making trillion‑parameter, long‑context training possible on smaller, more affordable hardware. It also highlights a trade‑off: MoP depends on fast connections between machines (lots of communication). On slower networks, the gains shrink.
Looking ahead, this strategy could:
- Make big‑model pre‑training and fine‑tuning more accessible to smaller labs.
- Improve long‑context abilities in practical applications (like long‑form analysis, code, or multi‑document reasoning).
- Be automated further—choosing how to split each part based on the model and the cluster—and extended to make long‑context inference (using the model) more efficient too.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a single, actionable list of what remains missing, uncertain, or unexplored in the paper.
- Formal algorithmic specification for the “memory-efficient LLEP” variant is missing (exact chunking policy, buffer lifetimes, overlap schedule, and a worst-case bound on transient memory and communication).
- How optimizer-state consistency is maintained when experts migrate across ranks under LLEP is unclear (where and master weights live, how they move, and how gradients are aggregated correctly across migrations and accumulation steps).
- Proof or rigorous numerical validation that the optimizer pipeline is “lossless” under reordering/overlap (showing no stale-weight effects and exact equivalence to standard AdamW across long training).
- Communication-computation overlap policies and stream/NCCL scheduling are not detailed, leaving uncertainty about deadlock avoidance and contention across overlapping sub-groups on the same ranks.
- No cost model or explicit formulas for per-layer communication volumes (all-gathers, all-to-alls, reduce-scatters) under the hybrid EP×sharding plan, preventing predictive sizing and topology-aware planning.
- The trade-off knob between expert routing volume and weight-gather volume in the hybrid EP×sharding scheme is described qualitatively but lacks quantitative guidelines or an automated selection procedure.
- The “advanced upgrades” to Ulysses-style sequence parallelism are not specified (algorithms, kernels, and memory footprints), limiting reproducibility and preventing practitioners from implementing or evaluating them.
- The sharded vocabulary-projection algorithm is under-specified: exact numerically-stable distributed log-sum-exp, reduction order, and gradient reconstruction across shards (including corner cases) are not provided.
- Support of the sharded projection for tied embeddings, label smoothing, sampled/adaptive softmax, or alternative output heads is not evaluated, leaving applicability to common training regimes uncertain.
- Interactions with quantization/low-precision training (e.g., FP8, 8-bit optimizers) are not explored, especially for numerically sensitive pieces like distributed softmax and optimizer offload.
- Position-encoding and long-context stabilization techniques required for 1M-token training (e.g., RoPE scaling, attention truncation, normalization strategies) are not described, obscuring how training quality is maintained.
- The evaluation reports throughput only; there are no convergence/quality metrics (loss/perplexity curves, final validation performance) to substantiate the “lossless” claim in end-to-end training.
- No ablation studies isolate contributions of each component (memory-efficient LLEP, sharded vocab projection, optimizer pipeline) to throughput/memory, nor a per-step time breakdown (compute vs. communication vs. optimizer).
- Sensitivity to network bandwidth/topology is only qualitatively discussed; there is no empirical sweep across interconnects (e.g., PCIe-only, 100/200/400GbE, different NVLink/NVSwitch fabrics) or larger to show where MoP becomes comm-bound.
- Portability across hardware is untested: behavior on A100/H100, AMD/ROCm, TPU, or heterogeneous clusters (and dependencies on vendor-specific kernels like FlashAttention) is unknown.
- The analysis assumes (single sequence per step); generalization to multi-sequence microbatches and the implications for sequence parallelism and router load are not addressed.
- Robustness to extreme or rapidly shifting expert popularity is not evaluated; worst-case communication/memory under heavy skew and backpressure or throttling policies remain open.
- Impact of LLEP and expert migration on optimizer-state locality and CPU-GPU bandwidth consumption (host offload traffic patterns, prefetch sizes, pinning, NUMA effects) is not quantified.
- Mechanisms for subgroup size selection (, , ) are not provided; automating them via a cost model or topology-aware search (and potentially adapting them online) is left as future work.
- Interactions with activation checkpointing and their net compute/memory trade-offs (especially under long contexts) are not measured; guidelines for when/how much to recompute are absent.
- Memory accounting lacks concrete peak traces; per-component memory breakdowns at long contexts (attention, MoE, vocab, optimizer) are not reported to validate claimed headroom and identify remaining bottlenecks.
- Fairness and breadth of baselines are limited: comparisons to specialized MoE systems (e.g., Tutel, DeepSpeed-MoE with advanced routing/sequence-parallel modes, Megablocks/GSPMD-style partitioners) are missing.
- Applicability beyond MoE (to dense transformers or other sparse architectures) is not discussed; which MoP components remain beneficial and how to specialize them for non-MoE models is open.
- Inference-time implications are untested: adapting component-specialized sharding and the sharded projection for low-latency decoding and KV-cache management at long context remains to be explored.
- Fault tolerance and elasticity (expert migrations mid-step, optimizer offload consistency after failures, checkpointing granularity, determinism) are not addressed.
- Energy efficiency and cost-per-token under higher communication loads are not measured; the trade-off between memory savings and energy due to increased networking is unknown.
- Vocabulary scaling beyond large (e.g., extremely large tokenizers) and subword/byte-level variants are not benchmarked, leaving open how the sharded projection scales in practice.
- Potential interactions with gating strategies (top-1 vs top-2, capacity factor, auxiliary losses, token dropping) under LLEP and hybrid sharding are not evaluated for stability or quality impacts.
- Implementation and reproducibility details (code release, kernels, exact configs, hyperparameters, routing/aux losses, dataset and training recipe) are missing, hindering independent validation.
Practical Applications
Overview
The paper introduces Mixture-of-Parallelisms (MoP), a component-specialized training stack for sparse Mixture-of-Experts (MoE) models that achieves major memory savings and throughput gains by:
- Assigning different parallelism strategies to each model component (attention, experts, vocabulary projection, optimizer) over overlapping rank sub-groups instead of a single global 3D plan.
- Using sequence parallelism for attention, a hybrid expert-parallel × sharding scheme for expert weights with a memory-efficient variant of LLEP routing, a sharded data–tensor-parallel vocabulary projection that avoids full logits materialization, and a host-offloaded optimizer pipeline with computation–communication overlap.
- Demonstrating 4.7–8.2× per-GPU throughput gains vs a tuned FSDP2 baseline and stable training up to 1M-token context on ~12×(8×H200) nodes.
Below are concrete, real-world applications derived from these findings, methods, and innovations.
Immediate Applications
These can be adopted now with appropriate engineering integration and suitable hardware.
- Train and fine-tune long-context MoE LLMs on smaller clusters
- Sectors: software, cloud AI services, enterprise AI, academia
- Use case: Pre-train or fine-tune trillion-parameter MoE LLMs for tasks requiring very long context (e.g., 128K–1M tokens) using ~10–12 nodes rather than much larger clusters.
- Potential workflows/products:
- Replace or augment FSDP/Megatron stacks with MoP-style component specialization.
- Integrate memory-efficient LLEP, sharded vocabulary projection, and optimizer offload pipeline into PyTorch-based training.
- Assumptions/dependencies:
- High-bandwidth interconnects (NVLink intra-node, fast Infiniband inter-node).
- Sufficient host DRAM for optimizer state.
- MoE-capable training code; FlashAttention or similar kernels; BF16/FP32 training.
- Domain-specific long-context models (million-token scale)
- Sectors: legal (contracts and eDiscovery), healthcare (longitudinal EHRs), finance (regulatory filings, research reports), software engineering (whole-repo code modeling), telecom/IT (log analysis), energy (multi-year sensor streams)
- Use case: Fine-tune long-context MoE LLMs to process end-to-end document collections or long sequences without aggressive chunking or RAG-only pipelines.
- Potential tools/products:
- “Whole-repository coding assistants” that are pre-trained/fine-tuned to understand an entire codebase.
- “All-in-one contract and policy analyzers” that ingest millions of tokens from related documents.
- “Longitudinal patient summarizers” trained on years of EHR timelines.
- Assumptions/dependencies:
- Availability of long-context training data and objectives.
- Compliance and privacy tooling for sensitive domains.
- Inference-time support for large contexts (engineering and cost considerations beyond training).
- Reduced training cost and higher throughput for MoE pretraining
- Sectors: model labs, cloud providers, AI startups
- Use case: Cut GPU-hours per token by 4.7–8.2× per-GPU throughput gains (especially at larger model scales) while enabling longer contexts.
- Potential workflows/products:
- More model runs and ablation studies within fixed compute budgets.
- Faster iteration cycles for architecture and data recipe search.
- Assumptions/dependencies:
- Bandwidth sufficient to keep communication overlapped with compute (speedups erode on slower fabrics).
- Adoption of MoE architectures and routing (top-k experts).
- Upgrade HPC/enterprise training stacks for memory efficiency
- Sectors: research HPC centers, enterprise on-prem clusters
- Use case: Retrofitting existing clusters to recover HBM for activations via host-offloaded optimizer updates and component-wise sharding.
- Potential workflows:
- Replace monolithic 3D parallel plans with overlapping sub-groups tailored to attention, MoE, projection, and optimizer components.
- Assumptions/dependencies:
- Systems support for large host-memory usage and tuned collective communication.
- Ops/DevOps readiness for new parallelism topologies and monitoring.
- Integrate MoP primitives into open-source frameworks
- Sectors: software tooling, open-source communities
- Use case: Contribute implementations of memory-efficient LLEP, sharded data–tensor-parallel vocabulary projection, and optimizer pipelines to PyTorch/Megatron/DeepSpeed ecosystems.
- Potential tools:
- PyTorch/FSDP-compatible modules for sequence parallelism + MoE routing with reduced activation peaks.
- Triton/CUDA kernels for online loss computation without full logit tensors.
- Assumptions/dependencies:
- Kernel engineering capacity; CI/benchmarking for correctness and performance.
- Community consensus on APIs and composability.
- Long-context SFT/RLHF and post-training on realistic histories
- Sectors: foundation model post-training for consumer and enterprise assistants
- Use case: Supervised fine-tuning and RLHF on long sessions/histories without OOM, improving instruction-following over extended dialogues or documents.
- Potential workflows:
- Use MoP to fit larger micro-batches or longer episodes per GPU for stable optimization.
- Assumptions/dependencies:
- Availability of long-horizon supervision data; stable RLHF pipelines with MoE backbones.
- Inference-time memory and latency constraints remain to be addressed separately.
Long-Term Applications
These require further research, engineering, or scaling, but are viable directions enabled by MoP’s principles.
- Automated per-component parallelism planner
- Sectors: software tooling, compilers, cloud training platforms
- Use case: Auto-tune subgroup sizes for sequence/expert/projection sharding (D, E_p, P) from model shape, cluster topology, and bandwidth to optimize throughput and memory.
- Potential tools/products:
- Cluster-aware auto-parallelism planners integrated with PyTorch 2.x compilers or distributed launchers.
- Assumptions/dependencies:
- Robust performance models and topology discovery; online adaptation to workload dynamics.
- Inference-time component specialization for long-context serving
- Sectors: SaaS LLM providers, enterprise inference platforms
- Use case: Apply MoP-style sharding (e.g., sharded vocab projection, sequence sharding) to reduce memory and latency at inference for very long contexts.
- Potential products:
- Long-context APIs that can serve 512K–1M-token prompts with controlled memory footprints.
- Assumptions/dependencies:
- Latency-sensitive kernels, KV-cache management with sequence sharding, careful QoS under all-to-all traffic.
- Multimodal trillion-scale MoE training with long context
- Sectors: robotics, autonomous systems, media/entertainment, healthcare imaging
- Use case: Train sparse MoE vision/language/audio models over long video/audio/text sequences (e.g., hours-long videos, multi-visit clinical timelines) using MoP to fit memory and bandwidth.
- Potential products:
- Long-horizon video understanding and planning models.
- Cross-document reasoning systems spanning text+images at corpus scale.
- Assumptions/dependencies:
- Suitable multimodal MoE architectures and routing; multimodal long-context datasets; additional kernel and communication support.
- Hardware–software co-design for communication-bound regimes
- Sectors: semiconductor, systems vendors, hyperscalers
- Use case: Design NICs, NVLink fabrics, memory tiering (HBM–DRAM), and accelerators optimized for MoP’s communication patterns (all-to-all, all-gather, reduce-scatter with overlap).
- Potential products:
- Network-aware schedulers; DPUs/SmartNICs that offload collective orchestration; larger CPU–GPU bandwidth for optimizer offload.
- Assumptions/dependencies:
- Long hardware design cycles, standardization across vendors, verified benefit across workloads.
- Enterprise products with whole-corpus reasoning
- Sectors: legal, finance, knowledge management, software development
- Use case: Train models that natively reason over entire corpora, reducing dependence on retrieval heuristics and context window fragmentation.
- Potential products:
- “Corpus-native” assistants: end-to-end legal review; comprehensive financial analysis of multi-year filings; codebase-wide refactoring and risk detection.
- Assumptions/dependencies:
- Inference cost/latency for long contexts remains a bottleneck; evaluation methods for corpus-scale reasoning; safety and compliance controls.
- Policy and access: democratizing large-scale training
- Sectors: public research, government, funding agencies
- Use case: Leverage MoP to lower the hardware barrier for long-context, trillion-parameter training, informing grant programs and compute-credit allocation.
- Potential outcomes:
- Broader academic participation; reproducibility via smaller clusters; updated sustainability metrics balancing fewer GPUs vs higher network usage.
- Assumptions/dependencies:
- Transparent reporting of energy and bandwidth costs; shared software artifacts; standardized evaluation.
- Cluster scheduling and fairness with LLEP-aware routing
- Sectors: cloud providers, HPC schedulers
- Use case: Combine least-loaded expert parallelism with job schedulers to mitigate stragglers and improve cluster utilization while containing inter-node traffic.
- Potential tools:
- LLEP-aware placement and migration policies; cross-job routing throttles; congestion-aware collectives.
- Assumptions/dependencies:
- Scheduler integration, congestion control mechanisms, and monitoring to avoid interference across tenants.
Key Cross-Cutting Assumptions and Dependencies
- High-bandwidth interconnects (NVLink, high-speed Infiniband) are critical; performance gains diminish on bandwidth-constrained clusters.
- Adequate host DRAM to store fp32 optimizer state (≈12× parameter bytes); stable CPU–GPU bandwidth for offloading.
- Availability of MoE architectures with top‑k routing and support for sequence-parallel attention and FlashAttention-like kernels.
- Software readiness: reliable implementations of memory-efficient LLEP, sharded vocabulary projection (exact loss/grad without materializing logits), and overlapped optimizer pipelines.
- Data prerequisites: long-context datasets and training objectives that benefit from million-token sequences; domain compliance/privacy for sensitive data.
- Inference implications: training with 1M-token contexts does not automatically guarantee cost-effective inference at the same lengths; serving stacks may require separate engineering.
Glossary
- AdamW: An optimizer that decouples weight decay from gradient-based updates, widely used for large-scale training. "under mixed-precision training with AdamW"
- Activation checkpointing: A memory-saving technique that discards intermediate activations in forward and recomputes them in backward. "Activation checkpointing"
- All-gather: A collective communication primitive that gathers shards from all ranks so each rank receives the full tensor. "an all-gather reconstructs its full weights"
- All-reduce: A collective that reduces (e.g., sums) tensors across ranks and distributes the result to all ranks. "synchronizes gradients with an all-reduce"
- All-to-all: A collective where each rank sends distinct data to every other rank, often used for token routing in MoE. "dispatches tokens to their destination expert by an all-to-all"
- bf16: A 16-bit brain floating point format that balances range and precision for efficient training. "a $2$-byte (bf16) working copy"
- Cartesian 3D parallelism: A composition of data, tensor, and pipeline parallelism axes into a 3D grid. "The three axes form a Cartesian 3D parallelism with "
- Context parallelism (CP): A parallelism axis that partitions the sequence/context dimension across devices. "tensor (TP), context (CP), and expert (EP) parallelism"
- Data-tensor parallelism: A hybrid scheme combining data and tensor parallelism, here used to shard the vocabulary projection while each rank keeps its own batch. "a sharded data-tensor-parallel vocabulary projection"
- Expert parallelism (EP): A scheme that partitions experts across devices so tokens are routed to expert-hosting ranks. "expert parallelism partitions experts across devices."
- FlashAttention: An IO-aware attention kernel that avoids materializing the full attention matrix for efficiency. "FlashAttention kernel"
- FLOPs: Floating point operations, a measure of computation cost. "FLOPs per token"
- Fully Sharded Data Parallelism (FSDP): A data-parallel sharding approach that shards parameters, gradients, and optimizer state across ranks. "fully-sharded data parallelism"
- GPU HBM memory: High Bandwidth Memory on GPUs, providing large bandwidth for model data. "GPU HBM memory"
- Host DRAM: The system’s main memory on the CPU side, often used for offloading optimizer state. "host DRAM"
- Least-Loaded Expert Parallelism (LLEP): A routing system that balances MoE load by migrating tokens and expert parameters to less-loaded ranks. "Least-Loaded Expert Parallelism (LLEP)"
- Logit tensor: The pre-softmax output matrix (e.g., N×V) whose size can dominate activation memory. "the single largest logit tensor"
- Megatron-LM: A framework that composes tensor, pipeline, and related parallelism strategies for large models. "Megatron-LM"
- Mixture-of-Experts (MoE): An architecture with many expert networks where each token is routed to a small subset (top-k) of experts. "Mixture-of-Experts (MoE)"
- Mixture-of-Parallelisms (MoP): The paper’s proposed training stack that specializes different parallelisms to different components of MoE training. "Mixture-of-Parallelisms (MoP)"
- NVLink: A high-bandwidth GPU interconnect used to keep tensor-parallel communication efficient. "NVLink"
- Optimizer pipeline: An overlapped scheme that updates optimizer state in parallel with compute to hide optimizer latency. "Efficient Optimizer Pipeline"
- Optimizer state: The per-parameter auxiliary data (e.g., master weights, moments m and v) maintained by optimizers like AdamW. "the optimizer state dwarfs the weights themselves."
- Pipeline parallelism (PP): Splitting model layers into stages across devices and streaming micro-batches through them. "Pipeline parallelism (PP) partitions the blocks"
- Reduce-scatter: A collective that reduces (e.g., sums) and scatters shards of a tensor across ranks, used for gradients. "Gradients follow the inverse schedule via reduce-scatter."
- Sequence parallelism: Sharding activations along the sequence dimension to reduce per-rank memory during attention. "sequence parallelism"
- Tensor parallelism (TP): Splitting weight matrices across ranks (by rows/columns) so each rank computes a partial matmul. "Tensor parallelism (TP)"
- Top-k: Selecting the k highest-scoring experts per token for routing in MoE layers. "top- experts"
- Ulysses-style sequence parallelism: A specific sequence-parallel attention approach that swaps layouts via all-to-all to enable full-sequence softmax. "Ulysses-style sequence parallelism"
- Vocabulary projection: The final linear mapping from hidden states to vocabulary logits, often the largest weight/activation. "The vocabulary projection forms the largest single weight matrix"
- ZeRO-3: The ZeRO stage that shards parameters, gradients, and optimizer state fully across data-parallel ranks. "ZeRO-3 / FSDP-FULL_SHARD"
- ZeRO-Offload: A technique that places optimizer state (and optionally gradients) on the host to save GPU memory. "ZeRO-Offload pushes the optimizer state and master weights"
