A Ai2 lançou o Olmo-core 3 em 1º de outubro como uma estrutura aberta de treinamento para modelos de linguagem de mistura de especialistas (MoE). O resultado mais útil para um engenheiro de sistemas é mais restrito do que o título de trilhões de parâmetros: a Ai2 publicou código, configurações de referência e medições delimitadas em GPU para que equipes decidam se vale testar esse stack em um cluster específico.

Um MoE encaminha cada token para um subconjunto de suas redes de especialistas. Isso limita o cálculo por token, mas todo o conjunto de especialistas e seu estado do otimizador ainda precisa caber nas GPUs. Mover tokens até os especialistas também leva tempo. O Olmo-core 3 muda como a Ai2 lida com essas duas restrições: o sistema baseado em DDP mantém os especialistas residentes nas GPUs e encaminha os dados até eles; a implementação anterior baseada em FSDP reunia e repartia pesos repetidamente para microbatches. O novo stack combina paralelismo de especialistas e de pipeline, estado distribuído do otimizador, roteamento residente na GPU e cálculo agrupado de especialistas. A Ai2 também oferece MXFP8 para operações selecionadas. São escolhas de projeto que uma equipe pode examinar e configurar, não uma promessa da mesma velocidade em outro cluster.

A grande mudança

O Olmo-core 3 disponibiliza a maquinaria de treinamento MoE de grande escala da Ai2 como código Apache 2.0 e scripts de referência. Os testes da Ai2 mostram vazão maior que a do stack anterior em uma comparação específica com oito B300 e mostram que uma configuração de 1,2 trilhão de parâmetros com roteamento aleatório pode rodar em 512 B300. Eles não estabelecem a qualidade de um modelo treinado desse porte nem a velocidade da carga de trabalho do leitor. O ganho prático é um ponto de partida verificável para reproduzir configurações, medir gargalos locais e decidir quais ajustes de paralelismo e precisão justificam uma execução cara de treinamento.

Três números, três denominadores

A comparação preliminar da Ai2 para um MoE de 47 bilhões de parâmetros rodou em oito GPUs Nvidia B300. O novo stack processou 52.000 tokens por segundo por GPU, contra 19.400 na implementação anterior baseada em FSDP. A razão é 52.000 ÷ 19.400 = 2,68, arredondada para 2,7 vezes. É uma comparação interna entre o stack antigo e o novo stack , não uma medição contra o Megatron-Core nem uma ablação limpa só de DDP. A comparação mais próxima nos exemplos marcados, DDP+paralelismo de especialistas contra FSDP/HSDP, mantém a forma do modelo e a janela de medição, mas também altera roteador, kernels esparsos, otimizador e outros detalhes.

O resultado de “menos de 5%” responde a outra pergunta. A Ai2 aumentou o conjunto de 8 para 128 especialistas, escolhendo quatro por token. A capacidade total subiu de 4,6 bilhões para 47 bilhões de parâmetros, enquanto os parâmetros ativos por token permaneceram perto de 3,2 bilhões. A vazão caiu menos de 5% entre essas configurações do conjunto de especialistas. Isso não significa que o novo stack seja apenas 5% mais lento que o antigo nem que adicionar 16 vezes mais especialistas não tenha custo em toda configuração. O lançamento não traz informação suficiente para converter esse percentual em custo em dólares para o leitor.

O resultado de escala tem um terceiro denominador: a Ai2 relata um máximo observado de 858 TFLOP/s por GPU para uma configuração com 1,2 trilhão de parâmetros no total e 58,36 bilhões ativos por token, em 512 GPUs B300. A tabela de referência v3.0.0 identifica essa linha Ultra-128E como roteamento aleatório, MXFP8 e recomputação por camada. O roteamento aleatório mede o caminho do sistema sem testar se um roteador aprendido produz um bom modelo. Uma configuração de 2,38 trilhões de parâmetros usou DeepEP v2 em um teste curto de capacidade. A Ai2 a descreve como verificação de escala, não treinamento sustentado. Nenhum número representa a precisão de um modelo treinado, a qualidade de uma saída útil ou prova de economia estável em um treinamento completo.

A Ai2 também relata uma comparação controlada com quatro B300: contra BF16, MXFP8 elevou a vazão de treinamento ponta a ponta em cerca de 21% e reduziu a memória ativa de pico de 103 GiB para 95 GiB, com o trabalho distribuído igualmente entre especialistas. O resultado se limita às opções de precisão e à carga testadas. Não pode ser somado ao número de 2,7 vezes como se as duas medições tivessem a mesma base.

