Paper · 2021-06-10 · cs.CV, cs.LG, stat.ML
Scaling Vision with Sparse Mixture of Experts
Vision MoE (V-MoE): a Vision Transformer whose every other MLP is replaced by 32 sparsely gated experts, with each patch routed to its top-2 experts. Batch Prioritized Routing drops low-priority patches to trade compute for accuracy at test time. A 14.7B model reaches 90.35% ImageNet accuracy after fine-tuning (author-reported).
Vision Transformer (ViT) backbonesMixture of experts (MoE)visionmixture-of-expertssparsityroutingvision-transformer
AI-compiled by claude-haiku-5-5 on 2026-10-18, not yet reviewed by a human. Every claim cites its source; check it when a detail matters.
In plain words
Most image models are dense: every part of the network works on every image. Making them bigger therefore makes them slower too. This paper takes a Vision Transformer, which cuts an image into small square patches and processes them as a sequence, and gives it a bank of specialist sub-networks, called experts. A small router looks at each patch and sends it to only a couple of experts. The network can hold far more parameters than it uses for any one patch.
The paper also adds a rule for what to do when an expert is overloaded. Instead of letting patches arrive in a fixed order and dropping whatever comes last, the model first handles the patches with the strongest router weights. Under a tight compute budget it can then skip the lowest-priority patches and spend the saved work on the rest. This rule can be applied to a model that was trained without it, so the compute budget can be changed after training.
TL;DR
V-MoE replaces every other MLP block of a ViT with a sparse mixture of 32 MLP experts, routing each patch to its top-2 experts §2.2–2.3 §3.1. The authors report accuracy on par with the largest dense ViTs at as little as half the inference compute §1, and a 14.7B model at 90.35% ImageNet fine-tuned accuracy §3.6 tab. 2. Batch Prioritized Routing lets a trained model discard patches at test time to trade accuracy for compute §4.1–4.2. Both results are author-reported.
Problem
Dense ViTs spend the same compute on every patch of every image, so scaling capacity scales cost §1. Sparse MoE layers decouple parameter count from per-token compute, but they have known failure modes in vision: routing can collapse onto a few experts, and fixed buffers can overflow §2.4. The paper asks whether sparse experts can be trained at vision scale, transferred, and used at a chosen compute budget §1.
Method
Architecture. A V-MoE is a ViT with L blocks. In some blocks the MLP is replaced by a sparse MoE layer whose experts are MLPs with the same shape but separate weights §2.2. The non-expert parts (attention, routers, the remaining MLPs) are shared across devices fig. 1. Experts are placed on every other block ("Every-2") by default, following GShard §3.1. An alternative, "Last-n", places experts only on the last n even blocks §3.1.
Routing. For a patch representation x, the router computes
g(\mathbf{x}) = \mathrm{TOP}_k\big(\mathrm{softmax}(\mathbf{W}\mathbf{x} + \boldsymbol{\epsilon})\big)
with ε drawn independently per entry from N(0, 1/E²) §2.3. The top-k operation is applied after the softmax, not before as in Shazeer et al. This is needed to train with k=1, where the other order gives zero gradient almost everywhere, and it also performed better at k=2 §2.3 app. A.1. In practice k is 1 or 2 §2.3; the default is k=2 §3.1.
Capacity. Each expert processes a fixed number of tokens, its buffer size
B_e = \mathrm{round}\left(\frac{k\,N\,P\,C}{E}\right)
where N is the number of images per batch, P the tokens per image, E the number of experts and C the capacity ratio §2.4. Tokens that overflow an expert are not processed by that expert, but the residual connection carries them forward §2.4. Underfilled buffers are zero-padded §2.4. C>1 gives slack; C<1 forces the router to drop assignments §2.4. Upstream training uses C=1.05 §3.1.
Load balancing. Training adds an auxiliary loss. It combines an importance loss, the squared coefficient of variation of the summed routing weights per expert, and a load loss, the same statistic applied to a smooth estimate of how many tokens each expert receives app. A.2. The two are averaged and added to the classification loss with weight λ=0.01 app. A.2. The load loss is needed because balanced average weights can still hide an expert that is never selected app. A.2.
Upstream and transfer. The models are pre-trained on JFT-300M, deduplicated against the validation and test sets §3.2. They are evaluated by JFT precision@1, which ignores the label hierarchy app. B.6. Transfer uses:
- linear few-shot: a linear regression from frozen features to one-hot labels, on ImageNet 1/5/10-shot §3.2 §3.4;
- full fine-tuning: the standard ViT protocol with expert dropout 0.1 and half the schedule length for the other datasets §3.5 app. B.4;
- VTAB: 19 tasks with 1,000 examples each §3.2 tab. 1.
Scaling to 15B. The largest model, V-MoE-15B, has 48 blocks, Every-2 placement, 32 experts and k=2, for 14.7B parameters §3.6 tab. 2. It is trained on JFT-3B, with the changes listed in app. B.3 §3.6.
Batch Prioritized Routing (BPR). BPR is applied at inference to models trained with vanilla routing, with unchanged parameters, and it trades compute for accuracy by changing the capacity ratio §4.2 app. C.2. Vanilla routing, as in GShard and Switch, goes through the rows of the batch in a fixed order and assigns each token to its top-i expert while the buffer has room. Priority is set by row order, and within an image the token order is fixed §4.1 app. C.1. BPR instead gives each token a priority score and sorts all tokens across the batch before allocation. The score is the token's largest router weight. The sum of the top-k weights worked equally well §4.1 app. C.1. Every top-i choice is still assigned before any top-j choice, for i < j §4.1.
# Batch Prioritized Routing allocation [§4.1] [app. C.1]
# Input: gates (N*P, E) router weights; k; capacity per expert
# Output: list of (token, expert, weight) assignments
def batch_prioritized_routing(gates, k, capacity):
# Priority score per token: its largest router weight [§4.1]
scores = max(gates, axis=expert) # (N*P,)
# Visit tokens from highest to lowest score [§4.1]
order = argsort(scores, descending=True) # (N*P,)
# Fill buffers choice by choice: every top-1 before any top-2 [§4.1]
buffer_fill = zeros(E) # (E,)
assignments = []
for i in range(k):
for token in order:
# i-th highest expert for this token (0-based index) [app. C.1]
expert = top_i_expert(gates, token, i)
if buffer_fill[expert] < capacity:
buffer_fill[expert] += 1
weight = gates[token, expert]
assignments.append((token, expert, weight))
# Full buffer: drop this choice, keep the residual [§2.4]
return assignmentsSkip-patch (a fixed fraction S of patches is kept, the rest is dropped) is also described, but the paper presents it only as a related algorithm it tried app. C.1. Priority routing with a capacity ratio C is the main method §4.2.
Hyperparameters
Upstream model and routing settings (default V-MoE configuration):
| Name | Value | Where | Notes |
|---|---|---|---|
| experts per MoE layer E | 32 | §3.1 tab. 2 | "sweet spot" in the authors' setting §3.1 |
| selected experts per token k | 2 (default); 1 or 2 used | §2.3 §3.1 | k can be changed after training §3.1 |
| placement | Every-2; Last-n even blocks | §3.1 §3.3 | n=5 for V-MoE-H, n=2 otherwise §3.3 |
| capacity ratio C (upstream) | 1.05 | §2.4 §3.1 app. B.5 | all V-MoE models in the table use 1.05 app. B.5 |
| router noise | std 1/E | §2.3 | changes roughly 15% of routing decisions in earlier layers and 2–3% in deeper layers §2.3 |
| auxiliary loss weight λ | 0.01 | app. A.2 | "robust and not sensitive" app. A.2 |
| expert dropout (fine-tuning) | 0.1 | app. B.4 | "did not make a significant difference" app. B.4 |
| BPR priority score | max_i of router weight | §4.1 app. C.1 | sum of top-k also works app. C.1 |
Upstream training on JFT-300M app. B.2:
| Variant | Epochs | Optimizer | Base LR | LR decay | Weight decay |
|---|---|---|---|---|---|
| ViT-S/32 | 5 | Adam | 1e-3 | linear | 0.1 |
| ViT-B/{16,32} | 7 | Adam | 8e-4 | linear | 0.1 |
| ViT-L/32 | 7 | Adam | 6e-4 | linear | 0.1 |
| ViT-L/16 | 7 or 14 | Adam | 4e-4 | linear | 0.1 |
| ViT-H/14 | 14 | Adam | 3e-4 | linear | 0.1 |
| V-MoE-15B | not stated | Adafactor | 8e-4 | rsqrt, then linear cooldown at end | (0.03, 3) |
Notes for V-MoE-15B app. B.2 app. B.3:
- weight decay 0.03 on kernels, with biases not regularised, and 3.0 on the head kernel app. B.3;
- gradient moving average stored in bfloat16 app. B.3;
- classification head is a self-attention head with an extra MLP, not the token head app. B.3;
- the paper says ViT-S settings do not match DeiT-Small app. B.2.
Fine-tuning app. B.4:
| Dataset | Steps | Base LR (grid) | Expert dropout |
|---|---|---|---|
| ImageNet | 10,000 | {0.003, 0.01, 0.03, 0.06} | 0.1 |
| CIFAR10 | 2,500 | {0.001, 0.003, 0.01, 0.03} | 0.1 |
| CIFAR100 | 2,500 | {0.001, 0.003, 0.01, 0.03} | 0.1 |
| Oxford-IIIT Pets | 250 | {0.001, 0.003, 0.01, 0.03} | 0.1 |
| Oxford Flowers-102 | 250 | {0.001, 0.003, 0.01, 0.03} | 0.1 |
| VTAB (19 tasks) | 1,250 | 0.001 | 0.1 |
V-MoE-15B ImageNet fine-tune: 560×560 input, 30,000 steps (about 6 epochs), base LR 0.006, debiased Polyak averaging with momentum 0.999999 app. B.4.
Results
Author-reported. The upstream set is JFT-300M; ImageNet numbers are few-shot or fine-tuned as labelled. Compute columns are as printed in the table tab. 2.
| Model | Params | JFT prec@1 | IN/1-shot | IN/5-shot | IN/10-shot | IN fine-tuned | ExaFLOPs | TPUv3-days | Source |
|---|---|---|---|---|---|---|---|---|---|
| ViT-H/14 | 656M | 56.68 | 62.34 | 76.95 | 79.02 | 88.08 | 4.27k | 2.38k | tab. 2 |
| V-MoE-L/16, Every-2 | 3.4B | 57.65 | 62.41 | 77.10 | 79.01 | 87.41 | 2.17k | 1.20k | tab. 2 |
| V-MoE-H/14, Last-5 | 2.7B | 60.12 | 62.95 | 78.08 | 80.10 | 88.23 | 4.75k | 2.73k | tab. 2 |
| V-MoE-H/14, Every-2 | 7.2B | 60.62 | 63.38 | 78.21 | 80.33 | 88.36 | 5.79k | 3.47k | tab. 2 |
| V-MoE-15B, Every-2 | 14.7B | not reported | 68.66 | 82.78 | 84.29 | 90.35 | 33.9k | 16.8k | tab. 2 §3.6 |
| NFNet-F4+ (baseline, cited in table) | 527M | – | – | – | – | 89.20 | – | 1.86k | tab. 2 |
| MPL (baseline, cited in table) | 480M | – | – | – | – | 90.20 | – | 22.5k | tab. 2 |
VTAB (19 tasks, 1,000 examples each; mean with 95% CI) tab. 1:
| Setting | ViT | V-MoE | Source |
|---|---|---|---|
| L/16 | 76.3 ± 0.5 | 77.2 ± 0.4 | tab. 1 |
| H/14 | 77.6 ± 0.2 | 77.8 ± 0.4 | tab. 1 |
Inference with BPR, FLOPs-matched to dense ViT-H/14 app. C (matching-cost table; ViT-H/14 row: JFT 56.68, IN/5-shot 76.95):
| Model | Experts | At inference | C | JFT prec@1 | IN/5-shot | Time [%] | FLOPs [%] |
|---|---|---|---|---|---|---|---|
| V-MoE-H/14 | Last-5 | k=2 | 0.5 | 58.61 | 77.92 | 118.14 | 100.02 |
| V-MoE-H/14 | Last-5 | k=2 | 0.6 | 59.42 | 78.05 | 121.68 | 102.30 |
| V-MoE-H/14 | Every-2 | k=2 | 0.5 | 59.44 | 77.70 | 155.83 | 100.03 |
| V-MoE-H/14 | Every-2 | k=2→k=1 | 1.05 | 59.46 | 77.82 | 134.87 | 100.07 |
Text claims for BPR §4.2: a V-MoE-H/14 trained with vanilla routing can beat the dense model while using about half the FLOPs and a little over half the runtime; the authors also state that BPR stays close to the dense model while processing roughly 15–30% of the tokens fig. 6. The low-capacity points that support these claims are in fig. 5 and app. C; the table in app. C for vanilla routing does not show them.
Training with BPR (the claims from app. C.3, not tabulated in the main text): matches dense upstream performance with about 80% of training FLOPs for V-MoE-S/32 and V-MoE-B/32, and with 70–75% for V-MoE-L/32 (k=1 and k=2) app. C.3.
Fine-tuning with BPR on V-MoE-S/32 (k=2) app. C.4: accuracy falls from 77.4% to 68.6% when capacity drops to 0.1; BPR in both pre-training and fine-tuning gives 71.8% at that capacity; keeping high capacity during fine-tuning matters more than during pre-training (74.1% vs 71.7%).
Model analysis §5 app. E: experts in deeper MoE layers specialize to small sets of ImageNet classes; earlier layers do not show this fig. 7 §5. Replacing one router at a time with a random router hurts little in early layers and more in the last layers §5 app. E.
Paper vs code
No official code. The paper's LaTeX source contains no code links or project page [raw/src/2106.05974/main.tex]. The arXiv abstract page lists no code repository. A GitHub repository search for the title returned one result, owned by an account that is not an author, so it was not used as official code. A search for the method name ("vmoe sparse mixture of experts vision") returned 0 results.
Pitfalls
- Router noise and inference. The paper says noise is added to the router logits during the forward pass and that it "improves performance" §2.3. It does not state whether noise is used at test time. Not stated.
- Top-k weights are not renormalised, as far as the text says. The paper applies top-k after the softmax §2.3, but does not state whether the selected weights are rescaled to sum to one. Not stated.
- Capacity and rounding. B_e uses round(); the tie-breaking and the rounding of very small buffers are not stated §2.4.
- Overflow order. Under vanilla routing, which tokens overflow depends on the fixed order within images and the random order of images in a batch §4.1. Under BPR, the token ranking is global across the batch, so each image's compute depends on the other images in the batch §4.1. The batch size used at test time is not stated, so reproducing the BPR numbers requires matching batch composition.
- Every-2 indexing. The paper says MoEs are "on every other layer" §3.1 and that Last-n uses "the last n even blocks" §3.1. Whether blocks are counted from 0 or 1 is not stated.
- Inconsistent upstream numbers. V-MoE-L/16 Every-2 has JFT prec@1 57.65 in tab. 2 but 57.64 in app. C. The ImageNet 5-shot values are the same (77.10) in both. The paper does not explain the difference.
- FLOPs and time are not the same. The paper repeatedly says dense models need less runtime for the same FLOPs because of data transfer §4.2. In the matching-cost table, several V-MoE rows are below the dense model in FLOPs but well above it in time (for example 155.83% time at 100.03% FLOPs) app. C.
- Hardware. All timing figures are on TPUv3 cores tab. 2 fig. 2. Other hardware is not covered.
- Layer choice. The authors state that fewer MoE layers (Last-n) have "typically little impact on quality" and are faster, because of less communication overhead §3.1 app. E. This is for their setup only.
- Fine-tuning. Full fine-tuning uses the auxiliary loss, though the authors say it is often not needed at that step §3.5. They also say the fine-tuning protocol "could be further improved" for sparse models §3.5.
- Scale-dependent tricks. The 15B model needs bfloat16 moving averages, rsqrt LR decay, changed weight decay and a new head app. B.3. These are described as changes "based on" another paper app. B.3; their effect on the 15B result is not isolated.
- Dropout and repeats. The ImageNet fine-tuning curve is averaged over three runs §3.5. Few-shot numbers for the training-data deduplication study vary a lot across seeds app. B.7.
- Priority scores are a heuristic. The authors note that router outputs mainly reflect token–expert fit rather than how much a token matters for the final label §4.1. Learned scoring functions were tried and not better app. C.1.
- Skip-patch is not the main method. Enforced dropping of a fraction S of patches is presented only as a related experiment app. C.1. Do not implement it as the BPR of this paper.
Lineage
- Builds on: Vision Transformer (ViT) §2.2 §3.1; sparsely gated MoE for deep learning (Shazeer et al. 2017), changing the top-k order and the load-balancing losses §2.3 app. A.2; GShard-style placement of MoEs on every other layer §3.1; Switch-style expert dropout app. B.4 §3.5.
- Compared against: dense ViT variants (S/32 to H/14), NFNet-F4+ and Meta Pseudo-Labels on ImageNet fine-tuning tab. 2.
- Superseded by: not stated.
Source and license
Adapted from “Scaling Vision with Sparse Mixture of Experts” by Carlos Riquelme, Joan Puigcerver, Basil Mustafa, Maxim Neumann, Rodolphe Jenatton, André Susano Pinto, Daniel Keysers, Neil Houlsby (arXiv:2106.05974), used under CC BY 4.0. Changes: condensed and restructured for implementation, with tables, equations and algorithms taken from the paper and its code, each cited to its source. Not affiliated with or endorsed by the authors.