6.1.5 · D3Scaling & Efficient Architectures

Worked examples — Sparse routing and gating networks

3,453 words16 min readBack to topic

This page takes the machinery from the parent note on sparse routing and runs the numbers — by hand — through every situation a Mixture-of-Experts layer can hit. If a symbol shows up, we re-earn it here so you never have to flip back.

Figure — Sparse routing and gating networks

Before any example, let us define the symbols we will use constantly, from zero.

The exponential just means " raised to the power ." When is bigger, is bigger; when , ; when is very negative, shrinks toward 0 but never hits it. That "never hits 0" is exactly why softmax gives every expert a tiny but non-zero share — important later.


The scenario matrix

Every worked example below is tagged with the cell it covers. Together they fill the whole grid.

# Cell class What makes it tricky
C1 Plain positive logits baseline softmax + top-2, nothing weird
C2 Negative & mixed-sign logits does softmax still work when scores go below 0?
C3 Zero / tied logits (degenerate) ties in the argmax, uniform output
C4 Limiting value: one huge logit softmax → one-hot, the "confident router", overflow-safe form
C5 Renormalization after top-k why the survivors get re-scaled and by how much
C6 Compute / FLOP accounting vs — the sublinear-scaling payoff
C7 Load balancing (Switch aux loss) imbalanced batch, compute , CV
C8 Expert Choice capacity experts pick tokens; solve for capacity
C9 Word problem (real-world) translate a scenario into routing arithmetic
C10 Exam twist temperature-scaled logits change the winner

Worked examples

Example 1 — Plain positive logits (cell C1)

Forecast: guess now — expert 1 wins (biggest logit), but is its probability above 60%? Write your guess.

  1. Exponentiate each logit. Why this step? Softmax needs positive weights so the outputs can be probabilities; turns any real score into a positive number.
  2. Sum them. Why? We need a common denominator so the three outputs add to exactly 1.
  3. Divide. Why? Dividing each positive numerator by their sum is exactly the softmax formula , guaranteeing the shares are fractions of one whole.
  4. Top-1 (argmax). Why? Switch routing keeps only the single biggest gate to run just one expert. Winner expert 1.

Verify: ✓ (probabilities sum to 1). Expert 1's share is , so the forecast "above 60%" is correct.


Example 2 — Negative and mixed-sign logits (cell C2)

Forecast: does a negative logit produce a negative probability? (No — predict why.)

  1. Exponentiate. Why? is positive for every real , including negatives — that is the whole point of using the exponential.
  2. Sum. Why? The same normalizing denominator that will force the outputs to add to 1.
  3. Divide. Why? Applying the softmax formula converts the positive numerators into shares of one whole.

Verify: all three are strictly positive despite being negative ✓, and (rounding) ✓. Takeaway: negative logits are fine — they just map to small probabilities, never negative ones.


Example 3 — Zero / tied logits, the degenerate case (cell C3)

Forecast: with a perfect tie, what fraction should each expert get?

  1. Exponentiate. Why? Same softmax rule applies. for all four.
  2. Sum and divide (softmax). Why? Building the denominator and dividing is the softmax step that turns equal logits into equal probabilities. Every numerator is 1, so and
  3. Top-1 under a tie. Why care? argmax must break the tie somehow, and which index it returns is framework-dependent (some return the lowest index, some are unspecified). You cannot rely on a particular tie-break. This is the degenerate router: it carries no information, so training must push logits apart.

Verify: ✓. Uniform is the maximum-entropy (least confident) gate.


Example 4 — Limiting value: one dominant logit (cell C4)

Forecast: roughly what probability does expert 1 grab — 0.9? 0.99? more?

  1. Subtract the max, then exponentiate. Why? From the intuition callout above, subtracting before gives the identical answer but never overflows. , so .
  2. Sum. Why? The denominator ; here it is , dominated by the top term.
  3. Divide. Why? The softmax step ; because one term swamps , that expert grabs almost all the mass.

Verify: sum ✓. Expert 1 holds . Limit statement: as with others fixed, — the router becomes deterministic, and top-1 vs weighted output become identical. This is the "confident router" regime a trained MoE lives in. (You can confirm the plain form gives the same — the max-subtraction only changes the arithmetic, not the answer.)


Example 5 — Renormalization after top-k (cell C5)

Forecast: after we drop experts 3 and 4, do the surviving weights still add to 1? If not, what do we fix?

  1. Select top-2. Why? We only pay to run experts, so we keep the two biggest gates. Survivors: experts 1 and 2 with gates .
  2. Note the leak. Why? Because zeroing experts 3 and 4 discards their probability, we must check the survivors still form a whole. : we threw away of the probability mass, which would silently scale the activation down by 20%.
  3. Renormalize. Why? Dividing each survivor by their sum restores a proper weighted average that sums to 1, undoing the leak from step 2.
  4. Combine. Why? The MoE output is the gate-weighted mix of the kept expert outputs, .

Verify: renormalized weights ✓. The answer lies between and ✓ (a weighted average must sit between its inputs). Without renormalization we'd have gotten , artificially small — the sanity check catches the mistake.


Example 6 — Compute accounting: vs (cell C6)

Forecast: we made the model 128× bigger in parameters — did per-token compute go up 128×, 2×, or barely at all?

  1. Dense cost per token. Why? We need a baseline to compare against; the two FFN matrices (up- and down-projection, introduced above) dominate. multiply-adds. Call this unit .
  2. MoE active expert cost. Why? A token runs through exactly experts, each the same size as the dense FFN, so we multiply by . Active .
  3. Gating cost. Why? We must also pay to compute the scores — one matrix-vector product of multiply-adds. Compare to M — the gate is of expert cost, negligible.
  4. Ratio. Why? Dividing MoE active cost by dense cost tells us the real compute overhead we pay. Active MoE / dense (plus the tiny gate). Compute scales with , not .
  5. Parameters. Why the punchline? Because storing full experts is what actually grows memory. Total expert params a dense FFN. Parameters grew ~128×; active compute grew ~2×. That gap is the sublinear scaling the parent note promised.