O que um engenheiro pode realmente testar

A versão do repositório de 1º de outubro v3.0.0 está pública sob Apache 2.0. O README recomenda instalar primeiro o PyTorch para o sistema operacional e hardware de destino e, depois, instalar ai2-olmo-core pelo PyPI ou usar o repositório clonado para desenvolvimento. A versão marcada src/examples/olmo_ddp/README.md associa os pontos de operação relatados aos scripts e documenta torchrun como caminho genérico de inicialização. Os scripts de produção pressupõem oito GPUs por nó e definem o número de nós em REF_NUM_NODES. São exemplos para quem já tem um ambiente de GPU distribuída, não uma forma de reproduzir os resultados B300 da Ai2 com um comando.

Os scripts do relatório têm requisitos de acesso relevantes. O README lista o extra beaker, FlashAttention 4, um /workspace gravável e acesso de leitura ao conjunto de dados da Ai2 s3://ai2-llm; o caminho DeepEP v2 também requer um checkout do DeepEP. O README principal da Ai2 diz que as imagens Docker públicas incluem dependências, mas não o pacote Olmo-core, e alerta que outro hardware ou versões de driver/CUDA podem exigir uma imagem adaptada. A v3.0.0 eleva o mínimo suportado do PyTorch para 2.10.0. Revisamos esses documentos e a tabela de referência marcada; a BIG CHANGE não instalou o pacote, obteve acesso ao conjunto de dados, reservou GPUs nem executou treinamento.

Para uma avaliação local, comece pela linha de referência marcada mais próxima do tamanho de modelo desejado e do hardware disponível; depois contabilize cada dependência e caminho de dados inacessível antes de reservar computação. Compare tokens por segundo por GPU com o mesmo comprimento de sequência, lote, roteamento, precisão e janela de medição; monitore separadamente memória de pico e comportamento de checkpoints. As linhas de produção publicadas usam sequência de 8.192, roteamento top-four e um especialista compartilhado. Tiny e Small têm scripts auxiliares com roteamento aprendido, enquanto as linhas maiores do título usam roteamento aleatório. A distribuição de dados do roteamento aprendido de uma equipe pode mudar o equilíbrio de comunicação e a vazão, então um piloto representativo continua necessário antes de projetar uma execução completa.

O limite de custo é físico além de ser de software. A comparação destacada de oito GPUs requer oito B300; o maior resultado de vazão usou 512. A Ai2 não fornece no lançamento um preço geral de aluguel por hora ou orçamento completo de treinamento. A licença Apache 2.0 elimina a taxa de licença do software para esse código, mas não fornece GPUs, drivers compatíveis, o acesso a dados citado nem tempo de operação. O README de referência também diz que a medição de sobreposição de dois lotes no relatório usou um branch anterior à integração e não pode ser reproduzida pelos scripts marcados.

O sistema aberto é útil porque suas afirmações podem ser verificadas contra configurações reais. O lançamento da Ai2 resume casos em que uma pontuação aparentemente melhor de equilíbrio de roteamento escondia trabalho menos equilibrado e em que sobrepor comunicação e cálculo atrasava o treinamento. Esses achados tornam o plano de medição local mais importante: um kernel rápido ou uma métrica isolada favorável não é resultado de treinamento ponta a ponta. A Ai2 diz que a próxima geração Olmo usará arquitetura MoE; este lançamento oferece o stack de treinamento e medições de sistema antes de qualquer avaliação de qualidade desse modelo futuro.

Fontes e leitura adicional

  • Lançamento da Ai2 de 1º de outubro explica a arquitetura e informa números delimitados de vazão, memória e escala. São medições da Ai2; a BIG CHANGE não as reproduziu.
  • Lançamento Olmo-core v3.0.0 estabelece a versão marcada, data de 1º de outubro, mínimo do PyTorch e mudanças no código. README do repositório documenta instalação, dependências opcionais e ressalvas da imagem Docker.
  • Guia marcado do script de referência MoE associa configurações do relatório à quantidade de GPUs, roteamento e precisão, e explica os limites da comparação entre stack antigo e novo. Relatório técnico é o relato principal dos experimentos de sistema; o PDF não foi obtido em nosso ambiente de pesquisa, então as afirmações detalhadas se baseiam no lançamento acessível da Ai2 e nos scripts marcados.