Architecture-Aware LLM Inference Optimization on AMD Instinct GPUs: A Comprehensive Benchmark and Deployment Study

Este estudo apresenta uma avaliação abrangente da inferência de LLMs em GPUs AMD Instinct MI325X, demonstrando que otimizações específicas da arquitetura (como o uso seletivo do runtime AITER e configurações de cache) são essenciais para maximizar o desempenho, alcançando altas taxas de processamento e estabilidade em workloads de texto e visão.

O essencial

Imagine que você tem uma equipe de cozinheiros extremamente talentosos (os Modelos de IA) e uma cozinha super equipada com fogões de última geração (GPUs da AMD). O objetivo é servir milhões de pratos (respostas de texto) o mais rápido possível para clientes famintos.

Este relatório técnico é como um "manual de sobrevivência" para quem quer montar essa cozinha na AMD, mas descobriu que não existe uma receita única que sirva para todos.

Aqui está a explicação simples, usando analogias do dia a dia:

1. O Cenário: Uma Cozinha Gigante

Os pesquisadores testaram 4 "chefes" diferentes (modelos de IA) em uma cozinha com 8 fogões potentes (GPUs AMD Instinct MI325X).

• Os Chefes: Alguns são gigantes (com 1 trilhão de ingredientes), outros são mais leves. Alguns são "generalistas" (fazem tudo sozinhos), outros são "equipes de especialistas" (cada um faz uma parte específica).
• O Desafio: A cozinha é enorme (2 Terabytes de geladeira), mas o gargalo não é o espaço, é a velocidade com que os ingredientes chegam aos fogões.

2. A Grande Descoberta: "Um Tamanho Não Serve para Todos"

A maior lição do estudo é que você não pode usar as mesmas regras para todos os modelos. É como tentar usar um mapa de metrô para dirigir um caminhão: não funciona.

• Os Modelos "GQA" (Como o Llama e o Qwen): Eles são como cozinheiros que gostam de trabalhar em grandes panelas. Eles funcionam muito bem com a configuração padrão da AMD. Conseguem usar a geladeira inteira e até guardar sobras na geladeira externa (memória do computador) se necessário.
• Os Modelos "MLA" (Como o DeepSeek e o Kimi): Eles são como chefs que usam panelas minúsculas e muito específicas.
  • O Problema: Na cozinha da AMD atual, eles precisam de panelas minúsculas (bloco de tamanho 1) e não podem usar a geladeira externa. Se você tentar forçá-los a usar a configuração padrão, a cozinha trava ou a comida sai errada.
  • A Solução: Eles precisam de um "ajudante especial" chamado AITER. Sem esse ajudante, eles cozinham 2 a 3 vezes mais devagar. Mas cuidado: esse ajudante só funciona se o chefe tiver o número exato de ajudantes (cabeças de atenção). Se não tiver, você tem que demitir o ajudante e deixar o chef trabalhar sozinho (o que deixa tudo mais lento, mas funciona).

3. O Segredo do Sucesso: "Ativos" vs. "Totais"

Muitas pessoas acham que quanto mais ingredientes (parâmetros) o modelo tem, mais lento ele é. O estudo provou que isso é um mito.

• A Analogia: Imagine dois times de futebol.
  • Time A: Tem 405 jogadores no banco, mas só 405 jogam de cada vez.
  • Time B: Tem 685 jogadores no banco, mas só 37 jogam de cada vez (os outros estão descansando).
• O Resultado: O Time B (que usa menos jogadores ativos) consegue fazer o mesmo número de gols (velocidade) que o Time A, mesmo tendo um banco de reservas muito maior.
• A Lição: O que importa para a velocidade é quantos jogadores estão ativos no campo, não quantos estão no banco. Modelos que ativam menos "cérebros" por vez são mais eficientes.

4. O Gargalo: A Estrada de Acesso

O estudo descobriu algo curioso: não importa se você tem 100 ou 1.000 clientes pedindo comida ao mesmo tempo, a velocidade máxima da cozinha para de subir em um certo ponto (cerca de 500 pedidos simultâneos para textos curtos).

• Por que? Não é porque os fogões (processadores) estão lentos. É porque a estrada de entrega (largura de banda de memória) está cheia de caminhões.
• A Analogia: Você tem 100 cozinheiros correndo, mas só há uma porta estreita para tirar os pratos da cozinha. Não adianta ter mais cozinheiros; a fila na porta é o limite. A AMD tem uma porta muito larga (6 TB/s), mas mesmo ela tem um limite.

5. O Recorde: O Gigante de 1 Trilhão

O estudo conseguiu colocar o modelo mais pesado de todos (Kimi-K2.5, com 1 trilhão de parâmetros) para rodar nessa cozinha.

