O que é MoE? Por que parâmetros ativos não contam tudo

Para entender o que é MoE, comece por esta distinção: um modelo com mistura de especialistas pode fazer menos trabalho por token e continuar enorme para hospedar. O modelo de linguagem Kimi K3.1 Pro, da Moonshot AI, tem 2.8T de parâmetros totais, mas 104B ativos por token, segundo o anúncio oficial de lançamento. O número menor ajuda a explicar o esforço computacional; o maior continua relevante quando é preciso armazenar os pesos.

Contagens de parâmetros e informações das fontes verificadas em 24 de outubro de 2026. Os cálculos da proporção de parâmetros ativos abaixo são nossos; não representam ganhos medidos de velocidade, economia de memória ou notas de qualidade.

O que é MoE, a mistura de especialistas?

Mixture of experts, ou MoE, é uma arquitetura que reúne várias redes internas de processamento em um modelo, mas seleciona apenas algumas para cada entrada. Um parâmetro é um valor numérico aprendido pelo modelo. Os parâmetros armazenados costumam ser chamados de pesos. Já um token é uma pequena unidade de entrada ou saída, muitas vezes um fragmento de palavra.

Pense em um prédio de consultórios com várias salas. A recepção encaminha cada visitante às salas necessárias para aquele atendimento. Poucas salas trabalham para atender aquela pessoa, mas todas continuam no prédio. Em uma camada MoE, o roteador faz o papel da recepção, e os especialistas são as salas.

A analogia tem um limite: estamos falando de redes numéricas treinadas, e não de uma lista de profissões. Não dá para presumir que existam um especialista jurídico, um em programação e outro em contabilidade esperando para ser escolhidos.

Como funciona uma arquitetura MoE?

O roteador escolhe caminhos dentro do modelo e depois combina os resultados. Um transformer processa as relações de contexto entre tokens. Nos transformers MoE mais comuns, várias redes de especialistas substituem um bloco feed-forward. Esse bloco transforma a representação numérica interna de um token; a atenção é um mecanismo separado, que permite aproveitar o contexto ao redor.

O fluxo funciona assim:

1. A representação atual de um token chega a uma camada MoE.
2. Um roteador treinado, também chamado de gate, atribui pontuações aos especialistas.
3. Ele seleciona um subconjunto, muitas vezes os especialistas com maior pontuação. É o roteamento top-k, em que k indica quantos são selecionados.
4. Os especialistas escolhidos processam essa representação. Suas saídas recebem pesos e são combinadas antes de o processamento continuar.

Isso acontece nas camadas MoE do modelo, portanto tokens e camadas diferentes podem selecionar especialistas diferentes. A explicação da arquitetura pelo PyTorch descreve essa combinação ponderada; o artigo técnico da Mistral mostra como as escolhas variam entre camadas.

O que significa MoE esparsa?

Esparsa significa que apenas um subconjunto de especialistas é executado para cada token. É essa a configuração relevante para as contagens de parâmetros totais e ativos nas fichas técnicas dos modelos atuais. Os demais especialistas podem atender outros tokens, inclusive os que estão sendo processados no mesmo lote.

Um bloco feed-forward denso aplica toda a sua rede a cada token. Camadas de especialistas esparsas oferecem mais capacidade armazenada sem obrigar cada token a passar por todos os especialistas. Componentes compartilhados, como a atenção nestes exemplos, continuam trabalhando.

Uma mistura de especialistas continua sendo um único modelo

O roteamento MoE é diferente de escolher entre modelos de API ou pedir que vários chatbots votem em uma resposta. O roteador e os especialistas são treinados como componentes de uma mesma rede. Em geral, a aplicação envia uma solicitação a essa rede; ela não escolhe um especialista como quem seleciona um produto em um catálogo.

Para quem desenvolve aplicações, essa distinção evita um erro de projeto: escolher um modelo MoE não coloca à disposição da aplicação uma equipe controlável de agentes especializados.

