Mixture of Experts

1. A premissa: por que MoE importa em 2026

Um Transformer denso aplica todo parâmetro a todo token. Essa simetria é matematicamente limpa e era o padrão correto enquanto o campo ainda estava aprendendo o que escala significava. Em 2024 ela havia se tornado o padrão errado na fronteira aberta. Mixtral 8x7B, DBRX, Grok-1, DeepSeek-V2, Qwen1.5-MoE, Hunyuan-Large e DeepSeek-V3 foram todos lançados em 2024 como modelos de linguagem Mixture-of-Experts (MoE) de pesos abertos, e o levantamento sobre MoE de Cai et al. cataloga o conjunto como uma única onda arquitetural em vez de uma sequência de experimentos isolados [src_026]. Qwen3-235B-A22B e DeepSeek-V3 levam a mesma lógica para 2025.

A razão é uma única observação mecânica. Um bloco FFN denso aplicado a um token de largura \(D\) custa aproximadamente \(8D^2\) parâmetros em compute sobre aquele token, independentemente de qual token seja. Um bloco FFN MoE mantém em memória um conjunto bem maior de FFNs experts, mas roteia cada token apenas por um pequeno subconjunto, de modo que o número total de parâmetros cresce com o tamanho do conjunto enquanto o compute por token permanece limitado por quantos experts são ativados. Os números de manchete tornam o trade-off concreto: o DeepSeek-V3 tem 671B parâmetros totais com 37B ativados para cada token [src_031]. O Mixtral 8x7B tem 47B totais com 13B ativos por token, aproximadamente 5x menos parâmetros ativos do que o baseline denso Llama-2 70B que ele, ainda assim, iguala ou supera na maior parte dos benchmarks [src_025].

🔗 Conexão

A intuição de over-training que levou o Llama-3 a empurrar além do ponto compute-ótimo de Chinchilla é a mesma intuição que guia a adoção de MoE — veja Capítulo 9 — Scaling Laws. O desacoplamento ativo-vs-total de parâmetros que §8 deste capítulo formaliza é a contraparte arquitetural do desacoplamento dados-vs-parâmetros do over-training.

Este capítulo percorre as mecânicas que fazem esse trade-off funcionar, o modo de falha (desbalanceamento de carga) que quase matou a arquitetura em produção, a cura em duas gerações para essa falha (auxiliary loss em 2021, balanceamento livre de auxiliary-loss em 2024), o custo de sistemas que a arquitetura troca pela sua eficiência em parâmetros (comunicação all-to-all durante o paralelismo de experts) e o estado empírico da questão por volta de 2025: MoE é o padrão da fronteira aberta, mas dense ainda está vivo no topo absoluto (Llama-3 405B), e a escolha depende daquilo para o qual a equipe está otimizando [src_007, src_026, src_031].

2. Anatomia de um bloco FFN MoE

A maneira mais simples de pensar em um bloco MoE é como um substituto direto para o sub-bloco FFN denso de um bloco Transformer padrão. Recapitulando: um sub-bloco FFN em um Transformer é composto por duas layers lineares separadas por uma não-linearidade, aplicadas independentemente por token. Onde um Transformer denso aplica uma única feed-forward network \(\mathrm{FFN}\) à ativação do residual stream \(x\), um bloco MoE mantém um conjunto de \(E\) FFNs experts \(\{E_1, E_2, \ldots, E_E\}\) junto com um pequeno router linear. Para cada token, o router produz um vetor de scores, as entradas top-\(k\) desse vetor são mantidas e os experts correspondentes são avaliados. Os \(E - k\) experts restantes contribuem exatamente zero naquele token; seus pesos só são tocados nos tokens roteados para eles, não neste.

Seguindo a convenção do Mixtral, escrevemos o router como uma projeção linear \(W_g \in \mathbb{R}^{E \times D}\) seguida por um softmax sobre os logits top-\(k\).

🎯 Intuição

Pense no router como um dispatcher aprendido. Para cada token, ele olha a ativação, varre todos os \(E\) experts, anota os nomes dos top-\(k\) que parecem mais promissores, e o bloco executa apenas esses experts nesse token. A saída do bloco é uma soma ponderada das saídas desses \(k\) experts, com pesos vindos dos scores de confiança do dispatcher.

O vetor de gate é

\[G(x) = \mathrm{Softmax}(\mathrm{TopK}(W_g x))\]

onde \(\mathrm{TopK}(\ell)_i = \ell_i\) se \(\ell_i\) está entre as top-\(k\) coordenadas do vetor de logits \(\ell\), e \(-\infty\) caso contrário [src_025]. A saída do bloco para o token de entrada \(x\) é então

\[y = \sum_{i \in \mathrm{TopK}} g_i \cdot E_i(x)\]

