Como o hardware está redesenhando o design dos LLMs

O paradoxo da capacidade ociosa do hardware para LLMs

Uma GPU NVIDIA H100 executa cerca de um quatrilhão de operações de ponto flutuante por segundo, o equivalente a mil teraflops. Em teoria, esse poder permitiria a um modelo de linguagem com oito bilhões de parâmetros gerar até 62 mil tokens por segundo.

A conta é simples: cada token exige aproximadamente duas operações por parâmetro, ou seja, cerca de 16 bilhões de operações. Portanto, dividir um quatrilhão por 16 bilhões leva a algo próximo de 62 mil tokens por segundo.

Na prática, porém, os melhores motores de inferência ficam presos em torno de 200 tokens por segundo nesse cenário. Em outras palavras, o hardware para LLMs entrega menos de 1% do que promete no papel.

Esse abismo entre a capacidade teórica e o desempenho real tem uma causa bem definida: o chamado memory wall, a parede da memória.

Se você ainda não conhece o caminho que um texto percorre dentro do modelo, vale ler antes o artigo sobre como uma LLM processa tokens e gera respostas. Assim, os termos das próximas seções ficam mais claros.

A origem do memory wall

Por décadas, a Lei de Moore garantiu a duplicação da densidade de transistores a cada ciclo de evolução. Com isso, o poder de computação bruto cresceu na mesma proporção.

A memória, no entanto, evoluiu em um ritmo bem mais lento. Ano após ano, o processador ficou mais capaz de calcular do que a memória de alimentá-lo com dados.

Esse desequilíbrio acumulado entre processador e memória ganhou o nome de memory wall. Além disso, ele virou um gargalo crítico para a inferência de LLMs a partir de 2019, quando os modelos explodiram em tamanho.

Desde então, o hardware para LLMs passou a esbarrar menos na quantidade de cálculo e mais na velocidade com que os dados chegam ao chip.

Como o hardware para LLMs organiza a memória

Para entender o problema, é preciso conhecer a hierarquia de memória de uma GPU. Afinal, cada nível dessa hierarquia troca velocidade por capacidade.

O ciclo de inferência autorregressiva

Em um LLM autorregressivo clássico, a geração acontece token por token. Cada novo token depende de todos os anteriores, por isso o modelo não consegue pular etapas.

Para cada token gerado, o modelo executa um forward pass completo. Nesse processo, o sistema carrega os pesos de cada camada da HBM para a memória on-chip, executa as operações e produz as ativações, camada por camada.

Para gerar uma resposta de 1.000 tokens, portanto, o modelo realiza 1.000 transferências completas dos seus parâmetros. Então, o custo da geração depende muito mais da memória do que do cálculo.

A H100 move dados da HBM a cerca de 3,3 terabytes por segundo. Já um modelo de oito bilhões de parâmetros em 16 bits ocupa 16 gigabytes.

Dessa forma, a GPU consegue fazer em torno de 200 transferências completas por segundo, o que explica o teto observado na prática.

// Especificações aproximadas de uma GPU H100
const double PeakFlops = 1e15;           // cerca de 1 quatrilhão de FLOP/s
const double MemoryBandwidth = 3.3e12;   // cerca de 3,3 TB/s de HBM

// Modelo de 8 bilhões de parâmetros em 16 bits (2 bytes por parâmetro)
const double Parameters = 8e9;
const double BytesPerParameter = 2;

double modelBytes = Parameters * BytesPerParameter;
double flopsPerToken = 2 * Parameters;

// Limite se só a computação importasse
double computeBoundTokensPerSecond = PeakFlops / flopsPerToken;

// Limite real: todos os pesos atravessam a memória a cada token
double memoryBoundTokensPerSecond = MemoryBandwidth / modelBytes;

Console.WriteLine($"Compute bound: {computeBoundTokensPerSecond:N0} tokens/s");
Console.WriteLine($"Memory bound:  {memoryBoundTokensPerSecond:N0} tokens/s");
// Compute bound: 62.500 tokens/s
// Memory bound:  206 tokens/s

O modelo roofline e o hardware para LLMs

Para raciocinar sobre a eficiência de algoritmos em relação ao hardware, os engenheiros usam o roofline model. Esse framework surgiu em 2009 para analisar a tensão entre memória e computação em CPUs multicore.

O eixo horizontal representa a intensidade aritmética, medida em flops por byte. Ela indica quantas operações úteis o processador realiza para cada byte que chega da memória principal.

