Mixture-of-Experts: por que modelos gigantes ativam só uma fração dos parâmetros

Existe uma contradição no coração dos modelos de fronteira que a indústria raramente explica em voz alta: os maiores modelos que você usa hoje quase nunca usam a si mesmos por inteiro. Um modelo pode carregar centenas de bilhões de parâmetros e, ainda assim, para cada token que gera, tocar apenas uma pequena parte deles. Essa não é uma falha de eficiência nem um truque de compressão. É uma decisão de arquitetura chamada mixture of experts, e ela redefiniu o que significa “modelo grande” nos últimos anos.

A tese aqui é simples e desconfortável para quem gosta de pensar em escala como uma linha reta: capacidade e custo de computação deixaram de ser a mesma coisa. Mixture-of-experts (MoE) é o mecanismo que quebrou o acoplamento entre os dois. E entender como isso funciona é entender por que a corrida atual não é mais sobre “quantos parâmetros”, mas sobre “quais parâmetros, para qual token, e quem decide”.

O gargalo que o MoE resolve

Num Transformer denso convencional, cada token que entra passa por todos os parâmetros do modelo. As camadas de atenção e, principalmente, as redes feed-forward (as MLPs que ficam entre os blocos de atenção) processam absolutamente tudo. Isso tem uma consequência dura: o custo de computação por token cresce junto com o número de parâmetros. Dobrar a capacidade do modelo significa dobrar o trabalho para gerar cada palavra. Treino e inferência ficam presos à mesma conta.

O problema é que boa parte desse trabalho é redundante. Nem todo token precisa de toda a rede. A palavra “de” numa frase trivial não exige a mesma máquina que resolve uma inferência de código ou uma equação. A intuição por trás do MoE é que um modelo suficientemente grande desenvolve, na prática, sub-redes especializadas, e forçar todo token a atravessar todas elas é desperdício.

MoE ataca justamente a camada feed-forward, que costuma concentrar a maior parte dos parâmetros de um Transformer. Em vez de uma única MLP gigante por camada, você tem várias MLPs menores, chamadas de especialistas (experts). E, crucialmente, um mecanismo que escolhe quais especialistas cada token vai usar.

Roteamento: o cérebro que decide quem trabalha

O componente que faz o MoE funcionar é o roteador (router, ou gating network). Ele é pequeno, geralmente uma camada linear seguida de uma normalização, e sua função é olhar para a representação de cada token e produzir uma pontuação para cada especialista disponível. A partir dessas pontuações, o roteador seleciona um subconjunto — no esquema conhecido como top-k, com k pequeno. Alguns modelos roteiam cada token para um único especialista; outros para dois ou alguns poucos. O número exato varia de arquitetura para arquitetura, mas a regra é sempre a mesma: ativar uma minoria dos especialistas por token.

O token então é processado apenas por esses especialistas escolhidos. As saídas são combinadas com pesos proporcionais às pontuações do roteador, e o resto da camada segue normalmente. Do ponto de vista do fluxo de dados, tudo continua sendo um Transformer. A diferença é que a camada densa virou uma camada condicionalmente esparsa: densa em capacidade instalada, esparsa em uso efetivo.

É por isso que surgem dois números distintos que a imprensa técnica frequentemente confunde. Existe o total de parâmetros do modelo — todos os especialistas somados — e existem os parâmetros ativos, aqueles efetivamente usados para processar um token. O custo de computação por token acompanha os parâmetros ativos, não o total. Um modelo pode ter uma capacidade instalada enorme e um custo de cálculo por token comparável ao de um modelo denso muito menor. Essa é a mágica, e ela não é gratuita.

Esparsidade condicional: capacidade sem pagar por ela o tempo todo

Vale nomear o princípio com precisão, porque ele é mais geral do que o MoE. Esparsidade condicional significa que a computação executada depende da entrada. Diferente da esparsidade estática, em que você poda pesos e eles somem para sempre, aqui todos os pesos continuam existindo — o que varia é quais deles são acionados a cada passo.

O ganho é conceitualmente elegante. Você aumenta a capacidade de memorização e especialização do modelo adicionando especialistas, sem aumentar proporcionalmente o custo de computação de cada forward pass. A capacidade cresce com o número total de especialistas; o custo de cálculo cresce com quantos você ativa. Como esses dois eixos foram separados, dá para empurrar a capacidade para cima mantendo a computação de inferência sob controle.

