Bring the mental model from Scaled Dot-Product Attention & Transformer Layers; this page will reuse it instead of restarting from zero.
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.

Concept Structure
MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism
Start with the picture, metaphor, or geometric mechanism.
Make the objects explicit and connect them with notation.
Mirror the equations with runnable implementation details.
Manipulate the mechanism and watch the idea respond.
Learning map
MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated ParallelismConceptual Bridge
What should feel connected as you move through this page.
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.
The next edge should feel earned: use the demo prediction here before following Speculative Decoding: Lossless Multi-Token Generation.
01
Intuition
Build the mental picture first so the rest of the page has something to attach to.
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
Math
Translate the story into symbols, assumptions, and a derivation you can inspect.
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:
where:
- is tokens in the microbatch,
- is top- experts per token,
- is hidden width,
- 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 be the number of tokens routed to expert in a microbatch. If expert compute time is proportional to token count, then layer time is dominated by:
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
Code
Keep the implementation aligned with the notation so the algorithm is legible.
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
Interactive Demo
Use direct manipulation to connect the explanation to a moving system.
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.
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.

Start with the picture, metaphor, or geometric mechanism.
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.
Which visible object should carry the first intuition?
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.
Grounds sparse expert routing and why gating turns capacity into dispatch and load-balance constraints.
Open sourceGrounds top-1 routing, capacity factors, and communication/training-stability caveats relevant to serving.
Open sourceServing-specific evidence for MoE decoding sparsity, attention/FFN disaggregation, M2N token-routing communication, and production expert-load imbalance.
Open sourceClaim 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.
Claims without a substantive review badge still need exact source-support review.
shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer
Use equation, code, and demo objects to check whether the source support is operational.
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-07Source support candidates
paper 2017Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts LayerGrounds sparse expert routing and why gating turns capacity into dispatch and load-balance constraints.
paper 2021Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient SparsityGrounds top-1 routing, capacity factors, and communication/training-stability caveats relevant to serving.
paper 2025MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert ParallelismServing-specific evidence for MoE decoding sparsity, attention/FFN disaggregation, M2N token-routing communication, and production expert-load imbalance.
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.
Before touching the demo, predict one visible change that should happen in MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism.
Reveal when your model needs a nudge.
Reveal when your model needs a nudge.
Reveal when your model needs a nudge.
A concrete answer is on the canvas.
The answer names why the claim should hold.
It touches the page context or a neighboring idea.
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.Open the draft below to save one note and next action in this browser.
MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism
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
This draft stays locally in this browser for concept:llm-systems/moe-serving.
- 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
- 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
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.
concept/concept-notebook/llm-systems/moe-serving
concept:llm-systems/moe-serving