Requisitos de VRAM para LLM: A Tabela Mestra de 2026 (Todos os Modelos, Todas as Quantizações)

Requisitos de VRAM para LLM: A Tabela Mestra de 2026 (Todos os Modelos, Todas as Quantizações)

Eis o número que apanha toda a gente de surpresa: o DeepSeek-V3.2 tem 671 mil milhões de parâmetros, mas apenas 37 mil milhões são ativados para qualquer token dado. Então, de quanta VRAM precisa realmente? De todos os 671 mil milhões, aproximadamente 382 GB em Q4. Os requisitos de VRAM para LLM raramente seguem a intuição, e a lacuna entre "parâmetros ativos" e "o que tem de carregar" é exatamente onde os orçamentos de hardware explodem. Este guia entrega-lhe a tabela mestra (todos os principais modelos open source, todos os níveis de quantização, o valor em GB e a GPU que o executa), mais a fórmula para dimensionar qualquer modelo por si mesmo em cerca de dez segundos.

Pontos Principais

• VRAM para os pesos ≈ parâmetros × bytes-por-parâmetro: FP16 = 2,0, Q8 = 1,0, Q5_K_M ≈ 0,68, Q4_K_M ≈ 0,57. Adicione cache KV e ~15-20% de sobrecarga adicional.
• Os modelos Mixture-of-Experts (DeepSeek, GLM-5.2, Qwen3-235B) devem carregar todos os especialistas na VRAM. Os "parâmetros ativos" dão-lhe velocidade, não poupança de memória.
• O cache KV é o custo oculto. O Llama 3.3 70B precisa de cerca de 2,6 GB de cache num contexto de 8K e aproximadamente 41 GB num contexto de 128K, para além dos pesos.
• Q4_K_M é a predefinição sensata: qualidade quase total com cerca de um quarto da pegada do FP16.
• Um modelo de 12B como o Gemma 4 cabe numa placa de 8 GB em Q4. Um modelo denso de 70B precisa de cerca de 40 GB. Um MoE de ponta de 671B precisa de um pequeno servidor.

Requisitos de VRAM para LLM por Modelo: A Tabela Mestra

A resposta curta: em Q4_K_M, os modelos pequenos (menos de 14B) cabem em placas de consumo de 8-12 GB, os modelos de tamanho médio (24-32B) querem 16-24 GB, um modelo denso de 70B precisa de cerca de 40 GB, e os modelos MoE de ponta saltam para centenas de gigabytes porque todos os especialistas têm de estar residentes. Eis o panorama completo num só lugar. Todos os valores referem-se à memória apenas para os pesos, calculados a partir da contagem de parâmetros de cada modelo e verificados com as fichas técnicas oficiais da Meta AI, Qwen e Hugging Face.

Duas coisas a retirar desta tabela. Primeiro, a quantização é a maior alavanca que tem: passar de FP16 para Q4 reduz a pegada em aproximadamente 4x com uma perda de qualidade quase impercetível. Segundo, as linhas MoE parecem brutais porque o são. O Qwen3-30B-A3B ativa apenas 3B de parâmetros por token, por isso corre à velocidade de um modelo minúsculo, mas ainda precisa de manter todos os 30B na memória para ter todos os especialistas prontos. Quer os detalhes modelo a modelo por trás destes números? A nossa análise profunda do Gemma 4 12B e a lista dos melhores LLMs open source de 2026 cobrem os benchmarks e licenças.

A Fórmula da VRAM: Calcule Qualquer Modelo Por Si Mesmo

Para dimensionar qualquer modelo, multiplique a sua contagem de parâmetros pelos bytes-por-parâmetro da sua quantização e adicione um pouco para o cache KV e sobrecarga de execução. É tudo. Os pesos são o termo dominante, e a aritmética é simples o suficiente para ser feita nas costas de um guardanapo.

A equação central para os pesos:

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

Os valores de bits-por-peso de que precisa (estas são as taxas efetivas para ficheiros GGUF k-quant, que carregam um pouco de metadados de bloco para além da profundidade de bits nominal):

