Ejecutar LLMs gigantes en GPUs pequeñas: cuando el cuello de botella pasa de la VRAM al NVMe

Durante años, la regla parecía clara: si querías ejecutar modelos de lenguaje grandes en local, necesitabas mucha VRAM. No había demasiada discusión. Una GPU de consumo podía servir para modelos pequeños o medianos, especialmente si se usaba cuantización, pero en cuanto se hablaba de modelos de decenas de miles de millones de parámetros, el salto natural era una GPU profesional, varias tarjetas o directamente infraestructura cloud.

Sin embargo, están apareciendo proyectos que atacan el problema desde otro ángulo. En lugar de intentar meter todo el modelo en la memoria de la GPU, lo dividen, lo cargan por capas y usan el almacenamiento NVMe como una extensión activa del proceso de inferencia. No es magia, no elimina los límites físicos y no convierte una tarjeta doméstica en una GPU de datacenter, pero sí cambia el tipo de experimentos que se pueden hacer desde una estación de trabajo normal.

Uno de los proyectos más interesantes en esta línea es oLLM, una librería ligera en Python construida sobre Hugging Face Transformers y PyTorch. Su propuesta es clara: permitir inferencia local con modelos grandes y contextos largos usando GPUs de consumo, sin recurrir necesariamente a cuantización, distilación o pruning. El repositorio menciona ejemplos como qwen3-next-80B, gpt-oss-20B, Gemma 3 12B o Llama 3.1 8B Instruct, ejecutándose con contextos de hasta 100k tokens en GPUs NVIDIA de 8 GB de VRAM.

La idea puede sonar contraintuitiva, pero para administradores de sistemas y desarrolladores tiene bastante sentido: si no puedes ampliar fácilmente la VRAM, puedes rediseñar el flujo de datos para que la GPU solo tenga cargado lo que necesita en cada momento.

El problema real: pesos, KV cache y contexto

Cuando se habla de ejecutar un LLM en local, muchas veces se simplifica todo diciendo que “el modelo ocupa X GB”. Pero eso es solo una parte del problema. En inferencia intervienen varios bloques de memoria:

• Los pesos del modelo.
• La caché KV generada durante la atención.
• Los tensores intermedios.
• El contexto de entrada.
• La memoria reservada por el framework y el runtime CUDA/ROCm/MPS.

Por eso un modelo que aparentemente “pesa” 16 GB puede requerir bastante más memoria en ejecución, especialmente con contextos largos. La KV cache se dispara a medida que aumenta la ventana de contexto, y ahí es donde muchas configuraciones locales empiezan a fallar.

oLLM aborda este problema moviendo parte de esa presión fuera de la VRAM. Sus mecanismos principales son:

• Carga de pesos desde SSD a GPU capa por capa.
• Offloading de KV cache a SSD.
• Offloading opcional de capas a CPU.
• Uso de FlashAttention-2 con online softmax para evitar materializar la matriz completa de atención.
• Chunked MLP para reducir el pico de memoria en proyecciones intermedias.

Dicho de forma sencilla: la GPU deja de tener que tragarse todo el modelo de golpe. Ejecuta una parte, libera memoria, carga la siguiente y continúa.

No es cuantización: es otra forma de mover el modelo

La diferencia con la cuantización es importante. La cuantización reduce el tamaño del modelo bajando la precisión de los pesos, por ejemplo a 8 bits, 4 bits o menos. Es una técnica muy útil y, en la práctica, es la que ha permitido popularizar la IA local en equipos de sobremesa. Herramientas como llama.cpp, Ollama, LM Studio o text-generation-webui han llevado este enfoque a muchísimos usuarios.

Pero cuantizar implica aceptar algún tipo de compromiso. En muchos casos la pérdida es pequeña, pero existe. Puede afectar más o menos según el modelo, el método de cuantización, la tarea y el tipo de prompt.

oLLM propone otra cosa: mantener precisión fp16/bf16 y usar almacenamiento NVMe para descargar pesos y caché. Esto no busca maximizar la velocidad, sino permitir que un modelo mucho más grande pueda ejecutarse en una máquina con VRAM limitada.

Para un desarrollador, esto abre una posibilidad interesante: probar el comportamiento de modelos grandes sin degradarlos agresivamente. Para un administrador de sistemas, permite montar laboratorios locales de inferencia avanzada sin tener que provisionar de entrada una GPU profesional con 48, 80 o 96 GB de memoria.

Qué se puede conseguir en la práctica

Según los datos publicados por el proyecto, oLLM puede ejecutar qwen3-next-80B con pesos bf16 de unos 160 GB y contexto de 50k tokens en una GPU de 8 GB, usando unos 7,5 GB de VRAM y alrededor de 180 GB de SSD.

También se citan otros casos:

Modelo	Pesos	Contexto	VRAM estimada sin offload	VRAM con oLLM	Uso aproximado de SSD
qwen3-next-80B	160 GB bf16	50k	~190 GB	~7,5 GB	180 GB
gpt-oss-20B	13 GB packed bf16	10k	~40 GB	~7,3 GB	15 GB
gemma3-12B	25 GB bf16	50k	~45 GB	~6,7 GB	43 GB
llama3-1B-chat	2 GB bf16	100k	~16 GB	~5 GB	15 GB
llama3-3B-chat	7 GB bf16	100k	~42 GB	~5,3 GB	42 GB
llama3-8B-chat	16 GB bf16	100k	~71 GB	~6,6 GB	69 GB

La cifra más llamativa es qwen3-next-80B en una GPU de 8 GB, pero también es la que mejor muestra la contrapartida: el rendimiento anunciado ronda 1 token cada 2 segundos. Eso no sirve para una experiencia conversacional fluida, pero sí puede ser suficiente para tareas offline.

Y ahí está el punto clave. oLLM no compite con una GPU de datacenter en throughput. Compite con la imposibilidad de ejecutar ciertos modelos en local.

Casos de uso para sysadmins y developers

Para un medio orientado a administradores de sistemas y desarrolladores, el interés no está en hacer una demo espectacular, sino en entender dónde encaja esta técnica.

Un primer caso claro es el análisis de documentación extensa. Contratos, normativas, manuales técnicos, informes de compliance, documentación legacy o RFCs pueden procesarse con ventanas de contexto mucho mayores sin depender de APIs externas.

Otro escenario es el análisis de logs y reportes de seguridad. Un administrador podría usar un modelo grande para revisar informes de amenazas, volcados de logs, trazas o documentación interna sin sacar datos sensibles fuera de su entorno.

También puede tener sentido para pruebas de modelos antes de desplegar en infraestructura mayor. Un equipo de desarrollo puede validar prompts, comportamiento, compatibilidad con adapters PEFT o capacidad de contexto antes de decidir si merece la pena mover el modelo a una GPU de más VRAM o a un entorno de producción.

Además, oLLM soporta casos multimodales como Gemma 3 12B con imagen y texto o Voxtral Small 24B con audio y texto, lo que lo hace interesante para laboratorios de IA local más allá del simple chatbot.

AirLLM: el precedente directo

oLLM no es el primer proyecto que explora esta vía. AirLLM ya popularizó la idea de ejecutar modelos de 70B en GPUs de 4 GB mediante inferencia por capas, sin cuantización, distilación ni pruning. También presume de poder ejecutar Llama 3.1 405B con 8 GB de VRAM, aunque de nuevo con las limitaciones de rendimiento esperables.

La filosofía es parecida: dividir el modelo, cargar las capas cuando se necesitan y reducir el consumo de VRAM. AirLLM añadió con el tiempo compresión opcional en 4 u 8 bits para acelerar la inferencia, porque en este enfoque el cuello de botella suele estar en la carga desde disco.

La diferencia más interesante es que oLLM parece especialmente orientado a contextos largos y a una integración más directa con modelos recientes sobre Hugging Face Transformers y PyTorch, incluyendo AutoInference para modelos Llama 3 y Gemma 3, soporte de adapters PEFT y offloading de KV cache a SSD.

El precio oculto: el SSD sufre

La parte menos vistosa, pero más importante para un administrador de sistemas, es el impacto sobre el almacenamiento. En estos enfoques el SSD deja de ser un simple repositorio de modelos y pasa a trabajar de forma intensiva durante la inferencia.

Esto tiene varias implicaciones prácticas.

La primera es el espacio. No basta con tener el modelo descargado. Algunos proyectos descomponen el modelo por capas, generan cachés y pueden duplicar temporalmente datos. Si se trabaja con modelos de 80B o 405B, el espacio necesario puede crecer muy rápido.

La segunda es la latencia y el ancho de banda real del NVMe. No todos los SSD son iguales. Un NVMe PCIe 4.0 o 5.0 con buena controladora, DRAM y disipación puede comportarse razonablemente bien. Un SSD barato, sin DRAM, casi lleno o con throttling térmico puede arruinar completamente la experiencia.

La tercera es el desgaste. El offloading constante de pesos y KV cache implica lecturas y, dependiendo de la configuración, también escrituras relevantes. En cargas ocasionales no debería ser un drama, pero en uso intensivo conviene monitorizar:

• TBW consumidos.
• Temperatura del NVMe.
• Throttling térmico.
• Errores SMART.
• Espacio libre.
• IOPS y latencia bajo carga.

Para pruebas serias, tiene sentido usar un NVMe dedicado para modelos y cachés, no el disco principal del sistema. También conviene evitar unidades QLC de gama baja si se pretende hacer uso intensivo.

Recomendaciones prácticas antes de probarlo

Para un laboratorio local, una configuración razonable debería incluir una GPU NVIDIA de 8 GB o más, un SSD NVMe rápido con espacio abundante, suficiente RAM del sistema y un entorno Python aislado mediante venv o conda.

