Hoe VRAM besparen bij het uitvoeren van AI-modellen lokaal zonder van GPU te wisselen

Ejecutar un modelo de inteligencia artificial en tu propio ordenador se ha vuelto mucho más accesible, pero la VRAM sigue determinando gran parte de los límites. Técnicas como la cuantización, FlashAttention, reducción del tamaño del contexto, caché KV optimizada y CPU offload permiten aprovechar mejor una GPU, aunque siempre hay que tener cuidado con reglas universales: un modelo de 13B no requiere siempre la misma cantidad de memoria y reducir capas no garantiza mantener su rendimiento o calidad.

Las claves para reducir el uso de VRAM en un LLM en tan solo 30 segundos

• La cuantización INT8 o INT4 puede disminuir drásticamente el tamaño de los pesos.
• La VRAM requerida también depende del tamaño del contexto, la caché KV, el tamaño del lote (batch) y el motor de inferencia utilizado.
• FlashAttention disminuye el uso de memoria durante el proceso de atención, pero su ahorro varía y no es un porcentaje fijo.
• El CPU offload permite superar la VRAM física usando la RAM, aunque con una penalización variable en rendimiento.
• Herramientas como llama.cpp y vLLM integran varias de estas optimizaciones directamente en su núcleo.

El auge de modelos abiertos y herramientas como llama.cpp, Ollama, vLLM o Transformers ha hecho posible ejecutar modelos de lenguaje localmente, sin necesidad de enviar cada consulta a una API externa. Sin embargo, el problema aparece cuando se descarga un modelo y la GPU se queda sin memoria incluso antes de generar el primer token.

La solución no siempre pasa por comprar una tarjeta gráfica más potente. Hay margen para adaptar y optimizar la ejecución del modelo según el hardware disponible.

La VRAM de un LLM no depende solo de sus parámetros

Una aproximación sencilla ayuda a entender rápidamente el problema. Si un modelo tiene 7.000 millones de parámetros y cada uno ocupa 16 bits, sus pesos requerirán aproximadamente 14 GB de memoria.

El cálculo básico sería:

memoria = número de parámetros × bits por parámetro / 8

Aplicando esto a diferentes precisiones:

Estas cifras sirven como referencia para el tamaño de los pesos, no como una necesidad total de memoria.

Un modelo cuantizado a cuatro bits ocupa más que ese cálculo simple debido al formato, las escalas, los metadatos y otros elementos. Durante la inferencia, hay que sumar buffers de ejecución y, especialmente, la KV cache.

Por tanto, dos usuarios pueden ejecutar el mismo modelo y usar cantidades de VRAM bastante diferentes.

INT4 e INT8: cuantiza antes de comprar más memoria

La cuantización sigue siendo una de las técnicas más efectivas para correr modelos grandes con recursos limitados.

En lugar de almacenar los pesos en FP16 o BF16, se representan con menos bits. Reducir de 16 a 8 bits puede casi reducir a la mitad el tamaño, y usar 4 bits puede disminuirlo aún más.

El ecosistema actual ofrece múltiples opciones.

llama.cpp habitualmente usa modelos en formato GGUF y soporta diferentes niveles de cuantización. GPTQ y AWQ son otras técnicas ampliamente utilizadas, mientras que Hugging Face incorpora cuantización con bitsandbytes. vLLM también soporta diversos formatos y técnicas para reducir la memoria durante la inferencia.

Eso sí, cuantizar no es gratis.

Reducir la precisión puede introducir pérdida de calidad, y ésta puede variar según el modelo y la tarea. Un modelo para conversación general puede tolerar una cuantización más agresiva que uno diseñado para código, razonamiento o tareas especializadas.

La clave práctica está en encontrar el equilibrio donde el ahorro de memoria justifique la posible degradación en calidad.

El tamaño del contexto puede consumir más memoria de lo esperado

Hay un elemento a menudo olvidado al calcular VRAM: la longitud del contexto.

Los modelos transformer mantienen información de tokens previos en la KV cache (Key-Value cache). Gracias a ella, no necesitan recalcular toda la secuencia en cada generación de token.

