6.1.6 · D2Scaling & Efficient Architectures

Visual walkthrough — Load balancing in MoE

2,261 words10 min readBack to topic

Before any symbols, the cast of characters:


Step 1 — The router turns one token into a bar chart of scores

WHAT. Take a single token, call its vector . The router multiplies it by a learned matrix and squashes the result with softmax:

  • — the router's probability that expert is the right one for this token. A number between 0 and 1.
  • The subscript runs over the experts, so one token produces of these numbers.
  • softmax guarantees : the whole bar chart's heights add to exactly one, like slices of a pie.

WHY softmax and not just the raw scores? Because we want a probability — a comparable, normalized preference — not an arbitrary magnitude. Softmax also keeps everything positive and differentiable, which we will need in Step 5.

PICTURE. One token in, one bar chart out. The tallest bar is where the router wants to send it.


Step 2 — Dispatch: keep only the top bar(s), throw a hard switch

WHAT. In Top-K routing we keep only the tallest bars (Switch Transformer uses ). That is a hard decision — a token either goes to an expert or it does not.

  • — the indicator: a light switch that reads 1 when the statement inside is true, else 0.
  • — the index of which token in the batch (token number 1, 2, 3, …).

WHY split "score" from "dispatch"? This is the crux of the whole derivation. The score is a smooth dial. The dispatch is a hard on/off switch. A smooth dial has a gradient; a hard switch does not. Remember these two objects — they become and in a moment.

PICTURE. The smooth bar chart on the left; the flattened 0/1 "who actually got the token" on the right.


Step 3 — Two summaries over the whole batch: (hard load) and (soft desire)

WHAT. One token is not enough to judge balance — imbalance is a batch phenomenon. So we average over all tokens in the batch, in two different ways.

The hard load — what fraction of tokens actually landed on expert :

The soft desire — the router's average probability for expert :

  • — number of tokens in the batch; dividing by it turns a count into a fraction.
  • is built from switches → non-differentiable, a plain count.
  • is built from dials → differentiable through .

WHY two? is what actually stresses the hardware (real tokens, real compute). is the only quantity we can push with gradient descent. We will need one to measure imbalance and the other to fix it.

Two useful sanity constants fall out immediately:

Each token contributes dispatches (so the fractions add to ), and each token's softmax scores add to 1.

PICTURE. Two bar charts side by side over a whole batch: blue (counts) and orange (probabilities).

Recall Which one carries the gradient?

or — which is differentiable? ::: (built from smooth softmax scores). is a hard count, gradient zero.


Step 4 — Watch collapse happen: the feedback loop we must break

WHAT. With no correction, the router drifts to a degenerate state: almost all tokens pile onto one or two experts.

WHY it happens (the runaway loop). Random init makes expert 1 slightly better at some common pattern → router sends it more tokens → expert 1 gets more gradient and improves → router sends it even more → experts 2…N starve. This is positive feedback, and it is exactly what we must counter.

PICTURE. An arrow-loop: "more tokens → more gradient → better expert → more tokens." Beside it, the collapsed bar chart with towering over flat neighbours.


Step 5 — Build the corrective loss: multiply hard load by soft desire

WHAT. We want a single number that is big when the router keeps favouring already-busy experts, and whose gradient pushes probability off those experts. The Switch Transformer answer:

  • — a small weight (typically ) so this nudge never drowns the real task loss.
  • — rescales the sum so the balanced value is a clean constant (we compute it in Step 6).
  • — the key product: the measured load acts as a coefficient on the pushable probability .

WHY multiply, and why treat as constant? Differentiate. Only has a gradient, so is frozen (detached) during backprop:

Read that literally: the push on expert 's probability is proportional to how overloaded it currently is. Busy experts (big ) get their pushed down hardest. And because is fixed by softmax, dropping for busy experts automatically raises it for idle ones. The loss is a feedback controller, cancelling the runaway loop of Step 4.