com \(g_i = G(x)_i\) o score de gate renormalizado para o expert \(i\) (zero se o expert \(i\) não foi selecionado). A notação anterior do Switch Transformer escreve \(p_i(x)\) para o mesmo valor de gate na equação (2) de Fedus et al., e a matemática é idêntica [src_024]. Usamos \(g_i\) ao longo do capítulo para nos manter alinhados com os artigos do Mixtral e do DeepSeek-V3.

Duas consequências decorrem dessa construção imediatamente. Primeiro, como apenas \(k\) de \(E\) experts são executados por token, o custo em FLOPs do bloco escala com \(k\), não com \(E\). Dobrar \(E\) dobra a contagem de parâmetros do modelo, mas não muda o compute por token. Segundo, como os coeficientes de gating \(g_i\) são produzidos por um softmax sobre os experts selecionados, o router permanece diferenciável, e os gradientes fluem da loss de volta pelos valores de gate e para \(W_g\). O Switch Transformer fez a observação adicional de que isso continua verdadeiro mesmo com \(k = 1\), contradizendo uma conjectura anterior de que \(k > 1\) era necessário para gradientes de roteamento não-triviais [src_024].

Em LLMs MoE baseados em Transformer, o bloco MoE tipicamente substitui o sub-bloco FFN de toda layer Transformer (Mixtral) ou de uma layer sim outra não (a tradição GShard) [src_025]. O DeepSeek-V3 substitui a FFN de toda layer exceto as três primeiras por um bloco MoE, e adicionalmente divide os experts em um pequeno conjunto de shared experts sempre ligados mais um conjunto bem maior de routed experts [src_031]. A decisão arquitetural de quantas layers carregam MoE e se mantêm shared experts é ortogonal à equação de roteamento acima; ambas as arquiteturas ainda computam a mesma soma ponderada das saídas dos experts selecionados.

3. Variantes de roteamento: top-1, top-2, top-k

Três regimes de roteamento foram todos implantados em escala. Eles não são variantes exóticas uns dos outros; correspondem a três pontos distintos em um trade-off de qualidade / compute / balanceamento de carga.

Top-1 (Switch Transformer, 2021). Cada token é roteado para exatamente um expert. A alegação do Switch é que o roteamento top-1 preserva a qualidade, divide pela metade a carga de trabalho do expert por token em relação ao top-2 e simplifica a comunicação entre dispositivos; o modelo fica equivalente em FLOPs a um baseline denso no sub-bloco FFN, enquanto a contagem de parâmetros cresce livremente com \(E\) [src_024]. Os benefícios que o Switch enumera são concretos: redução do compute do router, capacidade do expert dividida pela metade no batch size fixo e implementação mais simples [src_024]. Os experimentos do Switch usam 16, 32, 64, 128 e 256 experts por layer.

Top-2 (Mixtral 8x7B, 2024). Cada token ativa dois de oito experts; os experts são FFNs SwiGLU cujas saídas são combinadas pelos seus valores de gate renormalizados [src_025]. Top-2 recompra a habilidade de misturar dois especialistas por token ao custo de dobrar o compute FFN por token em relação ao top-1. Os resultados do Mixtral sugerem que a troca é favorável nesta escala: 13B parâmetros ativos igualam ou superam o Llama-2 70B na maior parte dos benchmarks que os autores avaliam [src_025]. A estrutura de oito experts do Mixtral também é pequena o bastante para caber em um único servidor multi-GPU, o que tornou o modelo incomumente amigável aos primeiros stacks de serving open-source.

🤔 Pause e pense

Mantenha \(E\) fixo em 64. Antes de ler adiante, preveja: o que muda no compute FFN por token e no tamanho do espaço de combinações quando \(k\) passa de 2 para 8? Em qual dessas duas quantidades o campo parece estar disposto a gastar? (Não olhe adiante — responda primeiro.)

Top-k para \(k > 2\) (DeepSeek-V3, 2024). O DeepSeek-V3 mantém 256 routed experts de granularidade fina por layer mais 1 shared expert sempre ligado, e ativa 8 dos 256 routed experts para cada token, além do shared [src_031]. O design de granularidade fina é uma ideia separada do \(k\) de roteamento: manter a capacidade total de experts fixa mas quebrá-la em mais experts, menores, dá ao router mais graus de liberdade para combinar especialistas. Com \(k = 8\) o compute por token é maior do que o \(k = 2\) do Mixtral, mas cada expert individual é correspondentemente menor, e o espaço de combinações (\(\binom{256}{8}\)) é grande o bastante para que o router possa compor em vez de meramente escolher. O Qwen3-235B-A22B segue o mesmo padrão geral com 128 experts e roteamento top-8.