O eixo vertical, por sua vez, representa a taxa de computação, em flops por segundo. Até o ponto de crista (ridge point), a relação entre os dois eixos é linear: performance = intensidade aritmética × largura de banda de memória.

Acima desse ponto, a capacidade máxima do processador limita o desempenho, no regime compute-bound. Abaixo dele, o sistema fica no regime memory-bound, em que a largura de banda de memória é o gargalo.

Na H100, o ponto de crista fica perto de 300 flops por byte. Enquanto isso, a decodificação de um único token com pesos de 16 bits rende algo próximo de 1 flop por byte.

Por isso, LLMs autorregressivos operam firmemente no regime memory-bound. Essa é a forma mais objetiva de mostrar por que o hardware para LLMs fica ocioso na geração de texto.

Otimizações de sistema: KV cache e paged attention

Uma das principais otimizações para a inferência autorregressiva é o KV cache, o cache de chave e valor. Ele evita que o modelo recalcule, a cada novo token, as chaves e os valores de todos os tokens anteriores.

Durante o processamento do prompt, na fase de prefill, o modelo trata todos os tokens em paralelo. Com isso, a intensidade aritmética sobe e o sistema alcança o regime compute-bound.

Esse truque alivia o hardware para LLMs logo no início da resposta.

Os vetores de chave e valor produzidos nessa fase ficam guardados em cache para as etapas seguintes da geração. Segundo a documentação do Microsoft Agent Framework, é por isso que o primeiro token demora mais do que os seguintes.

A desvantagem é que o KV cache consome memória proporcional ao número de tokens e ao tamanho do lote de requisições simultâneas. Além disso, cada requisição de um batch reserva um espaço exclusivo, mesmo quando o cache fica esparso ou parcialmente usado.

O paged attention, criado pelo projeto vLLM, ataca essa fragmentação com uma ideia emprestada dos sistemas operacionais: a paginação de memória. Dessa forma, o motor aloca blocos sob demanda e reduz o desperdício.

Hoje, o vLLM combina PagedAttention, batching contínuo e KV cache para servir modelos grandes com alta concorrência. Inclusive, o Foundry Local da Microsoft adota o vLLM como runtime para cargas em GPU.

Speculative decoding: especulação e paralelismo

O speculative decoding representa uma abordagem algorítmica para aumentar o throughput. Nesse método, um modelo menor e mais ágil, o draft model, propõe tokens candidatos.

Enquanto isso, o modelo principal, maior, atua como verificador. Como os candidatos já estão disponíveis, ele consegue checar várias predições em um único forward pass, o que aumenta a intensidade aritmética.

O desempenho depende criticamente da escolha do draft model. Se ele for grande demais, perde a vantagem de velocidade; se for pequeno demais, o verificador descarta boa parte das predições e o esforço vira desperdício.

Em outras palavras, a técnica tenta aproveitar a capacidade ociosa do hardware para LLMs sem alterar o resultado final do modelo principal.

LLMs de difusão e o hardware

Enquanto as otimizações de sistema exploram ao máximo o modelo autorregressivo, uma abordagem mais radical surge no horizonte: os LLMs de difusão. Nesse caso, o próprio design do modelo muda para se adaptar ao hardware.

Em vez de gerar um token por vez, um modelo de difusão começa com uma janela de contexto preenchida com ruído. Em seguida, ele refina esse rascunho iterativamente até chegar a uma resposta coerente.

O número de iterações é um hiperparâmetro que controla o equilíbrio entre velocidade e qualidade. Mais iterações produzem respostas melhores, mas custam mais tempo.

No fundo, o hardware para LLMs passa a ditar o formato do modelo.

Em cada iteração, o modelo não prevê um único token, já que atualiza todos os tokens do rascunho ao mesmo tempo. Assim, ele realiza mais operações por forward pass e se aproxima do regime compute-bound do roofline.

Essa mudança aproveita muito melhor o paralelismo da GPU. Por isso, os LLMs de difusão representam uma tentativa de redesenhar o modelo a partir das limitações do hardware.

Os desafios dos LLMs de difusão no hardware

Apesar de favoráveis na teoria do roofline, os primeiros modelos de difusão, como o MDLM e o LLaDA, costumavam ser mais lentos que os autorregressivos. Ou seja, usar bem o hardware para LLMs não basta quando boa parte do cálculo é inútil.

O problema central é o desperdício computacional. Estima-se que cerca de 90% das operações de uma etapa de refinamento sejam inúteis.

Isso acontece porque o modelo prevê com confiança apenas cerca de 10% dos tokens em cada iteração.

