O cenário competitivo dos chips de IA está passando por mudanças profundas. A OpenAI lançou o chip Jalapeño, focado em inferência de LLMs; a NVIDIA combinou GPUs com LPUs da Groq para realizar computação híbrida; e o Google dividiu treinamento e inferência em dois chips distintos: TPU 8t e TPU 8i. Essas três abordagens refletem as diferentes necessidades de recursos de hardware para treinamento e inferência: o treinamento prioriza cálculos matriciais e interconexões em larga escala, enquanto a inferência exige maior largura de banda HBM, maior SRAM e caminhos de rede mais curtos. À medida que a lacuna entre as configurações de chips para essas duas cargas de trabalho aumenta, os FLOPS deixam de ser o único critério de avaliação, e o custo por token surge como o novo parâmetro de competição na hardware de IA.

Autor e fonte do artigo: Leifeng.com

O custo do token torna-se um novo ponto de referência na competição de hardware de grandes modelos

Inteligência embodiada invade a cozinha cheia de fumaça

A vida de um robô trabalhador sob um milhão de visitas

Ex-vice-president da Covariant AI, Zhoupu Shuzhong diretamente caracterizou o papel do LPU como preencher a lacuna da Vera Rubin na região de Decode de baixa latência.

O design do chip da Groq também gira quase inteiramente em torno disso. Um rack LPX contém 256 LPU, somando apenas 128 GB de SRAM, uma capacidade que não pode ser comparada em escala com o HBM nos racks de GPU, mas a largura de banda agregada do SRAM pode atingir 40 PB/s.

Este design valoriza principalmente a "proximidade". O HBM pode armazenar muitos estados de modelo, mas está mais distante das unidades de cálculo; o SRAM é caro e difícil de escalar em capacidade, mas os dados estão dentro do chip, proporcionando largura de banda extremamente alta e baixa latência de acesso.

Cada etapa do cálculo é limitada, e os dados são frequentemente recuperados; colocar os dados mais próximos da ALU resultará em uma melhoria diretamente refletida no tempo de espera do próximo Token.

Groq também reduziu ainda mais o controle de hardware dinâmico. O LPU é uma arquitetura de execução determinística, na qual o agendamento de instruções é principalmente feito antecipadamente pelo software. Cada chip atua simultaneamente como processador e roteador, e o compilador agenda conjuntamente os recursos de computação e os recursos de rede, eliminando até mesmo mecanismos tradicionais como controle de fluxo de hardware e canais virtuais.

O custo também é evidente: essa arquitetura não é tão versátil quanto a GPU, e o SRAM on-chip não consegue armazenar o estado completo de modelos grandes. Por isso, a NVIDIA não fez o Groq 3 executar o modelo inteiro de forma independente, mas sim criou um sistema híbrido mais complexo.

A pré-preenchimento é realizado na GPU, a maioria do Decode é realizada no LPU; a Attention no Decode pode retornar à GPU. A GPU e o LPU mantêm seus próprios KV Cache separadamente, trocando principalmente Tokens de rascunho e sobrepondo cálculo e comunicação por meio de micro-batch. Como o LPU é um domínio síncrono, enquanto a GPU e o KV Cache externo pertencem a um sistema assíncrono, a NVIDIA até adicionou FPGA como ponte assíncrona entre os dois.

Essa estrutura ilustra bem até que ponto a especialização de chips de IA chegou. Ela não separa apenas “chips de treinamento” e “chips de inferência”, mas também diferentes partes de uma única operação de Decode podem ser executadas em arquiteturas distintas.

No entanto, os dados apresentados pela NVIDIA também delimitam os limites deste caminho: quando o negócio busca apenas吞吐 geral e pode aceitar latência mais alta, o Rubin GPU ainda é muito eficiente; à medida que a exigência de velocidade por token de usuário único aumenta, o LPX começa a mostrar suas vantagens, e após o uso de mais LPU, a eficiência geral de吞吐 também diminui.

Então, o surgimento do Groq 3 não significa que as GPUs foram eliminadas para inferência. Ele demonstra outra coisa: é difícil para a mesma GPU dominar simultaneamente os extremos de alta taxa de transferência e baixíssima latência; fazer com que dois tipos de hardware operem em suas faixas mais adequadas permite ao sistema ampliar ainda mais a curva de desempenho.

Já o Google colocou essa abertura em um nível mais alto.

Treinamento e inferência, com duas receitas de chips

Google lançou simultaneamente o TPU 8t e o TPU 8i nesta geração TPU 8,t voltado para treinamento,i voltado para inferência. A lógica por trás dessa divisão está diretamente incorporada na configuração de memória do chip.

Hot Chips em demonstração ao vivo, o TPU 8t usa 6 conjuntos de HBM, enquanto o TPU 8i usa 8 conjuntos. A Google explicou que a inferência requer mais HBM por unidade de cálculo, além de uma proporção maior de SRAM; portanto, o 8i alocou mais recursos para SRAM, capacidade de memória e largura de banda.

Essa diferença merece reflexão. Se os chips de IA estivessem apenas comparando capacidade matricial, não haveria razão para a versão de inferência gastar tanta área de chip e recursos de encapsulamento em memória. O design do TPU 8i indica que o gargalo observado pelo Google já se moveu para o fornecimento de dados.

