Ejecutar un modelo de inteligencia artificial en un ordenador propio se ha vuelto mucho más accesible, pero la VRAM sigue marcando buena parte de los límites. Cuantización, FlashAttention, reducción del contexto, KV cache optimizada y CPU offload permiten aprovechar mejor una GPU, aunque conviene huir de reglas universales: un modelo de 13B no necesita siempre la misma memoria y reducir capas no garantiza conservar su calidad.

Las claves para reducir la VRAM de un LLM en 30 segundos

• La cuantización INT8 o INT4 puede reducir drásticamente la memoria ocupada por los pesos.
• La VRAM necesaria depende también del contexto, la KV cache, el batch y el motor de inferencia.
• FlashAttention reduce memoria durante la atención, pero su ahorro no es un porcentaje fijo.
• CPU offload permite superar la VRAM física utilizando RAM, con una penalización variable de rendimiento.
• Herramientas como llama.cpp y vLLM ofrecen varias de estas optimizaciones directamente.

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

La solución no consiste necesariamente en comprar otra tarjeta gráfica. Hay bastante margen para adaptar el modelo y su ejecución al hardware disponible.

La VRAM de un LLM no depende únicamente de sus parámetros

Una aproximación inicial permite entender rápidamente el problema. Si un modelo tiene 7.000 millones de parámetros y cada parámetro ocupa 16 bits, sus pesos necesitan aproximadamente 14 GB.

La cuenta básica es:

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

Aplicándola a diferentes precisiones:

Modelo	FP16	INT8 teórico	4 bits teórico
7B	14 GB	7 GB	3,5 GB
13B	26 GB	13 GB	6,5 GB
32B	64 GB	32 GB	16 GB
70B	140 GB	70 GB	35 GB

Estas cifras sirven como orientación para los pesos, no como requisito total de memoria.

Un modelo cuantizado a cuatro bits ocupa más que el resultado de esa sencilla multiplicación debido al formato utilizado, escalas, metadatos y otros elementos. Durante la inferencia hay que sumar además buffers de ejecución y, especialmente, la KV cache.

Por eso dos usuarios pueden ejecutar exactamente el mismo modelo y obtener consumos de VRAM bastante diferentes.

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

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

En lugar de almacenar los pesos utilizando FP16 o BF16, se representan con menos bits. Reducir de 16 a 8 bits puede acercar el consumo de los pesos a la mitad, mientras que utilizar cuatro bits permite reducirlo todavía más.

El ecosistema ofrece actualmente numerosas alternativas.

llama.cpp utiliza habitualmente modelos en formato GGUF y dispone de diferentes niveles de cuantización. GPTQ y AWQ son otras dos técnicas ampliamente utilizadas, mientras que Hugging Face integra cuantización mediante bitsandbytes. vLLM también admite distintos formatos y técnicas para reducir la memoria necesaria durante la inferencia.

La contrapartida es que cuantizar no sale completamente gratis.

Reducir la precisión puede introducir pérdida de calidad, y esta no tiene por qué ser idéntica en todos los modelos ni tareas. Un modelo utilizado para conversación general puede tolerar una cuantización agresiva mejor que otro destinado a código, razonamiento o una aplicación especializada.

La cuestión práctica pasa por encontrar el punto en el que el ahorro de memoria compensa la posible degradación.

El contexto puede acabar ocupando más de lo esperado

Hay otro elemento que frecuentemente se olvida al calcular la VRAM: la longitud de contexto.

Los modelos transformer mantienen información de los tokens previamente procesados mediante la denominada KV cache (Key-Value cache). Gracias a ella no necesitan recalcular toda la secuencia cada vez que generan un nuevo token.

El mecanismo acelera considerablemente la generación, pero consume memoria.

Y cuanto mayor es el contexto, mayor puede ser esa memoria.

Es una de las razones por las que configurar automáticamente 64K, 128K o más tokens simplemente porque el modelo los admite puede ser una mala decisión. Que un modelo soporte una determinada ventana de contexto no significa que una aplicación necesite utilizarla permanentemente.