• O Truque: Eles usaram uma técnica de "compactação" (quantização INT4) que é como embrulhar os ingredientes em caixas super compactas.
• O Resultado: O modelo gigante coube em apenas 4 dos 8 fogões e serviu 7.300 pratos por segundo sem derrubar nenhum pedido. Isso é um marco histórico, provando que a AMD aguenta os modelos mais pesados do mundo.

Resumo Final para o Dia a Dia

Se você for montar uma IA na AMD hoje:

1. Não use a mesma configuração para tudo. Descubra se seu modelo é do tipo "panela grande" (GQA) ou "panela pequena" (MLA).
2. Use o "ajudante" (AITER) com cuidado. Ele acelera muito os modelos modernos, mas pode causar confusão se o modelo não for compatível.
3. Não se preocupe tanto com o tamanho total. O que importa é quantos "cérebros" estão trabalhando de cada vez.
4. Espere um limite de velocidade. Se você tiver muitos usuários, a velocidade vai estabilizar. Não adianta pedir mais velocidade se a "estrada de entrega" já está cheia.

Em suma: A AMD é uma cozinha poderosa e capaz de cozinhar os maiores pratos do mundo, mas você precisa saber exatamente qual receita usar para cada tipo de chef, ou a comida vai queimar!

Resumo técnico

Resumo Técnico: Otimização de Inferência de LLMs Arquiteturalmente Consciente em GPUs AMD Instinct

1. Problema e Contexto

A inferência de Grandes Modelos de Linguagem (LLMs) em escala de fronteira (de centenas de bilhões a trilhões de parâmetros) exige uma co-otimização cuidadosa entre a arquitetura do modelo, as capacidades do hardware e a configuração do sistema de serviço. Embora existam estudos de benchmarking para GPUs NVIDIA, há uma escassez significativa de avaliações sistemáticas em aceleradores AMD, especialmente para modelos com arquiteturas diversificadas (como MoE e MLA) e em clusters de produção.

Além disso, a diversidade arquitetural dos modelos modernos (Dense, MoE, GQA, MLA) impõe requisitos de configuração radicalmente diferentes. Uma configuração que funciona perfeitamente para um modelo denso pode ser ineficiente ou até mesmo falhar em um modelo com Mixture-of-Experts (MoE) e Multi-head Latent Attention (MLA). O objetivo deste trabalho é preencher essa lacuna, fornecendo o primeiro benchmark acadêmico cruzado de arquiteturas em hardware AMD Instinct MI325X.

2. Metodologia e Configuração Experimental

Plataforma de Hardware

• Hardware: Cluster de 8 GPUs AMD Instinct MI325X (arquitetura CDNA 3).
• Memória: 256 GB de HBM3e por GPU (2 TB agregados), com largura de banda de 6,0 TB/s por GPU (48 TB/s agregada).
• Software: vLLM v0.14.1 (framework de serviço), ROCm 6.4.2, Docker.
• Carga de Trabalho: Testes de estresse de 1 a 1.000 usuários concorrentes, cobrindo desde latência de solicitação única até saturação de throughput.

Modelos Avaliados

O estudo avaliou quatro modelos de fronteira representando três famílias arquitetônicas distintas:

1. DeepSeek V3.2: 685B parâmetros totais, ~37B ativos. Arquitetura: MoE + MLA.
2. Llama-3.1-405B: 405B parâmetros (Dense). Arquitetura: Dense + GQA.
3. Qwen3-VL-235B: 235B parâmetros totais, ~22B ativos. Arquitetura: MoE + GQA (Multimodal).
4. Kimi-K2.5: 1 Trilhão de parâmetros totais, ~32B ativos. Arquitetura: MoE + MLA (Multimodal).

Técnicas de Otimização

• Quantização: Uso de FP8 para modelos densos e MoE (DeepSeek, Llama), BF16 para Qwen3-VL (devido a restrições do codificador de visão) e INT4 QAT para Kimi-K2.5.
• Gestão de KV Cache: Avaliação de offloading para CPU e quantização FP8 do cache, dependendo da compatibilidade da arquitetura.
• Aceleração AITER: Uso do AMD AI Tensor Engine for ROCm (AITER) para kernels otimizados, com ablações controladas para medir seu impacto real.

3. Principais Contribuições

1. Benchmark Cruzado de Arquiteturas em MI325X: Primeira avaliação acadêmica abrangente de modelos de fronteira em hardware AMD, cobrindo desde 235B até 1T de parâmetros, com caracterização específica de configurações por arquitetura.
2. Otimização Consciente da Arquitetura: Demonstração de que não existe uma configuração "única" para todos os modelos.
   • Modelos MLA exigem block-size 1 e são incompatíveis com offloading de KV cache no stack ROCm atual.
   • Modelos GQA beneficiam-se de offloading e tamanhos de bloco padrão.
   • O AITER é obrigatório para throughput competitivo em modelos MLA, mas deve ser desativado para Kimi-K2.5 devido a incompatibilidades de contagem de cabeças de atenção e requisitos de hardware (MXFP4).
