AirLLM es una librería de código abierto que ejecuta modelos de lenguaje grandes cargando sus capas por turnos en la GPU. Su repositorio anuncia modelos de 70.000 millones de parámetros con 4 GB de VRAM, una opción para experimentar en local cuando los pesos completos no caben en tu gráfica. (github.com)
El coste aparece en el tiempo de respuesta. En la prueba del vídeo, una RTX 5080 con 16 GB de VRAM tardó 251 segundos en completar una ejecución limitada a cinco tokens de salida. La respuesta quedó cortada antes de decir cuál era la capital de España.
Qué significan los 4 GB que anuncia AirLLM
Los 4 GB del titular corresponden a la memoria de la tarjeta gráfica. La RAM del ordenador y el almacenamiento siguen siendo recursos distintos: esa cifra describe el consumo de VRAM de determinados modelos en las condiciones publicadas por el proyecto. (github.com)
La diferencia importa al decidir si tu equipo sirve. Los pesos del modelo tienen que estar disponibles para cargarlos durante la ejecución, aunque no permanezcan todos dentro de la gráfica. Reducir la memoria ocupada en la GPU desplaza parte del trabajo hacia la carga de esos pesos.
Tampoco debes interpretar la cifra como una garantía para cualquier modelo. El repositorio publica necesidades de VRAM diferentes según su tamaño y arquitectura; los 4 GB son una referencia para casos concretos. (github.com)
Para trastear, empieza por un modelo compatible y comprueba sus requisitos. Elegir el más grande porque aparece en una tabla te puede dejar esperando mucho más de lo que te compensa.
Cómo funciona la carga por capas
AirLLM mantiene en la GPU la parte del modelo que necesita procesar en ese momento. Después libera los pesos utilizados y carga los siguientes; así reduce la cantidad de pesos que deben permanecer simultáneamente en la memoria gráfica. (github.com)
Puedes entenderlo siguiendo el recorrido de una entrada:
- La herramienta carga los pesos de una capa.
- La GPU procesa los datos con esa capa.
- El resultado pasa a la siguiente.
- La herramienta sustituye los pesos que ya ha usado por los que necesita a continuación.
Cada capa transforma la información que recibe. Aunque retires sus pesos de la GPU, su resultado sigue formando parte del cálculo que continúa por el modelo. El ahorro viene de alternar los pesos residentes en memoria.
Esa alternancia añade trabajo a la ejecución. En la prueba del vídeo, la carga inicial terminó mucho antes que la generación: el mensaje de «modelo cargado» apareció alrededor de los 4,5 segundos, pero la respuesta necesitó varios minutos.
Por eso hay que medir hasta que termina la salida. Si vosotros os quedáis solo con el tiempo de carga, os falta el dato que determina si podéis usarlo como chat.
AirLLM y cuantización: qué cambia en cada caso
La carga por capas cambia cuándo están disponibles los pesos en la GPU. La cuantización reduce la precisión con la que se representan esos pesos. AirLLM anuncia ejecución sin exigir cuantización y también ofrece opciones de compresión. (github.com)
Las dos decisiones pueden aparecer juntas. En el vídeo se configuró Qwen3 de 32.000 millones de parámetros con compresión de 4 bits, además de utilizar AirLLM para cargarlo por partes.
Ese detalle limita la lectura del resultado. La prueba corresponde a esa combinación de modelo, compresión y equipo. Para atribuir una diferencia de calidad a una técnica concreta, tendrías que mantener iguales las demás condiciones y comparar las respuestas.
Si quieres una referencia sobre selección de modelos y memoria antes de montar el experimento, tienes la guía para ejecutar IA en local con Ollama. Te ayuda a empezar por un modelo ajustado a tu máquina y evitar una configuración que tarde demasiado para tu uso diario.
Qué ocurrió en la prueba con una RTX 5080
La ejecución utilizó una RTX 5080 con 16 GB de VRAM. El script cargaba el modelo, medía tiempos y enviaba la pregunta «¿Cuál es la capital de España?». La generación tenía un máximo de cinco tokens nuevos.
El resultado observado fue este:
| Elemento de la prueba | Configuración o resultado |
|---|---|
| Modelo seleccionado | Qwen3 de 32.000 millones de parámetros |
| Compresión | 4 bits |
| Carga inicial indicada | Alrededor de 4,5 segundos |
| Tiempo total mostrado | 251 segundos |
| Límite de salida | Cinco tokens |
| Respuesta visible | «La capital de España es» |
La salida se detuvo por el límite configurado. Los tokens no equivalen a palabras completas, así que reservar cinco no garantizaba espacio suficiente para contestar. Ese corte impide valorar la respuesta final a la pregunta.
El tiempo sí sirve para valorar la interacción en esa ejecución: 251 segundos para una salida tan corta hacen que cada intercambio sea una espera considerable. Preguntar, corregir y volver a preguntar multiplica esa fricción.
También aparecieron avisos relacionados con las dependencias durante la carga. El proceso continuó hasta generar texto, pero esos avisos merecen revisión antes de reutilizar el entorno para más pruebas.
La GPU de esta ejecución tenía 16 GB de VRAM. El resultado observado, por tanto, corresponde a ese equipo; la cifra de 4 GB aparece de los casos anunciados por AirLLM.
Qué comprobar antes de ejecutarlo con NVIDIA
El entorno del vídeo utilizaba NVIDIA, PyTorch y CUDA. Si vas a repetir ese recorrido, comprueba primero que Python puede acceder a la gráfica. Instalar la librería sin validar esto te puede hacer perseguir un fallo de dependencias como si fuera un problema del modelo.
-
Comprueba que el controlador reconoce tu GPU:
nvidia-smiRevisa que aparezca la tarjeta con la que quieres ejecutar la prueba. Si falla este paso, resuelve el controlador antes de continuar.
-
Crea y activa un entorno virtual de Python. Instala las dependencias dentro de él para mantener esta prueba separada de otros proyectos.
-
Instala una versión de PyTorch compatible con tu GPU y comprueba CUDA desde Python:
import torch print(torch.cuda.is_available())El resultado debe ser
Truepara seguir el recorrido con CUDA del vídeo. -
Revisa la instalación y los modelos compatibles en el repositorio oficial de AirLLM. Mantén juntos los requisitos del modelo y los de las dependencias que utiliza.
Al preparar el script, separa el tiempo de carga del tiempo de generación y deja espacio suficiente para que termine una respuesta breve. Ojo con un límite de tokens demasiado pequeño: puedes medir cuánto ha tardado el proceso y aun así quedarte sin una respuesta que evaluar.
Cuándo usar AirLLM y cuándo elegir otra opción
AirLLM tiene sentido como experimento si quieres estudiar la carga por capas o intentar acceder a un modelo que no cabe completo en tu GPU. La condición práctica es que puedas aceptar esperas como la observada y dedicar tiempo a preparar el entorno.
Para un chat interactivo, la ejecución del vídeo ofrece un criterio claro: varios minutos por una salida mínima dificultan una conversación. Para programar ocurre lo mismo, porque necesitas revisar cambios, pedir correcciones y comprobar resultados sin esperar varios minutos entre cada paso.
Un modelo más pequeño que responda con una latencia aceptable puede encajar mejor en ese trabajo. Si puedes usar servicios externos y necesitas acceder a otros modelos, tienes también la guía para montar una API de IA con modelos cloud y fallback.
Antes de montar un chat sobre AirLLM, ejecuta una pregunta breve con margen para completar la respuesta y mide el tiempo hasta el último token. Usa esa espera como criterio para decidir si seguir experimentando o elegir un modelo más pequeño.
¿Qué te ha parecido?
Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .