Memória em IA: como evitar OOM e latência alta no serving

Esse movimento do mercado — uma fabricante de chips de memória (Micron) ultrapassando Meta e chegando a superar, por um período, até a Tesla — não é “só bolsa”. Na prática, ele escancara uma mudança técnica que devs vivem todo dia: a infraestrutura de IA está deixando de ser só “modelo e GPU” para virar cadeia completa, onde memória (DRAM/HBM) e capacidade de fornecimento mandam tanto quanto compute.

Segundo o Olhardigital.com.br, a Micron atingiu um valor de mercado de aproximadamente US$ 1,398 trilhão depois de projeções acima do esperado e de compromissos de compra de clientes somando US$ 22 bilhões. Quando isso acontece, o investidor está comprando uma tese: “vai ter mais memória para alimentar mais inferência e mais treinamento”. E é exatamente aí que o impacto chega no nosso mundo: latência, custo por token, batch size, gargalos de throughput e até arquitetura de software.

Por que chips de memória estão liderando (e como isso aparece no seu código)

Na minha experiência trabalhando com stacks de IA e engenharia de performance, pouca gente liga para memória no nível certo. Todo mundo fala de GPU porque é o hardware mais “visível”. Mas em sistemas reais de IA, memória costuma ser o limitador silencioso.

Quando você aumenta contexto (long context), ativa lotes maiores, faz streaming com múltiplas sessões ou roda modelos maiores em batch, você pressiona:

• Memória de alta velocidade (por exemplo, HBM em aceleradores) e/ou memória próxima ao compute.
• DRAM do sistema e o subsistema de memória usado por CPU, pré-processamento, paginação e filas.
• Bandwidth (taxa de transferência), não só capacidade.

O que o noticiário chama de “demanda por chips de memória” vira, no nosso dia a dia, algo bem concreto: mais disponibilidade de componentes tende a reduzir escalas de espera, melhorar previsibilidade de fornecimento e tornar possível crescer clusters sem “parar por falta de memória”.

O que muda quando memória vira o gargalo principal

Compute por si só não resolve se o pipeline ficar preso em transferência e alocação. A diferença aparece em sintomas clássicos:

• Quedas de throughput ao aumentar batch size (não por compute, mas por memória).
• Mais pausas por paging/remoção de páginas (ou fallback de kernels/rotinas).
• Latência variando muito com concorrência (cada request “briga” por espaço e cache).
• Necessidade de quantização/compartilhamento de pesos mais agressivos.

Ou seja: um supply chain que favorece memória ajuda você a manter configurações de produção mais estáveis. E isso, para empresas que investem em IA, é dinheiro direto.

Micron vs. Meta e Tesla: por que isso é sobre infraestrutura de IA

O Olhardigital.com.br descreve que a Micron ultrapassou a Meta e, momentaneamente, a Tesla, ultrapassando valores de mercado (aprox. US$ 1,398 tri vs. US$ 1,392 e acima de US$ 1,4 por um período). Para mim, o ponto técnico por trás disso não é “chips como produto”, e sim memória como requisito operacional da expansão de IA.

Quando grandes players investem em IA, eles não compram só GPU. Eles compram:

• Servidores com layouts específicos de memória.
• Capacidade de storage/IO para checkpoints, datasets e offloading.
• Interconnect e configuração de rede para alimentar o compute.
• Mais control over plane (alocação, scheduling, tenancy e segurança).

Sem memória (capacidade e largura de banda), você não escala o mesmo jeito. Pode até rodar um demo, mas em produção o custo explodirá ou o SLA cai.

O “porquê” por trás da tese do mercado

Segundo a matéria, os investidores reagiram ao guidance acima das estimativas e aos acordos de compra de US$ 22 bilhões. Eu leio isso como:

• Consistência de demanda: não é pico momentâneo; é continuidade.
• Redução de incerteza: previsão melhora planejamento de data centers.
• Foco em gargalos: se a Micron sobe, o mercado está dizendo que memória é parte crítica do ganho de escala.

Em software, isso se traduz em menos “gambiarras permanentes” e mais espaço para otimizações estruturais.

Comparação técnica: memoria vs. compute na prática (e onde dev erra)

Quase todo dev que inicia em LLM/serving começa otimizando o que é mais “fácil de enxergar”: aumentar velocidade do kernel, usar FlashAttention, escolher batch. Só que a conta real geralmente fecha em torno de memória.

Comparando de forma direta:

Armadilhas comuns que eu vejo em PRs e tickets

• Subir batch size “no escuro”: sem medir memória efetiva e sem entender fragmentação/allocator.
• Ignorar KV cache: cache de atenção é memória de verdade; negligenciar isso vira OOM com o tempo.
• Assumir que quantização resolve tudo: reduz pesos, mas o restante do pipeline (ativations/KV) ainda pesa.
• Não controlar concorrência: duas dezenas de requests mal agendadas anulam qualquer ganho de kernel.

O mercado, ao priorizar memória, está indiretamente ajudando a reduzir a dor dessas arquiteturas “agressivas”. Mas o lado dev continua: sem observabilidade, você não sabe se está limitado por compute, por memória ou por banda.

