🤖 machine learning

Compute-Optimal Is Not Cluster-Optimal: Systems-Aware Scaling for Sparse Mixture-of-Experts

Este artigo apresenta o MOSAIC, um framework de co-design consciente de sistemas que demonstra como a esparsidade ideal para modelos de Mixture-of-Experts esparsos emerge apenas ao otimizar conjuntamente a arquitetura do modelo com as restrições de hardware, em vez de ocorrer apenas por meio das tradicionais leis de escala de computação ideal.

Autores originais: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Publicado 2026-08-12

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está tentando construir o cérebro robótico definitivo e mais poderoso. No mundo da inteligência artificial, esse "cérebro" é um programa de computador massivo chamado Modelo de Linguagem de Grande Escala (LLM). Para tornar esses cérebros mais inteligentes, os cientistas descobriram uma regra simples: se você alimentá-los com mais dados e os tornar maiores, eles ficam melhores em entender o mundo. Essa regra é chamada de "lei de escala" (scaling law). Por muito tempo, a receita para construir esses cérebros era dividida em duas etapas separadas. Primeiro, um matemático calculava o tamanho perfeito para o cérebro com base em quanta capacidade de computação (chamada de "compute") estava disponível. Depois, um engenheiro diferente tentava espremer esse cérebro em um conjunto específico de chips de computador para fazê-lo rodar o mais rápido possível.

Pense nisso como planejar uma viagem de carro. A primeira etapa é decidir o quão longe você quer dirigir com base no seu orçamento de combustível. A segunda etapa é escolher o carro. Mas e se o carro que você escolheu for tão pesado e desajeitado que consome combustível em um ritmo terrível, o que significa que você não poderá realmente dirigir tão longe quanto planejou? Esse é o problema que este artigo aborda. Ele argumenta que você não pode simplesmente escolher o tamanho de um cérebro e depois se preocupar com o carro. Você tem que projetar o cérebro e o carro juntos, porque a forma do cérebro altera o quão eficientemente o carro dirige. Se você ignorar o motor do carro, pode acabar com um cérebro "perfeito" que é pesado demais para se mover, deixando você parado na linha de partida.

O Problema: O Cérebro "Perfeito" Que Não Caberá

O artigo introduz uma nova forma de pensar chamada MOSAIC (Model Optimization via Systems-Aware TraIning Co-design). Os autores, trabalhando na Amazon AGI Foundations, perceberam que a antiga maneira de fazer as coisas estava deixando dinheiro na mesa. Tradicionalmente, os pesquisadores calculariam um modelo "Computacionalmente Ótimo" (Compute-Optimal). Este é o tamanho do modelo que obtém os melhores resultados para uma quantidade fixa de poder de computação, assumindo que cada bit de potência é usado perfeitamente.

No entanto, os autores encontraram uma armadilha oculta. Eles focaram em um tipo especial de arquitetura de IA chamado Mistura de Especialistas (Mixture-of-Experts - MoE). Imagine uma biblioteca gigante onde, em vez de um único bibliotecário gigante lendo todos os livros, você tem milhares de pequenos especialistas especializados. Quando surge uma pergunta, um roteador inteligente a envia para apenas alguns desses especialistas (por exemplo, 2 de 100) para responder. Isso torna o modelo muito rápido e eficiente porque não é necessário "acordar" a biblioteca inteira para cada pergunta.

A matemática antiga sugeria que, para obter os melhores resultados, você deveria tornar a biblioteca o maior possível e acordar o menor número de especialistas possível. Em outras palavras, o modelo "perfeito" deveria ser incrivelmente esparso (com a maior parte vazia). O artigo mostra que, se você olhar apenas para a matemática bruta de "quantos cálculos precisamos?", a resposta é sempre: "Torne-o o mais esparso possível". A matemática diz que a melhor esparsidade está no limite do que é possível.

A Reviravolta: O Motor do Carro Importa

É aqui que a história muda. Os autores perceberam que, embora a matemática diga "torne-o super esparso", a realidade física dos chips de computador diz "de jeito nenhum".