En una GPU limitada, bajar la longitud máxima del contexto puede liberar una cantidad importante de memoria sin modificar los pesos.

Motores como vLLM permiten además trabajar con KV cache cuantizada y controlar la memoria reservada para ella, algo especialmente relevante cuando se sirven varias peticiones simultáneamente.

FlashAttention reduce memoria, pero no hace milagros

FlashAttention es otra de las optimizaciones que han cambiado la forma de ejecutar transformers.

El mecanismo de atención convencional puede requerir grandes cantidades de memoria intermedia, especialmente a medida que aumenta la secuencia. FlashAttention reorganiza los cálculos para reducir accesos y movimientos de memoria y evitar materializar determinadas matrices completas.

El resultado puede ser menos consumo y mayor velocidad.

Sin embargo, atribuirle un ahorro universal, por ejemplo del 30 % de VRAM, resulta engañoso.

El beneficio depende de la longitud de la secuencia, arquitectura, batch, GPU, implementación y cantidad de memoria que ya ocupan los pesos.

Si un modelo utiliza 20 GB para sus pesos dentro de una GPU de 24 GB, FlashAttention no va a convertir esos 20 GB en 14 GB. Su efecto se produce principalmente sobre la memoria utilizada durante los cálculos de atención.

PyTorch incorpora actualmente implementaciones optimizadas de scaled dot product attention, mientras que motores especializados en inferencia también aprovechan técnicas de atención eficientes en memoria.

Batch pequeño para escritorio, batching eficiente para servidores

Reducir el batch es otro recurso sencillo.

Si únicamente existe una petición activa, no tiene demasiado sentido reservar memoria para procesar numerosas secuencias simultáneamente. Un batch size pequeño puede reducir activaciones y buffers necesarios durante la ejecución.

En un PC utilizado por una sola persona puede resultar una buena estrategia.

La situación cambia en producción.

Un servidor que atiende decenas o cientos de usuarios necesita aprovechar la capacidad paralela de la GPU. Reducir indiscriminadamente el batch podría disminuir el consumo de memoria, pero también desaprovechar una GPU que cuesta miles o decenas de miles de euros.

vLLM utiliza precisamente continuous batching para combinar solicitudes y mejorar el aprovechamiento del acelerador.

La optimización adecuada depende, por tanto, de si se persigue hacer entrar un modelo en una GPU doméstica o maximizar los tokens procesados por segundo en un servidor.

CPU offload: utilizar RAM cuando se acaba la VRAM

Cuando el modelo continúa siendo demasiado grande existe una solución especialmente práctica: colocar parte de sus pesos en la memoria RAM.

llama.cpp permite repartir el trabajo entre CPU y GPU. vLLM también ofrece mecanismos de CPU offload.

Eso permite escenarios que de otra manera serían imposibles. Un equipo con 24 GB de VRAM y mucha RAM puede ejecutar modelos cuyos pesos superan físicamente la memoria de su GPU.

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

Cuando la GPU necesita información almacenada en la memoria principal, los datos tienen que desplazarse entre ambos componentes. En equipos con GPU dedicada, PCI Express pasa entonces a formar parte del rendimiento de inferencia.

Cuanto mayor sea la parte descargada a CPU, mayor puede ser el impacto.

Por este motivo tampoco existe una regla fiable que diga que el CPU offload hace que un modelo funcione únicamente un 20 % o un 30 % más lento. Puede ser menos, pero también mucho más.

Para uso personal puede compensar perfectamente. Para serving con alta concurrencia, quizá no.

Podar capas no es equivalente a optimizar memoria

Eliminar capas de un modelo merece un tratamiento diferente.

Es técnicamente posible reducir un transformer eliminando determinadas capas, y existen investigaciones sobre layer pruning y otras formas de compresión estructural.

Pero aquí se está modificando la arquitectura.

No es equivalente a ejecutar los mismos pesos utilizando cuatro bits.