A alavanca que o campo tem puxado mais forte é aumentar \(E\) com \(k\) fixo (ou com \(k\) crescendo lentamente), porque essa é a direção que aumenta os parâmetros totais sem aumentar o compute por token [src_025, src_026]. Aumente \(E\) de 8 para 256 com \(k = 2\) e você multiplicou a capacidade total do modelo por 32x enquanto o número de experts que cada token visita permanece inalterado. O compute naquele token não fica inalterado, porque o router em si está agora pontuando 256 candidatos em vez de 8, mas o custo do router é dominado por uma única layer linear \(D \times E\) e permanece pequeno em relação ao custo FFN dos experts selecionados.

4. O problema de balanceamento de carga

Sem intervenção, o roteamento MoE colapsa. Uma pequena fração dos experts atrai a maior parte dos tokens, os experts restantes esfriam, e o modelo efetivamente se torna um modelo denso muito menor com a maioria dos seus parâmetros servindo como pesos de papel caros. Switch Transformer, o levantamento sobre MoE e o DeepSeek-V3 todos descrevem esse modo de falha em termos similares [src_024, src_026, src_031]. A causa é um loop de feedback positivo: experts que recebem mais tokens recebem mais sinal de gradiente, melhoram em processar os tipos de tokens que já veem e, assim, recebem scores mais altos do router naqueles tokens; o softmax do gate afia sobre o mesmo punhado de índices. (Esse loop se fecha pelo mesmo caminho de gradiente do router introduzido em §2 — os gradientes fluem da loss de volta por \(g_i\) e para \(W_g\), então um router que roteia bem nos tokens que vê é reforçado para aquele roteamento em tokens similares.)

A resposta do Switch Transformer é a abordagem canônica de auxiliary loss. Adotando a notação do Switch (a auxiliary loss foi escrita com \(N\) para a contagem de experts, então escrevemos \(N\) nesta seção como um alias para nosso \(E\)), e dado um batch \(B\) de \(T\) tokens, o Switch define

\[f_i = \frac{1}{T} \sum_{x \in B} \mathbb{1}\{\arg\max_j p_j(x) = i\}\]

como a fração de tokens roteados para o expert \(i\), e

\[P_i = \frac{1}{T} \sum_{x \in B} p_i(x)\]

como a massa de probabilidade média do router sobre o expert \(i\) no batch [src_024]. Ambos os vetores vivem no simplex sobre os experts; ambos têm valor \(1/N\) sob roteamento perfeitamente uniforme. A auxiliary loss é o produto escalar escalado dos dois:

🎯 Intuição

Por que um produto escalar detecta desbalanço: se tanto \(f\) (para onde os tokens de fato foram) quanto \(P\) (para onde o router quis mandá-los) acumulam massa sobre o mesmo expert, o produto escalar dispara. Distribuições uniformes sobre os experts minimizam \(\sum_i f_i P_i\) sujeito à restrição do simplex. Então a loss é grande exatamente quando o router se compromete com o mesmo punhado de experts que estão recebendo a maior parte dos tokens — que é o modo de colapso com que esta seção começou.

\[\mathcal{L}_{\mathrm{aux}} = \alpha \cdot N \cdot \sum_{i=1}^{N} f_i \cdot P_i\]

Essa loss é adicionada ao objetivo de cross-entropy durante o treinamento [src_024].

Três propriedades da auxiliary loss

Três propriedades da fórmula valem uma pausa. Primeiro, a loss é minimizada quando ambos \(f\) e \(P\) igualam \(1/N\) uniformemente, então o gradiente empurra o sistema em direção a roteamento balanceado. Segundo, o \(N\) multiplicativo no lado direito mantém o valor da loss comparável entre escolhas de \(N\): sob roteamento uniforme, a soma nua é \(\sum_i (1/N)(1/N) = 1/N\), e multiplicar por \(N\) normaliza isso a uma constante. Terceiro, apenas o vetor \(P\) é diferenciável como escrito (\(f_i\) contém um \(\arg\max\) não-diferenciável), mas o gradiente apenas por \(P\) é suficiente para moldar o router. O Switch varre \(\alpha\) de \(10^{-1}\) até \(10^{-5}\) e se assenta em \(\alpha = 10^{-2}\) como pequeno o suficiente para não dominar o sinal de cross-entropy mas grande o suficiente para manter a carga balanceada [src_024]. A família Mixtral, GShard e ST-MoE herda uma formulação estruturalmente similar [src_025, src_026].

💡 Resultado-chave

Adicionar a penalidade de produto escalar \(\alpha N \sum_i f_i P_i\) à cross-entropy é a cura industrial canônica para o colapso de roteamento — ela empurra o router em direção a carga uniforme enquanto o gradiente de cross-entropy ainda molda qual expert cuida de qual token.