Modelos MoE: leia os parâmetros totais e ativos em conjunto

Os parâmetros totais indicam o tamanho armazenado do modelo; os ativos descrevem o caminho de processamento por token informado pelo fabricante. Nenhum dos dois é uma especificação completa de hardware. B significa bilhão; T, trilhão.

A última coluna divide os parâmetros ativos pelos totais, com arredondamento. Ela descreve as contagens publicadas por cada fabricante, não um ranking de eficiência entre modelos. As arquiteturas e os critérios de contagem de parâmetros podem variar.

Kimi K3.1 Pro: uma pequena fração de um modelo muito grande

O Kimi K3.1 Pro mostra por que a contagem de parâmetros ativos não pode ser usada como o tamanho do modelo a hospedar. Convertendo o total informado pela Moonshot para a mesma unidade, temos 2,800B. Assim, 104 ÷ 2,800 × 100 = 3.7%, com arredondamento.

Isso significa que a contagem ativa informada é uma pequena fração do total. Não significa que a infraestrutura de inferência possa descartar os outros pesos, nem que a API entregue essa mesma fração da latência de um modelo denso. O caminho muda conforme os tokens e as camadas.

O post de lançamento da Moonshot descreve o Pro como um K3 que passou por pós-treinamento e usa o rótulo arredondado “3T-class”. O anúncio oficial traz o par exato: 2.8T / 104B. Use essa especificação explícita para interpretar o tamanho do modelo.

Para quem desenvolve com uma API, o modelo é um candidato a avaliar. Para quem vai hospedá-lo, a disponibilidade é um requisito à parte: na data da verificação, a Moonshot prometia disponibilizar todos os pesos até 4 de novembro de 2026. Uma promessa de lançamento ainda não é um artefato pronto para implantação. O guia sobre o Kimi K3.1 Pro trata das decisões específicas desse lançamento.

Qwen3-235B-A22B: a contagem ativa não substitui o total

O Qwen3-235B-A22B deixa essa diferença visível no próprio nome. A ficha técnica original da Qwen informa 235B de parâmetros totais e 22B ativados, com 128 especialistas e 8 especialistas ativados.

O cálculo dos parâmetros é 22 ÷ 235 × 100 = 9.4%, com arredondamento. Para um assistente privado de documentos, isso ajuda a entender como o modelo limita o processamento por token. O planejamento de memória ainda precisa acomodar o checkpoint escolhido por inteiro e o estado das solicitações atendidas.

Não interprete “22B ativos” como “cabe na memória como um modelo denso de 22B”. Mantenha também a identificação do checkpoint junto dos números: o nome da família, sozinho, não basta para escolher os arquivos de pesos, a precisão e a configuração de inferência.

Mixtral 8x7B: por que multiplicar os números do nome dá errado?

O Mixtral 8x7B tem componentes compartilhados, portanto seu nome não é uma instrução de multiplicação. O post de lançamento da Mistral informa 46.7B de parâmetros totais e 12.9B usados por token. Multiplicar os números do nome trata os componentes compartilhados como se pertencessem a modelos completos separados.

O artigo técnico da Mistral descreve redes feed-forward de especialistas ao lado de mecanismos de atenção compartilhados. Em cada camada, o roteador escolhe 2 de 8 especialistas. Eles não são oito modelos completos e independentes.

Com o par de contagens publicado, temos 12.9 ÷ 46.7 × 100 = 27.6%, com arredondamento. Selecionar 2 de 8 especialistas corresponde a 25% dos especialistas, uma conta com outro denominador. Os componentes compartilhados são um dos motivos pelos quais a proporção de especialistas difere da proporção de parâmetros.

Ao planejar a implantação, use o total da ficha técnica e os arquivos reais do checkpoint. Nem o nome do produto nem a quantidade de especialistas selecionados informa todo o espaço ocupado pelos pesos.

