# modelos locais para codar por VRAM: guia real

> Published 2026-10-17T01:32:08.938Z on https://www.crazystack.com.br/pt/p/modelos-locais-para-codar-por-vram-guia-real/
> Source video: https://www.youtube.com/watch?v=qkRIW2ieOK8

Modelos locais para codar por VRAM se decidem por três orçamentos de memória, não pelo tamanho do arquivo: pesos, cache KV e memória de trabalho do runtime. Um 9B em 4 bits pesa cerca de 5,75 GB, e sobra pouco mais de 2 GB num cartão de 8 GB. Se você ignorar o cache KV, o modelo carrega e trava no primeiro arquivo longo.

## Por que a tabela que só conta pesos engana

Modelos locais para codar por VRAM dependem de três consumos somados: pesos, cache KV e scratch do runtime. A tabela que só mostra o arquivo baixado esconde os outros dois, e é exatamente o cache KV que estoura primeiro num cartão apertado.

Os pesos são o arquivo que você baixa e a única coluna dessas tabelas. O cache KV guarda as notas que o modelo mantém sobre cada token, do seu prompt e das respostas dele; sem isso, ele releria a conversa inteira a cada palavra nova. O runtime ainda reserva memória própria para fazer as contas.

Quando a soma passa da VRAM, o sistema transborda para um caminho mais lento ou o processo morre. Alguns milhares de tokens de código e conversa já ocupam centenas de megabytes de cache, e esse número só cresce conforme o diálogo avança.

Sobram dois ajustes quando a memória aperta: cair para uma quantização menor, reduzindo os pesos, ou encurtar o contexto, reduzindo o cache. A maioria das pessoas só pensa em trocar de modelo, mas o contexto costuma ser a concessão mais barata.

## 4 GB a 12 GB: assistente de um arquivo só

De 4 GB a 12 GB você roda um assistente útil para explicar código, corrigir um bug focado e fazer edições pequenas, mas não para mudanças que atravessam vários arquivos. Nessa faixa, aumentar a precisão do modelo que você já usa costuma render mais que subir de tamanho.

No extremo inferior, um modelo de 4 bilhões de parâmetros em cerca de 2,6 GB de pesos é o formato típico. Um 4B perde o fio da meada quando a tarefa exige cinco arquivos e um plano; isso não é defeito do modelo, é escopo errado para o tamanho.

Um 9B é o primeiro salto real, porque a 4 bits ele ocupa cerca de 5,75 GB e cabe num cartão de 8 GB. O limite continua sendo espaço para contexto, então mantenha os prompts enxutos para ele sustentar um arquivo e uma conversa de verdade sobre ele.

### Dois ajustes que mudam o resultado

Um 4B de 2,6 GB responde bem a perguntas curtas e mal a tarefas multi-arquivo. Um 9B de 5,75 GB sustenta um arquivo com contexto real, mas não uma refatoração ampla.

Com 12 GB, rodar o mesmo 9B em 8 bits em vez de 4 bits dá cerca de 9,75 GB de pesos e devolve uma versão mais estável do modelo que você já conhece. Trocar de modelo nem sempre é a decisão certa.

## Quantização: onde a qualidade cai

Quantização é guardar cada peso com menos bits, e a faixa segura fica entre 4 e 5 bits para a maioria dos modelos de código. Abaixo de cerca de 3 bits, os erros que o modelo não cometia antes começam a aparecer.

A conta ajuda a fixar a ordem de grandeza: um modelo de 9 bilhões de parâmetros a 16 bits por peso fica perto de 18 GB; a 4 bits, cai para menos de 6 GB. Você encolhe para cerca de um terço do tamanho sem sentir muita diferença na maior parte do trabalho de código.

Construções de 1 bit funcionam como demonstração, não como ferramenta de uso diário. Se a quantização for agressiva demais, o modelo perde precisão em silêncio e você culpa o contexto ou o runtime por um problema que começou nos bits.

## 16 GB a 24 GB: quantização não uniforme e edição multi-arquivo

De 16 GB a 24 GB você roda um modelo de 27 bilhões de parâmetros e faz edições multi-arquivo, rodando a suíte de testes localmente. O ganho não vem de caber mais parâmetros, e sim de sobrar memória para o contexto que essa tarefa exige.

Uma quantização não uniforme mantém as camadas sensíveis em precisão maior e comprime as que importam menos, tudo dentro de um alvo fixo de tamanho. O resultado é um 27B abaixo de 12 GB, algo que um 4 bits uniforme não entrega quando você soma o contexto.

Com 24 GB, os mesmos pesos ficam em cerca de 16,5 GB e o resto do cartão fica livre para um arquivo longo e uma conversa longa. Uma mudança real vive em vários arquivos: renomear uma função num, atualizar as chamadas em outro, corrigir o teste que quebra num terceiro. Um 9B não tem espaço para manter esse quadro inteiro.

## 32 GB: mistura de especialistas e o que ela compra

Com 32 GB você escolhe entre maximizar o 27B em 6 bits, perto de 22 GB, ou subir para um modelo de 35 bilhões de parâmetros em torno de 25 GB. A escolha ensina a diferença entre velocidade e conhecimento.