🔄 Recapitulação

• Complete. A auxiliary loss é \(\mathcal{L}_{\mathrm{aux}} = \alpha \cdot N \cdot \sum_i \_\_\_ \cdot \_\_\_\), onde os dois vetores são a ___-empírica-de-tokens-por-expert e a ___-média-de-massa-do-router-por-expert.
• Explique. Por que o mínimo da loss fica em \(f_i = P_i = 1/N\)? Por que um dos dois vetores não é diferenciável, e por que isso não bloqueia o gradiente de fazer trabalho útil?
• Preveja. Uma equipe usa um coeficiente \(\alpha\) da auxiliary loss tão grande que o roteamento fica perfeitamente uniforme mas a cross-entropy a jusante para de melhorar. Qual dos dois objetivos a loss está favorecendo, e o que eles devem mudar?

5. O truque livre de auxiliary-loss do DeepSeek-V3

A auxiliary loss funciona, no sentido de que produz roteamento balanceado. A objeção que o DeepSeek-V3 levanta contra ela é que uma auxiliary loss forte o suficiente para balancear a carga também interfere com o gradiente de cross-entropy na tarefa real de modelagem de linguagem: o router está sendo solicitado simultaneamente a produzir bons trajetos e a distribuir o orçamento de roteamento uniformemente, e esses dois objetivos podem brigar [src_031]. A correção proposta, devida a Wang et al. e adotada pelo DeepSeek-V3, é tirar o balanceamento de carga inteiramente do gradiente.

Uma mudança notacional acompanha essa correção. O gate de §2 era um softmax sobre os logits top-\(k\) de \(W_g x\) — uma distribuição acoplada em que o score de um expert depende dos scores dos outros. §5 abaixo usa um sigmoid independente por expert sobre a afinidade \(u_t^T e_i\), então cada expert ganha seu próprio score escalar em \([0, 1]\) e o top-\(k\) é tomado sobre esses escalares. As duas são famílias distintas de gate-function com a mesma semântica de roteamento — seleção top-\(k\) seguida de soma ponderada — mas a independência por expert do sigmoid é o que torna o truque de atualização de bias limpo de implementar: deslocar \(b_i\) sobre um expert move apenas o score daquele expert em relação aos outros.

O bloco MoE do DeepSeek-V3 computa um score de afinidade por token \(s_{i,t} = \mathrm{Sigmoid}(u_t^T e_i)\) para cada routed expert \(i\), onde \(e_i\) é o vetor centroide do expert (um vetor por expert aprendido que o router usa como alvo de consulta) e \(u_t\) é a entrada da layer para o token \(t\) [src_031]. Para balancear a carga sem um termo de loss, o DeepSeek-V3 adiciona um bias por expert \(b_i\) ao score de afinidade apenas no momento do roteamento:

\[\text{biased\_score}_i = s_{i,t} + b_i\]

A seleção top-\(k\) é realizada contra esse score com bias, mas o valor de gate que efetivamente pondera a saída do expert na soma residual ainda é derivado do \(s_{i,t}\) sem bias [src_031]. Assim, o bias guia o roteamento sem distorcer a contribuição de qualquer expert selecionado.

Os bias não são aprendidos por descida de gradiente. Um controlador externo monitora a carga por expert sobre o batch inteiro a cada passo de treinamento. Ao final de cada passo, \(b_i\) é decrementado por uma constante \(\gamma\) (a velocidade de atualização do bias) para todo expert sobrecarregado e incrementado por \(\gamma\) para todo expert subutilizado [src_031].

🎯 Intuição

O bias é um termostato. Quando o expert \(i\) está quente — sobrecarregado neste batch — empurre seu bias para baixo para que o router o prefira menos no próximo batch. Quando estiver frio, empurre-o para cima. O sinal corretivo vive inteiramente no estado do bias, nunca no gradiente de cross-entropy, de modo que balanceamento e modelagem de linguagem param de brigar.

O DeepSeek-V3 define \(\gamma = 0.001\) para os primeiros 14.3T tokens e zera nos últimos 500B tokens de pretraining [src_031]. O mesmo artigo retém uma sequence-wise balance loss complementar com um \(\alpha\) extremamente pequeno para prevenir patologias intra-sequência, mas o trabalho pesado no balanço em nível de batch é feito pela atualização do bias [src_031].

O mecanismo é elegante pela mesma razão que a batch normalization foi: o sinal corretivo é computado a partir de uma estimativa móvel de uma estatística em nível de batch, então a política se ajusta em direção ao balanço sem que nenhum desbalanço vaze para o gradiente de cross-entropy. O DeepSeek-V3 reporta treinamento estável ao longo de 14.8T tokens sem picos de loss irrecuperáveis e sem rollbacks, e credita o resultado conjuntamente a MLA, MoE livre de auxiliary-loss, precisão mista FP8 e o schedule DualPipe [src_031]. A contribuição que esta seção credita é especificamente o esquema de balanceamento de carga; os outros três componentes são examinados no Capítulo 8 deste livro.