Este mecanismo acelera la generación, pero también consume memoria.

Cuanto mayor sea el contexto, más memoria requerirá esa caché.

Por eso, configurar automáticamente ventanas de 64K, 128K o más tokens solo porque el modelo las soporta puede ser una mala decisión. El que un modelo soporte un tamaño de ventana no significa que esa capacidad tenga que usarse en todas las aplicaciones.

En GPUs limitadas, reducir la longitud del contexto puede liberar una cantidad significativa de memoria sin modificar los pesos.

Herramientas como vLLM permiten además trabajar con KV cache cuantizada y controlar la memoria reservada para ella, especialmente importante cuando varias solicitudes se sirven simultáneamente.

FlashAttention reduce memoria, pero no es una solución universal

FlashAttention es otra de las optimizaciones que han transformado la ejecución de transformers.

El método tradicional requiere gran cantidad de memoria intermedia, sobre todo con secuencias largas. FlashAttention reorganiza los cálculos para reducir accesos y movimientos de memoria, evitando materializar matrices completas.

El resultado puede ser menor consumo y mayor velocidad.

Pero atribuirle un ahorro fijo, como un 30 % de VRAM, puede ser engañoso.

El beneficio depende de factores como la longitud de la secuencia, la arquitectura, el batch, la GPU usada, la implementación y el tamaño de la memoria ocupada por los pesos.

Por ejemplo, si un modelo usa 20 GB de sus 24 GB de VRAM para los pesos, FlashAttention no reducirá esos 20 GB a 14 GB. Su impacto principal es sobre la memoria en la que realiza los cálculos de atención.

Actualmente, PyTorch integra implementaciones optimizadas de scaled dot product attention, y motores especializados en inferencia también emplean técnicas de atención eficaces en memoria.

Batch pequeño en escritorio, batch eficiente en servidores

Reducir el tamaño del batch es una estrategia sencilla y efectiva.

Si solo hay una petición activa, no tiene sentido reservar memoria para varias secuencias simultáneas. Usar un batch size pequeño puede disminuir las activaciones y buffers necesarios durante la ejecución.

Para un PC personal, puede ser una buena opción.

Pero en entornos de producción la situación cambia.

Un servidor que atiende a decenas o cientos de usuarios necesita aprovechar al máximo la GPU. Reducir el batch a ciegas solo para disminuir el uso de memoria puede subutilizar el hardware, que puede costar miles de euros.

vLLM emplea continuous batching para combinar solicitudes y mejorar la eficiencia del procesador.

La estrategia óptima dependerá de si tu objetivo es simplemente hacer que un modelo quepa en una GPU doméstica o maximizar los tokens procesados por segundo en un entorno de servidor.

CPU offload: usar RAM cuando se agota la VRAM

Cuando un modelo es demasiado grande para la VRAM, una solución práctica y efectiva es trasladar parte de sus pesos a la memoria RAM.

herramientas como llama.cpp permiten distribuir el trabajo entre CPU y GPU. vLLM también soporta CPU offload.

Esto abre la puerta a ejecutar modelos cuyos pesos superan la memoria física de la GPU.

Pero la RAM no se convierte mágicamente en VRAM.

Cuando la GPU necesita datos de la memoria principal, estos deben transferirse entre componentes, lo que puede afectar el rendimiento, especialmente en sistemas con solo GPU dedicada mediante PCI Express.

Cuanto mayor sea la parte del modelo trasladada a CPU, mayor será el impacto en rendimiento.

Por eso, no hay una regla fija que diga que con CPU offload el modelo será solo un 20 % o un 30 % más lento. Puede ser menos o mucho más.

Para uso personal, puede ser aceptable. Para aplicaciones con alta demanda, quizás no tanto.

Podar capas no es lo mismo que optimizar memoria

Eliminar capas de un modelo requiere un tratamiento distinto.

Es técnicamente posible reducir un transformer eliminando ciertas capas, y existen investigaciones en layer pruning y otras técnicas de compresión estructural.

Pero en estos casos, se está modificando la arquitectura del modelo.