Verify: ✓; active that ✓; gate ✓; gate/active ✓.


Example 7 — Load balancing: Switch aux loss on an imbalanced batch (cell C7)

Forecast: the loss is minimized at value for perfect balance. Will our imbalanced batch score above or below 1?

  1. Fractions . Why? = share of tokens dispatched to expert (the "hard" count); we need it as the detached weight in the loss. .
  2. Aux loss. Why this formula? Gradients flow only through the soft ; multiplying by the detached penalizes probability piled on already-overloaded experts.
  3. Ideal minimum. Why 1? At perfectly uniform routing every and every , so each product is , and there are of them: . Multiplying by the front factor gives , the floor. Our ✓ (imbalance costs extra), matching the forecast.
  4. CV of load. Why a separate metric? CV is the monitoring number (not differentiable), so we watch it even though we don't optimize it. Loads are ; mean ; deviations ; ; .
  5. Balanced check. Why? To confirm the loss really bottoms out at the uniform routing we claimed. : , and loads .

Verify: imbalanced loss ✓; balanced loss ✓ (the floor); balanced ✓; imbalanced ✓. Larger CV and larger aux loss agree that the first batch is worse — two independent diagnostics point the same way.


Example 8 — Expert Choice capacity (cell C8)

Forecast: in Expert-Choice, every expert processes the same number of tokens by construction. Guess whether is a fraction or a whole number for these values.

  1. Total slots. Why? Each of tokens claims expert-slots, and we must count them all to share fairly. Total slots .
  2. Slots per expert. Why divide by ? Spreading the slots evenly across all experts is exactly what "balanced" means. .
  3. case. Why redo it? To show capacity scales linearly with the target experts-per-token. .
  4. Why perfectly balanced? Why no aux loss? Each expert selects its own top- tokens by affinity score , always filling exactly slots — imbalance is impossible by construction, so no is needed (contrast Example 7). See Conditional Computation.

Verify: ✓; ✓; both whole numbers ✓. Every expert handles exactly tokens CV of load automatically.


Example 9 — Word problem, real-world routing (cell C9)

Forecast: guess the saving factor before computing — is it near 2×, 50×, or 100×?

  1. Active FLOP/s. Why , not ? Only experts fire per token, so we multiply the token rate by 2 experts and the per-expert cost.
  2. Dense-equivalent FLOP/s. Why ? A dense model would hit all 100 experts per token, so we multiply by 100 instead of 2.
  3. Saving factor. Why the ratio? Dividing dense by active isolates exactly how many times more work the naive model does. . Sparsity does the same routing job for of the dense-all cost.

Verify: active MFLOP/s PFLOP/s ✓; dense MFLOP/s PFLOP/s ✓; ratio ✓ — a 50× saving, matching . (Recall PFLOP/s MFLOP/s.) Related idea: shrinking a big model differently, see Knowledge Distillation.


Example 10 — Exam twist: temperature changes the winner (cell C10)

Forecast: does lowering change which expert wins, or only how sure the router is?

Temperature is a positive knob that divides every logit before softmax: small makes the gate sharper (more one-hot), large flatter. Because it divides, the order of the logits is preserved for any .

  1. (no change). Why start here? It is the ordinary softmax baseline to compare against. , so . Winner: expert 1.
  2. (sharpen). Why? Dividing the logits by multiplies them by 10, blowing the gap up and pushing softmax toward one-hot. . These are large, so we use the max-subtracted form (subtract ): , , giving Winner: still expert 1, now near-certain.
  3. Why the winner is fixed for . Why? Dividing all logits by the same positive number is monotonic — it can't reorder them — so argmax is invariant to positive temperature scaling.
  4. The trap: . Why forbid it? Dividing by a negative flips every sign, so the smallest logit becomes the largest and expert 2 would win — a negative temperature silently inverts your router. (Contrast this with the normalization tricks in Batch Normalization, which rescale but never invert.)

Verify: : ✓ and so expert 1 wins ✓. : ✓, expert 1 still wins ✓ but sharper. Order preserved across ✓; sign-flip at makes expert 2 win ✓.


Recall

Recall Why does softmax never output a negative probability, even for negative logits?

Because for every real ; a positive numerator over a positive sum is always in . ::: Exponentials are strictly positive.

Recall Why subtract the max logit before exponentiating in softmax?

To prevent numerical overflow on large logits; subtracting leaves the fraction identical (multiply top and bottom by ) but caps the largest exponent at . ::: Overflow safety, exact same answer.

Recall After top-

, why renormalize the surviving gates? Dropping experts removes probability mass, so survivors no longer sum to 1; the output would be scaled down. Dividing by the survivors' sum restores a proper weighted average. ::: To keep a true convex combination.

Recall In the Switch aux loss

, which factor carries the gradient and why? Only (mean gate probability) is differentiable; is a detached hard count. So gradients push down probability on overloaded experts. ::: carries the gradient; is detached.

Recall Why does Expert-Choice routing need no auxiliary loss?

Each expert fills exactly slots by picking its own top- tokens, so load balance is structural, not learned. ::: Balance is enforced by construction.

See also: Transformer Architecture, Model Parallelism, Attention Mechanisms, Neural Architecture Search, Long-tail Distribution.