💡 Resultado-chave

O balanceamento de carga pode ser imposto por um termostato externo sobre bias por expert, de modo que os gradientes de cross-entropy não carregam nenhuma carga de balanceamento — e o treinamento resultante é estável em escala de fronteira.

🔗 Conexão

MLA, precisão mista FP8 e DualPipe — os três outros componentes do DeepSeek-V3 nomeados nesta seção — são examinados ao lado dos demais deltas de arquitetura do DeepSeek-V3 em Capítulo 8 — Por dentro de um LLM moderno só de decoder.

6. Capacidade de expert e tokens descartados

Uma sutileza que a equação de roteamento esconde é que implementações MoE em produção frequentemente precisam de tensores com formato fixo. Se o expert \(i\) acabar processando 137 tokens neste batch e o kernel foi compilado para 128, o sistema tem que ou fazer padding ou descartar. A solução padrão é declarar uma capacidade por expert antecipadamente e fazer o router cooperar.

🎯 Intuição

Imagine que você compilou um kernel que processa exatamente 32 tokens por expert. Enquanto o router não cooperar, o expert \(i\) pode receber 47 tokens neste batch (overflow — os 15 extras têm que ir para algum lugar) ou 19 (underflow — pad de 13 slots com zeros). Os dois casos são ruins: overflow significa trabalho descartado, underflow significa memória e FLOPs desperdiçados. O capacity factor é a relaxação desse slot fixo — uma pequena super-alocação que compra tolerância ao desbalanço a um custo controlado de memória.

O Switch Transformer formaliza isso definindo a capacidade do expert como

\[\mathrm{capacity} = \left\lceil \frac{\mathrm{tokens\_per\_batch}}{N} \cdot c \right\rceil\]

onde \(c\) é o capacity factor, um hiperparâmetro tipicamente um pouco maior que \(1.0\) [src_024]. Um capacity factor acima de \(1.0\) fornece um buffer para desbalanceamento de roteamento ao custo de memória e compute em slots de padding. Quando mais de \(\mathrm{capacity}\) tokens querem rotear para o expert \(i\), os tokens em excesso são descartados: a saída FFN deles para aquela layer é simplesmente substituída pelo seu próprio passthrough residual — o token contorna o bloco MoE e reentra no residual stream inalterado — como se o bloco MoE fosse a identidade para eles [src_024]. O Switch reporta taxas de descarte abaixo de 1% na prática quando a auxiliary loss fez seu trabalho [src_024].

🤔 Pause e pense

Defina \(c = 1.0\) e assuma que o roteamento está moderadamente desbalanceado — digamos, o expert mais carregado neste batch recebe 1.4× sua fatia. Antes de ler adiante, preveja: aproximadamente que fração dos tokens é descartada, e o que aumentar \(c\) para \(1.5\) compra em troca de qual custo? (Responda na sua cabeça antes de virar para o próximo parágrafo.)

O capacity factor é, ele próprio, um botão com custo bilateral. Um \(c\) mais alto é mais tolerante a desbalanço e reduz taxas de descarte mas infla memória e compute. Um \(c\) mais baixo é mais eficiente, mas mais frágil. Os experimentos do Switch usam valores na faixa de 1.0 a 2.0, com 1.25 sendo um padrão comum no catálogo do levantamento sobre MoE [src_024, src_026]. O DeepSeek-V3 contorna a questão inteiramente: o balanceamento livre de auxiliary-loss é bom o suficiente para que nenhum token seja descartado durante o treinamento ou a inferência, e a implementação não precisa de um buffer de capacidade [src_031].

O esboço de código de duas linhas abaixo mostra a aritmética de capacidade explicitamente.

import math

def expert_capacity(tokens_per_batch: int, num_experts: int,
                    capacity_factor: float = 1.25) -> int:
    """Static per-expert slot count used at compile time."""
    return math.ceil(capacity_factor * tokens_per_batch / num_experts)

# Switch-style example: 4096 tokens per batch, 128 experts, c=1.25
# -> each expert is sized for ceil(1.25 * 4096 / 128) = 40 tokens
print(expert_capacity(4096, 128, 1.25))  # 40

🔄 Recapitulação

