🧠FFVAcademy
🧩

Mixture of Experts (MoE)

10 min de leitura·+70 XP
Pré-requisitos (0/1)0%

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

GPT-4 tem estimados 1.7 trilhoes de parametros — mas ativar todos a cada token seria computacionalmente impossivel. A solucao: Mixture of Experts (MoE), uma arquitetura que escala parametros sem escalar compute proporcionalmente. Neste artigo, voce vai entender como o router seleciona experts, o problema de load balancing, e por que MoE dominou os modelos frontier.

A ideia: parametros abundantes, compute seletivo

Em um Transformer denso (como LLaMA), todos os parametros sao usados para processar cada token. Em MoE, a camada FFN (feed-forward network) e substituida por multiplos experts — cada um e um FFN independente — e um router decide quais ativar.

🗺️ Dense vs MoE — arquitetura comparada
TRANSFORMER DENSO (LLaMA 3 70B)
Token → Self-Attention → FFN → output
FFN usa 100% dos parâmetros
Todo token passa por todos os pesos
70B params totais · 70B ativos/token
compute = params totais
CASOS DE USO
Simples de servir
VRAM = modelo todo
Fine-tuning padrão
TRANSFORMER MoE (Mixtral 8×7B)
Token → Self-Attention → Router → top-2 experts
Router seleciona 2 de 8 experts
Expert 1 + Expert 2 ativados
Expert 3..8 dormindo (gradiente zero)
47B params totais · ~13B ativos/token
compute ≪ params totais
CASOS DE USO
VRAM = modelo todo (todos os experts)
Compute = só experts ativos
Escalável para 1T+ params
💡
O trade-off fundamental: MoE tem compute de modelo pequeno mas memoria de modelo grande. Todos os experts precisam estar na VRAM mesmo que so 2 de 8 sejam usados por token.

O Router: como escolher experts

O router e uma pequena rede (geralmente uma camada linear + softmax) que recebe a representacao do token e produz uma distribuicao de probabilidade sobre os experts.

🗺️ Router top-k — token "implementação" → seleção de experts
📥Token "implementação"Representação vetorial d-dimensional do token atual
🎯Router: W_gate × tokenScores: Expert1=0.05 · Expert2=0.41★ · Expert3=0.02 · Expert4=0.31★ · Expert5–8=0.08–0.03
🔝Top-2 selecionadosExpert 2 (0.41) + Expert 4 (0.31) → normalizados: 0.57 e 0.43
📤Output combinado0.57 × Expert2(token) + 0.43 × Expert4(token) — experts 1,3,5–8: gradiente ZERO
python
# Router simplificado em PyTorch
import torch
import torch.nn.functional as F

class Router(torch.nn.Module):
    def __init__(self, d_model, num_experts, top_k=2):
        super().__init__()
        self.gate = torch.nn.Linear(d_model, num_experts, bias=False)
        self.top_k = top_k

    def forward(self, x):
        # x: (batch, seq_len, d_model)
        logits = self.gate(x)              # (batch, seq_len, num_experts)
        scores = F.softmax(logits, dim=-1)
        top_scores, top_indices = scores.topk(self.top_k, dim=-1)
        top_scores = top_scores / top_scores.sum(dim=-1, keepdim=True)
        return top_scores, top_indices

Load Balancing: o problema central

Se o router prefere poucos experts, os outros nao recebem gradientes e nao treinam. Isso e expert collapse — o modelo desperica a maioria da sua capacidade.

TecnicaComo funcionaUsado em
Auxiliary load balancing lossAdiciona um termo a loss que penaliza distribuicao desigual de tokens entre expertsSwitch Transformer, Mixtral, GPT-4 (provavel)
Expert capacityLimita o numero maximo de tokens que cada expert pode processar. Excedente e descartado ou roteado para outro.Switch Transformer, GShard
Noise in routerAdiciona ruido gaussiano aos logits do router durante treino para explorar experts menos usadosST-MoE, Mixtral
Auxiliary-loss-free balancingBias adaptativo no router sem distorcer a loss principalDeepSeek v3 (inovacao chave)

Modelos MoE reais

ModeloParams totaisParams ativosExpertsTop-kPerformance
Mixtral 8x7B47B~13B82~ LLaMA 2 70B (dense) com 5x menos compute
Mixtral 8x22B176B~44B82Compete com GPT-3.5 Turbo
GPT-4 (estimado)~1.7T~220B~16~2Frontier (ate mar/2024)
DeepSeek v3671B~37B2568Compete com GPT-4o por ~$5.5M de treino
Grok-1 (xAI)314B~79B82Open-source, competitivo com Mixtral
💡
DeepSeek v3 e notavel: 256 experts com top-8 ativacao + 1 expert compartilhado (sempre ativo). O expert compartilhado captura conhecimento geral; os especializados cobrem dominios. MLA (Multi-head Latent Attention) comprime K/V em latent space, reduzindo o KV Cache drasticamente.

