Bring the mental model from Scaled Dot-Product Attention & Transformer Layers; this page will reuse it instead of restarting from zero.
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.
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.
Copy-only prompts — each action copies a page-grounded prompt to your clipboard. Nothing is sent by this site.
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:
- T is tokens in the microbatch,
- k is top-k experts per token,
- dmodel is hidden width,
- b 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 ne be the number of tokens routed to expert e 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.
Copy-only prompts — each action copies a page-grounded prompt to your clipboard. Nothing is sent by this site.
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())
Copy-only prompts — each action copies a page-grounded prompt to your clipboard. Nothing is sent by this site.
04
Interactive Demo
Use direct manipulation to connect the explanation to a moving system.
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.
Choose what to inspect in MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism. This shared fallback is an observation guide, not evidence of learning.
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.
Copy-only prompts — each action copies a page-grounded prompt to your clipboard. Nothing is sent by this site.
Concept: 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?
Object contextLLM Systems
concept:llm-systems/moe-servingMoE 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?
Start with the prediction checkpoint, then compare the reveal to the mental model.
Take this moveStudy modes
Keep the object fixed; change the lens.Route back through the notebook
Carry the same object through intuition, math, code, and demo.
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.
After The First Pass
Turn the concept into an inspected object.
The lower panels are one second act: keep the object fixed, inspect it visually, check source boundaries, practice transfer, then attach the 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.
What is the smallest example that makes MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism click without losing the math?
concept:llm-systems/moe-servingsources: shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer
Open the closest source note before trusting the local explanation.
3 selected-object sources shown first; 3 references total.
Audit the claim boundary, then ask from the same selected object.
Grounds sparse expert routing and why gating turns capacity into dispatch and load-balance constraints.
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, an...
Checks sparse routing, uneven expert load, and load-balancing/scheduling only. Shazeer/Fedus ground model/distributed mechanics; MegaScale-Infer supplies serving scope. Local byte-count,...
Grounds top-1 routing, capacity factors, and communication/training-stability caveats relevant to serving.
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, an...
Checks sparse routing, uneven expert load, and load-balancing/scheduling only. Shazeer/Fedus ground model/distributed mechanics; MegaScale-Infer supplies serving scope. Local byte-count,...
Serving-specific evidence for MoE decoding sparsity, attention/FFN disaggregation, M2N token-routing communication, and production expert-load imbalance.
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, an...
Checks sparse routing, uneven expert load, and load-balancing/scheduling only. Shazeer/Fedus ground model/distributed mechanics; MegaScale-Infer supplies serving scope. Local byte-count,...
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.
What is the smallest example that makes MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism click without losing the math?
concept:llm-systems/moe-servingsources: shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer
Treat every claim as provisional until source support and a local witness agree.
1 structured claim check on this concept.
Run the prediction or practice transfer before asking for a grounded review.
Publisher-side editorial review is not independent replication. Claims without it still need exact source-support review. 3 references and 3 local witnesses are available for inspection.
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...
Checks 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, c...
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-07Practice notebook
Use the idea, then test it somewhere new
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.
What is the smallest example that makes MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism click without losing the math?
concept:llm-systems/moe-servingsources: shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer
Use one state from MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism to explain what changes, why it changes, and which assumption the explanation needs.
No learner move yet; no learning state is inferred.
Write first, use only the help you need, then try a new case without it.
Use one state from MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism to explain what changes, why it changes, and which assumption the explanation needs.
Reveal when your model needs a nudge.
Reveal when your model needs a nudge.
Reveal when your model needs a nudge.
Write an attempt before asking the companion.
0 of 3 progressive hints opened.
This draft and any AI response do not establish mastery; a later unassisted case can.
- ObjectConceptMoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated P...
- PredictBefore revealMoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated P...
- WitnessCompare codeMoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated P...
- RoomAsk groundedChecking local snapshot
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?
These are fixed, deterministic perspectives derived from the selected object. They do not represent people, community contributions, or independent review.
Source ids shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer must support the exact object, not just the surrounding topic.
Treat this as a mechanism object: connect the definition to one equation, code witness, or demo before broadening the discussion.
Ask the learner to perturb one representation, then check whether the same invariant survives in math, code, and demo.
The learner can state the mechanism in their own words
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 Deterministic role lenses for this object: - Boundary: fixed perspectives, not people, community contributions, or independent review - Source-checking summary: Treat this as a mechanism object: connect the definition to one equation, code witness, or demo before broadening the discussion. - Proposed experiment: Ask the learner to perturb one representation, then check whether the same invariant survives in math, code, and demo. - Teach/transfer move: Turn the mechanism into one sentence that predicts a neighboring concept. - Assumptions: - Source ids shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer must support the exact object, not just the surrounding topic. - The stable content-object key lets local drafts, prompts, and route memory attach without changing the source page. - The concept explanation is local atlas prose until checked against its math, code, and source support. - Prerequisite gaps should become a repair route, not a reason to leave the object vague. - Role-lens requests: - Learner: ask for "Ask what would make "MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism" feel predictable rather than familiar." | assumption: Source ids shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer must support the exact object, not just the surrounding topic. | next action: The learner can state the mechanism in their own words - Researcher: ask for "Source ids to inspect: shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer" | assumption: The stable content-object key lets local drafts, prompts, and route memory attach without changing the source page. | next action: The learner can name the prerequisite that would repair confusion - Experimenter: ask for "Choose one variable or condition to perturb before asking for an explanation." | assumption: The concept explanation is local atlas prose until checked against its math, code, and source support. | next action: The learner can predict how the mechanism changes under one perturbation - Professor: ask for "Find the smallest transferable rule a learner could reuse without the AI." | assumption: Prerequisite gaps should become a repair route, not a reason to leave the object vague. | next action: Teach or transfer: Turn the mechanism into one sentence that predicts a neighboring concept. 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. Current deterministic role lens for this object: - Role lens: Learner - Evidence request: Ask what would make "MoE Serving & Scheduling: Token Dispatch, All-to-All, Disaggregated Parallelism" feel predictable rather than familiar. - Assumption to keep visible: Source ids shazeer-2017-sparsely-gated-moe, fedus-2021-switch-transformer, zhu-2025-megascale-infer must support the exact object, not just the surrounding topic. - Proposed experiment: Ask the learner to perturb one representation, then check whether the same invariant survives in math, code, and demo. - Next action: The learner can state the mechanism in their own words
concept/concept-notebook/llm-systems/moe-serving
concept:llm-systems/moe-serving