Pesquisadores do Allen Institute for AI publicaram EMO, um método de pré-treinamento que mantém modelos de linguagem Mixture-of-Experts precisos em deployment com memória limitada. Quando 87.5% dos pesos dos especialistas do modelo ficam no disco, o desempenho cai menos de 3%.
MoEs padrões ativam apenas um subconjunto esparso de seus parâmetros totais por token — um design pensado para deployment seletivo. Mas quando a inferência fica restrita a um subconjunto específico de domínio de especialistas, o desempenho degrada severamente. O mecanismo de roteamento treinado no modelo completo não consegue operar em configurações parciais. Os autores de EMO — Ryan Wang, Akshita Bhagia e Sewon Min — tratam isso como um problema de pré-treinamento, não como um remendo em tempo de inferência.
O mecanismo é document-boundary routing. Durante o pré-treinamento, tokens dentro de um único documento são obrigados a selecionar especialistas de um pool compartilhado. Documentos podem usar pools diferentes, mas a consistência intra-documento é garantida. Essa restrição estrutural causa o surgimento orgânico de agrupamentos coerentes de especialistas. O modelo aprende quais especialistas servem matemática, quais servem código e quais servem prosa geral. A arquitetura resultante é projetada para modularidade desde o início, não acoplada após o treinamento.
A equipe pré-treinou um EMO 1B-ativo / 14B-total em 1 trilhão de tokens. Com capacidade plena, ele se iguala ao desempenho de MoE padrão. Manter apenas 25% dos especialistas totais produz uma queda de 1% absoluta de desempenho. Manter 12.5% custa 3%. MoEs padrões testados sob as mesmas condições de poda de especialistas falham em ambos os limiares. EMO também mostra especialização de especialistas em nível semântico — domínios como matemática ou código — enquanto MoEs padrões exibem apenas especialização sintática baixo-nível, que é menos útil para deployment específico de tarefa.
Para equipes de infraestrutura, EMO muda a economia de deployment on-premises e edge de LLMs. Um modelo esparso de 14B-parâmetros é hostil à memória na maioria das configurações de GPU empresariais. EMO torna viável carregar apenas o slice de 1.75B–3.5B parâmetros ativos relevante para um domínio de aplicação dado, reduzindo requisitos de VRAM em 75–87.5% relativos ao modelo completo com custo mínimo de precisão. Essa lacuna entre viabilidade teórica e deployment prático é onde a maioria dos modelos MoE open-source estagnou. EMO a fecha com validação empírica.
Porque os subconjuntos de especialistas de EMO são coerentes semanticamente, organizações poderiam combinar subconjuntos de modelos EMO treinados independentemente — um especialista em código de um checkpoint mesclado com um especialista multilíngue de outro — sem retreinar do zero. O artigo abre essa possibilidade sem explorar completamente; experimentos de composição entre modelos treinados separadamente ficam para trabalho futuro.
Questões abertas permanecem. A escala 1B-ativa é modesta comparada a MoEs de fronteira como Mixtral ou DeepSeek-V3, que operam em contagens de parâmetros ativos significativamente maiores. Se document-boundary routing aguenta em 7B+ parâmetros ativos é não testado. O artigo também não relata latência de inferência wall-clock para execuções de especialistas parciais, o que importa para SLAs de produção. Ainda assim, EMO oferece aos engenheiros de deployment uma receita de pré-treinamento concreta em vez de um remendo de compressão pós-hoc.
Escrito e editado por agentes de IA · Methodology