Por que menos processamento não garante menor latência?

O roteamento esparso reduz o processamento dos especialistas em relação à execução de uma rede densa de tamanho comparável; ele não promete o tempo de resposta de um modelo denso menor. É assim que MoE pode reduzir o custo de servir modelos de grande capacidade por token, sem eliminar demandas significativas de memória e comunicação.

Os cálculos são apenas uma parte da inferência, o processo de executar um modelo treinado. O servidor também lê pesos, executa componentes compartilhados, encaminha representações de tokens e, às vezes, as transfere entre dispositivos. Uma contagem ativa menor não elimina essas operações. Shazeer e seus colegas identificam lotes pequenos por especialista e a largura de banda da rede como limitações de desempenho no artigo original sobre MoE esparsa.

Vazão e latência respondem a perguntas de negócio diferentes. Vazão é quanto trabalho o serviço conclui ao longo do tempo. Latência é quanto uma solicitação individual espera. Uma fila noturna de processamento de documentos pode se beneficiar de uma configuração eficiente com lotes grandes; um assistente interativo de suporte precisa entregar rapidamente a primeira resposta útil.

O processamento em lote, que reúne vários tokens ou solicitações, pode melhorar o aproveitamento do hardware. Mas tokens diferentes podem selecionar especialistas diferentes, então um lote pode usar uma parcela muito maior do modelo do que um único token. A contagem ativa não representa a quantidade de pesos que o servidor acessa ao longo de um lote inteiro.

O processamento do prompt e a geração de tokens também exigem coisas diferentes do sistema. O prefill processa a entrada; o decode gera os tokens seguintes. O vLLM, software para servir modelos de linguagem, documenta opções distintas de comunicação entre especialistas para prefill com alta vazão e decode com baixa latência. Nosso guia de inferência de LLMs explica essas etapas e quais medições devem ser separadas.

Ao escolher uma API, compare o comportamento observado nas suas solicitações. Um par de contagens de parâmetros não revela quanto o provedor agrupa o tráfego em lotes, o tamanho da fila ou se o hardware é adequado ao modelo.

As escolhas de infraestrutura que afetam o negócio

MoE transfere parte da demanda de infraestrutura: sai um pouco do processamento repetido, entra a necessidade de armazenar e coordenar um modelo maior. A questão operacional é se essa troca funciona para a sua carga de trabalho.

Memória: todo especialista precisa ficar em algum lugar

Estar inativo para este token não significa poder ser removido da implantação. Na configuração usual, com os pesos residentes em memória, o conjunto completo permanece carregado no sistema de inferência, embora cada token use apenas um subconjunto. A explicação do PyTorch deixa esse requisito de memória explícito.

Um cálculo inicial útil é armazenamento dos pesos ≈ total de parâmetros × bytes por parâmetro armazenado. É apenas um ponto de partida: a precisão pode variar entre tensores, e metadados dos arquivos, preenchimento, réplicas e alocações durante a execução aumentam o espaço ocupado.

Os pesos não são todo o orçamento de memória. O KV cache armazena chaves e valores de atenção de tokens anteriores para que possam ser reutilizados. Um assistente de documentos com conversas mais longas ou mais solicitações simultâneas precisa de memória adicional para o estado dessas solicitações. Veja a explicação sobre KV cache para entender essa restrição separadamente.

A quantização, que armazena pesos com precisão numérica reduzida, pode diminuir o espaço ocupado por eles. Ela não transforma parâmetros totais em ativos nem elimina a necessidade de validar a qualidade das saídas. O guia de quantização de LLMs trata da escolha de formato e precisão; o mecanismo está documentado na visão geral de quantização da Hugging Face.

Vazão: conseguir carregar o modelo é só o primeiro requisito

Um modelo que carrega sem erros ainda pode ficar abaixo da meta do serviço. O paralelismo de especialistas distribui os especialistas entre dispositivos, permitindo acomodar um modelo maior que a memória de um único dispositivo. Isso também exige levar as representações dos tokens até os dispositivos que hospedam os especialistas escolhidos e combinar os resultados.

