Worked examples — Sparse routing and gating networks
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.

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.
- Exponentiate each logit. Why this step? Softmax needs positive weights so the outputs can be probabilities; turns any real score into a positive number.
- Sum them. Why? We need a common denominator so the three outputs add to exactly 1.
- Divide. Why? Dividing each positive numerator by their sum is exactly the softmax formula , guaranteeing the shares are fractions of one whole.
- 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.)
- Exponentiate. Why? is positive for every real , including negatives — that is the whole point of using the exponential.
- Sum. Why? The same normalizing denominator that will force the outputs to add to 1.
- 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?
- Exponentiate. Why? Same softmax rule applies. for all four.
- 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
- Top-1 under a tie. Why care?
argmaxmust 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?
- Subtract the max, then exponentiate. Why? From the intuition callout above, subtracting before gives the identical answer but never overflows. , so .
- Sum. Why? The denominator ; here it is , dominated by the top term.
- 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?
- Select top-2. Why? We only pay to run experts, so we keep the two biggest gates. Survivors: experts 1 and 2 with gates .
- 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%.
- Renormalize. Why? Dividing each survivor by their sum restores a proper weighted average that sums to 1, undoing the leak from step 2.
- 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?
- 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 .
- MoE active expert cost. Why? A token runs through exactly experts, each the same size as the dense FFN, so we multiply by . Active .
- 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.
- 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 .
- 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?
- Fractions . Why? = share of tokens dispatched to expert (the "hard" count); we need it as the detached weight in the loss. .
- Aux loss. Why this formula? Gradients flow only through the soft ; multiplying by the detached penalizes probability piled on already-overloaded experts.
- 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.
- 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 ; ; .
- 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.
- Total slots. Why? Each of tokens claims expert-slots, and we must count them all to share fairly. Total slots .
- Slots per expert. Why divide by ? Spreading the slots evenly across all experts is exactly what "balanced" means. .
- case. Why redo it? To show capacity scales linearly with the target experts-per-token. .
- 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×?
- Active FLOP/s. Why , not ? Only experts fire per token, so we multiply the token rate by 2 experts and the per-expert cost.
- Dense-equivalent FLOP/s. Why ? A dense model would hit all 100 experts per token, so we multiply by 100 instead of 2.
- 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 .
- (no change). Why start here? It is the ordinary softmax baseline to compare against. , so . Winner: expert 1.
- (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.
- 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.
- 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.