Quando você tem um modelo com milhares de pequenos especialistas, o computador tem que fazer muito trabalho extra apenas para decidir quais especialistas acordar e para passar a informação entre eles. É como ter um grande edifício de escritórios onde o gerente passa o dia inteiro correndo entre as baias para entregar memorandos, deixando muito pouco tempo para o trabalho real de fato. Quanto mais esparso o modelo se torna, menos tempo o computador gasta com essas tarefas de "correr de um lado para o outro" (custos de comunicação) e menos tempo ele passa no pensamento real (cálculos).

O artigo argumenta que a antiga matemática de "Computação Ótima" era falha porque assumia que o computador poderia entregar 100% de sua potência para a parte do pensamento. Na realidade, um modelo super esparso pode receber apenas 8% do poder do computador para o pensamento real, enquanto um modelo ligeiramente mais denso pode receber 15%.

A Solução: MOSAIC

Para corrigir isso, a equipe construiu o MOSAIC. Em vez de perguntar, "Qual é o melhor modelo para uma quantidade fixa de matemática?", eles perguntaram, "Qual é o melhor modelo que podemos realmente rodar em nosso cluster específico de computadores em um tempo fixo?".

Eles combinaram duas coisas:

Uma Lei de Escala (Scaling Law): Uma previsão de quão inteligente o modelo será com base em seu tamanho e forma.
Um Modelo de Desempenho: Um simulador que prevê o quão rápido o modelo realmente rodará em hardware real, levando em conta os custos de "correr de um lado para o outro".

Quando rodaram o MOSAIC, os resultados foram surpreendentes. O modelo "perfeito" não era aquele no extremo da esparsidade. Em vez disso, o melhor modelo era uma solução de interior — um meio-termo feliz. Era esparso o suficiente para ser eficiente, mas não tão esparso que o computador ficasse sobrecarregado pelo overhead de gerenciar todos aqueles pequenos especialistas.

O Que Eles Descobriram

A equipe testou isso em hardware real usando GPUs NVIDIA B200. Eles treinaram modelos variando de 700 milhões a 18 bilhões de parâmetros ativos (e até 79 bilhões de parâmetros totais).

A Forma Antiga: Se você apenas seguisse a matemática antiga, escolheria um modelo com uma esparsidade de cerca de 0,985 (significando que 98,5% dos especialistas estão dormindo). Mas, no cluster específico deles, esse modelo seria tão lento que levaria uma eternidade para treinar e, de fato, seria menos inteligente do que um modelo ligeiramente mais denso.
O Jeito MOSAIC: O sistema encontrou que o ponto ideal era uma esparsidade de cerca de 0,96. Este modelo não era o "teórico" melhor, mas era o melhor prático. Ele rodava mais rápido, usava o poder do computador de forma mais eficiente e alcançou uma taxa de erro menor (significando que era mais inteligente) do que o melhor "teórico".

De fato, eles mostraram que o modelo que parecia melhor no papel (aquele com mais "Model FLOPs") era, na verdade, o mais lento para treinar na vida real. O modelo que venceu foi o que equilibrou a matemática com a realidade do hardware.

Por Que Isso Importa

Este artigo sugere que precisamos parar de tratar o design dos modelos de IA e o design dos computadores que os executam como etapas separadas. Você não pode apenas escolher um tamanho de modelo e esperar que os computadores deem conta dele. A forma do modelo altera o comportamento do computador.

Os autores são cuidadosos ao notar que suas descobertas são específicas para o tipo de chip de computador que usaram (NVIDIA B200s) e o software específico que construíram. Eles não encontraram uma lei universal que se aplique a todos os computadores do universo. No entanto, provaram que, para a fronteira do treinamento de IA, ignorar os "sistemas" (o hardware e como ele move os dados) leva a resultados subótimos.

Ao usar o MOSAIC, eles mostraram que o "melhor" modelo não é um ponto fixo em um gráfico, mas um alvo móvel que depende do seu orçamento de hardware específico. O modelo mais eficiente é aquele que se ajusta ao seu cluster como uma luva, não aquele que parece melhor em um pedaço de papel. Isso é uma mudança do "Computacionalmente Ótimo" (o que a matemática diz) para o "Otimizado para o Cluster" (o que o hardware pode realmente entregar).

