Switch Transformer (2021, Fedus et al.)
arXiv: 2101.03961
Core Problem
Early MoE models (e.g., Shazeer's 2017 work) had two main issues:
- Training instability: expert load was unbalanced — some experts were overused while others sat idle.
- High communication overhead: tokens had to be routed to experts distributed across different devices.
- Built on T5-Base and T5-Large: 7x pretraining speedup
- Trillion-parameter model (1T)
- 4x speedup over T5-XXL
- Full wins in the multilingual setting (mT5-Base, 101 languages)
How can MoE be made both stable and efficient?
Method: Three Key Simplifications
Switch Transformer simplifies MoE in three ways:
1. Top-1 routing: each token is routed to only 1 expert (instead of top-K). This drastically reduces communication and computation — only one expert needs to be activated and communicated with.
2. Load-balancing loss: an auxiliary loss penalizes load imbalance. If an expert receives too many tokens, the loss gives negative feedback, encouraging the gate network to spread tokens more evenly.
3. bfloat16 training: first demonstration that large sparse models can be trained stably in low precision (bfloat16). Previously, it was believed sparse models required fp32 for numerical stability.
Key Numbers
Impact
Switch Transformer turned MoE from a "research concept" into an "engineering-viable solution." Later Google models (PaLM, early versions of Gemini) were based on the Switch Transformer architecture. It proved that MoE can scale to a trillion parameters while maintaining training stability.
Feynman-style Commentary
> The Switch Transformer's way of thinking is "simplify to the core." Original MoE used top-2 routing — each token goes to two experts. Switch asks: do you really need two? If experts are numerous and specialized enough, one is enough. It's like delivery — you don't send every package to two addresses; you deliver it precisely to one. The simplification brings big benefits: much lower communication and easier load balancing. Feynman would say: good design is subtraction, not addition. When you remove something that seems necessary and find it truly wasn't, you've found a more elegant solution.
arXiv: 2101.03961