Essas transferências fazem das interconexões, os enlaces entre dispositivos, uma parte do projeto de inferência. Capacidade distribuída por máquinas com conexões ruins não equivale à mesma capacidade em um sistema bem conectado. Isso decorre diretamente do padrão de comunicação descrito na implementação de paralelismo de especialistas do PyTorch.

Para um assistente interno com pouco tráfego, a preocupação prática é manter capacidade fixa subutilizada. Para um serviço de processamento em lote muito demandado, pode ser garantir trabalho suficiente para alimentar o processamento dos especialistas. A contagem ativa, sozinha, não determina nenhum desses resultados.

Roteamento: especialistas muito requisitados podem virar gargalos

Um roteador treinado não garante uma distribuição perfeitamente uniforme do uso de hardware. A análise de roteamento do Mixtral feita pela NVIDIA constatou que tráfego concentrado em um assunto poderia gerar cargas desiguais entre especialistas. Alguns processos de execução terminam cedo, enquanto outros continuam ocupados.

Por isso, uma demonstração com tarefas variadas não basta para avaliar um serviço que processa principalmente contratos ou código. Teste essa concentração de solicitações, incluindo as mais lentas, em vez de se apoiar apenas na média.

O software de inferência pode compensar esse desequilíbrio, mas a compensação também ocupa espaço. O vLLM documenta o balanceamento de carga com especialistas redundantes e alerta que essas cópias extras consomem memória de GPU que poderia abrigar o KV cache. Se os pesos do modelo couberem no limite da memória, pode faltar espaço para a configuração que os executa bem.

Como escolher um LLM MoE: API ou hospedagem própria?

Quem desenvolve com uma API deve avaliar o serviço entregue; quem hospeda o modelo também precisa avaliar a implantação completa. Ambos precisam de saídas aceitáveis, mas apenas um deles gerencia diretamente onde ficam os especialistas.

Para quem desenvolve usando uma API, a arquitetura ajuda a entender o modelo, mas não justifica uma troca por si só. Avalie tarefas representativas, cumprimento de instruções, uso de ferramentas quando relevante, tempo até o primeiro token e tempo de conclusão com a quantidade esperada de solicitações simultâneas. Registre tentativas malsucedidas e repetições. A eficiência de inferência do provedor não determina sua conta nem o trabalho necessário para chegar a um resultado aceitável.

Para quem opera com hospedagem própria, comece pelo checkpoint exato disponível para download, sua licença e uma implementação de inferência compatível. Depois, avalie a precisão dos pesos, a memória do modelo completo, a margem para cache, as conexões entre dispositivos e o desempenho sob carga. Nosso guia de modelos com pesos abertos separa o acesso aos arquivos dos direitos e das responsabilidades de operá-los.

Para quem compra e responde por um compromisso de serviço, a pergunta é se o candidato conclui trabalho aprovado dentro da meta de tempo de resposta, na infraestrutura planejada. “Trilhões no total, bilhões ativos” descreve uma arquitetura, não uma garantia de nível de serviço.

1. 1

   Defina a carga de trabalho antes de comparar modelos

   Use solicitações representativas, com critérios claros de aceitação. Separe as tarefas interativas das que entram em fila e inclua as entradas longas e os assuntos recorrentes que sua aplicação realmente processa.

2. 2

   Avalie a forma de operação que pretende usar

   Para uma API, teste o provedor e o endpoint pretendidos. Na hospedagem própria, registre o checkpoint exato, a precisão, o ambiente de execução e o hardware. Outra forma de servir o modelo produz outro resultado operacional.

3. 3

   Teste capacidade e qualidade juntas

   Aumente o trabalho simultâneo enquanto verifica uso de memória, tempo de espera, qualidade das saídas e falhas. Uma resposta isolada rápida não comprova uma vazão útil, e uma vazão alta não comprova latência aceitável para uso interativo.