Em suma, se você quer construir a IA mais inteligente possível, você não precisa apenas de um cérebro maior; você precisa de um cérebro que caiba no corpo onde ele vive.

Resumo Técnico: Computacionalmente Ótimo Não é Cluster-Ótimo

Definição do Problema
Os fluxos de trabalho atuais de pré-treinamento em larga escala convencionalmente separam as decisões de escalonamento algorítmico da implementação de sistemas. Uma etapa de "lei de escala" seleciona uma arquitetura de modelo e um orçamento de dados para minimizar a perda sob uma restrição fixa de computação (FLOPs), seguida por uma etapa de "sistemas" desconectada que otimiza a implementação para eficiência de hardware. Os autores argumentam que essa separação é falha para modelos esparsos de Mistura de Especialistas (MoE). Enquanto as leis de escala tradicionais otimizam para o FLOPs do Modelo ( $C_{model}$ ), elas ignoram a eficiência de sistemas da arquitetura prescrita. Duas arquiteturas com o mesmo $C_{model}$ e perda prevista podem gerar variações vastamente diferentes em throughput de treinamento devido a variações na Utilização de FLOPs do Modelo (MFU), custos de comunicação e pegadas de memória. Consequentemente, a configuração "computacionalmente ótima" derivada de um orçamento de FLOPs pode ser inviável ou subótima em um cluster de hardware específico, pois não leva em conta o computação "entregável" que um cluster pode realmente sustentar ao longo de uma janela de treinamento fixa.

Metodologia: MOSAIC
Os autores introduzem o MOSFFIC (Model Optimization via Systems-Aware Training Co-design), um framework que formula o co-design de arquitetura de modelo e sistemas como um problema de otimização único. O MOSAIC seleciona conjuntamente a arquitetura do modelo, o orçamento de tokens de treinamento e o layout de execução distribuída (estratégia de paralelismo) para minimizar a perda prevista sob um orçamento restrito pelo hardware.

O framework integra três componentes principais:

Uma Lei de Escala Conjunta de Quatro Dimensões: Os autores ajustam uma nova lei de escala para modelos esparsos de MoE que inclui o número total de parâmetros ( $N_{tot}$ ), tokens de treinamento ( $D$ ), esparsidade ( $S$ ) e um fator de divisão de especialistas ( $G$ ). $G$ é definido como a razão entre a largura densa do feed-forward e a largura de um único especialista ( $G = d_{ff}/d_{expert}$ ), capturando a granularidade dos especialistas. A lei é formulada como:
$L(N_{tot}, S, D, G) = \frac{a}{N_{tot}^\alpha} + \frac{b}{D^\beta} + \frac{c}{(1-S)^\lambda} + \frac{j}{(1-S)^\delta N_{tot}^\gamma G^\eta} + e$
Esta formulação permite que a perda seja prevista com base em escolhas geométricas discretas em vez de contagens de parâmetros abstratas.
Um Modelo de Desempenho ao Nível de Operador: Para estimar a eficiência do sistema, os autores desenvolveram um modelo de desempenho analítico que prevê o MFU e a pegada de memória para uma determinada arquitetura e layout de paralelismo. Este modelo considera:
- Custos de computação (GEMMs densos e agrupados, atenção).
- Overhead de comunicação (all-to-all para paralelismo de especialistas, bubbles de pipeline, coletivos de paralelismo de dados).
- Latência de despacho de CPU (crítica para micro-batches pequenos).
- Fatores de calibração específicos de hardware para stragglers intra-nó e sobreposição intra-nó.
  O modelo é validado contra execuções de treinamento de até 18 bilhões de parâmetros ativos, alcançando um erro percentual absoluto médio (MAPE) inferior a 15% na previsão de MFU.
Otimização Conjunta (MINLP): O MOSAIC resolve um programa não linear de inteiros mistos (MINLP) que minimiza a perda prevista sujeito à restrição de que os Model FLOPs necessários ( $C_{model}$ ) não excedam os Model FLOPs Entregáveis ( $C_{deliverable}$ ).
$C_{deliverable} = C_{peak} \times \text{MFU}(Z, P_\ell, B) \times \eta_{good}$
Aqui, $C_{peak}$ é o teto bruto do hardware, e o MFU é dependente da arquitetura. A otimização busca em uma grade discreta de geometrias realizáveis ( $Z$ ) e planos de execução ( $P_\ell$ ) para encontrar a configuração que minimiza a perda dentro das capacidades reais do cluster.

