LLM Systems

MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism

Serving MoE turns sparse compute into a scheduling problem: routing skew can create stragglers and token-dispatch communication can bottleneck, motivating scheduling and, in systems such as MegaScale-Infer, disaggregated expert-parallel serving.

status: publishedimportance: importantdifficulty 4/5math: graduateread: 20mlive demo
Editorial systems illustration of sparse token routing across experts with all-to-all exchange and a straggler bottleneck.

Concept Structure

MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism

01Intuition

Start with the picture, metaphor, or geometric mechanism.

02Math

Make the objects explicit and connect them with notation.

03Code

Mirror the equations with runnable implementation details.

04Interactive Demo

Manipulate the mechanism and watch the idea respond.

4prerequisites
1next concepts
2related links

Learning map

MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism
BeforeScaled Dot-Product Attention & Transformer LayersNow4/4 sections readyTryManipulate one control and predict the visible change.NextSpeculative Decoding: Lossless Multi-Token Generation

Object flow

4/4 sections readyAsk about thisResearch room
ConceptMoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated ParallelismLLM Systems
3 sources attachedLocal snapshot ready
concept:llm-systems/moe-serving

Conceptual Bridge

What should feel connected as you move through this page.

Carry inScaled Dot-Product Attention & Transformer Layers

Bring the mental model from Scaled Dot-Product Attention & Transformer Layers; this page will reuse it instead of restarting from zero.

Work hereMoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism

Serving MoE turns sparse compute into a scheduling problem: routing skew can create stragglers and token-dispatch communication can bottleneck, motivating scheduling and, in systems such as MegaScale-Infer, disaggregated expert-parallel serving.

Carry outSpeculative Decoding: Lossless Multi-Token Generation

The next edge should feel earned: use the demo prediction here before following Speculative Decoding: Lossless Multi-Token Generation.

Test the linkManipulate one control and predict the visible change.Then continue to Speculative Decoding: Lossless Multi-Token Generation
01

01

Intuition

Build the mental picture first so the rest of the page has something to attach to.

Section prompt

MoE looks like "cheaper inference": only run a few experts per token.

In serving, the story flips. MoE becomes a systems scheduling problem:

  • tokens get routed unevenly, so some experts become bottlenecks (stragglers),
  • expert-parallel MoE layers must dispatch token activations to the selected experts and combine results; this is often all-to-all in colocated expert parallelism and becomes M2N/N2M in disaggregated layouts such as MegaScale-Infer,
  • at decode time, you also carry the KV cache burden, so you are juggling both memory and communication.

MegaScale-Infer illustrates the systems goal: keep GPUs busy despite sparsity, skew, and communication overhead. The biggest wins are not guaranteed by sparse FLOPs alone; they come from the surrounding scheduling, batching, and communication plan.

02

02

Math

Translate the story into symbols, assumptions, and a derivation you can inspect.

Section prompt

Token dispatch communication (why layout matters)

Per MoE layer, tokens are routed to experts and then combined back. A crude but useful byte-count is:

Bytescomm2Tkdmodelb,\mathrm{Bytes}_{\mathrm{comm}} \approx 2\cdot T\cdot k\cdot d_{\mathrm{model}}\cdot b,

where:

  • TT is tokens in the microbatch,
  • kk is top-kk experts per token,
  • dmodeld_{\mathrm{model}} is hidden width,
  • bb is bytes per element (e.g., 2 for fp16),
  • the factor of 2 is dispatch + combine.

If communication is the bottleneck, adding more experts can make you slower even if compute drops.

Stragglers from routing skew

Let nen_e be the number of tokens routed to expert ee in a microbatch. If expert compute time is proportional to token count, then layer time is dominated by:

tlayermaxe  temaxe  ne.t_{\mathrm{layer}} \approx \max_e\; t_e \propto \max_e\; n_e.

Even if the average load is small, the maximum load can be much larger when routing is skewed. Tail latency kills throughput.

Disaggregation (separate pools)

One modern response is disaggregation: run attention in one pool of GPUs and experts in another, pipelining between them. This trades extra communication for higher utilization and better resource matching.

03

03

Code

Keep the implementation aligned with the notation so the algorithm is legible.

Section prompt
import numpy as np

rng = np.random.default_rng(0)
E = 16        # experts
T = 4096      # tokens in a microbatch

# A skewed routing distribution (one "popular" expert)
p = np.ones(E) * 0.9
p[0] = 6.0
p = p / p.sum()

choices = rng.choice(E, size=T, p=p)  # top-1 for simplicity
counts = np.bincount(choices, minlength=E)

print("avg tokens/expert:", round(float(counts.mean()), 2))
print("max tokens/expert:", int(counts.max()))
print("straggler factor max/mean:", round(float(counts.max() / counts.mean()), 2))
print("top-5 expert loads:", np.sort(counts)[-5:][::-1].tolist())
04

04

Interactive Demo

Use direct manipulation to connect the explanation to a moving system.

Section prompt

The demo below asks you to predict the serving bottleneck before revealing expert loads and token-dispatch communication bytes. The key invariant is that sparse activated compute does not guarantee low latency: routing skew and dispatch/combine traffic can bottleneck the layer.

Live Concept Demo

Explore MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism

The stage is code-native and interactive. Use it to test the explanation against the mechanism.

difficulty 4/5graduatecode-aligned
Demo Prediction Checkpoint

Manipulate one control and predict the visible change.

Commit to what MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism should make visible before reading the result.

After The First Pass

Turn the concept into an inspected object.

Once the invariant is visible in the intuition, math, code, and demo, use these panels to inspect the mechanism visually, check source support, practice the idea, and attach a grounded research question.

Mechanism Storyboard

See the idea move before the page explains it

