Los modelos de lenguaje de gran tamaño locales se sienten increíblemente rápidos al principio. Cargas un modelo de 7B o 13B parámetros, lanzas un prompt corto y los tokens fluyen por la pantalla a un ritmo cómodo. Luego pegas un bloque de código largo, o tu historial de chat crece a lo largo de una docena de turnos, y el modelo empieza a ir a paso de tortuga. La ralentización rara vez es gradual. Es un precipicio. En un momento la GPU está produciendo tokens; al siguiente, el monitor de tu sistema muestra que aumenta la presión de memoria y la generación se ralentiza hasta tartamudear. No puedes predecir exactamente cuándo sucederá esto con una fórmula sencilla. Tu única guía fiable es el propio hardware.

El coste oculto del contexto

Cada token que generas añade estado al KV cache. Este caché almacena las claves y los valores calculados durante las fases de prefill y generación, y reside en la memoria junto con los pesos del modelo, los buffers de atención y la sobrecarga de ejecución (runtime overhead). En una GPU de consumo típica con 12 GB o 16 GB de VRAM, el KV cache acaba compitiendo por el espacio con todo lo demás. Cuando la memoria de vídeo dedicada se llena, el sistema operativo no lanza un error y se detiene. Simplemente vuelca el exceso en la memoria compartida, trasladando datos entre la GPU y la RAM del sistema a través del bus PCIe. Ese bus es rápido para transferencias de archivos, pero es glacial en comparación con el ancho de banda de memoria dentro de una tarjeta gráfica. El resultado no es una pequeña caída en el rendimiento. Es un colapso.

Tres señales de que el precipicio ha llegado

Observa tus monitores de hardware mientras el modelo se ejecuta. Verás tres señales claras una vez que se alcance el precipicio de rendimiento.

  • La VRAM compartida aumenta. Esta es la memoria que el controlador de la GPU ha desplazado de la VRAM dedicada al grupo gestionado por el sistema operativo anfitrión. En el momento en que esta métrica sube de cero, has cruzado la línea.
  • El uso de la RAM del sistema aumenta. El exceso tiene que aterrizar en algún lugar, y ese destino es tu memoria principal. Si el uso de tu RAM crece mientras el modelo genera tokens, se están descargando datos de la GPU.
  • La velocidad de evaluación (eval speed) cae a la mitad o más. Una ralentización del 10% podría significar estrangulamiento térmico (thermal throttling) o procesos en segundo plano. Una caída del 50%, o peor, significa que el cuello de botella se ha desplazado de los tensor cores al ancho de banda de memoria y a la latencia de PCIe. Cuando veas que la generación cae de dos dígitos a uno, ya te habrás caído por el precipicio.

Por qué tu benchmark rápido probablemente te está mintiendo

Una breve prueba de humo te dará una falsa confianza. Si haces un benchmark del modelo con un prompt de cien tokens, ves un rendimiento saludable y lo das por terminado, solo has medido la fase de luna de miel. El KV cache está casi vacío. Las capas no han sido sometidas al estrés de un prefill largo. La verdadera huella solo se revela después de que el modelo haya procesado un prompt sustancial y el caché se haya llenado hasta su tamaño de trabajo real. Debes realizar pruebas con un prefill profundo y ejecuciones de generación largas. Deja que el contexto se acumule realmente. Solo entonces la presión de memoria se estabilizará y te mostrará el límite real.

Encontrando tu límite con llama.cpp

Si estás ejecutando modelos a través de llama.cpp, puedes medir tu muro con aritmética simple y una ejecución de prueba paciente.

1. Mide el uso de la memoria compartida.
Registra tu VRAM dedicada de referencia con un prompt mínimo, luego ejecuta una tarea de contexto largo y anota el pico. Resta la referencia del pico. La diferencia es lo que se ha desbordado de tu GPU hacia la memoria compartida del sistema.

2. Calcula tu delta de RAM.
Realiza la misma resta para la RAM del sistema. Resta tu RAM de referencia del pico de RAM durante la ejecución larga. Este número te indica exactamente cuántos datos se han desplazado de la tarjeta de vídeo a tu memoria principal. Cuantifica la fuga a través del bus.

3. Cronometra el colapso de la velocidad de evaluación.
Compara tu tasa de referencia de tokens por segundo con la tasa después de que el modelo haya procesado un documento largo. Podrías ver un modelo avanzar a diecisiete tokens por segundo cuando el contexto es nuevo, para luego entregar solo dos tokens por segundo una vez que el caché se ha inflado. Esa caída de quince tokens es tu canario en la mina.

Triangulando el punto 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.