Rodar LLM local: guia de memória e VRAM

Rodar LLM local exige somar três coisas antes do download: os pesos do modelo, o KV cache que cresce com o contexto e a memória de trabalho do software. O tamanho do arquivo cobre apenas os pesos. Por isso um modelo listado como 5,2 GB pode dividir uma GPU de 6 GB entre CPU e GPU quando você carrega a conversa.

Rodar LLM local: por que o tamanho do arquivo engana

Rodar LLM local exige somar três parcelas que o tamanho do download não mostra: os pesos do modelo, o KV cache que cresce com a conversa e a memória de trabalho do motor. O arquivo listado cobre só os pesos. Por isso um modelo de 5,2 GB pode dividir uma placa de 6 GB entre CPU e GPU.

O exemplo vem da própria documentação do Ollama, ferramenta que baixa e serve modelos locais por linha de comando. O comando ollama ps mostra a divisão entre processamento na CPU e na GPU depois do carregamento. Quando aparece algo como 48% CPU e 52% GPU, o modelo carregou, mas boa parte do trabalho ficou do lado lento da máquina.

A conta completa tem três nomes. Pesos são os parâmetros aprendidos no treino, fixos depois que o modelo carrega. O KV cache guarda as chaves e valores calculados para cada token lido, e cresce conforme o contexto aumenta. A memória de trabalho é o espaço que o software precisa para operar. Estimar as três antes do download evita surpresa.

Fitting e velocidade são perguntas separadas. Um modelo pode carregar sem erro e ainda assim gerar tokens devagar, porque o que ficou na RAM passa pela CPU a cada token. Trate capacidade e desempenho como dois cálculos distintos desde o começo.

Denso ou MoE: o que muda no consumo de memória

Denso e MoE mudam quanto trabalho cada token exige, mas não quanto de memória você precisa. Um modelo denso usa todos os pesos em cada token. Um modelo de mistura de especialistas, ou MoE, ativa apenas parte deles por token, mantendo o restante guardado. A memória precisa caber no bloco inteiro; o cálculo toca só a fatia ativa.

A página do Qwen3-30B-A3B no Hugging Face descreve o arranjo: 30,5 bilhões de parâmetros distribuídos em 128 especialistas, dos quais 8 são ativados por token, o que dá cerca de 3,3 bilhões de parâmetros ativos. Compare com um denso como o Qwen3-32B, que usa todos os pesos em cada token.

O efeito prático aparece na escolha entre dois modelos quase do mesmo tamanho. O MoE ocupa memória parecida com o denso, mas gasta menos trabalho por token. Se ambos cabem na sua placa, a diferença que você sente é de velocidade, não de espaço.

Essa distinção também explica por que o Ollama lista um MoE de 19 GB e um denso de 20 GB lado a lado. São um gigabyte de diferença no arquivo, mas ordens de grandeza diferentes de trabalho por token.

Quantização: de FP16 a Q4_K e Q6_K

Quantização reduz o número de bits por peso e encolhe o arquivo, ao custo de arredondamento. O cálculo de base é direto: parâmetros multiplicados por bits por peso, divididos por oito, dão bytes. Oito bilhões de pesos em 16 bits ocupam 16 GB; em 4 bits, 4 GB. O tamanho listado pelo repositório é o número real a considerar.

A tabela de quantização da documentação do Hugging Face mapeia cada nome para bits por peso. Q4_K equivale a 4,5 bits por peso e Q6_K a 6,5625. Passar de Q6_K para Q4_K encolhe os pesos em cerca de um terço, o que pode decidir entre uma e duas faixas de memória.

GGUF é o formato que empacota pesos e metadados em um arquivo único, para que o motor saiba exatamente o que está abrindo. O formato importa porque define quais engines conseguem ler o arquivo. Um GGUF e um download no formato MLX não são intercambiáveis.

Mais bits significam arquivo maior e menos arredondamento. Quanto de qualidade você perde depende do modelo e da tarefa, e nenhuma listagem responde isso. Teste suas próprias perguntas depois de trocar a quantização.

O KV cache cresce com o contexto reservado

O KV cache guarda as chaves e valores de cada token processado e cresce a cada nova interação. A tabela da documentação do Hugging Face mostra o tamanho para o Llama 3.1 8B: 0,12 GB com 1.000 tokens de contexto, 1,95 GB com 16.000 e 15,62 GB com 128.000. Os pesos em 16 bits ocupam 16 GB.

Perto do contexto máximo, o cache chega a usar tanta memória quanto os próprios pesos. O que conta não é o limite da listagem, mas o que o seu software reserva. O Ollama escolhe um padrão conforme a VRAM detectada: abaixo de 24 GB usa 4K de contexto, entre 24 e 48 GB usa 32K e a partir de 48 GB reserva 256K.

Existe uma inconsistência conhecida nas páginas do Ollama. O FAQ ainda afirma que o padrão é 4.096 tokens em qualquer caso. Duas páginas da mesma documentação dão respostas diferentes. Confie no que a máquina reporta: a coluna de contexto do ollama ps mostra o que foi realmente carregado.