Why not or alone?

  • — non-differentiable (it is all hard counts). No gradient, useless for training.
  • — differentiable, but only tames the router's confidence; it never sees the actual dispatched load that stresses hardware.
  • — couples the measured imbalance (constant ) to the pushable probability (). Best of both.

PICTURE. For each expert, a blue bar and an orange bar; the gradient arrow on is tall exactly where is tall — a downward push scaled by the blue height.


Step 6 — The balanced fixed point: what the loss settles to

WHAT. Suppose the controller wins: the router equalizes probability () and dispatch equalizes (). Plug in:

  • Each of the terms equals ; there are of them; the outer scales it.
  • The result is a small constant — the loss floor. Any imbalance pushes above .

WHY this matters. It tells you the loss's job is done when it flatlines near , not near zero. The extra factor in the formula exists precisely to make this floor tidy.

PICTURE. A gauge: needle at when balanced (green), swinging higher (red) as one expert hogs load.


Step 7 — Worked numbers: 4 experts, 8 tokens, Top-1

WHAT. From the parent's Example 1. Dispatch: tokens 1–4 → E1, tokens 5,6 → E2, token 7 → E3, token 8 → E4. So:

(check: .) Average router probabilities:

Now the loss with , :

  • The balanced floor here would be .
  • We measured → the batch is imbalanced, and the loss correctly reports it.

WHY show the number? So you see the floor () and an imbalanced value () side by side — the gap is the signal the router learns from.

PICTURE. The two bar charts for this exact example, the per-term products, and the two dashed lines: floor vs actual .

Recall Recompute the floor

For , , , what is the perfectly-balanced ? ::: .


Step 8 — The hard backstop: capacity and token dropping

WHAT. The soft loss nudges; sometimes we also want a wall. Each expert gets a hard seat count:

  • — the fair share of tokens per expert.
  • — the capacity factor (typically ), a little slack above the fair share.
  • Tokens that arrive after an expert is full are dropped — they skip the expert and pass through as a residual.

WHY a second mechanism? The aux loss is a soft incentive; dropping is a hard limit. Dropping creates back-pressure: overload expert 1 → its tokens get dropped → the model does worse on them → gradients discourage over-routing to expert 1. See Expert Capacity and Token Dropping for the full treatment.

Degenerate cases to keep straight:

  • too low (e.g. ): many tokens dropped even when routing is reasonable → accuracy suffers.
  • too high (huge): the wall never binds → you are back to relying on the soft loss alone, and you waste memory.
  • : no soft push at all → collapse returns (Step 4).
  • too large: balance dominates the task loss → the router spreads tokens randomly, ignoring which expert is actually best. A dumb but perfectly balanced model.

PICTURE. Four buckets each with a capacity line at ; expert 1 overflows and the spilled tokens are drawn as red residual arrows going around it.


The one-picture summary

The whole pipeline on one canvas: token → router bar chart () → hard dispatch → the two batch summaries (blue, constant) and (orange, differentiable) → their product summed and scaled to → gradient pushing busy experts' down → back toward the floor .

Recall Feynman retelling — say it like you'd explain it to a friend

A little router gives every token a bar chart of how much it likes each expert. We keep the tallest bar and actually send the token there. Over a whole batch we make two summaries: a blue one, — how busy each expert really got (just a headcount, can't be nudged), and an orange one, — how much the router wanted each expert on average (this one we can nudge). We build a penalty by multiplying them expert-by-expert and adding up: . The magic is in the calculus: since only orange can move, the pressure on each expert's want-level equals its blue busy-ness, . So the busiest experts get their probability shoved down hardest, and because all probabilities must add to one, the quiet experts get lifted for free. When everything evens out, the penalty rests at a tiny floor, ; any lopsidedness lifts it above that, and the gradient keeps pushing until it settles back. If we also want a hard wall, we give every expert a seat limit and drop the overflow — a physical backstop when the gentle nudge isn't enough.

See also: Switch Transformer · GShard · MoE Training Dynamics · Gradient Routing in MoE