Quanto de VRAM uma GPU precisa para rodar um LLM?

Este artigo é para você se:

• Dimensiona infraestrutura de IA e precisa calcular com precisão quanta memória GPU alocar para inferência de LLMs;
• Enfrenta erros Out Of Memory (OOM) ao expandir a janela de contexto ou aumentar o batch size em modelos já implantados;
• Avalia provedores de GPU dedicada no Brasil e busca previsibilidade de custos em reais sem egress fee.

O que é VRAM no contexto de LLMs e como ela é consumida?

VRAM para LLM é a memória de vídeo dedicada alocada em uma unidade de processamento gráfico para hospedar os pesos de um modelo de linguagem grande, o cache de chaves e valores gerados durante a inferência, os buffers de ativação intermediária e o overhead do framework de execução, funcionando como o espaço de trabalho exclusivo onde todo o processamento de tokens ocorre.

Diferente de uma CPU que pode recorrer a memória RAM do sistema via swap, uma GPU opera de forma autônoma dentro de seu próprio pool de memória. Quando a soma dos componentes excede a capacidade física da placa, o framework gera um erro fatal de Out Of Memory (OOM) e a inferência para completamente. Não há paginação de emergência: ou tudo cabe na VRAM, ou a operação falha.

O consumo total de VRAM em uma carga de LLM se divide em quatro componentes distintos:

• Pesos do modelo: os parâmetros treinados que definem o comportamento do LLM. Constituem a fatia mais previsível e geralmente a maior do consumo.
• KV Cache: matrizes que armazenam os estados de atenção de tokens anteriores para evitar recomputação. Cresce com o tamanho do contexto e o batch size.
• Ativações e buffers intermediários: tensores temporários gerados durante o forward pass, especialmente intensos em camadas de atenção e feed-forward.
• Overhead do framework: memória reservada pelo CUDA, pelo PyTorch ou pelo vLLM para gerenciamento de kernels, alocadores e filas de execução.

Como calcular a VRAM necessária para um LLM?

A fórmula prática para estimar a VRAM mínima de um LLM em inferência é:

VRAM total = (Parâmetros × Precisão) + KV Cache + Ativações + Overhead

Na prática, o cálculo se desdobra assim:

• Pesos: multiplique o número de bilhões de parâmetros pelo tamanho em bytes de cada parâmetro. FP16 = 2 bytes, INT8 = 1 byte, INT4 = 0,5 byte. Um modelo de 7B em FP16 ocupa 14 GB de VRAM apenas nos pesos.
• KV Cache: para cada camada do transformer, cada token gerado armazena um vetor de chave e um de valor. A fórmula aproximada é: 2 × camadas × dimensão_oculta × sequência_comprimento × batch_size × precisão.
• Overhead: adicione 10% a 20% de folga para o framework (CUDA context, alocador de memória, kernels compilados).

Quanta VRAM consomem os principais modelos open source?

A tabela abaixo mostra o consumo estimado de VRAM para modelos open source populares, considerando inferência em precisão FP16 (2 bytes por parâmetro) e uma janela de contexto de 4.096 tokens com batch size: 

* Inclui pesos, KV Cache para 4.096 tokens, ativações e overhead de framework. Valores aproximados.
** Modelos Mixture of Experts (MoE) como DeepSeek-V3 utilizam precisão FP8 e técnicas de descarregamento de experts que reduzem a VRAM ativa, mas ainda exigem infraestrutura multi-GPU.

Note que modelos acima de 70B parâmetros em FP16 já excedem a capacidade de qualquer GPU de consumo disponível no mercado. Mesmo a RTX 4090, com seus 24 GB de VRAM, mal comporta um modelo de 8B parâmetros em FP16 com contexto generoso. Para cargas corporativas, a alternativa é a quantização ou o uso de múltiplas GPUs em cluster com paralelismo de tensores.

Quantização: como reduzir o consumo de VRAM sem perder qualidade?

A quantização é a técnica de reduzir a precisão numérica dos pesos do modelo, diminuindo o espaço ocupado por cada parâmetro. Os formatos mais comuns são:

• FP16 / BF16: 2 bytes por parâmetro. Padrão para treino e fine-tuning. Mantém a precisão original do modelo.
• INT8: 1 byte por parâmetro. Reduz pela metade o consumo de VRAM com perda mínima perceptível em tarefas de linguagem.
• INT4 / Q4: 0,5 byte por parâmetro. Reduz para um quarto o tamanho. Adequado para inferência em dispositivos limitados, mas pode degradar performance em raciocínio complexo.
• FP8: 1 byte por parâmetro. Novo padrão em GPUs Hopper/Blackwell. Oferece balanço superior entre economia de VRAM e fidelidade do modelo.

A escolha da quantização envolve tradeoffs claros. INT4 permite rodar um Llama 70B em uma única GPU de 48 GB, mas a qualidade de respostas em tarefas de raciocínio lógico e matemática cai perceptivelmente. Para APIs corporativas onde a precisão é crítica, FP16 ou BF16 permanecem como padrão, exigindo múltiplas GPUs ou modelos menores.

