6.1.5 · D4Scaling & Efficient Architectures

Exercises — Sparse routing and gating networks

2,729 words12 min readBack to topic

This page tests your grip on Sparse routing and gating networks. Work each problem before opening its solution. Every problem is graded by cognitive level: L1 Recognition (do you know the pieces?), L2 Application (can you compute?), L3 Analysis (can you compare and diagnose?), L4 Synthesis (can you combine ideas into a design?), L5 Mastery (can you reason at the edges — zero, limits, degenerate cases?).

Before we start, a symbol reminder so nothing appears un-earned:


L1 — Recognition

Problem 1.1

An MoE layer has experts and uses top- routing with . For a single token, how many experts are (a) available in the parameter store and (b) actually run (compute happens) during one forward pass?

Recall Solution 1.1

(a) All experts sit in memory — the full parameter store is always present. (b) Only experts actually run. "Sparse" means available active. Answer: 64 available, 2 active.

Problem 1.2

The gating function has three stages: raw scores, then softmax, then top-. Match each stage to what it guarantees: (i) values sum to 1, (ii) only a handful of experts are kept, (iii) turns the input vector into numbers.

Recall Solution 1.2
  • Raw scores () → (iii) turns into numbers.
  • Softmax → (i) forces the numbers to be positive and sum to 1 (a probability distribution).
  • Top-(ii) keeps only the largest few, zeros the rest.

Problem 1.3

True/False: In the conditional-computation picture, growing from 8 to 128 (with fixed) roughly multiplies the per-token active compute by 16.

Recall Solution 1.3

False. Active compute is — it depends on , not . Going leaves fixed, so per-token active compute is essentially unchanged (only the tiny gating cost grows). That is the whole point of sparse routing.


L2 — Application

Problem 2.1

A gate produces logits for experts. Compute the full softmax (4 dp). Then with , list the selected experts and the renormalized weights.

Recall Solution 2.1

Exponentiate: . Sum . Top-2 experts: expert 1 and expert 2 (weights ). Why renormalize? Once top- drops experts 3 and 4, their probabilities vanish — the two surviving weights no longer add to 1, so would be a shrunken blend, not a proper average. Dividing by the kept-sum restores a valid convex combination (weights positive and summing to 1), keeping the output's scale correct. Renormalize over the kept two: divide by :

Problem 2.2

A dense feed-forward sublayer costs per token. An MoE layer with has the same per-expert width. By what factor does the active per-token compute of the expert FFNs change when we replace the dense layer by this MoE, ignoring gating cost?

Recall Solution 2.2

Dense active work . MoE with runs one expert of the same width also . Factor (unchanged), yet the model now holds experts' worth of parameters. This is the Switch Transformer bargain: same FLOPs, far more capacity.

Problem 2.3

Expert Choice routing: batch tokens, experts, target experts per token on average. What capacity (tokens per expert) does each expert receive?

Recall Solution 2.3

Total slots . Every expert processes exactly tokens — balance is structural.


L3 — Analysis

Problem 3.1

A batch of tokens is routed over experts with the loads . Compute the coefficient of variation . Is this balanced?

Recall Solution 3.1

Mean . Deviations: . Squares: ; sum . Population variance ; . A perfectly balanced load would give . A value signals severe imbalance — one expert is doing 70% of the work. (See Long-tail Distribution — this collapse is exactly a long-tailed usage pattern.)

Problem 3.2

For the same batch, the mean gate probabilities are and the dispatch fractions are . Compute the Switch auxiliary loss with , . Compare it to the loss under perfect balance.

Recall Solution 3.2

. Perfect balance () gives , so . Our imbalanced batch scores 1.916 vs the ideal 1.0 — the loss is nearly double, pushing the gate to spread probability mass away from expert 1.

Problem 3.3

Explain, using the gradient argument, why the auxiliary loss uses the product rather than or alone.

Recall Solution 3.3

(the hard top- count fraction) is non-differentiable — you cannot backprop through an -selection. It is treated as a detached constant. The gradient of therefore flows only through . In the product , acts as a weight: experts that are already overloaded (large ) get a large gradient pushing their down; underloaded experts get little push. Using alone would ignore the actual observed load; using alone would have zero gradient. The product marries "what actually happened" (measured by ) to "what we can steer" (the differentiable ).