Requisições paralelas multiplicam o valor do cache. Se você roda várias conversas ao mesmo tempo, cada uma reserva o próprio contexto e a conta final cresce na mesma proporção.

Quanto de VRAM para 6 GB, 24 GB e 64 GB

A quantidade de VRAM necessária depende de quatro fatores: tamanho dos pesos, bits por peso, contexto reservado e número de requisições paralelas. Nenhum deles isolado decide o resultado. Use a tabela abaixo como ponto de partida e rode uma estimativa real antes do download.

Máquina	Modelo sugerido	Pesos	Como roda
Notebook, GPU 6 GB, RAM 16 GB	MoE de ~8B em Q4, contexto curto	~5,2 GB	Na borda da placa; modelos maiores caem em modo híbrido com a CPU
Desktop, GPU 24 GB	MoE de 30B, contexto de 32K	~19 GB	Cabe na VRAM com sobra para cache; denso de 32B também cabe, com menos margem
Mac, 64 GB de memória unificada	MoE de 30B ou denso de 32B	~19-20 GB	Cabe com folga e aceita contextos longos

No notebook, restam cerca de 0,8 GB dos 6 GB depois dos pesos. Com o padrão de 4K de contexto, o cache para um modelo de 8B fica na casa de 0,5 GB, segundo a tabela do Hugging Face, e o cache de cada família varia. A margem é pequena e é aí que o transbordo acontece.

No desktop, os 19 GB do MoE deixam cerca de 5 GB para cache e sobrecarga. Verifique a coluna de contexto, porque uma placa de 24 GB fica exatamente na fronteira da faixa de 24 a 48 GB. O denso de 32B, com 20 GB, também cabe e usa todos os pesos em cada token.

No Mac não existe trailer: a GPU usa o mesmo pool de 64 GB que o restante do sistema. O sistema operacional e seus aplicativos ocupam parte desse espaço, e o macOS limita quanto a GPU pode fixar para si. A documentação do MLX, framework de arrays da Apple para Apple Silicon, recomenda aumentar esse limite quando modelos grandes ficam lentos.

Velocidade: TTFT e tokens por segundo

Velocidade se divide em duas fases com causas diferentes: o tempo até o primeiro token, chamado TTFT, e a taxa de geração em tokens por segundo. O TTFT é dominado pelo processamento do prompt e cresce com o que você cola na entrada. A geração é o gotejamento que vem depois e depende de onde os pesos estão.

Um prompt curto começa rápido. Um documento longo obriga o modelo a ler tudo o que cabe no contexto antes de responder. Com o padrão de 4K, boa parte de um documento extenso simplesmente não entra.

O llama.cpp é o motor que roda por baixo de várias dessas ferramentas. Ele expõe as opções de offload de camadas, tipo de KV cache e uma flag de ajuste automático que adapta o que você não configurou para caber na memória do dispositivo. Prompt caching vem ligado por padrão no servidor.

Quando o modelo fica lento, identifique qual fase está ruim. Uma pausa longa antes da primeira palavra pede olhar para o tamanho do prompt e para o cache. Um gotejamento lento depois disso pede olhar para onde os pesos moram e quantos estão ativos em cada token.

Ollama, LM Studio, llama.cpp e MLX: qual escolher

Ollama, LM Studio, llama.cpp e MLX resolvem problemas diferentes e se sobrepõem mais do que os logos sugerem. Alguns são motores que fazem a conta, outros são aplicativos em volta de um motor, e um é o framework da própria Apple.

O Ollama é o caminho mais curto até um modelo rodando. Você baixa pelo nome, ele escolhe padrões com base na VRAM e o ollama ps mostra onde o modelo ficou. A troca é que os padrões decidem contexto, divisão CPU/GPU e paralelismo sem que você perceba.

O LM Studio é um aplicativo de desktop com interface gráfica. Ele roda llama.cpp em todas as plataformas e MLX no Apple Silicon, e traz um utilitário de linha de comando com modo de estimativa. Esse modo calcula a memória necessária antes de você carregar qualquer coisa, o que ajuda quem quer testar modelos grandes.

O llama.cpp é a rota mais direta para quem quer todas as opções e não se importa com o terminal. Ele também tem um modo pensado para MoE: manter os pesos dos especialistas das primeiras camadas na CPU, já que só alguns especialistas trabalham por token. O MLX é exclusivo de Apple Silicon e trabalha com memória unificada, com cache de prompt e KV cache rotativo próprios.

Como acelerar: oito alavancas e o que cada uma corrige

Nenhuma alavanca de desempenho garante ganho, e cada uma corrige uma fase específica. Trate todas como hipóteses a testar nas suas próprias perguntas, porque efeito depende de hardware e modelo.