A proposta FOCUS tenta mitigar isso com uma abordagem gulosa. Primeiro, ela identifica as posições de alta confiança; depois, decodifica esses tokens com prioridade e reduz o trabalho desperdiçado.

Outro desperdício vem das janelas de contexto fixas, geradas mesmo para prompts que pedem respostas curtas. Nesse sentido, pesquisas recentes propõem ajustar o tamanho da janela ao longo das iterações, começando com 64 tokens e expandindo conforme a necessidade.

A convergência: block diffusion

A tendência mais promissora do setor aponta para a block diffusion, uma arquitetura híbrida que combina difusão e autorregressão. Nela, o modelo agrupa os tokens em blocos.

Dentro de cada bloco, a decodificação acontece por difusão, em paralelo. Entre os blocos, por outro lado, o processamento segue sequencial e autorregressivo.

Essa abordagem oferece duas vantagens concretas em relação à difusão pura. Primeiro, a decodificação pode parar cedo: quando um bloco produz o token de fim de sequência, a resposta termina sem processar os blocos seguintes.

Em segundo lugar, a volta da autorregressão permite reaproveitar anos de otimizações criadas para LLMs tradicionais. Por exemplo, KV cache e speculative decoding voltam a valer, agora operando no regime compute-bound.

Na prática, a block diffusion une o melhor dos dois mundos. Ela mantém a qualidade e as ferramentas do modelo autorregressivo, enquanto aproveita o paralelismo que o hardware para LLMs oferece.

O ecossistema emergente de inferência para difusão

Os primeiros motores de inferência dedicados a LLMs de difusão já começam a surgir. No campo open source, destacam-se iniciativas como XDIT, WeDLM e DINFER, todas vindas de laboratórios chineses.

Cada um desses motores nasce para extrair mais do hardware para LLMs.

No lado proprietário, a empresa Inception desenvolveu um motor próprio que serve modelos de difusão a mais de mil tokens por segundo. Além disso, ela lançou o Mercury II, apresentado como o primeiro LLM de difusão especializado em raciocínio.

Esse movimento mostra que a mudança já saiu dos artigos acadêmicos. Assim, quem trabalha com IA em produção deve acompanhar essas ferramentas de perto nos próximos anos.

Para onde caminha o hardware para LLMs

A crise do memory wall não é apenas um problema de hardware que a próxima geração de chips vai resolver. Na verdade, ela está forçando uma revisão profunda na forma de projetar, treinar e servir os modelos de linguagem.

A trajetória atual aponta para uma convergência entre otimizações de sistema e novas arquiteturas, como a block diffusion. Além disso, técnicas complementares como destilação, mixture of experts e quantização reduzem o volume de dados que precisa atravessar a memória.

A velocidade dessa convergência vai determinar o ritmo de adoção de LLMs em aplicações que exigem baixa latência e alto throughput. Portanto, entender o hardware para LLMs deixou de ser assunto só de quem projeta chips.

Para quem desenvolve aplicações, esse conhecimento ajuda a escolher modelos, estimar custos e entender por que respostas longas demoram mais. Se você quer aplicar esses modelos no ecossistema Microsoft, o artigo sobre IA generativa no .NET e C# é um bom próximo passo.

Vídeo de referência

O conteúdo deste artigo tem como base o vídeo abaixo, que aprofunda a relação entre o memory wall e o design dos modelos de linguagem.

FAQ

O que é o memory wall?

É o descompasso entre a velocidade de cálculo dos processadores e a velocidade com que a memória entrega dados. Na inferência de LLMs, ele faz a GPU passar a maior parte do tempo esperando os pesos.

Por que um LLM gera poucos tokens por segundo em uma GPU tão potente?

Porque cada token exige carregar todos os pesos da HBM até o processador. Assim, a largura de banda de memória, e não a capacidade de cálculo, define o limite.

O que o KV cache resolve?

Ele guarda as chaves e os valores dos tokens já processados para que o modelo não os recalcule a cada passo. Em troca, consome memória proporcional ao contexto e ao número de requisições.

Qual a diferença entre um LLM autorregressivo e um LLM de difusão?

O autorregressivo gera um token por vez, da esquerda para a direita. O de difusão parte de um rascunho com ruído e refina todos os tokens em paralelo a cada iteração.

O que é block diffusion?

É uma arquitetura híbrida que usa difusão dentro de blocos de tokens e autorregressão entre os blocos. Com isso, ela aproveita o paralelismo da GPU sem abrir mão de otimizações como o KV cache.