3. Implantação de Modelo de 1 Trilhão de Parâmetros: Sucesso no deploy e benchmarking do Kimi-K2.5 (1T parâmetros) em apenas 4 GPUs MI325X usando quantização INT4 QAT, alcançando 100% de confiabilidade.
4. Validação Empírica de Parâmetros Ativos: Confirmação de que, em escala de fronteira, o número de parâmetros ativos por token (e não o total) é o principal motor do throughput de inferência, embora confundido por variáveis de quantização e paralelismo.
5. Saturação Dependente da Carga: Identificação de um ponto de saturação comum de throughput para todas as arquiteturas dentro de uma mesma carga de trabalho, indicando um gargalo de largura de banda de memória.

4. Resultados Chave

Desempenho de Throughput

• Cargas de Texto: Llama-3.1-405B (Dense+GQA) e DeepSeek V3.2 (MoE+MLA) alcançaram throughputs de pico comparáveis (~15.944 tok/s e ~15.343 tok/s, respectivamente), apesar do DeepSeek ter apenas 9% dos parâmetros ativos do Llama. Isso sugere que as vantagens de esparsidade do MoE foram compensadas pelas restrições de configuração do MLA no ROCm.
• Cargas de Visão: Qwen3-VL-235B (MoE+GQA) atingiu 47.873 tok/s, sendo 6,5 vezes mais rápido que Kimi-K2.5 (MoE+MLA, 7.327 tok/s). A diferença é atribuída ao menor número de parâmetros ativos do Qwen, ao uso de GQA (permitindo offloading e blocos maiores) e à aceleração AITER (que está desativada no Kimi devido a limitações de hardware).

Impacto do AITER

• Para modelos MLA (DeepSeek), o AITER é essencial; a alternativa baseada em Triton oferece desempenho drasticamente inferior.
• Para modelos GQA (Llama-3.1-405B), um estudo de ablação mostrou que o AITER oferece um benefício modesto de 3–5% em throughput de alta concorrência, mas aumenta a variabilidade das medições (coeficiente de variação) em 2–16 vezes. Isso confirma que os ganhos de 2–3x anunciados pelo AMD são específicos para kernels MoE/MLA.

Saturação e Confiabilidade

• Ponto de Saturação: Todos os modelos atingiram o pico de throughput em aproximadamente 500 solicitações concorrentes para cargas curtas e 100–200 para cargas longas. Acima desse limite, o throughput estagna, indicando um gargalo de largura de banda de memória (DRAM), não de capacidade de computação (FLOPs).
• Confiabilidade: Todos os modelos mantiveram 100% de taxa de sucesso (HTTP 200) até 1.000 usuários concorrentes, processando 18,9 milhões de tokens sem falhas. O sistema gerencia o excesso de carga aumentando a latência em vez de rejeitar solicitações.

Eficiência de Hardware

• A utilização de FLOPs permaneceu baixa (<15% para o modelo mais denso, <3% para MoE), confirmando que a inferência autoregressiva é limitada pela largura de banda de memória.
• A grande capacidade de memória HBM3e (256 GB/GPU) eliminou a necessidade de offloading para CPU na maioria dos cenários, simplificando a arquitetura de implantação.

5. Significado e Implicações

Este estudo estabelece diretrizes críticas para a implantação de LLMs em hardware AMD:

1. Configuração Específica por Arquitetura: Não se pode usar uma configuração padrão de vLLM para todos os modelos. A detecção automática da arquitetura (MLA vs. GQA, MoE vs. Dense) é necessária para definir parâmetros como tamanho de bloco, uso de AITER e estratégias de offloading.
2. Viabilidade da Plataforma MI325X: O cluster de 8 GPUs MI325X demonstrou ser uma plataforma viável e robusta para modelos de fronteira, incluindo o primeiro benchmark publicado de um modelo de 1 trilhão de parâmetros em CDNA 3.
3. Gargalo de Memória: Para cargas de trabalho de inferência, a otimização deve focar na redução do tráfego de memória (via quantização, MoE e compressão de KV cache) em vez de apenas aumentar a capacidade de computação bruta.
4. Maturidade do Software: Embora o ROCm e o AITER sejam capazes de produção, restrições específicas (como a necessidade de desativar AITER para certos modelos MLA ou usar builds noturnos) ainda exigem atenção manual na configuração.

Em resumo, o trabalho valida o hardware AMD Instinct MI325X para inferência de LLMs de escala global, mas enfatiza que o sucesso depende de uma otimização fina e consciente da arquitetura do modelo, onde "uma configuração não serve para todos".