LLM local sem VRAM? Veja pesos vs cache KV com gputaskman

Seu modelo local carregou bem ontem, hoje ele trava ao carregar ou fica lento, e a única coisa que você mudou foi o comprimento do contexto. Um culpado comum é o cache KV, e uma ferramenta de terminal gratuita chamada gputaskman pode mostrar isso em vez de te deixar adivinhando.

Um monitor de GPU típico te diz o quão cheia a VRAM está. Isso é o "o quê", não o "porquê". O README do gputaskman (verificado em 5 de novembro de 2026) se descreve como "Um htop para o que está dentro da sua GPU, não apenas o quão cheia ela está." É um projeto inicial, experimental, licenciado sob MIT, então trate-o como uma lente útil, não como um veredito.

O que realmente enche sua VRAM#

Pense na VRAM como uma mala. Três coisas entram nela:

• Pesos: o modelo em si. Tamanho fixo para um dado modelo e quantização.
• Cache KV: a memória de curto prazo do modelo sobre sua conversa. Ela cresce conforme o contexto cresce.
• Buffers de computação: espaço de rascunho que o runtime precisa enquanto trabalha.

Quando as pessoas dizem "o modelo não cabe", muitas vezes querem dizer que os pesos cabem, mas o cache que você pediu por cima não coube. Essa distinção decide a correção, e é exatamente o que um monitor comum esconde.

Instale o gputaskman e olhe por processo#

O README lista três formas de entrada: um ZIP portátil para Windows, um clone executado com uv run --locked gputaskman, ou pip dentro de um ambiente virtual Python 3.11+. Plataformas, conforme o README as descreve:

• Windows 10/11 64 bits com GPU NVIDIA ou AMD (ZIPs x64 e ARM64 na página de Releases);
• Linux e WSL com GPU NVIDIA (glibc 2.35+; o WSL pode ler contadores do host Windows);
• macOS apenas em Apple Silicon a partir de um clone do código-fonte, sem build portátil.

Os ZIPs para Windows não são assinados. Baixe-os apenas da página de Releases do repositório oficial, github.com/shanselman/gputaskman. Copie os comandos exatos do README: o projeto é jovem e as opções podem mudar.

Depois que estiver rodando, duas visões importam para este problema:

1. Visão do dispositivo: uso de VRAM, atividade da GPU, PCIe, temperatura, energia, clocks e gráficos de histórico. Boa para "algo deu um pico?"
2. Visão por processo: memória de GPU local por processo, RAM do sistema acessível pela GPU, atividade da engine e o runtime detectado (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime).

Na visão por processo, encontre seu servidor de modelo (para Ollama, seu runner embutido). Depois verifique o resto da lista. Se um navegador ou um jogo ocupa alguns gigabytes, você encontrou sua resposta sem mexer no modelo.

Pesos, cache KV, buffers: de onde vêm os números#

O inspetor de modelo mostra arquitetura, quantização e tamanhos de buffer quando disponíveis. Uma ressalva importa: conforme o README, pesos, cache KV e buffers de computação vêm dos logs de carregamento do runtime quando o logging compatível está habilitado. Para llama.cpp, inicie seu próprio llama-server com logging (--log-file server.log -lv 4; o README diz que o nível 4 é necessário para tamanhos de buffer). Para Ollama, o gputaskman usa o server.log do Ollama se estiver disponível. Caso contrário, são estimativas a partir dos metadados GGUF e do tamanho do contexto, assumindo posicionamento no estilo llama.cpp. A contabilização de KV por modelo dentro de um único processo ainda não é suportada.

Então leia uma divisão estimada como "aproximadamente", e uma divisão baseada em log como "o que o runtime reportou". Para Ollama, o README diz que runners embutidos são detectados, blobs GGUF são nomeados a partir dos manifestos do Ollama, e server.log é usado quando disponível. O suporte ao LM Studio é parcial: os modelos são nomeados a partir da pasta dele e sondados via sua API local, mas isso foi testado com respostas de fixture, não de ponta a ponta.

Você também pode salvar dois snapshots como JSON e compará-los com o comando diff. Essa é uma forma limpa de responder "o que mudou quando fui de contexto 4K para 16K?": tire um snapshot, mude a configuração, recarregue, tire outro.

Qual ajuste girar#

Ler a divisão te dá uma decisão, não apenas uma imagem.

Os pesos são a fatia grande. Mude para uma quantização menor ou um modelo menor. Esta é a única alavanca que encolhe os pesos. Se você quiser a matemática de memória por trás disso, veja Um modelo de 125B pode rodar em uma GPU de 16 GB?

O cache KV é a fatia grande. Encurte o contexto. No Ollama você pode tentar direto na sessão:

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 é apenas um valor de exemplo; escolha o que sua tarefa realmente precisa (comando conforme a documentação do Ollama, verificada em 5 de novembro de 2026).

Se depois você vir lentidão estranha no processamento de prompt com um cache quantizado no llama.cpp, esta correção para o cache KV q5_1 é o próximo passo. Para saber o que uma janela de contexto contém em primeiro lugar, leia O que é uma janela de contexto?

Outro processo é a fatia grande. Feche-o, ou rode-o na GPU integrada. Nada no modelo precisa mudar.

Se não funcionar#

• A divisão parece errada. Verifique se é uma estimativa (sem logs de carregamento compatíveis). Com llama.cpp, rode seu llama-server com --log-file server.log -lv 4 e recarregue o modelo. Com Ollama, o gputaskman usa server.log se existir; um rótulo de estimativa é normal ali.
• O LM Studio mostra menos detalhes. O suporte é parcial, como acima.
• Sem GPU NVIDIA ou AMD. A ferramenta cobre apenas cargas de trabalho de GPU local; cargas somente CPU, somente NPU e na nuvem estão fora do escopo.
• macOS. Rode a partir de um clone do código-fonte; não há build portátil.

Quando um modelo hospedado é a correção mais simples#

Digamos que você precise de um contexto longo para uma tarefa, como resumir um documento grande, e sua GPU só comporta o modelo com um contexto curto. Você pode continuar ajustando, ou tirar a VRAM da equação. Para tarefas assim, a CheapTokens oferece DeepSeek-V4-Flash: contexto de 380K, até 32.768 tokens de saída por resposta, um preço a qualquer hora do dia, através de uma API compatível com OpenAI. O GLM-5.3-Flash tem contexto de 390K e até 8.192 tokens de saída.

A chamada é no formato OpenAI usual (coloque sua chave em uma variável de ambiente):

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

Os detalhes de configuração estão na documentação. Uma regra prática para decidir: se uma tarefa continua precisando de mais contexto ou de um modelo maior do que sua placa comporta, e a visão por processo mostra que sua VRAM já está bem usada, envie essa tarefa para a API e mantenha os trabalhos pequenos e rápidos locais. Rodar DeepSeek localmente ou usar uma API? aprofunda o trade-off.

Digamos que você resuma 100 documentos grandes, cada um com 60.000 tokens de entrada e 1.000 tokens de saída (bem dentro da janela de 380K). Aqui está quanto custa hoje:

Nesses números, $0.001 por documento é o preço vigente para uma chamada dessas, e no total, com entrada e saída contadas juntas, fica abaixo do OpenRouter.