Exemplo prático, Gemma 4 12B em Q4_K_M: 11,95 × 4,5 ÷ 8 = cerca de 6,7 GB para os pesos. Isso alinha-se com os cerca de 6,6 GB citados na ficha técnica oficial e explica por que cabe numa placa de 8 GB com espaço para um contexto modesto. Faça a mesma conta para um modelo de 70B em Q4 e obtém 70 × 4,5 ÷ 8 = 39,4 GB, razão pela qual "precisa de duas placas de 24 GB ou uma de 48 GB para um 70B" é a regra prática que todos repetem.

O panorama completo adiciona mais dois termos: VRAM total ≈ pesos + cache KV + ~15-20% de sobrecarga. A sobrecarga cobre buffers de ativação, o contexto CUDA e fragmentação de memória, e a sua GPU também reserva cerca de meio gigabyte para o driver, por isso nunca planeie usar 100% da VRAM indicada.

Por Que Razão o Cache KV É o Número Que O Apanha

O cache KV armazena as chaves e valores de atenção para cada token já no contexto, e cresce linearmente com o comprimento do contexto. Em prompts curtos, é um erro de arredondamento. Ao avançar para um contexto longo, pode rivalizar ou exceder os próprios pesos. Esta é a razão mais comum para um modelo que "deveria caber" lançar um erro de falta de memória a meio da geração.

A fórmula, por token:

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Tome o Llama 3.3 70B: 80 camadas, 8 cabeças KV, dimensão da cabeça 128, portanto kv_dim é 1024. Em FP16, isso dá 80 × 2 × 1024 × 2 = 327.680 bytes por token, cerca de 0,31 MB. Multiplique pelo comprimento do contexto e a história escreve-se sozinha: em 8K tokens o cache é de cerca de 2,6 GB, em 32K é de cerca de 10 GB, e em 128K infla para cerca de 41 GB. Esse último valor soma-se aos 40 GB de pesos, por isso um "modelo de 40 GB" torna-se silenciosamente num problema de 80 GB no momento em que enche a janela.

Duas saídas práticas. A atenção de consulta agrupada (que todos os modelos recentes usam) já reduz drasticamente o kv_dim em relação ao antigo design multi-head, por isso os modelos modernos são muito mais simpáticos neste aspeto do que o Llama 2 era. E a maioria dos motores de inferência pode quantizar o cache KV para 8-bit ou 4-bit, reduzindo para metade ou um quarto o seu tamanho por um pequeno custo de qualidade. Se estiver a servir contextos longos em produção, a comparação vLLM vs SGLang cobre qual backend gere esta memória de forma mais eficiente com atenção paginada.

Modelos MoE: Por Que Razão os "Parâmetros Ativos" Não Salvam a VRAM

Esta é a armadilha que custa mais dinheiro às pessoas. Um modelo Mixture-of-Experts como o DeepSeek-V3.2 (671B total, 37B ativos, partilhando a arquitetura V3) ou o GLM-5.2 (744B total, 40B ativos) encaminha cada token através de um pequeno subconjunto dos seus especialistas. O marketing apoia-se no número ativo porque descreve a velocidade: só paga o computo de 37B de parâmetros por token, por isso a inferência é rápida para o tamanho do modelo. Mas todos os especialistas devem estar na memória, prontos a ser escolhidos, o que significa que o seu orçamento de VRAM é definido pela contagem total de parâmetros, não pela ativa.

Assim, a leitura honesta da tabela acima: o GLM-5.2 corre à velocidade de um modelo de 40B, mas ocupa a memória de um de 744B. É por isso que estes modelos open source de ponta precisam de um servidor de 8 GPUs ou de uma máquina de memória unificada grande, embora uma única passagem direta seja barata. O Qwen3-235B-A22B tem a mesma forma numa escala menor, rápido por token, pesado de alojar.

