AISubHub/Notícias de IA
Desenvolvedores

Análise aprofundada · Cerca de 4 min de leitura

Laplace 3B no Trainium2: estado fixo não é memória perfeita

O relato de i14 e AWS distingue estado recorrente, comunicação do otimizador e compilação realista.

Publicado aqui
Data da fonte
Fonte verificada

Um artigo da AWS de 20 de outubro descreve o treinamento e a execução do Laplace 3B da i14 no Trainium2 com PyTorch nativo. O diferencial é manter estado recorrente fixo em vez de uma cache KV crescente. É preciso entender qual restrição muda e quais questões de qualidade e implantação continuam abertas.

Ouça as notícias

Ouça este artigo ou continue ouvindo as notícias.

Laplace 3B no Trainium2: estado fixo não é memória perfeita

Preparando a leitura…

Voz do dispositivo

O navegador ou dispositivo processa a voz. O AISubHub não envia o texto a uma API de áudio. As vozes e a reprodução com a tela bloqueada variam conforme o dispositivo.

Ao continuar, uma frase curta pode se repetir.

Resumo

  • O relato informa 29.5 MB de estado por sequência e 11544 tokens de saída por segundo agregados entre 1280 sequências numa trn2.48xlarge. Não são memória total nem taxa por usuário.
  • A receita prevê 100 bilhões de tokens; os resultados chegam a aproximadamente 44 bilhões. Comunicação 24 vezes menor e treinamento 1.63 vez mais rápido são medidas distintas.

Estado constante é história comprimida

Na inferência com softmax, chaves e valores normalmente crescem com o contexto. O Laplace 3B atualiza uma matriz recorrente por Gated Linear Attention e comprime o passado em 29.5 MB por sequência. A atenção no treinamento passa de escala quadrática para linear no comprimento. Isso não elimina pesos, ativações, entrada nem outros buffers. A compressão também muda quais informações são recuperáveis. A própria fonte pede avaliação de recuperação por carga: uma conversa caber na memória não prova que todos os detalhes antigos permaneçam acessíveis com a precisão exigida.

Mapeamento e comunicação explicam ganhos diferentes

O grupo substituiu um kernel Triton específico de GPU por operadores PyTorch. Dezesseis blocos de 128 tokens correspondem às 128 partições do buffer; o relato atribui 14% de ganho a esse alinhamento. O problema do Muon era outro: gradientes fragmentados precisavam de informação entre fragmentos. Duas operações all-to-all distribuem matrizes completas e devolvem os resultados. O tráfego por rank cai de 10.87 GB para 0.45 GB e a taxa sobe de 73378 para 119934 tokens por segundo. Reduzir comunicação 24 vezes não significa acelerar treinamento 24 vezes.

Uma receita planejada não foi toda executada

A configuração tem 3.028 bilhões de parâmetros, 24 camadas e receita FineWeb-Edu de 100 bilhões de tokens. Os resultados apresentados terminam no passo 84210, cerca de 44 bilhões, não nos 190735 passos previstos. Os aproximadamente 120000 tokens por segundo e a queda de loss descrevem esse intervalo. Estabilidade é evidência útil sobre implementação, mas não substitui avaliações de aplicação ou demonstra superioridade sobre todos os transformers e memória factual. Nossa leitura separa o marco de engenharia da utilidade que precisa ser comprovada na tarefa pretendida.

A taxa agregada pertence a uma configuração

A inferência utiliza uma trn2.48xlarge com 64 NeuronCores lógicos, 20 sequências por réplica e 1280 ao todo. Os 11544 tokens de saída por segundo são compartilhados nessa carga. O estado cerca de 82 vezes menor é comparado a uma cache KV equivalente em 8192 tokens, não à fatura inteira. Aumentar entradas de 2048 para 8192 tokens acrescentou 0.5% ao custo por token de saída nesse experimento. Processamento da entrada, alocação, qualidade e utilização continuam relevantes para o orçamento real.

Tráfego variável revela o custo de compilar

Uma nova largura de lote de decodificação exigiu inicialmente cerca de 11 segundos de compilação. Esses passos eram 1.1% do total, mas consumiram 47.5% do tempo de decodificação. Completar entradas até larguras fixas removeu esse custo; o ganho com chegadas escalonadas diferiu do observado em lotes fixos. A fonte alerta ainda que reassociação BF16 pode produzir pequenas diferenças entre compilado e eager, recomendando eager quando a reprodução exata importa. Um piloto deve medir chegadas reais, caudas de latência, tolerância numérica e recuperação. São nossas recomendações, não economias ou serviço implantado pelo AISubHub.

Por que importa

Nossa análise: estado fixo pode facilitar a capacidade de sessões longas, mas exige testes de recuperação de informações e chegadas reais. Arquitetura e execução precisam ser avaliadas juntas.

Limites e disponibilidade

Lemos todo o texto e as legendas, sem executar código. Resultados são do projeto i14/AWS, não nossos. O artigo não estabelece preço de assinatura, hardware gratuito, superioridade universal ou garantia operacional. TorchNeuron Native foi usado em beta.

Fontes e evidências

AWS · i14 Laplace 3B engineering report

Data da fonte: · Fonte verificada:

Conteúdo editorial com apoio de IA, verificado em fontes primárias. Alegações dos fornecedores são atribuídas; inclusão não é recomendação.