Entre em qualquer thread sobre LLMs locais e a briga é sobre GPUs. Benchmarks de VRAM, placas de 24 GB, CUDA contra ROCm, se a 3060 ainda é a placa do povo. Enquanto isso, o número que realmente decide se o seu modelo roda está no outro slot, sem benchmark e sem marketing: quanta RAM a máquina tem.
A VRAM vende o sonho. A RAM decide se o modelo abre de verdade — e quanta sobrevive de contexto quando abre.
Testei na máquina à minha frente enquanto escrevia este post: um desktop Ryzen com 32 GB de RAM e uma GeForce RTX 3060 com 12 GB de VRAM. Baixei o llama3.1:8b — a página diz 4,9 GB. Veja o que ele reservou de fato:

O argumento inteiro cabe nessa tela. Um «modelo de 4,9 GB» reservou 7,0 GB antes de responder um único prompt — um imposto de contexto de 43 % — e ficou com 7.963 dos 12.288 MiB de VRAM. Os pesos nunca foram o orçamento. O contexto era.
De onde vêm os gigabytes extras
As notas de memória do llama.cpp detalham a aritmética que as páginas de download omitem: memória total = pesos do modelo + cache KV + buffer de computação. Só o primeiro termo é constante. O cache KV cresce linearmente com o comprimento do contexto, e o buffer de computação com o batch. O Ollama embrulha o llama.cpp, então a mesma lei vale — por isso o ollama ps reportou 7,0 GB para uma tag de 4,9 GB com janela de 32.000 tokens, tudo residente na GPU.
Um modelo quantizado não é um compromisso. É a admissão de que memória sempre foi o orçamento de verdade.
É também por isso que a escada de quantização GGUF existe. Q4 não é religião; é o que faz a aritmética de memória caber no hardware que as pessoas têm. E é por isso que duas configurações «idênticas» de 8B não se parecem em nada: mesmo modelo, outro comprimento de contexto, outras máquinas.
A tabela que ninguém consulta antes de comprar
Três classes de modelo, os dois tipos de memória, uma placa de 12 GB e 32 GB de RAM — a configuração que milhares de desenvolvedores realmente têm:
| Classe de modelo (Q4) | Download | Carregado + ctx 32k | Em 12 GB de VRAM | Em 32 GB de RAM |
|---|---|---|---|---|
7–8B (llama3.1:8b) | 4,9 GB | 7,0 GB (medido) | 100% GPU, ~8 GiB usados | quase não notou |
13–14B (qwen2.5:14b) | 9,0 GB | ~12 GB | o offload começa | de boa |
27–32B (gemma3:27b) | 17 GB | ~20 GB ou mais | a CPU carrega o peso | a única razão de rodar |
Releia as duas últimas linhas. Só com VRAM, um 14B com contexto real já é um trabalho de offload dividido, e um 27B é impossível. Com 32 GB de RAM, ambos são apenas lentos. Essa diferença — entre impossível e lento — é toda a diferença prática entre VRAM e RAM. Se cabe na VRAM, é rápido. Se cabe na RAM, funciona. Se não cabe em nenhuma, você está fazendo swap para o NVMe e o tempo perde o sentido.
O offload passa pela PCIe, e o FAQ do Ollama é direto sobre o custo: as camadas que não cabem na GPU rodam na CPU, e o throughput despenca quando a fatia de GPU encolhe. Ninguém escolhe esse trade-off conscientemente. Ele acontece em silêncio, camada por camada, e o sintoma é só «modelos locais são superestimados».
O livro-razão honesto
O que quebrou ou surpreendeu enquanto eu escrevia, em ordem:
- O próprio número de 43 %. Eu esperava que o 8B ocupasse «mais ou menos o tamanho do arquivo». Ele reservou 7,0 GB contra 4,9 GB baixados. Se isso me surpreendeu, surpreende todo mundo que lê ficha técnica em vez de
ps. - A sessão de screenshots. Minha primeira captura pegou a janela errada. A segunda funcionou, e é a de cima. Evidência é fluxo de trabalho, não vibe — e um ciclo pull → captura →
ollama rmmantém o disco honesto. - O que não quebrou: a GPU nunca estourou. 8B com contexto de 32k em 12 GB é confortável de verdade. A placa está bem. Mal calibrado é o discurso em volta da placa.
Nada disso significa que GPUs não importam — a linha de 100% GPU na captura é o motivo de a geração parecer instantânea. Significa que a GPU é a segunda pergunta. A escolha entre Ollama e llama.cpp vem depois de saber o que cabe, não antes.
A regra que vale guardar
RAM necessária = arquivo do modelo + cache KV para o seu contexto real + 4 GB de continuar sendo um computador. Para 7–8B em Q4, 16 GB são confortáveis. Para 14B–32B, 32 GB deixam de ser luxo e viram o ponto. Compre VRAM pela velocidade que você quer no contexto que usa; compre RAM por tudo o que vai carregar algum dia.
Olhe o
ollama psuma vez e a religião das fichas técnicas termina em silêncio.
Então, duas perguntas. Quando especificar sua próxima máquina, você compra VRAM pelos benchmarks que vai postar — ou RAM pelos modelos que realmente vai rodar? E, sendo honesto: quantos dos modelos que você baixou às 2 da manhã você apagou antes do café? Eu apaguei, hoje, no meio do post. Diga nos comentários que não sou o único — e de que lado da linha RAM/VRAM está a sua máquina.
FAQ
Quanta RAM você precisa para rodar um LLM local?
Tamanho do arquivo do modelo, mais contexto, mais o seu desktop. 16 GB dão folga para modelos 7–8B em Q4; 32 GB é o que transforma um 14–32B em ferramenta diária em vez de demo.
O que importa mais para LLMs locais: VRAM ou RAM?
A VRAM decide a velocidade quando tudo cabe nela. A RAM decide se o modelo roda e quanta sobrevive de contexto. O offload por PCIe entre os dois é o meio-termo lento de que ninguém gosta.
Por que um modelo usa mais memória carregado do que o tamanho do download?
O cache KV e os buffers de computação crescem com o comprimento do contexto. A documentação de memória do llama.cpp traz a conta: pesos + cache KV + buffer de computação — e só o primeiro número aparece na página de download.
— mrsaynothing
— mrsaynothing
Opinions load-tested before shipping. Mostly.
Discuta este post no dev.to dev.to ↗
Get the next argument by email
One email per post. Agree or tear it apart.
o que é isso?SSH Permission denied (publickey): a correção certa
Gostou dos artigos? É assim que eu construo profissionalmente. me contrate