Um modelo de mistura de especialistas ativa só uma parte dos parâmetros por token. Um 35B total pode disparar cerca de 3 bilhões por token e correr perto da velocidade de um 3B, carregando o conhecimento de um 35B.

O detalhe que muita gente perde é que os 35 bilhões inteiros precisam caber na memória de qualquer forma. Esparsidade compra velocidade, não espaço; você só deixa de pagar compute por todo parâmetro em cada palavra. A decepção aparece quando você espera qualidade de 35B em tudo: com 3 bilhões ativos por token, o raciocínio mais difícil fica mais fino que o número do título promete.

## 48 GB a 128 GB: agente de código e o gargalo do barramento

De 48 GB a 128 GB você roda um agente de código de verdade, que lê o erro, edita o arquivo, roda os testes, lê o novo erro e repete mantendo a cadeia em contexto. Nessa faixa, o gargalo deixa de ser o chip e passa a ser o barramento entre a GPU e a memória do sistema.

Modelos dessa classe carregam cerca de um quarto de milhão de tokens de contexto nativamente, o que permite ao agente manter uma tarefa inteira em vista. Quando você empurra camadas para a RAM do sistema, o modelo atravessa esse barramento toda hora e a GPU fica parada esperando dado.

A fase pior é a leitura inicial de um prompt longo, quando as partes fora da GPU precisam cruzar o barramento antes de o modelo escrever a primeira palavra. Um runtime bem configurado adianta a busca durante o compute; uma configuração descuidada deixa o chip rápido ocioso boa parte do tempo.

### Quando 1 GB muda a decisão

Duas placas separadas por 1 GB no papel podem inverter a escolha. Uma placa de data center de 94 GB usa memória HBM rápida e link dedicado entre chips; uma estação de trabalho de 96 GB usa GDDR7 e link mais lento. Em uma única placa, benchmarks publicados colocam a de 96 GB ligeiramente à frente em throughput bruto.

Ao juntar quatro placas, a de 94 GB se distancia, porque o link entre chips move centenas de gigabytes por segundo contra dezenas na outra. São números de benchmarks publicados, não de teste próprio, e o tamanho da memória não previu nada disso.

## 141 GB ou mais: memória unificada, SSD e o que muda

Acima de 141 GB entram memória unificada grande, múltiplas GPUs e modelos que não caberiam de outra forma. Mesmo aqui, um modelo menor e mais esparso com folga para rodar tende a ser mais útil no dia a dia que o gigante que mal carrega.

Memória unificada é um pool único compartilhado pelo computador inteiro. Cinquenta e doze gigabytes dela não são 512 GB de VRAM dedicada: num Mac, esse pool divide espaço com todo o sistema e opera em banda menor que uma pilha de placas de data center. Duas placas somando o mesmo total são rápidas, mas o modelo precisa ser dividido entre elas, com as dores próprias dessa divisão.

Existe também a ideia de separar o modelo por quão quente cada parte é. Uma tabela de consulta usada de vez em quando e de forma previsível pode ficar no SSD e ser buscada a tempo, enquanto os pesos tocados o tempo todo ficam em memória rápida. Já existe implementação experimental nessa direção, então não aposte um prazo nela ainda.

## Perguntas frequentes sobre modelos locais por VRAM

- **Quantos GB de VRAM preciso para rodar um modelo de 9B em 4 bits?** Cerca de 5,75 GB só de pesos, o que cabe num cartão de 8 GB e deixa pouco mais de 2 GB. Esse resto precisa cobrir o cache KV e o scratch do runtime, então prompts longos ainda podem derrubar o processo. O ajuste mais barato é encurtar o contexto antes de trocar de modelo.

- **Por que o modelo carrega mas trava ao editar o primeiro arquivo?** Porque o consumo cresce depois do carregamento. Cada token de prompt e de resposta entra no cache KV, e alguns milhares de tokens já somam centenas de megabytes. Quando a soma de pesos, cache e scratch passa da memória disponível, o sistema transborda para um caminho mais lento ou falha.

- **Vale mais subir para um modelo maior ou aumentar os bits?** Depende da tarefa, mas com memória sobrando aumentar a precisão costuma dar retorno confiável. A faixa de 4 a 5 bits quase não move os resultados, enquanto abaixo de cerca de 3 bits os erros novos aparecem. Subir de tamanho só compensa se sobrar contexto para a tarefa que você quer resolver.

- **Posso rodar um modelo grande dividindo camadas na RAM do sistema?** Dá para tentar, mas o barramento entre GPU e memória vira o limite. A GPU fica ociosa esperando os dados das camadas que você empurrou para a RAM, e a fase de leitura de um prompt longo é a pior de todas. O resultado tende a ser instável em trabalhos longos.

- **Memória unificada de 512 GB substitui 512 GB de VRAM?** Não. A memória unificada é um pool compartilhado com o sistema inteiro e opera em banda menor que placas de data center. O modelo pode caber com conforto e ainda gerar tokens mais devagar do que o número grande da ficha técnica sugere.

[Source video](https://www.youtube.com/watch?v=qkRIW2ieOK8)