En NVIDIA, oLLM puede beneficiarse de dependencias opcionales como kvikio y flash-attn, aunque el proyecto indica que ya no son obligatorias. Esto es relevante porque reduce las restricciones de hardware y facilita la instalación en más equipos.

La instalación básica parte de un entorno Python:

python3 -m venv ollm_env
source ollm_env/bin/activate
pip install --no-build-isolation ollm

O desde código fuente:

git clone https://github.com/Mega4alik/ollm.git
cd ollm
pip install --no-build-isolation -e .

Para NVIDIA con CUDA, se puede añadir kvikio:

pip install kvikio-cu12

Y para evitar problemas de fragmentación de memoria en PyTorch, el propio proyecto sugiere ejecutar ejemplos con:

PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True python example.py

En entornos de desarrollo, también es recomendable separar directorios:

• models/ para pesos.
• kv_cache/ para caché.
• Un volumen NVMe dedicado si es posible.
• Monitorización con nvme smart-log, iostat, iotop, nvidia-smi y métricas del sistema.

No es para producción interactiva, sí para laboratorio avanzado

La lectura correcta de oLLM no es “ya no hacen falta GPUs grandes”. Esa conclusión sería exagerada. Para producción, concurrencia, baja latencia, agentes interactivos o APIs con varios usuarios, sigue haciendo falta VRAM, ancho de banda de memoria y capacidad de cómputo.

La lectura correcta es otra: algunas cargas offline pueden beneficiarse de modelos grandes aunque sean lentos. Si un proceso tarda media hora pero permite analizar un informe completo con un modelo que antes ni siquiera podías cargar, el compromiso puede ser aceptable.

Esto encaja bien con tareas como:

• Análisis documental interno.
• Revisión de logs extensos.
• Laboratorios de IA privada.
• Pruebas de modelos antes de despliegue.
• Comparación de comportamiento entre modelos cuantizados y no cuantizados.
• Procesamiento local de datos sensibles.
• Experimentación con contextos muy largos.

Para desarrolladores, es una forma de acercarse a modelos grandes sin depender siempre de APIs externas. Para administradores de sistemas, es otro ejemplo de cómo la arquitectura de inferencia empieza a parecerse cada vez más a un problema clásico de sistemas: jerarquía de memoria, latencia, caché, throughput, almacenamiento y planificación de recursos.

El cambio de mentalidad

Durante mucho tiempo, el debate sobre IA local se ha centrado en “qué modelo cabe en mi GPU”. Proyectos como oLLM o AirLLM cambian la pregunta: “qué modelo puedo ejecutar si rediseño cómo se mueve la memoria”.

No es una solución universal. No es rápida. No es gratis para el SSD. Pero sí es una herramienta muy potente para determinados perfiles técnicos.

La clave está en asumir que la VRAM ya no es el único recurso crítico. La CPU, la RAM, el bus PCIe, el SSD, el sistema de ficheros, el runtime y la organización de las capas importan. Para quien viene del mundo de sistemas, esto resulta familiar: cuando no cabe todo en memoria rápida, se construye una jerarquía y se acepta el coste de moverse entre niveles.

En ese sentido, oLLM no solo es una curiosidad para ejecutar modelos enormes en hardware modesto. Es una señal de hacia dónde puede evolucionar la inferencia local: menos obsesionada con cargarlo todo en GPU y más centrada en orquestar inteligentemente los recursos disponibles.

Preguntas frecuentes

¿oLLM sirve para usar un chatbot local rápido?
No es su caso de uso principal. Para chat fluido en local suele ser mejor usar modelos más pequeños y cuantizados. oLLM tiene más sentido para inferencia offline, contextos largos y pruebas con modelos grandes sin reducir precisión.

¿Qué ventaja tiene frente a cuantizar el modelo?
La principal ventaja es que permite mantener fp16/bf16 y evitar parte de la degradación asociada a ciertas cuantizaciones. La desventaja es que la inferencia será mucho más lenta y dependerá mucho del SSD.

¿Qué tipo de SSD conviene usar?
Lo ideal es un NVMe rápido, con buena controladora, buena refrigeración y resistencia razonable. Para uso intensivo, mejor dedicar un SSD específico a modelos y cachés, y evitar unidades de gama baja o discos casi llenos.

¿Puede usarse en producción?
Para producción interactiva o con varios usuarios no parece la opción adecuada. Para procesos batch, análisis offline, laboratorios internos o evaluación de modelos, puede ser muy útil.

¿AirLLM y oLLM hacen lo mismo?
Comparten una filosofía similar: reducir VRAM mediante carga por capas y offloading. AirLLM fue uno de los proyectos que popularizó este enfoque. oLLM añade un foco claro en contextos largos, caché en SSD, modelos recientes y uso con Hugging Face Transformers/PyTorch.