• Complete. A fórmula de capacidade do Switch é \(\mathrm{capacity} = \lceil c \cdot \_\_\_ / \_\_\_ \rceil\), onde \(c\) é o ___-factor.
• Explique. Por que os kernels MoE precisam de uma capacidade por expert declarada antecipadamente? O que acontece com os tokens em excesso, e por que isso significa que a auxiliary loss de §4 está fazendo trabalho de sistemas além de trabalho de qualidade?
• Compare. O Switch define \(c \approx 1.25\) e tolera uma pequena taxa de descarte. O balanceamento livre de auxiliary-loss do DeepSeek-V3 mantém a taxa de descarte em zero. Com qual problema cada arquitetura escolhe conviver — e qual cada uma se recusa a aceitar?

7. Paralelismo de experts: o panorama de sistemas

Em escala de treinamento e inferência, os \(E\) experts em uma layer MoE não cabem em um dispositivo. O paralelismo de experts shardeia os experts entre GPUs (ou, em escala maior, entre nós), e cada token deve ser comunicado para qualquer dispositivo que hospede o(s) expert(s) para o(s) qual(is) ele foi roteado [src_024, src_025, src_026]. A coletiva padrão para isso é o all-to-all: cada dispositivo envia uma fatia de tokens para cada outro dispositivo, em proporção a quantos tokens roteou para lá, então cada dispositivo envia as saídas dos experts de volta pelo caminho reverso. (Para leitores cuja base em treinamento distribuído seja rasa: all-to-all é distinto do all-reduce, que soma tensores entre dispositivos, e do all-gather, que os concatena — all-to-all permuta tokens entre dispositivos, e é a coletiva natural quando o índice de onde cada token deve aterrissar depende de uma decisão de roteamento por token.) A latência do all-to-all é o custo de sistemas que o MoE paga pela eficiência em parâmetros.

Três consequências de engenharia decorrem disso. Primeiro, balanceamento de carga não é apenas uma questão de qualidade; é uma questão de wall-clock. Um expert subutilizado significa que a GPU que o hospeda fica ociosa enquanto seus pares terminam, e a GPU mais lenta determina o tempo do passo. O Mixtral especificamente menciona que o paralelismo de experts introduz pressão de balanceamento de carga no lado da engenharia, não apenas no lado da modelagem [src_025]. Segundo, a banda do all-to-all escala com o número de nós envolvidos, então o treinamento MoE entre nós amplifica os custos de comunicação rapidamente com o tamanho do cluster. O DeepSeek-V3 introduz node-limited routing para limitar isso: cada token alcança no máximo \(M\) nós, onde \(M = 4\) na configuração do DeepSeek-V3, com a restrição de que os top-\(M\) nós são escolhidos por score de afinidade somado entre os experts de cada nó [src_031]. Terceiro, o schedule de quando fazer o all-to-all dos experts importa: o algoritmo de paralelismo de pipeline DualPipe do DeepSeek-V3 é construído especificamente para sobrepor compute de forward e backward com o all-to-all do MoE, tornando o custo de comunicação MoE entre nós quase ocultável [src_031].

O Ultra-Scale Playbook do time Nanotron da Hugging Face discute paralelismo de experts ao lado de paralelismo de dados, tensor, sequência e pipeline como um dos eixos de paralelismo usados para entregar modelos modernos de fronteira, e enquadra o panorama de engenharia nesses termos [src_007]. Stanford CS336 cobre o mesmo material no ritmo de aula [src_004]. O Building LLMs from Scratch de Grigorov (Apress, 2026) trata o ângulo de engenharia / PyTorch / kernel-CUDA do sharding de experts como uma perspectiva complementar ao tratamento algorítmico que damos aqui [src_047].

🔗 Conexão

O tratamento completo de MoE em nível de sistemas — stacks de paralelismo (dados, tensor, sequência, pipeline, expert), kernels fundidos, precisão mista FP8 e o schedule do all-to-all — fica fora do escopo algorítmico deste capítulo. As três referências acima (Ultra-Scale Playbook, Stanford CS336 e Grigorov 2026) são as leituras seguintes naturais para esse material.

8. Parâmetros totais versus ativos

Duas contagens de parâmetros importam para um modelo MoE, e a diferença entre elas é a proposta de valor de manchete da arquitetura.

Total parameters é o que o modelo tem em disco e na memória da GPU. Escala com \(E\) e domina o custo de serving: ainda que apenas \(k\) de \(E\) experts processem qualquer token dado, todos os \(E\) estão carregados para que qualquer um deles possa ser selecionado no próximo token. Active parameters é o que processa um único token, escala com \(k\) (e com o tamanho de qualquer shared expert sempre ligado) e domina os FLOPs por token e a latência de inferência em batch sizes pequenos.

A comparação empírica que o Mixtral faz é o exemplo mais limpo do trade-off [src_025]:

Modelo	Parâmetros totais	Parâmetros ativos por token	Notas
Llama-2 70B (denso)	70B	70B	todo parâmetro tocado por token
Mixtral 8x7B	47B	13B	8 experts, roteamento top-2
DeepSeek-V3	671B	37B	256 routed + 1 shared, top-8