A vantagem do MoE aparece em hardware de memória unificada. Um Mac Studio com 512 GB de memória unificada pode conter um modelo de 671B em Q4 e ainda executá-lo a velocidades utilizáveis precisamente porque apenas 37B são ativados, mantendo a procura de largura de banda de memória por token razoável. Se é novo na execução destes localmente, comece com o nosso guia de configuração de LLM local antes de gastar em hardware.

Qual Quantização Deve Escolher?

Para quase todos, Q4_K_M é a predefinição correta: mantém qualidade quase total enquanto corta a pegada do FP16 em cerca de 4x. Suba para Q5_K_M ou Q8 apenas se tiver VRAM sobressalente e uma tarefa sensível à qualidade, e recorra ao FP16 apenas quando estiver a fazer fine-tuning ou benchmarking contra uma referência. Abaixo de Q4, a degradação da qualidade torna-se rapidamente perceptível, por isso Q3 e inferiores são um último recurso para espremer um modelo numa placa que é genuinamente demasiado pequena.

Uma ressalva: a qualidade da quantização não é idêntica entre modelos. Modelos muito pequenos (menos de 4B) sentem mais o Q4 do que os grandes, porque têm menos redundância para desperdiçar. Num modelo de 70B, Q4 versus Q8 é difícil de distinguir na maioria das tarefas. Num modelo de 1,7B, a diferença é real.

De Que GPU Precisa Realmente?

Combine a coluna Q4 da tabela mestra com uma placa com alguma margem para o cache KV. Eis o mapeamento prático desde hardware de consumidor económico até ao data center, com o nível de modelo que cada classe executa confortavelmente em Q4.

O Apple Silicon merece uma menção especial porque a memória unificada muda o cálculo. Um Mac não divide a VRAM da RAM do sistema, por isso uma máquina M-series de 128 GB pode carregar modelos que precisariam de múltiplas GPUs discretas, trocando o pico de throughput pela capacidade de acomodar pesos enormes num único desktop. Para os backends que extraem o máximo de qualquer uma destas placas, a nossa lista das melhores ferramentas para executar LLMs localmente analisa as diferenças de velocidade no mundo real.

Como Dimensionamos a VRAM para Implementações de Clientes

Na Techsy, implementamos modelos open source para clientes com frequência suficiente para que o dimensionamento da VRAM seja a primeira conversa, antes da escolha do modelo, antes dos prompts, antes de tudo. O nosso método é propositadamente aborrecido, porque o modo de falha (um OOM em produção sob carga de contexto real) é dispendioso. Eis o processo que realmente executamos.

Começamos com a matemática da tabela, depois medimos. Após carregar um modelo, verificamos a pegada residente real em vez de confiar na estimativa:

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

A lição que se repete: as equipas dimensionam para os pesos e esquecem o cache KV, depois perguntam-se por que razão um modelo que carregou bem morre três pedidos longos depois numa demonstração. Dimensionamos para os pesos mais o cache KV no contexto máximo que a aplicação irá realmente usar, mais margem, e limitamos o --ctx-size para que um pedido descontrolado não cause OOM na máquina. Para qualquer coisa voltada ao cliente, preferimos executar um 32B quantizado que nunca cai, do que um 70B FP16 que causa OOM sob carga.

Se estiver a pesar se deve autoalojar um modelo open source ou permanecer numa API alojada, essa troca (custo de hardware e fardo operacional versus preço por token e controlo) é exatamente o que a nossa equipa avalia durante um engajamento de integração de IA. Se ajudasse ter alguém a correr os números contra a sua carga de trabalho real, obtenha uma consulta gratuita e dimensionaremos consigo.

Sobre o Autor

Mert Batur Gurbuz é Co-Fundador da Techsy.io, onde a equipa entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Estuda na Universidade de Birmingham e escreve sobre a stack de ferramentas LLM que a equipa da Techsy realmente usa em produção.

Credenciais: Co-Fundador, Techsy.io, Universidade de Birmingham. Conecte-se no LinkedIn.

Perguntas Frequentes

