Ejecutar modelos de lenguaje grandes en local siempre ha tenido una barrera muy clara: la memoria de la GPU. No basta con tener una tarjeta gráfica razonablemente potente; hace falta que el modelo, sus pesos, la caché de atención y el contexto que se está procesando quepan en la VRAM. Por eso, durante los últimos años, la vía más habitual para llevar modelos grandes a equipos domésticos ha sido la cuantización: reducir precisión para que el modelo ocupe menos.
Pero proyectos como oLLM, desarrollado por Mega4alik, apuntan a una alternativa interesante: no comprimir necesariamente el modelo, sino cambiar la forma en la que se mueve por la máquina. En vez de cargar todos los pesos en la GPU, oLLM permite ejecutar inferencia de grandes modelos mediante SSD offloading, cargando capas desde un SSD NVMe cuando hacen falta y descargando parte de la caché al almacenamiento local. El proyecto afirma que puede ejecutar modelos como qwen3-next-80B, gpt-oss-20B o Llama-3.1-8B-Instruct con contextos muy largos usando una GPU de consumo de 8 GB de VRAM, sin cuantización y en precisión fp16/bf16.
La idea no elimina las limitaciones físicas, pero sí las desplaza. La GPU deja de ser el único cuello de botella y el SSD pasa a tener un papel protagonista. En otras palabras: ya no se trata solo de cuánta VRAM tienes, sino de cómo de rápido puedes mover datos entre disco, CPU y GPU.
Qué hace realmente oLLM
La propuesta de oLLM parte de una observación sencilla: durante la inferencia, un modelo Transformer ejecuta sus capas de forma secuencial. No todas las capas están calculando al mismo tiempo. Si el modelo tiene decenas de capas, puede cargarse una, ejecutarse, liberar memoria y pasar a la siguiente. Este enfoque, conocido como layer-wise inference, ya estaba presente en herramientas anteriores como AirLLM, pero oLLM lo lleva a un escenario especialmente llamativo: contextos largos, modelos grandes y GPUs de consumo.
Según la tabla publicada por el propio repositorio, un modelo como qwen3-next-80B tendría unos 160 GB de pesos en bf16, una caché KV de unos 20 GB para 50.000 tokens de contexto y una necesidad estimada de unos 190 GB de VRAM en una inferencia convencional. Con oLLM, esa carga se reduce a unos 7,5 GB de VRAM, apoyándose en aproximadamente 180 GB de SSD.
| Modelo | Pesos | Contexto | VRAM estimada sin offload | VRAM con oLLM | Uso 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-8B-chat | 16 GB bf16 | 100k | ~71 GB | ~6,6 GB | 69 GB |
Esto no significa que una RTX de 8 GB se convierta mágicamente en una H100. La velocidad baja, y bastante. El propio repositorio habla de 1 token cada 2 segundos para qwen3-next-80B, una cifra que no sirve para un chatbot fluido, pero sí puede ser aceptable para pruebas, análisis offline, investigación, resúmenes largos o procesamiento de documentación local.
La diferencia frente a la cuantización
La cuantización reduce el tamaño del modelo bajando la precisión de los pesos, por ejemplo a 8 bits, 4 bits o incluso menos. Esto ha permitido ejecutar modelos muy potentes en máquinas relativamente modestas, pero también introduce compromisos: pérdida de precisión, posibles degradaciones en determinadas tareas y diferencias de comportamiento frente al modelo original.
oLLM plantea otra vía: mantener fp16/bf16 y apoyarse en el almacenamiento local. No intenta hacer el modelo más pequeño, sino evitar que todo tenga que residir simultáneamente en la VRAM. Para determinadas cargas de trabajo, eso tiene sentido. Si el objetivo es analizar un contrato de cientos de páginas, procesar un informe técnico enorme o revisar logs de seguridad en local, quizá sea aceptable esperar más tiempo a cambio de usar un modelo grande sin recortes agresivos.
El propio proyecto enumera casos de uso como análisis de contratos, normativas, informes de cumplimiento, historiales médicos extensos, literatura médica, logs, informes de amenazas o conversaciones históricas para extraer patrones. Son escenarios en los que la latencia por token importa menos que la capacidad de meter mucho contexto en una sola pasada.
AirLLM ya abrió antes este camino
oLLM no aparece en el vacío. Antes, AirLLM popularizó una idea similar: ejecutar modelos grandes en GPUs pequeñas mediante inferencia por capas. Su repositorio afirma que permite correr modelos de 70B en una GPU de 4 GB sin cuantización, destilación ni pruning, y que incluso se puede ejecutar Llama 3.1 405B con 8 GB de VRAM.
La explicación técnica de AirLLM es clara: como las capas se ejecutan una detrás de otra, no es necesario mantener todo el modelo cargado en memoria de GPU. Se carga la capa necesaria, se calcula y se libera. En su artículo técnico publicado en Hugging Face, el autor explica que el cuello de botella real pasa a ser la lectura desde disco, por lo que el modelo se preprocesa y se divide por capas para evitar cargar fragmentos demasiado grandes de forma innecesaria.
AirLLM también incorporó posteriormente compresión opcional de pesos en 4 u 8 bits para acelerar la ejecución, con el argumento de que su cuello de botella principal está en la carga desde disco. Es decir, incluso en este tipo de enfoques, reducir el tamaño de lo que se lee desde almacenamiento puede mejorar mucho el rendimiento.
La cara B: el SSD trabaja mucho más
La principal pega de esta aproximación es evidente: el disco deja de ser un simple almacén y pasa a formar parte activa del proceso de inferencia. Eso tiene consecuencias.
Primero, hace falta mucho espacio libre. AirLLM advierte de que el modelo original se descompone y se guarda por capas, y pide asegurarse de tener suficiente espacio en la caché de Hugging Face. Su propia sección de FAQ indica que errores como MetadataIncompleteBuffer pueden deberse a falta de espacio, porque el proceso de división del modelo consume bastante disco.
Segundo, el rendimiento dependerá muchísimo del SSD. No es lo mismo usar un NVMe PCIe 4.0 o 5.0 con buen controlador, DRAM y disipación que un SSD barato, sin DRAM, saturado o térmicamente limitado. Si la inferencia depende de leer y escribir constantemente capas y caché KV, el almacenamiento puede convertirse en el cuello de botella dominante.
Tercero, está el desgaste. Los SSD modernos soportan grandes volúmenes de escritura, pero no son infinitos. En usos intensivos, especialmente si se offloadea la caché KV a disco y se trabaja con contextos enormes, conviene vigilar métricas SMART, temperatura, TBW consumidos y throttling térmico. Para pruebas ocasionales puede no ser grave; para uso diario o profesional, lo sensato sería dedicar un NVMe específico para caché y modelos, no machacar el disco principal del sistema.
No sustituye a una GPU profesional, pero cambia el acceso
Este tipo de herramientas no convierten un PC doméstico en un clúster de inferencia. La diferencia de velocidad frente a tener el modelo completo en VRAM sigue siendo enorme. Para aplicaciones interactivas, agentes en tiempo real, APIs de producción o cargas concurrentes, una GPU con mucha VRAM, varias GPUs o infraestructura especializada seguirán siendo la opción lógica.
Pero oLLM y AirLLM sí cambian algo importante: permiten experimentar con modelos grandes sin pasar necesariamente por una GPU profesional de miles o decenas de miles de euros. Para desarrolladores, investigadores, administradores de sistemas, periodistas de datos o equipos que quieren probar modelos en local por privacidad, soberanía o simple curiosidad técnica, el salto es relevante.
La democratización no viene de que todo sea rápido, sino de que sea posible. Poder cargar un modelo de 80B en una GPU de 8 GB, aunque sea lentamente, abre una puerta que hasta hace poco parecía cerrada. Y en inteligencia artificial local, muchas veces la primera revolución no es la velocidad, sino el acceso.
Qué tener en cuenta antes de probarlo
Para quien quiera experimentar con este tipo de proyectos, lo recomendable es hacerlo con expectativas realistas. Hace falta una GPU compatible, un entorno Python bien preparado, suficiente RAM, mucho espacio en disco y, sobre todo, un SSD NVMe rápido y bien refrigerado.
También conviene separar claramente tres escenarios. Para un chatbot local rápido, probablemente siga siendo mejor usar modelos más pequeños y cuantizados con herramientas como Ollama, llama.cpp o LM Studio. Para analizar documentos enormes con modelos grandes y sin degradar precisión, oLLM puede ser mucho más interesante. Para producción, concurrencia o baja latencia, lo normal seguirá siendo usar GPUs con más VRAM o infraestructura cloud/bare-metal especializada.
La novedad no está en que el SSD sea más rápido que la VRAM, porque no lo es. La novedad está en aceptar que, para algunas tareas, es mejor un modelo grande ejecutándose despacio que un modelo pequeño respondiendo rápido.
Preguntas frecuentes
¿oLLM permite ejecutar modelos de 80B en una GPU de 8 GB?
Según su repositorio, oLLM permite ejecutar modelos como qwen3-next-80B en una GPU NVIDIA de 8 GB usando SSD offloading, con pesos en bf16 y sin cuantización. La contrapartida es la velocidad: no está pensado para obtener una experiencia conversacional rápida.
¿Qué diferencia hay entre oLLM y AirLLM?
Ambos explotan la idea de cargar el modelo por capas para reducir el consumo de VRAM. AirLLM fue uno de los proyectos que popularizó la ejecución de modelos 70B en GPUs muy pequeñas. oLLM se centra especialmente en inferencia local con contextos largos, offload de pesos y caché KV a SSD, y soporte para modelos recientes como qwen3-next-80B o gpt-oss-20B.
¿Es mejor usar SSD offloading que cuantización?
Depende del objetivo. La cuantización permite más velocidad y menor consumo, pero puede alterar el comportamiento del modelo. El SSD offloading permite mantener mayor precisión, pero a costa de mucha más latencia y mayor presión sobre el disco.
¿Puede dañarse el SSD por usar este tipo de herramientas?
No debería “romperse” de inmediato, pero sí puede sufrir más desgaste si se usa de forma intensiva. Lo recomendable es usar un NVMe de calidad, con buena refrigeración, espacio libre suficiente y monitorización de salud del disco. Para uso frecuente, tiene sentido dedicar un SSD específico a modelos y cachés.