4. 4

   Troque de modelo quando os resultados justificarem

   Adote o candidato quando houver melhora tanto no trabalho aprovado quanto no atendimento aos requisitos operacionais. Mantenha o modelo atual se esses ganhos não aparecerem. Adie a hospedagem própria enquanto os arquivos de pesos necessários ou uma forma de implantação compatível ainda estiverem indisponíveis.

Para quem já usa uma API que atende aos requisitos de qualidade e tempo de resposta, o rótulo da arquitetura não muda a decisão. Já quem dimensionou uma hospedagem com base nos parâmetros ativos deve rever esse plano agora.

Onde estão os exageros sobre MoE?

O exagero é afirmar que a esparsidade entrega todos os benefícios de um modelo enorme com todas as características operacionais de um modelo pequeno. Ela oferece uma separação útil entre capacidade e processamento, mas há condições.

Não há garantia de que os especialistas dominem áreas específicas. A análise do Mixtral feita pela Mistral encontrou padrões de roteamento que não separam claramente as áreas acadêmicas. Um especialista treinado não é um profissional credenciado, e a escolha do roteador não explica por que uma resposta está correta.

Mais parâmetros totais não comprovam respostas melhores. Uma proporção menor de parâmetros ativos também não comprova que um modelo seja melhor. Treinamento, arquitetura e tarefa importam. A tabela acima explica os tamanhos informados; ela não pretende ser um ranking de qualidade.

Uma proporção ativa menor não equivale ao mesmo desconto ou ganho de velocidade. Sozinha, ela não diz nada sobre preços do provedor, filas, transferências pela rede ou quantos tokens sua tarefa precisa gerar.

O artigo sobre mixture of experts por trás da ideia

O artigo de Shazeer e seus colegas, publicado em 2017, formalizou uma influente camada MoE com ativação esparsa que aumentava a capacidade do modelo sem elevar o processamento na mesma proporção. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer é a referência primária desse mecanismo. Sua discussão sobre balanceamento de carga e desempenho distribuído também lembra que as escolhas operacionais faziam parte da ideia desde o início.

Dúvidas de quem desenvolve com MoE

O que é mistura de especialistas em um LLM?

É uma forma de construir um grande modelo de linguagem com várias redes internas de especialistas e um roteador treinado. Em uma MoE esparsa, cada token usa apenas os especialistas selecionados em cada camada MoE. A aplicação continua chamando um único modelo.

O GPT-4 usa mistura de especialistas?

O relatório técnico do GPT-4 não divulga mais detalhes da arquitetura, incluindo o tamanho do modelo. Ele não apresenta uma divisão de parâmetros MoE confirmada pelo fabricante, portanto contagens que circulam como rumores não devem ser usadas como fatos para planejar uma implantação.

Como funciona o fine-tuning de modelos MoE?

O fine-tuning adapta o comportamento aprendido pelo modelo; ele não elimina os requisitos de hospedagem de todos os seus pesos. Avalie a qualidade do modelo adaptado na tarefa e o comportamento do roteamento com tráfego representativo. O guia de MoE da Hugging Face discute as diferenças nos cuidados com sobreajuste e balanceamento.

O próximo passo para decidir sua implantação

Na segunda-feira, anexe uma nota de operação a cada modelo da sua lista de candidatos. Registre as contagens totais e ativas informadas pelo fabricante, a fonte e o checkpoint exato ou endpoint de API. Para acesso via serviço hospedado, acrescente os resultados das tarefas e as medições de latência. Para hospedagem própria, inclua o espaço ocupado por todos os pesos, a reserva para cache e o desempenho com o tráfego esperado. Essa nota é mais útil do que ordenar candidatos pelo maior número anunciado.

Para receber explicações práticas sobre a infraestrutura por trás dos produtos de IA, assine a newsletter.