L4 — Synthesis

Problem 4.1

You must design an MoE feed-forward block for a Transformer Architecture with model dim , expert width , and a per-token active-FLOP budget equal to one dense FFN. You want the largest possible parameter store. Pick and justify the largest sensible given a capacity factor constraint that each expert can hold at most tokens with .

Recall Solution 4.1

Budget → : one dense FFN's active work equals one expert's work. To stay at that budget you can run expert per token (Switch-style). This maximizes how large can be for a fixed active cost. is limited by the capacity floor, not FLOPs: active FLOPs are -independent, so in principle . The real limit is that each expert's capacity must be at least token, else experts sit empty. Setting : . Practically you'd pick so is a few dozen (e.g. tokens) to avoid tiny, high-variance loads. Report: , , , giving the FFN parameters at the FFN compute.

Problem 4.2

Rework 4.1 but the client refuses an auxiliary loss (too much tuning). Redesign the routing so load balance is structural, and state the new per-token cost relative to .

Recall Solution 4.2

Switch to Expert Choice routing: experts pick their top- tokens, so every expert gets exactly tokens — balance is guaranteed by construction, no auxiliary loss. To keep the same average tokens-per-token, set the average experts-per-token to , i.e. . Per-token average active cost stays dense FFN (total slots ), though individual tokens may see 0, 1, or several experts. Alternatively Soft MoE with slots per expert gives fully-differentiable, perfectly balanced routing at the cost of computing slot mixtures.


L5 — Mastery (edges, limits, degenerate cases)

Problem 5.1 — the limit

Show that top- routing with and renormalization reduces the MoE layer exactly to the dense weighted sum . What is lost?

Recall Solution 5.1

With every expert is kept, so the kept-index set (all experts) and nothing is dropped. The renormalizer (softmax already sums to 1), so renormalization does nothing and . Hence — the dense MoE, where is expert 's output on token . What is lost: all sparsity and all compute savings — you now run every expert. Sparse routing is only meaningful for .

Problem 5.2 — the degenerate tie

The gate outputs logits (, ). Two experts tie for the top. What happens, and why is this a real training hazard?

Recall Solution 5.2

Softmax: twice, ; sum ; . The is tied between experts 1 and 2. Implementations break ties deterministically (e.g. lowest index), so all tied tokens deterministically flood one expert → sudden load spike. Hazard: ties create discontinuous jumps in routing as logits wobble across each other during training; combined with zero gradient through , the gate can oscillate. Tie-breaking noise (adding small random noise to logits before top-) smooths this — the same trick that helps Neural Architecture Search escape argmax plateaus.

Problem 5.3 — the empty-expert / zero-load case

In a batch, expert receives zero tokens (). (a) What is its contribution to ? (b) Does the gate ever learn to send tokens to it again? Explain the mechanism.

Recall Solution 5.3

(a) Its term is — a dead expert contributes nothing to the load loss. (b) Yes, and this is subtle. Even with , the soft probability is generally (softmax never outputs an exact zero). The main-task gradient still nudges ; if some token's true best answer sits in expert , the loss on that token's output pulls up until eventually wins a top- slot. Because does not penalize an empty expert, it never forces revival — recovery relies on the task loss plus the fact that overloaded experts are being pushed down, raising the relative appeal of idle ones. This is why a long warmup and noisy gating matter: they keep every expert weakly alive so none dies permanently.

Problem 5.4 — quantifying "almost free" scaling

A model has a dense backbone costing FLOPs/token. Adding an MoE FFN with , , adds expert-FLOPs plus gating FLOPs. For , what fraction of the added MoE cost is the gating? (Count one multiply-add as 1 FLOP; use for the experts.)

Recall Solution 5.4

Expert FLOPs: . Gating FLOPs: . Fraction gating . Gating is of the added cost — genuinely tiny, confirming that growing is "almost free." (Even quadrupling to 1024 only lifts this to .)


Recall One-line self-check

Active compute scales with , capacity scales with :::