De quanta VRAM preciso para executar um modelo de 70B?

Um modelo denso de 70B como o Llama 3.3 70B precisa de cerca de 40 GB de VRAM para os pesos em Q4_K_M, por isso planeie para uma placa de 48 GB (RTX 6000 Ada) ou duas placas de 24 GB. Adicione vários gigabytes adicionais para o cache KV se usar um contexto longo, o que empurra os requisitos práticos para 48 GB ou mais.

De quanta VRAM precisa o Llama, Qwen ou DeepSeek?

Depende inteiramente da variante. O Llama 4 Scout precisa de cerca de 62 GB em Q4, o Qwen3-32B cerca de 18 GB, e o Qwen3-8B menos de 5 GB. O DeepSeek-V3.2, um MoE de 671B, precisa de aproximadamente 382 GB porque todos os especialistas devem carregar. Verifique sempre a contagem total de parâmetros, não a ativa, para modelos MoE.

Posso executar um LLM numa GPU de 8GB?

Sim, confortavelmente. Uma placa de 8 GB, como uma RTX 4060, executa modelos até cerca de 12B de parâmetros em Q4_K_M. O Gemma 4 12B cabe em cerca de 6,8 GB, deixando espaço para um contexto modesto. Para algo maior, terá de quantizar mais agressivamente, manter o contexto curto ou mudar para uma placa maior.

O que pode executar uma GPU de 24GB como a RTX 4090?

Uma placa de 24 GB lida com modelos densos até cerca de 32B em Q4_K_M com margem para um contexto razoável, por isso o Qwen3-32B e o Mistral Small 3.2 24B são confortáveis. Também executa o MoE Qwen3-30B-A3B, que carrega 30B de pesos mas gera à velocidade de um modelo de 3B graças à ativação esparsa.

A quantização prejudica a qualidade do modelo?

Em Q4_K_M e acima, a perda de qualidade é pequena e muitas vezes impercetível em tarefas reais, especialmente para modelos acima de 13B. A lacuna alarga-se à medida que desce e os modelos ficam menores, por isso Q4 num 70B é quase gratuito, enquanto Q4 num 1,7B é perceptível. Q8 é efetivamente sem perdas se tiver memória.

Os modelos MoE precisam de menos VRAM do que os modelos densos?

Não, e este é o equívoco mais comum. Um modelo Mixture-of-Experts deve manter todos os especialistas na VRAM, por isso a sua memória é definida pela contagem total de parâmetros. O valor de parâmetros ativos descreve apenas a velocidade de inferência. O GLM-5.2 corre à velocidade de um modelo de 40B, mas precisa da memória de um de 744B.

A memória unificada é o mesmo que VRAM?

Funcionalmente, para carregar modelos, sim. O Apple Silicon e alguns outros sistemas partilham um pool de memória entre CPU e GPU, por isso um Mac de 128 GB pode carregar modelos que de outra forma precisariam de múltiplas GPUs discretas. A troca é a largura de banda: a memória unificada geralmente oferece menor throughput de pico do que uma GPU de data center de alta gama, por isso os tokens-por-segundo são mais baixos.

Posso descarregar parte de um modelo para a RAM do sistema ou CPU?

Sim. Motores como llama.cpp e Ollama permitem manter algumas camadas na GPU e o resto na RAM do sistema com uma flag como --n-gpu-layers. Permite executar um modelo demasiado grande para a sua VRAM, mas cada camada na CPU abranda drasticamente a geração, por isso use-o para tornar um modelo possível, não rápido.

Como calculo a VRAM para um modelo que não está na tabela?

Multiplique a contagem de parâmetros em milhares de milhões pelos bits-por-peso da sua quantização e divida por 8. Para Q4_K_M use cerca de 4,5 bits, por isso um modelo de 40B precisa de 40 × 4,5 ÷ 8 = cerca de 22,5 GB para os pesos. Adicione aproximadamente 15-20% de sobrecarga mais o seu cache KV para o requisito real.