Durante o treinamento, um grande batch distribui o custo de leitura dos pesos por muitos tokens; durante a decodificação, cada token gerado é muito pouco, mas os pesos e o KV Cache ainda são acessados com frequência. Assim, a quantidade de largura de banda HBM necessária por unidade de FLOPS difere entre esses dois tipos de tarefas.

Google até levou essa diferença para a topologia da rede. O 3D Torus anteriormente comum nos TPU é mais adequado para treinamento, enfatizando o throughput total em clusters em grande escala. O TPU 8i suporta BoardFly, com caminhos de rede mais curtos: o limite de caminhos do BoardFly é de 7 hops, enquanto o 3D Torus alcança 16 hops.

Para treinamento, após algumas saltos adicionais de rede, ainda há uma grande quantidade de cálculo matricial, o que permite amortecer o tempo de comunicação. A janela de cálculo para cada etapa de Decode é curta, e a latência da rede em poucos saltos容易 cair diretamente dentro do intervalo entre tokens.

O MoE torna esse problema ainda mais evidente. O MoE permite que um Token ative apenas uma parte dos Experts, o que é economicamente vantajoso em termos de cálculo, mas o Router envia os Tokens para diferentes Experts. Quando esses Experts estão distribuídos em chips diferentes, a redução no cálculo é acompanhada por um aumento na comunicação All-to-All.

Portanto, o TPU 8i também incorporou o Collective Acceleration Engine, que realiza certas operações coletivas diretamente no I/O Die, próximo à interface de rede. Os dados não precisam mais ser transferidos primeiro para o Compute Die e depois processados através do HBM, economizando parte da movimentação interna de dados no chip.

A alocação de recursos da versão de treinamento do TPU 8t está claramente inclinada para o outro lado. O treinamento exige grande quantidade de FLOPS e também um enorme domínio de Scale-Up para sincronizar parâmetros e gradientes. O Superpod do TPU 8t pode ser expandido para 9600 chips, com cerca de 2 PB de HBM compartilhado e 121 EFLOPS FP4 de capacidade de computação agregada, e o Google introduziu a rede Virgo para criar um sistema dedicado para conectar treinamentos em maior escala.

O Google também mencionou um problema prático de design de chip: dark silicon.

A área do chip e o orçamento de consumo de energia são limitados. Se a mesma unidade de chip for preenchida simultaneamente com os grandes recursos de cálculo matricial necessários para treinamento, além de mais SRAM, HBM e rede de baixa latência necessários para inferência, em determinado tipo de carga de trabalho, sempre haverá parte dos circuitos ociosos por longos períodos.

Como as duas tarefas já exigem proporções diferentes de recursos, fazer dois chips separados é mais limpo.

De FLOPS para economia de tokens

Colocando as três rotas juntas, as diferenças são realmente claras.

OpenAI faz Jalapeño, especializando o chip até o nível de inferência de LLM, mas mantendo o agendamento flexível do Prefill e Decode em hardware homogêneo; NVIDIA continua dividindo para baixo, fazendo GPU e Groq LPU compartilharem diferentes estágios de uma única inferência; Google corta para cima, transformando treinamento e inferência diretamente em duas TPU.

Por trás dessas rotas não há novos princípios de cálculo misteriosos; o que muda é a proporção de recursos. O treinamento busca alocar mais transistores para cálculo matricial e interconexão em larga escala, pois lotes maiores distribuem o custo de transferência de dados; a inferência de baixa latência exige maior largura de banda HBM, maior SRAM, melhor localidade de KV Cache e caminhos de rede mais curtos, pois muito tempo é gasto esperando por dados.

Quando as "receitas de chip" necessárias para os dois tipos de carga se distanciam cada vez mais, o uso de um único chip universal para atendê-los resultará em perdas de eficiência cada vez mais evidentes.

É por isso que os números centrais nesta rodada de competição de hardware estão mudando. FLOPS ainda são importantes, mas ao lado começam a aparecer Tokens/s/user, TBT, TTFT, Tokens/kW, largura de banda HBM e latência de rede.

Eles descrevem na verdade a mesma coisa: a capacidade de mineração já está lá, o sistema consegue continuar alimentando os dados e enviando os Tokens gerados o mais rápido possível.

OpenAI, NVIDIA e Google ainda não escolheram a mesma linha divisória; a linha que realmente continuará a mudar provavelmente será sobre onde traçá-la.

Treinamento e inferência podem ser separados, Prefill e Decode podem ser separados, e a atenção interna ao Decode e outros cálculos também podem ser further divididos. Quanto mais fina for a divisão, mais fácil é melhorar a eficiência individual, mas o agendamento de recursos, a transferência de KV Cache e a comunicação entre hardware se tornam mais complexos.

Portanto, o desafio da próxima fase da competição em chips de IA talvez já não seja apenas criar um chip mais poderoso.

O mais difícil é decidir: quais tarefas valem a pena dedicar um chip específico e quais tarefas continuarão no mesmo conjunto de hardware, para que o custo total de Token do sistema seja menor.