Expert Parallelism: como servir MoE em clusters

Um MoE de 671B params (DeepSeek v3) não cabe em uma única GPU — nem em 8. O serving requer estratégias específicas de paralelismo. Em modelos densos, o padrão é tensor parallelism(dividir matrizes entre GPUs). Em MoE, adiciona-se expert parallelism: cada GPU hospeda um subconjunto de experts.

🗺️ Expert Parallelism — 8 experts em 4 GPUs
GPU 0
Expert 1 (hospedado)
Expert 2 (hospedado)
Attention layers (compartilhadas)
Recebe tokens roteados p/ E1/E2
GPU 1
Expert 3 (hospedado)
Expert 4 (hospedado)
Attention layers (compartilhadas)
Recebe tokens roteados p/ E3/E4
GPU 2
Expert 5 (hospedado)
Expert 6 (hospedado)
Attention layers (compartilhadas)
Recebe tokens roteados p/ E5/E6
GPU 3
Expert 7 (hospedado)
Expert 8 (hospedado)
Attention layers (compartilhadas)
Recebe tokens roteados p/ E7/E8
EstratégiaO que fazTrade-off
Expert ParallelismDiferentes GPUs hospedam diferentes experts. All-to-all communication move tokens entre GPUs.Alta largura de banda inter-GPU necessária (NVLink)
Tensor ParallelismDivide cada camada entre GPUs (matrizes particionadas).Funciona bem para attention; usado em conjunto com EP
Expert OffloadingExperts inativos ficam na RAM CPU; carregados na GPU quando chamados.Latência alta (PCIe ~10x mais lento que HBM)
Token DroppingSe um expert excede capacidade, tokens em excesso são descartados (skip).Perda de qualidade controlável com buffer capacity
⚠️
O gargalo real em MoE serving é o all-to-all communication: cada token precisa ser enviado para a GPU que hospeda o expert selecionado. Com batch grande, isso gera tráfego massivo entre GPUs. Por isso NVLink (600 GB/s) é praticamente obrigatório para clusters MoE eficientes — Ethernet (100 Gbps) causa degradação severa de throughput.

Fine-tuning MoE: complexidades práticas

Fine-tuning de modelos MoE é mais complexo que modelos densos. A principal questão: o router deve ser atualizado? E se sim, como evitar que o fine-tuning colapse a especialização aprendida no pré-treino?

AbordagemO que congelaQuando usarRisco
Full fine-tuningNada — atualiza tudo incluindo routerQuando tem dados suficientes (>100k exemplos)Router pode colapsar especializações do pré-treino
LoRA nos expertsPesos base dos experts; treina adaptadores LoRAFine-tuning eficiente em domínio específicoLoRA pode conflitar se expert não for ativado para o domínio
Congelar routerRouter congelado; atualiza apenas expertsPreservar routing do pré-treino ao especializarRouter pré-treino pode não ser ótimo para nova tarefa
Congelar experts inativosSó atualiza experts ativados para o domínioMáxima eficiência; mínima interferênciaIdentificar quais experts são relevantes é não-trivial
💡
MoE + LoRA na prática: a implementação mais comum aplica LoRA em todosos experts com rank baixo (r=8 ou r=16). Durante o fine-tuning, apenas os adaptadores LoRA dos experts ativados recebem gradiente — comportamento análogo ao routing normal. O router geralmente é congelado. Custo: ~2% dos parâmetros treináveis de um full fine-tune.

Vale a pena fazer fine-tuning de Mixtral 8x7B vs LLaMA 3 70B para o mesmo caso de uso?

Depende do compute disponível. Mixtral 8x7B tem ~13B params ativos (compute similar a um denso de 13B) mas precisa de 47B na VRAM. LLaMA 3 70B requer 70B na VRAM. Se VRAM é o gargalo: Mixtral vence (mais qualidade por VRAM com offloading). Se latência é crítica: LLaMA 3 70B em tensor-parallel costuma ser mais previsível. Para a maioria dos casos de uso empresariais, LLaMA 3 70B dense é mais simples e suficiente.

MoE vs Dense: quando usar cada um

📋 Qual arquitetura para um LLM de uso geral em producao?

MoE