🤔 Pause e pense

Olhando apenas para a tabela: o Mixtral 8x7B será mais barato ou mais caro de servir do que o Llama-2 70B? Decida separadamente para o compute por token e para a pegada de memória total, e só depois de se comprometer com essas respostas, leia o próximo parágrafo.

O Mixtral iguala ou supera o Llama-2 70B na maior parte dos benchmarks usando aproximadamente 5x menos parâmetros ativos durante a inferência [src_025]. O custo de memória para servir o Mixtral é determinado pelos 47B totais, que ainda são menores do que os 70B completos do Llama-2 70B. O DeepSeek-V3 puxa a mesma alavanca com mais força, multiplicando a capacidade total por uma ordem de grandeza acima do Llama-2 70B enquanto mantém os parâmetros ativos comparáveis [src_031].

O trade-off tem uma borda afiada. A comparação inteligente é parâmetros ativos para compute, parâmetros totais para capacidade [src_025, src_026]: um modelo de 13B ativos é precificado como um modelo denso de 13B em FLOPs por token e KV-cache por token, mas tem acesso a uma representação de 47B parâmetros quando importa. O qualificador quando importa faz trabalho real: apenas os dois experts certos de oito são consultados, então a gating network tem que de fato aprender a se especializar. A própria análise de roteamento do Mixtral no conjunto de validação do The Pile descobre que os experts não se especializam por tópico no sentido humanamente legível (textos de filosofia e papers do arXiv são roteados de forma similar), mas se especializam em padrões sintáticos e exibem localidade posicional, com tokens consecutivos frequentemente roteados para os mesmos experts em layers mais altas [src_025].

💡 Resultado-chave

Parâmetros ativos determinam o compute por token, parâmetros totais determinam o teto de capacidade — eles se desacoplam em MoE de uma forma que não podem em um Transformer denso.

9. Por que MoE se tornou o padrão na fronteira aberta

Três coisas tinham que ser verdadeiras ao mesmo tempo para que o MoE se tornasse o padrão.

O compute de inferência por token permanece limitado conforme você aumenta a capacidade. Esse é o fato arquitetural. Ao longo da vida útil de um modelo implantado, a inferência é executada ordens de magnitude mais vezes do que o treinamento. Se o custo de serving domina o custo de treinamento ao longo da vida útil de um modelo, e se os parâmetros ativos guiam o custo de serving, então aumentar parâmetros totais com parâmetros ativos fixos é uma melhoria de Pareto sobre dense [src_025, src_031]. A mesma lógica que levou o Llama-3 a fazer over-training nas suas variantes menores além do ponto ótimo de Chinchilla (Capítulo 9) leva à adoção de MoE aqui: em produção, a inferência é amortizada ao longo de muitos mais tokens do que o treinamento.

🔗 Conexão

O regime de over-training introduzido em Capítulo 9 — Scaling Laws §6 (Pós-Chinchilla) fornece o argumento de amortização do custo de inferência que este bullet invoca.

O treinamento MoE de pesos abertos alcançou o dense. A linha do tempo do levantamento sobre MoE mostra a curva: Mixtral-8x7B (jan 2024), DBRX, Grok-1, DeepSeek-V2, Qwen1.5-MoE, Hunyuan-Large, DeepSeek-V3, todos LLMs MoE de pesos abertos lançados ao longo de 2024 e em 2025 [src_026]. Ao final daquela onda, a distância para os modelos flagship de código fechado havia sido substancialmente fechada; o DeepSeek-V3 em particular reporta desempenho comparável ao GPT-4o e ao Claude-3.5-Sonnet em uma variedade de benchmarks padrão e abertos [src_031]. O Ultra-Scale Playbook enquadra o toolchain de sistemas (stacks de paralelismo, kernels fundidos, precisão mista FP8, all-to-all expert-paralelo) como a infraestrutura amadurecendo que tornou isso possível [src_007].

O balanceamento livre de auxiliary-loss fechou a lacuna de estabilidade no treinamento. O Switch Transformer havia identificado instabilidade e interferência de balanceamento de carga como obstáculos gêmeos lá em 2021 [src_024]. A contribuição do DeepSeek-V3 mostrou que a objeção de balanceamento de carga podia ser endereçada sem comprometer o gradiente de cross-entropy, e que o treinamento resultante era estável ao longo de 14.8T tokens sem rollbacks [src_031]. Essa é uma falsificação concreta da reivindicação de longa data de que MoE era inerentemente mais frágil do que dense em escala de fronteira.

⚠️ Armadilha