Eliminar las últimas dos o cuatro capas de un modelo de 13B no permite afirmar automáticamente que conservará prácticamente toda su capacidad. El resultado depende enormemente del modelo y debería comprobarse mediante evaluaciones sobre las tareas para las que vaya a utilizarse.

Para alguien que simplemente intenta ejecutar un LLM en una GPU pequeña, cuantización, contexto, KV cache y offload son normalmente opciones más conservadoras antes de recurrir al pruning.

Una GPU de 8 GB todavía tiene bastante recorrido

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

Con 8 GB de VRAM pueden ejecutarse numerosos modelos pequeños y medianos cuantizados. Los modelos de aproximadamente 7B u 8B son especialmente interesantes para esta categoría.

Con 12 o 16 GB aumenta considerablemente el margen para utilizar modelos mayores, contextos más amplios o cuantizaciones menos agresivas.

Las GPU de 24 GB abren otra categoría y permiten trabajar con modelos considerablemente mayores o repartir la memoria entre pesos y contextos largos con mayor comodidad.

A partir de ahí aparecen configuraciones multi-GPU y aceleradores profesionales con cantidades mucho mayores de memoria.

Pero tener más VRAM no convierte automáticamente una instalación en mejor.

La optimización cambia completamente cuando el LLM llega a producción

La obsesión por conseguir que un modelo «quepa» tiene sentido en un ordenador personal. En una empresa, el problema es bastante más amplio.

Una infraestructura de inferencia debe considerar simultáneamente VRAM, ancho de banda de memoria, potencia de cálculo, RAM, CPU, almacenamiento, red y consumo eléctrico.

También hay métricas que no aparecen en una sencilla captura de nvidia-smi: tiempo hasta el primer token, tokens por segundo, concurrencia, throughput agregado y coste por millón de tokens.

Un modelo de 70B ejecutándose con una enorme cantidad de CPU offload puede funcionar técnicamente, pero ser una pésima plataforma para atender usuarios.

Y un modelo de 8B correctamente seleccionado, cuantizado y especializado puede resolver determinadas tareas con mucha menos infraestructura.

Ahí aparece una de las decisiones más importantes de cualquier proyecto de IA empresarial: no elegir primero el modelo y buscar después dónde ejecutarlo.

Conviene empezar por el proceso.

Qué información recibe, qué respuesta debe producir, qué precisión necesita, cuántas peticiones tendrá que atender, qué latencia resulta aceptable y qué datos pueden salir de la organización.

Solo entonces tiene sentido decidir si hacen falta 8, 24, 80 o cientos de GB de memoria GPU.

La ingeniería de inferencia local está avanzando precisamente en esa dirección: conseguir más rendimiento con los mismos recursos. Cuantizar pesos es una parte de ese trabajo, pero la verdadera optimización aparece cuando modelo, contexto, runtime y hardware se diseñan como un único sistema.

Preguntas frecuentes

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

Sus pesos necesitan unos 26 GB en FP16 y alrededor de 6,5 GB teóricos a cuatro bits. El consumo real será superior porque hay que añadir el formato de cuantización, KV cache, buffers y memoria del runtime.

¿Es mejor INT8 o INT4 para ejecutar un LLM?

INT4 permite ahorrar más memoria, mientras que INT8 conserva mayor precisión numérica. La elección depende del modelo, hardware y calidad requerida, por lo que conviene evaluar el resultado sobre la tarea real.

¿Qué se puede hacer cuando un modelo no cabe en la GPU?

Las primeras opciones son utilizar una cuantización más pequeña, reducir el contexto y optimizar la KV cache. También puede recurrirse a CPU offload o repartir el modelo entre varias GPU si el motor de inferencia lo permite.

¿FlashAttention reduce siempre el consumo de VRAM?

Reduce especialmente la memoria asociada al cálculo de atención, pero no existe un porcentaje fijo de ahorro. Su efecto depende del modelo, la longitud de contexto, el batch, la GPU y la implementación utilizada.