Isso muda a economia de forma concreta. Servir um modelo denso de fronteira é caro porque cada token paga o preço cheio em computação. Um MoE bem projetado tende a entregar qualidade próxima da de um denso muito maior, gastando por token o esforço de cálculo de um modelo bem menor. Para quem opera inferência em escala, onde o custo marginal por token multiplica por bilhões de requisições, essa diferença deixa de ser detalhe de arquitetura e vira estratégia de negócio.

Onde a conta não fecha tão bem

Se fosse só vantagem, todo modelo já seria MoE. Não é, e as razões são instrutivas.

O primeiro problema é o balanceamento de carga. O roteador aprende junto com o resto do modelo, e ele tende a um comportamento preguiçoso: mandar cada vez mais tokens para os mesmos poucos especialistas que já foram bem treinados, num ciclo de retroalimentação. Especialistas populares ficam melhores, atraem mais tráfego, e os demais definham sem nunca receber gradiente suficiente. O modelo colapsa numa fração da própria capacidade. A correção padrão é introduzir um termo de perda auxiliar que penaliza a distribuição desigual, empurrando o roteador a espalhar os tokens. É um remendo necessário, e sintonizá-lo é uma arte delicada: perda de balanceamento forte demais degrada a qualidade, fraca demais deixa o colapso voltar.

O segundo problema é memória. Parâmetros ativos baixos reduzem a computação, mas todos os especialistas precisam estar carregados e disponíveis, porque qualquer token pode acionar qualquer um deles. Você economiza FLOPs, não memória. Um modelo MoE ocupa a memória de sua contagem total de parâmetros, mesmo usando uma fração por vez. Isso desloca o gargalo de inferência da computação para a largura de banda e a capacidade de memória — um trade-off, não um almoço grátis.

O terceiro é a complexidade de sistema. Em treino e inferência distribuídos, especialistas ficam espalhados por diferentes aceleradores. Rotear tokens significa enviá-los para o acelerador certo e trazer o resultado de volta, o que gera comunicação intensa entre dispositivos. Some-se a isso o fato de que cada especialista costuma ter uma capacidade máxima de tokens por batch; quando o roteador manda tokens demais para um especialista lotado, o excedente pode ser descartado (token dropping) ou desviado, o que introduz uma irregularidade que o modelo denso simplesmente não tem. Engenharia de MoE é, em boa medida, engenharia de comunicação e escalonamento, não só de matemática.

Há ainda um custo menos tangível: instabilidade de treino. A decisão discreta do top-k — escolher este especialista e não aquele — não é suave, e roteadores mal calibrados produzem oscilações que atrapalham a convergência. Modelos densos são mais chatos e mais previsíveis. MoE é mais poderoso e mais temperamental.

Especialistas não são o que o nome sugere

Um mal-entendido comum merece correção direta. A palavra “especialista” evoca a ideia de que um deles cuida de medicina, outro de programação, outro de poesia. Não é assim que costuma emergir. A especialização que o roteador aprende tende a ser opaca e de baixo nível — padrões estatísticos ligados a tipos de token, posição, estrutura sintática — e nem sempre corresponde a categorias semânticas legíveis para humanos. Os especialistas se dividem o trabalho por critérios que fazem sentido para a otimização, não necessariamente para a nossa intuição. Antropomorfizar isso leva a expectativas erradas sobre interpretabilidade e controle.

Minha posição

Mixture-of-experts é a admissão, em silício, de que escala bruta e uniforme é ineficiente. E é a resposta mais madura que a indústria encontrou para uma pergunta que a lei de escala densa não respondia: como continuar crescendo em capacidade quando o custo de inferência já dói? A resposta foi parar de tratar todo token como igual.

Mas eu resisto ao entusiasmo fácil. MoE não torna modelos gigantes baratos — ele torna a computação por token mais barata, empurrando o custo para memória, banda e complexidade operacional. Quem lê “só ativa uma fração dos parâmetros” e conclui “então é leve” entendeu metade da frase. O modelo continua gigante onde importa para quem precisa hospedá-lo. O que mudou foi onde a conta é cobrada, não se ela existe.

Para quem toma decisões de tecnologia e produto, a lição prática é essa: pare de comparar modelos apenas pela contagem total de parâmetros. É um número cada vez mais desconectado do que você vai pagar em computação e da latência que vai sentir. Pergunte também pelos parâmetros ativos, pela pegada de memória, pela estabilidade sob carga. MoE não simplificou os modelos de fronteira. Tornou-os mais sofisticados — e, portanto, mais fáceis de avaliar mal por quem só olha para o número grande.