KV Cache: o vilão oculto que explode o uso de memória

Se os pesos do modelo são a base, o KV Cache é a variável que mais surpreende equipes de infraestrutura. Durante a geração de texto autoregressiva, cada novo token precisa consultar todos os tokens anteriores para calcular a atenção. Recomputar esses estados a cada passo seria absurdamente lento. A solução é armazenar as matrizes de chaves (K) e valores (V) de cada camada e cada token em VRAM.

O problema: o KV Cache cresce linearmente com o comprimento da sequência. Para um modelo com 80 camadas e dimensão oculta de 8.192, cada token armazenado consome aproximadamente 2,6 MB de VRAM em FP16. Uma conversa com janela de 128.000 tokens exige mais de 330 GB de VRAM apenas no KV Cache, além dos pesos do modelo.

Estratégias para mitigar o KV Cache incluem:

• Compressão de KV Cache: técnicas como KV Cache quantization (INT8/INT4) e eviction policies que descartam tokens menos relevantes.
• PagedAttention: algoritmo do vLLM que aloca memória em blocos dinâmicos, reduzindo fragmentação e permitindo batching mais eficiente.
• Sliding Window Attention: limita o alcance da atenção a uma janela fixa de tokens recentes, truncando o crescimento do cache.
• Offloading para CPU: em sistemas híbridos, camadas menos acessadas podem residir em RAM do host, com penalidade de latência.

Batch size e paralelismo: quando a VRAM vira gargalo

O batch size determina quantas requisições são processadas simultaneamente na GPU. Em produção, batching agressivo é essencial para maximizar a utilização do hardware: uma GPU processando uma única sequência por vez desperdiça a maior parte de seus núcleos CUDA ociosos.

Porém, cada sequência no batch adiciona sua própria fatia de KV Cache à VRAM. Se uma sequência de 4.096 tokens consome 8 GB de cache, um batch de 8 sequências exige 64 GB só de cache. O resultado é um dilema de dimensionamento: aumentar o throughput via batching exige VRAM adicional, e a VRAM disponível impõe um teto rígido no throughput máximo.

Ferramentas como o vLLM e o TensorRT-LLM otimizam o batching dinâmico (continuous batching), onde novas requisições entram no batch assim que outras finalizam, mantendo a GPU saturada. Mesmo assim, o teto de VRAM é o fator limitante. Quando a VRAM esgota, o sistema recusa novas requisições ou degrada para filas de espera.

GPU de consumo versus GPU servidor: o limite da VRAM doméstica

As placas de vídeo voltadas para jogos e estações de trabalho individuais possuem tetos rígidos de VRAM que as desqualificam para LLMs em produção:

Modelos maiores que 70B parâmetros exigem múltiplas GPUs trabalhando em paralelo via NVLink ou técnicas de model parallelism. Nesse cenário, a largura de banda entre GPUs se torna tão crítica quanto a VRAM individual. GPUs corporativas possuem interfaces de alta velocidade (NVLink 900 GB/s) que as de consumo simplesmente não oferecem.

Para ambientes corporativos que buscam dimensionar infraestrutura GPU de forma previsível, a escolha do hardware deve considerar não apenas a VRAM de hoje, mas a trajetória de crescimento dos modelos. A Lei de Scaling dos LLMs sugere que modelos maiores continuam emergindo a cada ciclo de lançamento, e a infraestrutura precisa acomodar essa evolução sem troca completa de hardware. Saiba mais sobre como escolher servidores GPU adequados em nosso guia sobre o que considerar ao escolher um servidor GPU para empresas.

A abordagem da EVEO

A EVEO oferece servidores dedicados com GPUs NVIDIA profissionais em 5 data centers Tier III no Brasil e nos Estados Unidos: Cotia/SP, Osasco/SP, Curitiba/PR, Fortaleza/CE e Miami/FL. O portfólio inclui GPUs com 32 GB a 96 GB de VRAM, configuráveis em clusters multi-GPU para cargas de LLM de grande porte.

A infraestrutura é single-tenant, o que significa que a GPU alocada é exclusiva do cliente, sem compartilhamento de memória ou competição por recursos com outras cargas. O faturamento é fixo mensal em reais, sem egress fee, permitindo previsibilidade orçamentária mesmo quando o tráfego de inferência oscila. Todos os dados permanecem em território nacional (exceto Miami, para cargas híbridas), garantindo conformidade automática com a LGPD.

Com mais de 10 anos de mercado, mais de 5.000 clientes e mais de 130 colaboradores, a EVEO atua como parceira de infraestrutura para empresas que implantam LLMs em produção, oferecendo suporte técnico 24/7 em português e arquitetura validada para cargas de IA contínuas. A atuação é exclusivamente corporativa, mediante CNPJ.

Perguntas frequentes