Servir MoE é mais difícil do que servir dense — a pegada de parâmetros totais determina a pressão de memória, o roteamento expert-paralelo tolera melhor cargas de trabalho em batch do que as interativas de token único, e a escolha do Llama-3 por dense para o flagship de 405B é o contraexemplo vivo.

A ressalva honesta: servir MoE é mais difícil do que servir dense. A pegada de parâmetros totais é o que determina a pressão de memória, o roteamento expert-paralelo introduz overhead que cargas de trabalho em batch toleram melhor do que as interativas de token único, e o artigo do Mixtral nota especificamente que as layers MoE são mais adequadas a serving em batch onde o custo de roteamento por batch é amortizado em alta intensidade aritmética [src_025]. O Llama-3 explicitamente escolheu dense em vez de MoE para o flagship de 405B, citando estabilidade de treinamento [src_026]. Então o MoE é o padrão na fronteira aberta a partir de 2025, mas não é uma conclusão prefixada: a escolha depende da tolerância a risco da equipe, do perfil de implantação e de quanto investimento em engenharia no caminho do all-to-all o projeto pode bancar. O Ultra-Scale Playbook trata ambas as arquiteturas como opções vivas dentro do mesmo stack de paralelismo [src_007].

🔄 Recapitulação

• Complete. Três coisas tinham que ser verdadeiras ao mesmo tempo para que o MoE assumisse: o ___-compute-por-token permanece limitado à medida que a capacidade cresce; o treinamento MoE de pesos abertos alcançou o dense; e o balanceamento livre de ___-loss fechou a lacuna de estabilidade no treinamento.
• Compare. Por que a mesma equipe Llama-3 que empurrou o over-training além do ponto ótimo de Chinchilla (Cap.9) escolhe dense para o flagship de 405B em vez de MoE? O que cada escolha está otimizando?
• Preveja. Uma equipe escolheu MoE para um modelo de fronteira de pesos abertos e um produto de chat. O perfil principal de implantação é serving interativo de token único. Qual dos três habilitadores "tinham-que-ser-verdadeiros" é o mais fraco da equipe, e em que ela deveria investir para compensar?

10. Encerramento

Este capítulo fica na costura entre arquitetura (Parte 4) e pós-treinamento (Parte 6). O DeepSeek-V3 reaparece na tabela de comparação de arquiteturas do Capítulo 8 como o modelo de fronteira canônico de MoE de granularidade fina, e novamente no Capítulo 13 sobre modelos de reasoning porque o DeepSeek-R1 herda a base V3 e aplica reinforcement learning com recompensas verificáveis em cima dela. A maquinaria MoE desenvolvida aqui é o substrato comum a ambos os fios.

🔗 Conexão

A base MoE do DeepSeek-V3 reaparece em dois capítulos posteriores: como uma entrada de arquitetura de fronteira em Capítulo 8 — Por dentro de um LLM moderno só de decoder, e como o substrato pré-treinado para o DeepSeek-R1 em Capítulo 13 — Modelos de raciocínio.

O que você deve levar daqui: um bloco MoE é o mesmo slot FFN que um Transformer denso tem, parametrizado de forma diferente, mais um router aprendido, mais uma estratégia de balanceamento de carga. A equação do router \(y = \sum_{i \in \mathrm{TopK}} g_i \cdot E_i(x)\) é mecanicamente simples. A estratégia de balanceamento de carga é o que tornou a arquitetura industrialmente viável, e a passagem de auxiliary-loss para balanceamento livre de auxiliary-loss é o que a tornou competitiva com dense na fronteira. O custo de sistemas é real, mas paga de volta na implantação.

Referências

• [src_004] Hashimoto, T., & Liang, P. (2025). Stanford CS336: Language Modeling from Scratch (Spring 2025). https://stanford-cs336.github.io/spring2025/
• [src_007] Hugging Face. (2025). The Ultra-Scale Playbook: Training LLMs on GPU Clusters. https://huggingface.co/spaces/nanotron/ultrascale-playbook
• [src_024] Fedus, W., Zoph, B., & Shazeer, N. (2021). Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity. https://arxiv.org/pdf/2101.03961
• [src_025] Jiang, A. Q., Sablayrolles, A., Roux, A., Mensch, A., Savary, B., Bamford, C., et al. (2024). Mixtral of Experts. https://arxiv.org/pdf/2401.04088
• [src_026] Cai, W., Jiang, J., Wang, F., Tang, J., Kim, S., & Huang, J. (2024). A Survey on Mixture of Experts. https://arxiv.org/pdf/2407.06204
• [src_031] DeepSeek-AI. (2024). DeepSeek-V3 Technical Report. https://arxiv.org/pdf/2412.19437
• [src_047] Grigorov, D. (2026). Building Large Language Models from Scratch (Apress). https://doi.org/10.1007/979-8-8688-2297-1