Comparativo de mercado e desempenho do acelerador de IA
A avaliação de hardware de IA para uso com modelos de linguagem grandes (LLMs) como a principal carga de trabalho exige uma abordagem consistente e neutra em relação ao fornecedor. Este guia descreve uma metodologia para comparar o desempenho de chips aceleradores de IA de diferentes fornecedores, como NVIDIA,AMD, Googlee AWS. Os princípios e a metodologia são adaptáveis a qualquer chip ou carga de trabalho de IA, mas os exemplos se concentram em uma combinação comum do setor de unidades de processamento gráfico (GPUs) da NVIDIA e unidades de processamento de tensor (TPUs) Googleexecutando cargas de trabalho de LLM.
Os modelos geralmente são otimizados para uma plataforma de hardware específica. Portanto, avaliar apenas o desempenho do modelo não é suficiente para entender os recursos do hardware. Ao avaliar chips aceleradores para LLMs, considere três dimensões principais: microbenchmarking, análise de roofline e comparativo de mercado de modelos para treinamento e inferência.
Microbenchmarking e análises de roofline são essenciais para entender os recursos e o potencial de uma determinada plataforma de acelerador. Depois que essas informações são conhecidas, o comparativo de modelos em treinamento e inferência fornece comparações reais de carga de trabalho entre chips e insights sobre se a arquitetura do modelo está otimizada para uma plataforma específica.
Dimensões de performance
Sugerimos que os avaliadores pensem na performance em três dimensões para criar uma compreensão mais abrangente de um determinado sistema acelerador:
- Microbenchmarking:ter as especificações de hardware mais altas não significa que os aplicativos podem usar essas especificações. É possível usar o microbenchmarking para avaliar como as operações de ponto flutuante por segundo (FLOPS), a memória de alta largura de banda (HBM) e a largura de banda de rede afetam o que é possível alcançar em cargas de trabalho do mundo real.
- Análise de Roofline:a utilização ideal do hardware pode ser prejudicada pela largura de banda da memória ou pela velocidade de computação. Você pode usar um modelo de roofline e a intensidade operacional (OI) de diferentes componentes do sistema para ver como o hardware e as cargas de trabalho são adequados um para o outro. Uma combinação de microbenchmarks e rooflines fornece uma avaliação teórica do que o hardware selecionado pode alcançar para diferentes tipos de cargas de trabalho.
- Comparativo de modelos:o comparativo entre cargas de trabalho de treinamento e inferência para medir tokens por segundo por chip (TPS/chip) permite avaliar o mesmo modelo em diferentes plataformas. Se os resultados iniciais forem diferentes da análise de microbenchmarking e de roofline, isso indica que é necessário mais trabalho de software para alcançar os rooflines identificados anteriormente. Por exemplo, esse trabalho pode envolver a mudança de estratégias de fragmentação ou o uso de kernels personalizados.
A comparativa de modelos é uma abordagem de snapshot no tempo para um determinado modelo, escala e plataforma. Usuários avançados também consideram tendências do setor (como arquitetura de modelo), microbenchmarking e resultados de roofline ao avaliar o desempenho.
Criação conjunta de modelo e hardware
As avaliações de desempenho precisam considerar cuidadosamente a arquitetura do modelo no contexto do hardware testado. Modelos projetados de forma eficiente geralmente são criados em conjunto para uma plataforma de hardware específica, aproveitando nuances específicas da plataforma. Consequentemente, esses modelos podem não utilizar totalmente outras plataformas ou até mesmo diferentes gerações da mesma plataforma. Por exemplo, um modelo projetado para GPUs NVIDIA Hopper pode não utilizar totalmente as GPUs AMD ou NVIDIA Blackwell.
Essa consideração é especialmente importante ao migrar entre plataformas de hardware que podem ter recursos diferentes, porque um modelo projetado para uma plataforma pode precisar de mudanças de configuração, de software ou de ambos para atingir o desempenho máximo em outra plataforma. Fazer comparativos de modelos otimizados é essencial para validar as declarações de marketing dos fornecedores sobre o desempenho "teórico máximo" e medir os resultados no mundo real. A empresa de análise independente SemiAnalysis observa: "Comparar FLOPS teóricos conta apenas parte da história. O que importa são os FLOPS efetivos, já que os números máximos quase nunca são alcançados em cargas de trabalho do mundo real".
Exemplo: o desafio gpt-oss-120B
Um erro comum no comparativo de mercado é avaliar um modelo em um hardware para o qual ele não foi projetado. O gpt-oss-120B modelo de ponderação aberta da OpenAI é um exemplo de por que a arquitetura do modelo precisa ser mapeada de perto para o silício de destino. O exemplo a seguir mostra que o design conjunto de modelos é essencial e precisa ocorrer no início do processo.
O modelo gpt-oss-120B usa uma dimensão de mecanismo de atenção de 64. Embora isso seja padrão para muitos modelos otimizados para GPU, ele cria uma incompatibilidade arquitetônica para aceleradores de TPU. TPUs como Trillium e Ironwood
são otimizadas para dimensões de matriz que são múltiplos de 256 para saturar totalmente
as unidades de multiplicação de matriz (MXUs). Como a dimensão do cabeçalho, 64, não é otimizada para TPUs, a execução de gpt-oss-120B em um sistema de TPU resulta em menos tokens por segundo (TPS) e utilização de FLOPS do modelo (MFU). O hardware desperdiça ciclos de clock e energia preenchendo o espaço restante com zeros para ajustar as grades de execução de 256x256.
Usar gpt-oss-120B como comparativo para TPUs pode sinalizar incorretamente uma capacidade de hardware ruim quando, na realidade, reflete uma incompatibilidade de arquitetura de software. Para avaliar com precisão o "teto" de um acelerador, teste-o com modelos projetados em conjunto para a geometria específica dele. Por exemplo, modelos com dimensões de cabeçalho de 128 ou 256, como o Gemma 4. É possível melhorar a performance desse modelo com kernels personalizados que evitam o padding de zeros e, em vez disso, "preenchem" a MXU, o que exige experiência e não atinge o mesmo nível de performance que nas GPUs. Também é possível mudar as dimensões do cabeçalho para otimizar mais as TPUs, mas essa mudança invalida os pesos do modelo atual, exigindo um novo treinamento.
Princípios de comparativo de mercado
Para oferecer avaliações justas e preparadas para o futuro, considere os seguintes princípios de comparativo de mercado em todos os aceleradores:
- Foco na performance por dólar:alguns fornecedores se concentram no desempenho bruto de um único chip, mas a performance por dólar no nível do sistema é mais representativa do custo total de propriedade (TCO) e do valor geral. Se o chip A for 20% mais eficiente e 50% mais caro que o chip B, os avaliadores vão reconhecer os ganhos de desempenho por dólar do chip B. Considere também o desempenho por watt como parte do custo.
- Representar cargas de trabalho de IA modernas:foco em modelos transformadores populares, clusters grandes e as estruturas mais recentes, considerando as tendências do setor. Por exemplo, a mudança do setor para modelos de mistura de especialistas (MoE) mais esparsos dificulta a otimização total de FLOPS e exige maior largura de banda de bissecção das redes.
- Garanta suporte amplo aos requisitos dos desenvolvedores:considere o desempenho, a flexibilidade e a escalonabilidade em diferentes cargas de trabalho: treinamento, ajuste e serviço em uma variedade de LLMs e outros modelos.
- Escolha modelos e ferramentas independentes de fornecedores:escolha modelos e mecanismos que funcionem em vários aceleradores para facilitar as avaliações entre eles. Por exemplo, use modelos abertos como Qwen e Gemma, além de mecanismos de inferência de código aberto que são executados em GPUs e TPUs, como o vLLM. Evite stacks do PyTorch/CUDA específicas do hardware. Para comparativos de treinamento de modelo, os frameworks específicos do fornecedor (como MaxText para TPUs e Megatron para GPUs) são mais úteis quando os modelos são mantidos constantes em todas as plataformas.
- Coprojeto de modelos:usuários experientes criam modelos em conjunto para aproveitar ao máximo a plataforma de hardware. Não espere que um modelo treinado no chip A tenha um bom desempenho "pronto para uso" no chip B.
- Considere todo o sistema de hardware:alguns aceleradores podem anunciar alta performance em uma área, como FLOPS. No entanto, gargalos em outras áreas, como largura de banda da memória, podem limitar significativamente os recursos do acelerador. Outros aspectos do sistema a serem considerados são as especificações do chip, a rede de chips e a arquitetura de expansão horizontal.
- Confiabilidade de hardware e software:interrupções durante treinamento em grande escala ou operações de inferência críticas podem ser extremamente caras. Da mesma forma, um acelerador de IA só é útil se o software executado nele for útil. Uma pilha de software madura e confiável, comprovada em escala, é essencial para maximizar o valor.
Microbenchmarks
No contexto de comparativos de mercado de aceleradores, o microbenchmarking isola componentes de hardware específicos, como núcleos de computação, memória e interconexões, para medir os limites absolutos deles sem a interferência de stacks de software complexos. Muitos fornecedores destacam "FLOPS de pico de chip único", mas a IA do mundo real é um problema de sistemas distribuídos. O microbenchmarking ajuda a entender se um chip é apenas poderoso isoladamente ou se foi projetado para a escala do data center.
Use o microbenchmarking para medir o desempenho máximo do hardware e conhecer os limites do sistema no mundo real, independente da arquitetura do modelo. O microbenchmarking é especialmente útil ao avaliar aceleradores em relação a casos de uso e arquiteturas de modelos futuros ou indeterminados.
Para fazer microbenchmarks de aceleradores de maneira eficaz, avalie o seguinte:
| Comparativo de mercado | Explicação |
|---|---|
| Utilização de multiplicação de matrizes gerais densas (GEMM) | Executa kernels GEMM altamente otimizados em várias precisões para medir a potência matemática bruta e sustentada das unidades de computação principais do acelerador. |
| Streaming de memória de alta largura de banda (HBM) | Execute microbenchmarks de largura de banda da memória para medir as velocidades sustentadas de leitura, gravação e cópia da memória integrada do acelerador. Arquiteturas que mantêm uma proporção saudável de bytes para FLOP evitam que os núcleos de computação fiquem ociosos. |
| Coletivos distribuídos (all-reduce e all-gather) | Execute testes padronizados de comunicação coletiva em milhares de chips para medir a gravidade da degradação da largura de banda e da latência da rede à medida que o cluster é escalonado. |
| Taxas de transferência de host para dispositivo (H2D) e de dispositivo para host (D2H) | Envie grandes fluxos contínuos de dados entre a memória do sistema da CPU host e o acelerador para medir as taxas de transferência no barramento PCIe ou na interconexão personalizada. |
| Limitação térmica e consumo de energia constantes | Execute um loop GEMM de utilização máxima continuamente por 48 horas enquanto monitora o consumo de energia no nível do rack para avaliar a estabilidade térmica sustentada e a eficiência energética no mundo real. |
Exemplo de comparação de microbenchmarks
Confira uma comparação ilustrativa entre dois chips. Um chip A hipotético pode parecer melhor que um chip B hipotético, mas ter um desempenho pior na prática:
| Nome do comparativo de mercado | Resultado do teste do chip A | Especificação do chip A | Proporção teste / especificação | Resultado do teste do chip B | Especificação do chip B | Proporção teste / especificação |
|---|---|---|---|---|---|---|
| Rede de chip para chip | 800 GBps | 1.000 GBps | 80,0% | 850 GBps | 900 GBps | 94,4% |
| gemm/peakTOPS | 1.800 TFLOPS | 2.500 TFLOPS | 72,0% | 1.800 TFLOPS | 2.000 TFLOPS | 90% |
| Largura de banda da memória | 6.000 GBps | 8.000 GBps | 75,0% | 6.500 GBps | 7.500 GBps | 86,7% |
| Host para dispositivo | 58 GBps/chip | 70 GBps/chip | 82,9% | 60 GBps/chip | 65 GBps/chip | 92,3% |
| Do dispositivo para o host | 55 GBps/chip | 70 GBps/chip | 78,6% | 55 GBps/chip | 65 GBps/chip | 84,6% |
Análise de linha do telhado
Uma análise de roofline (ou modelo de roofline) pode fornecer uma visualização para analisar a intensidade operacional (OI) de diferentes componentes do sistema e como designs específicos se adequam a plataformas específicas.
O throughput de um chip acelerador de IA é limitado por três fatores principais:
- Capacidade de computação:o pico de capacidade de processamento matemático do chip (FLOPS).
- Largura de banda da memória:a taxa em que os dados podem ser transferidos de ou para a memória de alta largura de banda (HBM) local do chip.
- Largura de banda da rede:a taxa em que os dados podem ser compartilhados entre vários chips usando a rede de chips durante o treinamento ou a inferência distribuídos. Por exemplo, a taxa de transferência de ICI (para TPUs) ou NVLink (para GPUs).
Para mais informações sobre rooflines, consulte Tudo sobre rooflines.
O gráfico de teto padrão consiste em dois eixos:
- Eixo X (intensidade operacional): a intensidade operacional é a proporção entre o trabalho de computação (FLOPS) e o tráfego de memória (bytes transferidos), expressa como FLOPS por byte. Ele representa a quantidade de trabalho de computação realizada para cada byte de dados buscado da memória.
- Eixo Y (performance alcançável): a performance alcançável é expressa como FLOPS por segundo. Ele representa a capacidade de processamento computacional real alcançada.
O "teto" é formado por duas linhas que se cruzam e representam os máximos de hardware:
- O teto inclinado (limitado pela memória): desempenho alcançável = largura de banda de memória máxima × intensidade operacional. Nessa linha, a performance é estritamente limitada pela velocidade com que os dados podem ser enviados às unidades de computação.
- O limite máximo (vinculado à computação): desempenho possível = capacidade máxima de computação. Nessa linha, os dados são fornecidos com rapidez suficiente para que as unidades de computação funcionem na capacidade máxima.
O ponto em que essas duas linhas se cruzam é conhecido como ponto de crista. Ele define o OI mínimo que uma carga de trabalho exige para atingir a utilização máxima do hardware.
Na imagem anterior, o Algo 1 está na parte do gráfico rotulada como "limitado pela memória" e não está utilizando totalmente as unidades de computação. Por outro lado, o Algo 2 tem um OI mais alto e está na parte do gráfico rotulada como "limitado por computação". Para otimizar o algoritmo 1, um usuário tentaria modificar o algoritmo para fazer mais cálculos com menos movimentação de dados (aumentar o OI) e mudar o desempenho para a direita, em direção ao ponto de crista.
Exemplos de cargas de trabalho de OI baixa e alta
- Baixa intensidade operacional de HBM (limitada pela memória): cargas de trabalho como operações de elemento a elemento (funções de ativação como ReLU ou GeLU), normalização de camada e decodificação autorregressiva (tamanho do lote = inferência de 1).
- Alta intensidade operacional de HBM (vinculada à computação): cargas de trabalho como GEMMs ou redes neurais convolucionais de lote grande. A multiplicação de matrizes reutiliza os dados buscados muitas vezes (multiplicando linhas por colunas). Portanto, a OI é muito alta, e as cargas de trabalho ficam abaixo do teto de computação plana.
Comparativo de mercado de modelos
O comparativo de modelos mede o desempenho real deles. Com os comparativos de treinamento e inferência, é possível comparar a performance de modelos conhecidos em um momento específico.
A tabela a seguir compara os insights que você pode receber do comparativo de modelos para cargas de trabalho de treinamento e inferência:
| Insight | Cargas de trabalho de treinamento | Cargas de trabalho de inferência |
|---|---|---|
| Escala | Geralmente, testes de maior escala (mais de 10 mil chips, até mais de 100 mil para os maiores modelos). Fornece insights sobre cargas de trabalho distribuídas, sobrecarga de comunicação e limites de rede no nível do cluster. | Geralmente testes menores (de 1 a mais de 64 chips). Fornece insights sobre como a plataforma lida com usuários simultâneos e escalonamento rápido sob carga. |
| Desempenho | Geralmente mais vinculados à computação. Mede tokens processados por segundo por chip e a utilização de FLOPS do modelo (MFU). | Sensível à latência. Mede o tempo para o primeiro token (TTFT), a latência entre tokens e o total de tokens gerados por segundo por usuário. |
| Latência | Latência de E/S e interconexão que destacam gargalos de armazenamento ao carregar grandes conjuntos de dados e latência de rede entre nós durante atualizações síncronas de gradiente. | Latência de resposta de ponta a ponta que destaca atrasos de enfileiramento, latência de endpoint e tempos de espera para o usuário. |
Comparativo de mercado de treinamento
Para determinar a eficiência real de hardware e rede, é necessário normalizar o desempenho em uma única métrica comparável entre aceleradores: tokens por segundo por chip (TPS/chip), mantendo constante uma arquitetura de modelo específica e representativa. Ao rastrear como o TPS/chip se comporta à medida que você dimensiona o tamanho de um cluster, você descobre o "tributo de escalonamento" oculto do sistema.
Para normalizar o desempenho com o custo dos aceleradores, divida ainda mais TPS/chip pelo custo de cada chip para gerar TPS/chip/$, que se torna outro ponto de comparação.
Para cada modelo comparado, avalie o seguinte:
| Comparativo de mercado | Explicação |
|---|---|
| Medir TPS/chip e TPS/chip/$ da linha de base |
Execute o modelo de destino no menor cluster viável. Registre a capacidade de processamento global de treinamento (total de tokens processados por segundo) e divida pelo número de chips para estabelecer o TPS/chip de referência. Divida pelo custo do acelerador para receber TPS/chip/$. Outra opção é observar a utilização de FLOPs do modelo (MFU) durante o treinamento para medir a proporção da capacidade de processamento observada em relação ao máximo teórico. Isso é útil para entender o quão próximo o desempenho do hardware está do benchmarking. No entanto, ele não oferece uma comparação de chip a chip tão útil quanto o TPS/chip. |
| Avaliar a degradação do escalonamento | Escalone o cluster para 256, 1024 e 4096 chips, executando exatamente o mesmo modelo. Recalcule o TPS/chip em cada escala. |
| Conta para goodput |
O TPS bruto/chip só importa se o modelo estiver aprendendo. Calcule o goodput para medir a taxa de computação útil que avança diretamente o estado de treinamento de um LLM, excluindo explicitamente o tempo e a energia desperdiçados em falhas de hardware, interrupções de rede ou recuperações de checkpoint. Ao avaliar aceleradores de IA em grande escala, o goodput oferece uma visão mais realista do retorno do investimento do que a taxa de transferência bruta teórica, já que revela a eficácia com que o hardware mantém o desempenho em clusters propensos a falhas no mundo real. |
A tabela a seguir lista os modelos recomendados para comparativo de treinamento:
| Tamanho | Arquitetura | Modelo | Justificativa |
|---|---|---|---|
| Pequeno (8B) | Dense | Llama 3.1 8B | O Llama 3 é um modelo padrão, conhecido por padrões de comparativo de mercado como o MLPerf há vários anos. |
| Médio (70B) | Dense | Llama 3.1 70B | O Llama 3 é um modelo padrão, conhecido por padrões de comparativo de mercado como o MLPerf há vários anos. |
| Grande (671B) | MoE | DeepSeek-V3 671B | O DeepSeek-V3 estabeleceu um novo padrão de tamanho e desempenho em 2025 e está bem otimizado em muitas plataformas de vários chips. |
Exemplo: normalização para performance por dólar
Considere uma comparação de comparativos de mercado entre Chip_A, Chip_B e Chip_C em que você executou comparativos de mercado de treinamento para modelos comuns e conferiu a performance em TPS. Em seguida, analise a proporção entre o desempenho de Chip_A e o desempenho de Chip_B e Chip_C para o mesmo modelo:
| Comparativo de mercado | TPS de Chip_A como uma fração do TPS de Chip_B | TPS do Chip_A como uma fração do TPS do Chip_C |
|---|---|---|
| Pequeno e denso: Llama 3.1 8B | 0,82 | 0,62 |
| MoE: Mixtral 8x7B | 0,72 | 0,55 |
| Grande e denso: Llama 3.1 405B | 0.77 | 0.61 |
| Grande MoE: DeepSeek-V3 | 0,85 | 0,62 |
| Valor médio | 0.79 | 0,60 |
Com base nos dados da tabela anterior, a performance de Chip_A é, em média, 0,79 da performance de Chip_B e 0,60 da performance de Chip_C. Sem mais informações, a conclusão seria que Chip_C é superior.
No entanto, se o Chip_A custar US $100, o Chip_B custar US $180 e o Chip_C custar US $200, a normalização da performance por dólar (perf/$) mudará o resultado:
| Comparativo de mercado | Chip_A perf/$ como uma fração de Chip_B perf/$ | Chip_A perf/$ como uma fração de Chip_C perf/$ |
|---|---|---|
| Pequeno e denso: Llama 3.1 8B | 1,48 | 1.24 |
| MoE: Mixtral 8x7B | 1,30 | 1.10 |
| Grande e denso: Llama 3.1 405B | 1,39 | 1.22 |
| MoE grande: DeepSeek-V3 | 1,53 | 1.24 |
| Valor médio | 1,42 | 1.20 |
Quando você considera perf/$ como o ponto de comparação, Chip_A ultrapassa Chip_B em uma média de 42% e Chip_C em uma média de 20%.
Comparativo de mercado de inferência
O treinamento é uma despesa de capital inicial enorme, mas a veiculação (e, portanto, a inferência) representa uma despesa operacional de longo prazo. Um TPS/chip maior significa que você precisa de menos servidores físicos para oferecer suporte às mesmas cargas de trabalho operacionais, reduzindo drasticamente o consumo de energia e a pegada do data center.
Na inferência, o objetivo é maximizar a capacidade de processamento sem violar os requisitos de latência para garantir uma experiência do usuário responsiva. Ao padronizar a avaliação em TPS/chip para um modelo fixo, é possível comparar diretamente a performance em diferentes chips.
Ao comparar a inferência, normalize a performance calculando TPS/chip/$:
| Comparativo de mercado | Explicação |
|---|---|
| Estabelecer o SLA de latência |
Primeiro, defina um SLA rigoroso para a experiência do usuário. Por exemplo, uma latência de cauda previsível (P99) de 100 milissegundos. Meça a experiência do usuário de capacidade de resposta usando TTFT (menos de 500 ms) e tempo por token de saída (TPOT). |
| Aumentar o tamanho do lote | Aumente gradualmente o número de solicitações simultâneas (tamanho do lote) no hardware. À medida que o tamanho do lote aumenta, a capacidade de processamento aumenta, mas a latência acaba diminuindo. |
| Recorde de TPS/chip máximo sustentado |
Quando o hardware violar o SLA de latência P99, pare. Registre a capacidade de processamento total do sistema nesse tamanho de lote exato e divida pelo número de chips. Esse é o valor de TPS/chip. Alguns aceleradores de uso geral têm dificuldades com a "latência de cauda" (picos aleatórios no tempo de processamento) sob altas cargas de lote, forçando os operadores a executá-los com utilizações mais baixas para manter os usuários satisfeitos. Meça nas duas fases distintas de pré-preenchimento (vinculado à computação) e decodificação (vinculado à largura de banda da memória). |
| Calcular o TCO por mil ou milhão de tokens | Divida o custo amortizado de capital e energia de um chip pelo TPS máximo sustentado por chip. Isso traduz o comparativo técnico em uma métrica financeira, revelando o custo real. |
A tabela a seguir lista os modelos recomendados para comparativo de mercado de inferência:
| Tamanho | Arquitetura | Modelo | Justificativa |
|---|---|---|---|
| Pequeno (8B) | Dense | Llama 3.1 8B | O Llama 3 é um modelo padrão, conhecido por padrões de comparativo de mercado como o MLPerf há vários anos. |
| Médio (70B) | Dense | Llama 3.1 70B | O Llama 3 é um modelo padrão, conhecido por padrões de comparativo de mercado como o MLPerf há vários anos. |
| Grande (480B) | MoE | Qwen3 Coder 480B (em inglês) | O Qwen3 480B é um modelo de programação OSS líder. |
A seguir
- Arquitetura do Cloud TPU
- Receitas de desempenho do Cloud TPU
- Documentação da TPU do vLLM
- MaxText para treinamento de modelos em TPUs
- Modelo de Roofline na Wikipédia