Modelos de linguagem de grande escala (LLMs) locais parecem extremamente rápidos no início. Você carrega um modelo de 7B ou 13B parâmetros, envia um prompt curto e os tokens fluem pela tela em um ritmo confortável. Depois, você cola um bloco de código longo, ou seu histórico de chat aumenta ao longo de uma dúzia de turnos, e o modelo começa a rastejar. A desaceleração raramente é suave. É um precipício. Em um momento, a GPU está gerando tokens; no próximo, o monitor do sistema mostra a pressão de memória aumentando e a geração desacelera até começar a engasgar. Você não pode prever exatamente quando isso acontecerá com uma fórmula simples. Seu único guia confiável é o próprio hardware.

O Custo Oculto do Contexto

Cada token que você gera adiciona estado ao cache KV. Este cache armazena as chaves e valores computados durante as fases de prefill e geração, e reside na memória junto com os pesos do modelo, buffers de atenção e o overhead de tempo de execução. Em uma GPU de consumo típica com 12 GB ou 16 GB de VRAM, o cache KV acaba competindo por espaço com todo o resto. Quando a memória de vídeo dedicada enche, o sistema operacional não emite um erro e para. Ele silenciosamente transborda o excesso para a memória compartilhada, transportando dados entre a GPU e a RAM do sistema através do barramento PCIe. Esse barramento é rápido para transferências de arquivos, mas é glacial comparado à largura de banda de memória dentro de uma placa de vídeo. O resultado não é uma pequena queda de desempenho. É um colapso.

Três Sinais de que o Precipício Chegou

Observe seus monitores de hardware enquanto o modelo é executado. Você verá três sinais claros assim que o precipício de desempenho for atingido.

  • A VRAM compartilhada aumenta. Esta é a memória que o driver da GPU moveu da VRAM dedicada para o pool gerenciado pelo sistema operacional host. No momento em que essa métrica sobe acima de zero, você cruzou a linha.
  • O uso da RAM do sistema aumenta. O excesso tem que ir para algum lugar, e esse destino é a sua memória principal. Se o uso da sua RAM cresce enquanto o modelo gera tokens, os dados estão sendo descarregados da GPU.
  • A velocidade de avaliação (eval speed) cai pela metade ou mais. Uma desaceleração de 10% pode significar thermal throttling ou processos em segundo plano. Uma queda de 50%, ou pior, significa que o gargalo mudou dos tensor cores para a largura de banda de memória e a latência do PCIe. Quando você vê a geração cair de dois dígitos para um dígito, você já caiu no precipício.

Por que seu Benchmark Rápido Provavelmente está Mentindo

Um teste rápido pode lhe dar uma falsa sensação de confiança. Se você fizer o benchmark do modelo com um prompt de cem tokens, observar um throughput saudável e considerar o trabalho concluído, você mediu apenas a fase de lua de mel. O cache KV está quase vazio. As camadas não foram estressadas por um prefill longo. A verdadeira pegada (footprint) só se revela depois que o modelo processou um prompt substancial e o cache atingiu seu tamanho de trabalho real. Você deve testar com prefill profundo e execuções de geração longas. Deixe o contexto realmente acumular. Só então a pressão de memória se estabilizará e mostrará o limite real.

Encontrando seu Limite com llama.cpp

Se você estiver executando modelos através do llama.cpp, pode medir seu limite com aritmética simples e uma execução de teste paciente.

1. Meça o uso da memória compartilhada.
Registre sua VRAM dedicada de referência com um prompt mínimo, execute uma tarefa de contexto longo e anote o pico. Subtraia a referência do pico. A diferença é o que transbordou da sua GPU para a memória compartilhada do sistema.

2. Calcule o seu delta de RAM.
Faça a mesma subtração para a RAM do sistema. Subtraia a RAM de referência do pico de RAM durante a execução longa. Esse número diz exatamente quanta informação foi empurrada da placa de vídeo para a sua memória principal. Ele quantifica o vazamento através do barramento.

3. Cronometre o colapso da velocidade de avaliação.
Compare sua taxa de referência de tokens por segundo com a taxa após o modelo processar um documento longo. Você pode observar um modelo operando a dezessete tokens por segundo quando o contexto é novo, e entregar apenas dois tokens por segundo quando o cache estiver inchado. Essa queda de quinze tokens é o seu canário na mina de carvão.

Triangulando o Ponto de Ruptura

To map the curve accurately, do not settle for one lonely data point. Run three distinct trials at 16,000 tokens, 32,000 tokens, and 65,000 tokens. Two points might suggest a line, but two dots are just a guess. The third point proves whether you are looking at measurement noise or a real memory wall. Subtract the results between runs to calculate how much extra memory each additional thousand tokens consumes on your specific combination of model, quantization layer, and GPU.

Once you have that slope, you can project forward. Take your per-token cost, multiply it by the target context length, divide by 1024 to move between units, and add the result to your base model VRAM load. The equation looks like this:

Model VRAM load + (tokens × memory per token ÷ 1024) = Theoretical VRAM usage

This projection is not prophecy. It is a guidepost derived from actual behavior. Use it to estimate your ceiling before you commit to a full production run.

Why Paper Formulas Fail, and What Quantization Can Fix

Textbook formulas ignore the messy reality of local inference. Different architectures allocate attention buffers differently. Your operating system reserves VRAM for the display driver, compositor, and CUDA context. Driver versions change how aggressively they use shared memory. A theoretical equation cannot know how much VRAM is actually free on your machine at 2:00 PM with a browser full of tabs open. You have to run the model on your specific hardware and watch the meters.

Quantization offers partial relief. Moving the KV cache from f16 to q8_0 halves its memory footprint while keeping precision high enough for nearly all practical tasks. That change buys you headroom. It does not grant immunity. The cache still grows linearly with every token you feed in. Eventually, even the reduced size overwhelms your available dedicated memory and the spillover to system RAM begins. The pressure only stops when the context window is capped or the data stops moving.

The Real Takeaway

Do not trust marketing slides, parameter counts, or back-of-the-envelope math. Load the model. Open your system monitor. Run a 65,000-token thread, watch the RAM climb, and count the tokens per second. The numbers that appear on your specific screen, on your specific GPU, are the only numbers that matter. Context always wins. Your job is to know exactly when it wins on your machine.