Principais Contribuições

Reformulação do Orçamento de Computação: O artigo demonstra que, para modelos esparsos de MoE, a otimização sob um orçamento fixo de $C_{model}$ leva a um comportamento de "busca de fronteira", onde a esparsidade ótima reside no limite superior do suporte de dados (ou seja, o modelo mais esparso possível). Isso ocorre porque a lei de escala prevê uma perda menor para modelos mais esparsos em FLOPs fixos, ignorando o custo de sistemas.
Co-design Consciente de Sistemas: Ao acoplar a lei de escala com um modelo de desempenho, o MOSAIC desloca o orçamento de $C_{model}$ para $C_{deliverable}$ . Isso revela que a esparsidade ótima é um ponto interior determinado pelas restrições específicas do cluster (memória, largura de banda, overhead de paralelismo), em vez da fronteira.
Validação do Modelo de Desempenho: Os autores fornecem um modelo de desempenho validado, ao nível de operador, que prevê com precisão o MFU e identifica o layout paralelo ideal (Paralelismo de Tensor, de Especialista, de Pipeline, de Dados) para MoEs esparsos, mostrando que o "melhor" layout é altamente dependente da geometria específica e do tamanho do cluster.
Validação Empírica: O framework foi testado em nós AWS p6 (GPUs NVIDIA B200) com execuções de até 250B de parâmetros totais. Os resultados confirmaram que a configuração baseada em classificação de Model FLOPs difere significativamente da classificação baseada em eficiência de computação de hardware (tempo de parede/wall-clock time).

Resultados

Ótimos de Fronteira vs. Ótimos de Interior: Sob um $C_{model}$ fixo, a perda ajustada diminui monotonicamente com o aumento da esparsidade, empurrando o ótimo para a fronteira ( $S_{max}$ ). No entanto, sob um orçamento de hardware fixo ( $C_{deliverable}$ ), a curva de perda exibe um mínimo interior. Os custos de sistema (comunicação, memória) de modelos extremamente esparsos eventualmente superam seus benefícios teóricos de perda.
Trade-off entre Perda e Throughput: Em experimentos com um orçamento de 32 nós e 20 dias, a configuração que realizou o maior número de Model FLOPs (uma geometria de especialista mais densa e grosseira) não alcançou a menor perda. Inversamente, a configuração ótima de perda (uma geometria de especialista mais esparsa e fina) sustentou um MFU menor, mas alcançou uma perda final menor porque foi a única configuração que coube dentro da restrição de FLOPs entregáveis enquanto mantinha uma trajetória de perda favorável.
Validação no Mundo Real: Execuções de pré-treinamento em estágios em clusters de 8 nós validaram o framework. A ordenação medida do MFU coincidiu com a ordenação prevista. Além disso, ao plotar a perda contra a "computação de hardware equivalente de pico" (levando em conta o MFU), a classificação das configurações inverteu-se em comparação com a classificação contra os Model FLOPs brutos, confirmando que o modelo "computacionalmente ótimo" não é o modelo "cluster-ótimo".

Significância
O artigo defende uma mudança fundamental na forma como os modelos de linguagem de fronteira são treinados: passando de estágios desconectados de "seleção de lei de escala" e "ajuste de sistemas" para um co-design de arquitetura-sistema unificado. Os autores afirmam que confiar apenas em orçamentos de Model FLOPs é insuficiente para modelos esparsos de MoE porque falha em precificar a eficiência de sistemas da arquitetura. Ao introduzir o MOSAIC, eles demonstram que a geometria ótima do modelo não é uma constante universal, mas é contingente ao cluster de hardware específico, à janela de treinamento e às restrições de paralelismo. Essa abordagem garante que a arquitetura selecionada não seja apenas teoricamente ótima em termos de perda, mas também praticável e eficiente no hardware alvo.

Mais como este