Na Prática: como ajustar serving quando memória vira limitador

Vou mostrar um caminho prático que funciona para a maioria dos times: limitar concorrência, controlar batch efetivo e tornar o uso de KV cache mensurável. Isso costuma reduzir picos de latência e OOM.

1. Instrumente métricas: monitore latência p95/p99, throughput (req/s), taxa de erro OOM e uso de memória (VRAM/RAM) por request.
2. Implemente backpressure: em vez de enfileirar infinitamente, imponha limite por instância.
3. Configure batch dinâmico com teto: agregue requests até um limite de memória estimada.
4. Controle o tamanho de contexto: aplique políticas (por exemplo, truncar, resumir ou recusar) para evitar “requests monstruosas”.
5. Valide com carga real: simule concorrência real, não só teste unitário.

Exemplo funcional (Node.js): backpressure simples com fila com timeout

Esse snippet não “tune memória” diretamente, mas evita que você mate a instância por acúmulo de requests (que frequentemente estoura memória via contextos e buffers). Na minha experiência, isso sozinho já derruba OOM em produção.

import pLimit from "p-limit";

const limit = pLimit(4); // teto de concorrência por instância
// ajuste conforme sua capacidade de memória e throughput

async function handleRequest(req, modelFn) {
  const started = Date.now();

  return limit(async () => {
    const timeoutMs = 12_000; // não deixe requests presas ocupando buffers
    return await Promise.race([
      modelFn(req),
      new Promise((_, reject) => setTimeout(() => reject(new Error("timeout")), timeoutMs))
    ]).catch((err) => {
      // aqui você pode logar métricas: timeout, OOM, latency, etc.
      throw err;
    });
  }).then(result => {
    const elapsed = Date.now() - started;
    return { result, elapsedMs: elapsed };
  });
}

// Exemplo: modelFn seria seu pipeline de inferência
// const response = await handleRequest({ prompt: "..." }, (r) => model.generate(r.prompt));

Por que isso importa para memória? Porque concorrência descontrolada costuma multiplicar: buffers de tokenizer, tensores intermediários, KV cache e estruturas do runtime. Se você limita concorrência, você controla a pressão de memória com uma “alavanca” que dá previsibilidade.

O que evitar: otimizações que parecem boas, mas pioram latência e OOM

Quando memória vira o assunto, as pessoas caem em “otimizações” que só funcionam em ambiente feliz. Aqui vão os erros mais comuns.

1) Não medir KV cache e assumir que “quantização baixou tudo”

Quantização reduz parte dos pesos, mas o cache de atenção e outros buffers podem continuar pressionando memória. Se o seu sistema usa contextos longos, o KV cache cresce brutalmente.

2) Batch grande demais

Batch ajuda throughput quando o sistema está compute-bound. Quando fica memory/bandwidth-bound, batch alto piora p99 e aumenta chance de OOM.

3) Enfileirar sem limite

Em produção, fila infinita vira bomba. Você aumenta concorrência “indiretamente”, porque requests aguardando ainda ocupam recursos (buffers, contexto serializado, timers, memória do app).

4) Falta de políticas de contexto

Sem limites, um cliente manda um prompt enorme e sua infraestrutura entra em espiral. Políticas de tamanho e rejeição são parte do sistema, não “feature do front”.

FAQ

Memória “realmente” importa mais do que GPU para IA em produção?

Na maioria dos deployments de LLM, memória e principalmente bandwidth importam muito. GPU pode estar subutilizada enquanto o sistema espera dados ou sofre por alocações/fragmentação. O efeito aparece em throughput que não escala com batch e em p99 instável.

Como identificar se estou limitado por memória ou por compute?

Se VRAM/RAM chega perto do limite (ou há OOM/picos) e o throughput cai com aumento de concorrência/batch, é forte sinal de limitação de memória/banda. Em monitoramento, olhe também taxa de paging, tempo em kernels de cópia e crescimento do KV cache por request.

O que devo ajustar primeiro quando surgem OOM em LLM serving?

Eu começo por: limitar concorrência (backpressure), reduzir tamanho efetivo de contexto (truncar/resumir/rejeitar), ajustar batch dinâmico e rever políticas de cache. Quantização entra depois, porque pode impactar qualidade e não resolve KV cache sozinho.

Qual a relação desse noticiário com decisões técnicas do dia a dia?

A relação é indireta, mas real: supply de memória tende a reduzir gargalos de infraestrutura e melhorar a previsibilidade de capacidade. Isso afeta quantos clusters você consegue rodar com configurações estáveis, e por consequência o quanto sua arquitetura pode ser “menos agressiva” em gambiarras.

Por que o mercado reagiu tanto ao guidance da Micron?

Porque, segundo o Olhardigital.com.br, as projeções vieram acima do esperado e há acordos de compra grandes (US$ 22 bilhões). Guidance forte em memória sinaliza demanda contínua para sustentar expansão de IA — e investidores precificam isso como capacidade futura de escala.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.