No es lo mismo que ejecutar los mismos pesos en bits más bajos.

Quitar las últimas dos o cuatro capas de un modelo de 13B no garantiza mantener toda su capacidad. El resultado dependerá mucho del modelo y de las tareas para las cuales se utilice, y debe evaluarse en consecuencia.

Para quien solo busca correr un LLM en una GPU pequeña, la cuantización, la gestión del contexto, la caché KV y el offload suelen ser opciones más seguras antes de optar por pruning.

Todavía hay mucho por hacer con GPUs de 8 GB

El avance en cuantización ha dado una segunda vida a GPUs que parecían demasiado pequeñas para IA generativa.

Con 8 GB de VRAM, es posible ejecutar muchos modelos pequeños y medianos cuantizados. Los modelos de unos 7B u 8B son especialmente adecuados para esta categoría.

Con 12 o 16 GB, las opciones para modelos mayores o contextos más amplios se amplían significativamente.

Las GPUs de 24 GB abren otra categoría, permitiendo trabajar con modelos mucho más grandes o repartir la memoria entre pesos y contextos largos de forma más cómoda.

Y a partir de ahí aparecen configuraciones multi-GPU y aceleradores profesionales con memorias aún mayores.

Pero tener más VRAM no siempre significa una mejor configuración.

La optimización cambia cuando el LLM pasa a producción

La obsesión por hacer que un modelo «quepa» en tu máquina personal tiene sentido solo en ese contexto. En el mundo empresarial, la realidad es mucho más compleja.

Una infraestructura de inferencia debe considerar VRAM, ancho de banda, potencia de cálculo, RAM, CPU, almacenamiento, red y consumo energético.

Hay métricas que no se ven en una simple captura de nvidia-smi: tiempo hasta el primer token, tokens por segundo, concurrencia, throughput total y coste por millón de tokens.

Un modelo de 70B que funcione con mucho CPU offload puede ser técnicamente viable, pero no ideal para atender usuarios en producción.

Un modelo de 8B bien diseñado, cuantizado y especializado puede conseguir tareas específicas con mucha menos infraestructura.

Una de las decisiones más estratégicas en proyectos de IA empresarial es: no elegir primero el modelo y después dónde ejecutarlo.

Es mejor empezar por definir los requerimientos: qué información recibe, qué respuestas debe dar, qué precisión es necesaria, cuántas peticiones atenderá, qué latencia es aceptable y qué datos pueden salir de la organización.

Solo así se podrá dimensionar correctamente la memoria GPU, la infraestructura y el hardware necesarios.

La ingeniería de inferencia local avanza en ese sentido: obtener más rendimiento con los recursos existentes. La cuantización y otras técnicas ayudan, pero la clave real está en diseñar modelo, contexto, runtime y hardware como un sistema integral.

Preguntas frecuentes

¿Cuánta VRAM necesita realmente un modelo de 13B?

Sus pesos ocupan aproximadamente 26 GB en FP16 y unos 6,5 GB en teoría usando cuantización de 4 bits. Sin embargo, el consumo real será mayor, al incluir formatos de cuantización, la caché KV, buffers y la memoria necesaria para el runtime.

¿Es mejor INT8 o INT4 para ejecutar un LLM?

INT4 reduce aún más el tamaño, pero conserva menos precisión numérica que INT8. La elección adecuada dependerá del modelo, el hardware disponible y la calidad requerida; lo más recomendable es evaluar en tareas reales.

¿Qué hacer si un modelo no cabe en la GPU?

Las opciones incluyen usar cuantización más agresiva, reducir el tamaño del contexto, optimizar la caché KV, aplicar CPU offload o distribuir el modelo en varias GPUs si el motor de inferencia lo soporta.

¿FlashAttention siempre reduce el uso de VRAM?

No siempre, aunque acostumbra a reducir la memoria para cálculos de atención. El porcentaje exacto de ahorro depende de la longitud de la secuencia, arquitectura, batch, GPU y la implementación específica. No es una solución mágica, pero puede variar significativamente el consumo.