AirLLM: IA de 70B con solo 4 GB de GPU, paso a paso (2026)

🧩 Qué es AirLLM y por qué es diferente

Un modelo de 70B parámetros ocupa unos 130 GB. Para cargarlo entero en una GPU necesitarías dos A100. Lo que hace AirLLM es inferencia por capas: divide el modelo en capas individuales, las guarda en disco, y va cargando a la GPU solo la capa que está calculando en cada momento. Carga, calcula, libera memoria, y pasa a la siguiente. Es el clásico divide y vencerás aplicado a los transformers, explicado por su propio autor, Gavin Li, en el blog de Hugging Face.

Lo importante: esto no es cuantización. No comprime el modelo ni pierde precisión. El modelo es el original, entero, solo que vive en tu disco en vez de en la memoria de la GPU. En los modelos MoE como Kimi K3 el truco es todavía mejor: cada capa tiene 896 expertos de unos 55 GB en total, pero cada token solo necesita 16, así que AirLLM solo carga el gigabyte que ese token va a usar. Por eso un modelo de 2,8T cabe en menos VRAM que uno de 671B.

El proyecto no es nuevo ni un experimento de fin de semana: lleva 27.400 estrellas en GitHub, 3.000 forks, licencia Apache 2.0 y se actualiza sin parar. La versión 3.1.0 del 29 de julio de 2026 es la que añade el soporte de Kimi K3.

🧩 Caso 1: instalar AirLLM y ejecutar tu primer modelo

Vas a necesitar una GPU Nvidia con al menos 4 GB (una GTX 1650 de segunda mano vale, y las hay baratas en Amazon), un disco con espacio de sobra y Python. La instalación es una línea:

Y ejecutar un modelo son cuatro líneas más. Solo necesitas el identificador del modelo en Hugging Face:

Un aviso que aprendí leyendo la documentación y que me habría gustado saber antes: la primera vez que cargas un modelo, AirLLM lo descompone en capas y lo guarda en la caché de Hugging Face. Descarga el modelo completo y además necesita espacio para la versión dividida. Para un modelo grande, calcula decenas o cientos de GB. Si vas justo de espacio, puedes pasar el parámetro delete_original=True para borrar el original tras la conversión y quedarte solo con la copia dividida.

🧩 Caso 2: subir la apuesta, de 32B a 671B

Lo bueno de AirLLM es que la API es idéntica da igual el tamaño. Cambias una línea y estás corriendo algo mucho más gordo. Estas son las cifras oficiales de memoria que da el proyecto:

• Qwen3-235B: unos 3 GB de VRAM (modelo MoE, desde v3.0)
• Llama 3.1 405B: 8 GB
• DeepSeek-V3 (671B): unos 12 GB
• Kimi K3 (2,8T): 3,72 GB

Sí, el DeepSeek de 671B pide más memoria que el Kimi de 2,8T. No es un error: en los MoE dispersos se transmite experto a experto en vez de capa entera, y los pesos MXFP4 de Kimi viajan comprimidos por el bus PCIe y se expanden en la GPU, moviendo cuatro veces menos datos.

Para Kimi K3 hay tres requisitos no opcionales que el propio aviso de la release detalla: instalar compressed-tensors y flash-attn, usar torch compilado para CUDA 12 (aún no hay ruedas de flash-attn para CUDA 13) y quedarse en transformers 4.56.x, porque el código remoto de K3 no carga en la versión 5.

🧩 Caso 3: el dato que nadie te cuenta, la velocidad

Aquí está la parte que me hizo escribir este artículo. Los titulares dicen "ejecuta 2,8T en 4 GB" y se quedan tan anchos. Pero en la tabla de la release, medida de punta a punta en una RTX 6000 Ada, la generación de Kimi K3 va a 292 segundos por token. Casi cinco minutos por palabra. El arranque inicial, además, cuesta 900 segundos. La culpa no es de la GPU: es que el cuello de botella es el disco. Un usuario de Hacker News lo resumió con humor: "son unos cuatro tokens por milifortnight".

Con los modelos más pequeños la cosa mejora mucho, pero sigue sin ser un chat instantáneo. ¿Se puede acelerar? Sí. AirLLM incluye un modo de compresión de pesos a 4 u 8 bits con bitsandbytes que, según el proyecto, da hasta 3 veces más velocidad con pérdida de precisión casi negligible. Se activa así:

Y hay una alternativa que merece la pena conocer: Swiftlet, publicado el mismo día, lleva la misma idea al ecosistema Apple con Swift y Metal. Consigue que Qwen3-Next-80B funcione en un Mac M5 con 4,3 GB de RAM a 4,5 tokens por segundo, y el modelo de 35B hasta en un iPhone con unos 2,5 GB. Si tienes un Mac, míralo antes que AirLLM.

🧩 Caso 4: para qué sirve de verdad

En los comentarios del hilo de Hacker News, la pregunta del millón era exactamente esa. Y las respuestas útiles fueron dos:

La primera, de un desarrollador que trabaja con datos sensibles: procesamiento por lotes nocturno. "Tengo un SaaS con datos que no puedo enviar a terceros. Las tareas que no son urgentes las dejo corriendo toda la noche. Esto me permite usar modelos de más calidad sin vender mi casa para comprar GPUs". Para eso sí tiene sentido: lanzas 200 prompts antes de dormir y por la mañana tienes las respuestas. Aquí un SSD NVMe rápido y grande marca la diferencia, porque todo el invento vive del disco.

La segunda, la honesta: para chatear, no. Si quieres un asistente interactivo con un modelo de 30B en tu GPU, Ollama con una cuantización decente te va a dar decenas de tokens por segundo donde AirLLM te da uno cada varios segundos. La pregunta que se hacía un usuario en el hilo era legítima: ¿qué ventaja tiene esto frente a descargar un quant de Unsloth y correrlo con llama.cpp? Para uso diario, ninguna. AirLLM gana cuando quieres el modelo original sin cuantizar y el tiempo no importa.

🧩 Caso 5: probarlo sin GPU, desde el navegador

Si no tienes GPU Nvidia y quieres trastear antes de decidirte, el proyecto mantiene notebooks de ejemplo en Google Colab con los que puedes ejecutar el código directamente en el navegador, gratis, con la GPU que te preste Google. También hay soporte para MacOS con Apple Silicon (necesitas instalar mlx y torch, y Python nativo, no bajo Rosetta) y desde la versión 2.10 incluso inferencia solo con CPU, aunque ahí ya sí que estás esperando sentado.