Offload de camadas. Em llama.cpp, um parâmetro controla quantas camadas ficam na VRAM. Coloque todas se couberem; se não, a flag de ajuste distribui o resto. Confira o resultado no ollama ps e busque 100% na GPU.
Contexto enxuto. Se suas conversas são curtas, não reserve 256K. Um contexto menor libera memória e pode trazer camadas de volta para a GPU.
Quantização. Sair de Q6_K (6,5625 bits) para Q4_K (4,5 bits) encolhe os pesos em cerca de um terço.
Flash Attention. Reduz o uso de memória no cálculo de atenção. O efeito na velocidade depende do hardware, então meça.
Quantização do KV cache. Q8_0 ocupa cerca de metade do que F16, e Q4_0 cerca de um quarto, segundo o FAQ do Ollama.
Prompt caching. Ajuda quando o início dos prompts se repete, como um assistente de código com instruções fixas. Não acelera a geração.
Decodificação especulativa. Um modelo pequeno propõe tokens e o grande valida. O rascunho precisa compartilhar o vocabulário do modelo principal, segundo a documentação do LM Studio, que avisa que a velocidade pode não aumentar ou até cair.
Predição multi-token (MTP). Funciona apenas em famílias de modelos que oferecem esse mecanismo. Verifique a lista de suporte antes de planejar em cima disso.

Quando o modelo não cabe: RAM, streaming e SSD

Quando o modelo não cabe na VRAM, existem três caminhos: transbordar para a RAM, transmitir especialistas ou partes do modelo de um meio mais lento, ou adicionar GPUs. Cada um amplia a capacidade e cobra em velocidade.

O transbordo para RAM em modo híbrido permite ultrapassar a VRAM, desde que o modelo caiba na soma de VRAM e RAM. No notebook, isso significa cerca de 22 GB de espaço combinado em vez de 6 GB, antes do que o sistema operacional reserva. Cada token passa por todas as camadas, inclusive as que a CPU processa.

Modelos MoE melhoram essa troca. Como cada token usa poucos especialistas, dá para deixar os pesos especialistas na CPU e manter na GPU o que todo token precisa. Reduza o KV cache antes de empurrar caixas para o lado lento, porque isso reduz o volume que precisa sair da placa.

Existe ainda o streaming de especialistas, que mantém os mais usados próximos e busca os outros quando necessário. O artigo do FreeToken relata 39,3 tokens por segundo para um modelo de 35B em uma GPU de notebook com 8 GB. São resultados dos próprios autores, ainda sem verificação independente, e qualquer busca em memória lenta vira espera. Teste na sua máquina antes de tratar o número como referência.

No extremo, há o streaming direto do SSD. O desenvolvedor antirez publicou um GGUF de DeepSeek com cerca de 750 bilhões de parâmetros e instruções para rodá-lo em um Mac de 128 GB lendo apenas as linhas necessárias do disco. A página não informa velocidades medidas, então trate como demonstração de possibilidade e não como configuração prática.

Faça a estimativa antes de baixar o modelo

A estimativa antes do download é o passo que evita baixar dezenas de gigabytes para descobrir que o modelo não cabe. Duas ferramentas fazem essa conta: o modo de estimativa do LM Studio e o llmfit, utilitário que detecta seu hardware e projeta quantos tokens por segundo você teria.

Os números de velocidade do llmfit vêm de um modelo de largura de banda de memória combinado com amostragem em tempo de execução e medições da comunidade. São estimativas, e o próprio README diz isso. Use como previsão de tempo, não como medição do seu sistema.

O roteiro é sempre o mesmo. Estime o encaixe com o contexto que você realmente vai usar, carregue o modelo, confira onde ele ficou e cronometre suas próprias perguntas. Depois avalie a qualidade das respostas nas tarefas reais, porque só os seus prompts dizem se o resultado serve.

A ordem das alavancas depende do sintoma. Se o modelo não carrega, mexa em contexto, quantização do KV cache, Flash Attention e nível de quantização. Se demora para começar a responder, foque em cache de prompt e prompts mais curtos. Se gera devagar, revise offload, quantização e decodificação especulativa.

Perguntas frequentes

Por que meu modelo cabe no papel mas roda devagar?

Porque o tamanho do arquivo cobre apenas os pesos. O KV cache, o contexto reservado e a memória de trabalho do motor consomem o resto, e as camadas que transbordam para a RAM passam pela CPU a cada token. Confira a divisão com ollama ps.

Perguntas frequentes (continuação)

Quantos GB de VRAM preciso para um modelo de 8B em 4 bits?

Os pesos ficam em torno de 5 GB, mas você ainda precisa de espaço para o KV cache e a sobrecarga do motor. Em uma placa de 6 GB, use contexto curto e verifique se o carregamento ficou inteiro na GPU ou em modo híbrido.

O Ollama e o LM Studio usam o mesmo motor?

O LM Studio roda llama.cpp em todas as plataformas e adiciona MLX no Apple Silicon. O Ollama tem seu próprio caminho de execução. Por isso a mesma máquina pode apresentar divisões e contextos diferentes entre os dois.

Vale a pena usar quantização menor para caber na placa?

Uma quantização menor reduz os pesos e pode evitar o transbordo, mas aumenta o arredondamento. O impacto na qualidade varia por modelo e tarefa. Teste suas perguntas reais antes de adotar Q4_K no lugar de Q6_K.

Source video