Para modelos frontier (>100B params), MoE e essencial. O custo de servir um modelo denso de 1.7T params seria astronomico. MoE permite escalara parametros sem escalar compute linearmente.

Alt: DenseModelos menores (<70B params) onde a complexidade do MoE nao compensa. LLaMA 3 70B dense e mais simples de servir que um MoE de 70B params.

FatorDenseMoE
Compute por tokenProporcional aos params totaisProporcional aos params ATIVOS (muito menor)
VRAM necessariaProporcional aos params totaisProporcional aos params TOTAIS (todos os experts na memoria)
Complexidade de servirSimples — sharding padraoComplexo — expert parallelism + routing overhead
EscalabilidadeLinear: 2x params = 2x computeSublinear: 2x params pode ser apenas 1.2x compute
TreinamentoEstavel, bem compreendidoLoad balancing e instabilidade sao desafios ativos
Fine-tuningSimples — LoRA/QLoRA padraoComplexo — quais experts atualizar? Router muda?

DeepSeek v3: anatomia de um MoE de fronteira barato

DeepSeek v3 (dezembro 2024) abalou a indústria ao demonstrar que um modelo competitivo com GPT-4o podia ser treinado por ~$5,5M — enquanto estimativas de GPT-4 falam em $100M+. As inovações técnicas foram específicas e complementares:

🗺️ As 4 inovações-chave do DeepSeek v3
MLA (Multi-head Latent Attention)
Comprime K/V em latent space antes de armazenar no KV Cache
KV Cache ~90% menor que Multi-Head Attention padrão
Crítico: KV Cache é o gargalo de memória em long contexts
Projeta K,V de d_model para d_latent (muito menor)
maior economia de memória
Auxiliary-Loss-Free Balancing
MoE padrão adiciona load balancing loss
Essa loss distorce o gradiente principal
DeepSeek v3: bias adaptativo por expert no router
Sem loss auxiliar: gradiente limpo, convergência melhor
melhor qualidade de treino
FP8 Mixed Precision Training
Maioria das operações em FP8 (8-bit float)
FP16 só onde numericamente crítico
Reduz memória e compute ~2x vs FP16
Requer calibração cuidadosa para evitar divergência
2× eficiência de compute
256 Experts + 1 Shared
256 routed experts + 1 expert compartilhado
Expert compartilhado sempre ativado: captura geral
Top-8 de 256 routed: especialização fina
671B total · ~37B ativos por token
granularidade de especialização
💡
O resultado: DeepSeek v3 treinou 14.8T tokens em ~2.788 GPU-days (H800 SXM). Modelos concorrentes estimam 30-50× mais compute para qualidade similar. A lição não é "GPUs baratas" — é eficiência de algoritmo compensa hardware. O paper completo está disponível no arXiv e é uma leitura obrigatória para quem trabalha com infraestrutura de LLMs.

Perguntas e respostas

Cada expert se especializa em um dominio (codigo, matematica, etc.)?

Na teoria, sim. Na pratica, a especializacao e mais sutil: experts tendem a se especializar em padroes sintaticos (tokens de pontuacao, inicio de frase, numeros) mais do que em dominios semanticos. Analises do Mixtral mostram que a maioria dos experts e “generalista” com leves preferencias, nao especialistas puros.

Posso rodar um MoE em hardware menor se so carregar 2 experts?

Em teoria parcialmente — e o conceito de “expert offloading”: manter experts inativos na RAM e carregar na GPU sob demanda. Funciona mas adiciona latencia significativa (PCIe e ~10x mais lento que HBM). Mixtral 8x7B com offloading roda em GPUs de 24GB mas com throughput muito menor que carregar tudo na VRAM.

O router e treinado junto com os experts?

Sim. O router e uma camada linear cujos pesos sao aprendidos end-to-end via backpropagation. O gradiente flui do output, passa pelos experts ativados, e volta ao router. O desafio: o gradiente so flui pelos top-k experts selecionados — os outros nao recebem sinal, o que pode causar collapse sem a load balancing loss.
O que voce aprendeu: MoE substitui o FFN por multiplos experts + router. Apenas top-k experts sao ativados por token — compute de modelo pequeno, memoria de modelo grande. Load balancing e critico para evitar expert collapse. Modelos frontier (GPT-4, DeepSeek v3) usam MoE massivo. DeepSeek v3 mostrou que inovacao em training efficiency (MLA + auxiliary-loss-free balancing + FP8) pode competir com budgets 20x maiores. Proximo: como LLMs interagem com o mundo real — Tool Calling.
🧩

Quiz rápido

4 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito

Continue lendo