Serving MoE turns sparse compute into a scheduling problem: routing skew can create stragglers and token-dispatch communication can bottleneck, motivating scheduling and, in systems such as MegaScale-Infer, disaggregated expert-parallel serving.

Prediction open01 / Intuition
Editorial systems illustration of sparse token routing across experts with all-to-all exchange and a straggler bottleneck.
Prediction lens

Start with the picture, metaphor, or geometric mechanism.

Commit first

Before reading further, choose the kind of change MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism should make visible.

Visual Inquiry

Make the image answer a mathematical question

Serving MoE turns sparse compute into a scheduling problem: routing skew can create stragglers and token-dispatch communication can bottleneck, motivating scheduling and, in systems such as MegaScale-Infer, disaggregated expert-parallel serving.

4/4 stages readyLive demo connected
Prediction

Which visible object should carry the first intuition?

Commit first

Pick the cue that should make MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism easier to reason about before the page gives the answer.

Source Grounding

Canonical references for the mechanism on this page.

paper · 2017Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts LayerShazeer et al.

Grounds sparse expert routing and why gating turns capacity into dispatch and load-balance constraints.

Open source
paper · 2021Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient SparsityFedus, Zoph, and Shazeer

Grounds top-1 routing, capacity factors, and communication/training-stability caveats relevant to serving.

Open source
paper · 2025MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert ParallelismZhu et al.

Serving-specific evidence for MoE decoding sparsity, attention/FFN disaggregation, M2N token-routing communication, and production expert-load imbalance.

Open source

Claim Review

Serving MoE turns sparse compute into a scheduling problem: routing skew can create stragglers and token-dispatch communication can bottleneck, motivating scheduling and, in systems such as MegaScale-Infer, disaggregated expert-parallel serving.

Status1 substantive review recorded

Claims without a substantive review badge still need exact source-support review.

Sources3 references

shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer

Witnesses4 local objects

Use equation, code, and demo objects to check whether the source support is operational.

Substantively reviewedMoE inference and serving use sparse routing: a gate sends each token to a small subset of experts, so per-expert token counts can become uneven and require load-balancing, capacity buffers, or scheduling/parallelism choices.Claim metadata: source checked

Shazeer supports sparse top-k MoE routing plus importance/load-balancing losses for uneven expert use. Fedus supports top-1 routing, expert-capacity overflow, auxiliary load balancing, and communication-cost tradeoffs. MegaScale-Infer supplies serving-specific support for MoE decoding, token dispatch, attention/FFN disaggregation, M2N/N2M communication, and production expert-load imbalance.

Sources: Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer, Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity, MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert ParallelismChecks sparse routing, uneven expert load, and load-balancing/scheduling only. Shazeer/Fedus ground model/distributed mechanics; MegaScale-Infer supplies serving scope. Local byte-count, straggler formula, code, and demo are toy witnesses, not universal latency/cost claims.A bounded review summary is present; still check caveats and exact source scope.

Shazeer 2017 supports sparse top-k MoE routing and load/importance-balancing losses for uneven expert use. Fedus 2021 supports top-1 routing, capacity overflow, auxiliary load balancing, and communication-cost tradeoffs. MegaScale-Infer 2025 supplies serving evidence for MoE decoding, token dispatch, FFN underutilization from sparsity, attention/FFN disaggregation, M2N/N2M communication in that setup, and production expert-load imbalance. Local math/code/demo remain toy witnesses.

Reviewer: codex+oracle; reviewed 2026-05-07

Practice Loop

Try the idea before it explains itself

Serving MoE turns sparse compute into a scheduling problem: routing skew can create stragglers and token-dispatch communication can bottleneck, motivating scheduling and, in systems such as MegaScale-Infer, disaggregated expert-parallel serving.

Readiness0/3 checks ready
Predict

Before touching the demo, predict one visible change that should happen in MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism.

Hint 1

Reveal when your model needs a nudge.

Hint 2

Reveal when your model needs a nudge.

Hint 3

Reveal when your model needs a nudge.

Object research drawerClose
ConceptMoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated ParallelismLLM Systems

Research Room

Attach the question to an exact object

Pick the concept, equation, source, code witness, claim, misconception, or demo state before asking for help. The handoff stays grounded to that object.
Next local actionNo local draft saved yet

Open the draft below to save one note and next action in this browser.

conceptLLM Systems

MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism

Anchored question

What is the smallest example that makes MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism click without losing the math?

Local action draftNo local draft saved yetExpand only when ready to capture one local next action
Local action draft

This draft stays locally in this browser for concept:llm-systems/moe-serving.

No local draft saved.
Evidence to inspect
  • Source ids to inspect: shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer
  • Definition, prerequisite, and contrast concept links
  • The equation or code witness that makes the concept operational
  • One demo state that shows the invariant instead of a slogan
What would resolve this
  • The learner can state the mechanism in their own words
  • The learner can name the prerequisite that would repair confusion
  • The learner can predict how the mechanism changes under one perturbation
Grounded AI handoff

I am working in Continuous Function's research reading room. Object: concept - MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism Object key: concept:llm-systems/moe-serving Context: LLM Systems Anchor id: concept/concept-notebook/llm-systems/moe-serving Open question: What is the smallest example that makes MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism click without losing the math? Evidence to inspect: - Source ids to inspect: shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer - Definition, prerequisite, and contrast concept links - The equation or code witness that makes the concept operational - One demo state that shows the invariant instead of a slogan What would resolve this: - The learner can state the mechanism in their own words - The learner can name the prerequisite that would repair confusion - The learner can predict how the mechanism changes under one perturbation Answer as a careful research tutor: stay source-grounded, separate verified evidence from assumptions, name the relevant math objects, and end with one next action.

Open source object
concept/concept-notebook/llm-systems/moe-serving concept:llm-systems/moe-serving