AirLLM ejecuta Kimi K3, el modelo abierto más grande, en 3.72 GB de VRAM

AirLLM ya corre el modelo de código abierto más grande jamás publicado, Kimi K3, con sus 2,8 billones de parámetros, en una sola tarjeta gráfica de menos de 4 GB de memoria. La actualización de julio de 2026 dejó ese número en 3,72 GB de VRAM, medidos de punta a punta en una RTX 6000 Ada, sin recurrir a quantización, destilación ni poda del modelo.

La clave está en cómo AirLLM mueve los pesos: en vez de cargar el modelo completo en la GPU, trae del disco solo lo necesario para cada paso de inferencia. Con Kimi K3, un modelo disperso de tipo Mixture of Experts (MoE), eso significa cargar un experto a la vez en lugar de una capa entera.

TL;DR

• AirLLM (julio 2026) suma soporte para Kimi K3, el modelo abierto más grande liberado hasta ahora con 2.8 billones de parámetros.- Kimi K3 corre en 3.72 GB de VRAM medidos de punta a punta en una sola RTX 6000 Ada.- AirLLM permite correr Llama 3.1 de 405B en 8 GB y DeepSeek-V3 (671B) en unos 12 GB de VRAM.- La versión 3.0 (junio 2026) agregó soporte FP8 y bajó Qwen3-235B-A22B a unos 3 GB de VRAM.- Kimi K3 exige flash-attn obligatorio, compressed-tensors, torch con CUDA 12 y transformers 4.56.x.- El streaming por experto (MoE) carga solo los expertos que cada token activa, no la capa completa.- La compresión por bloques de AirLLM ofrece hasta 3x más velocidad con pérdida de precisión casi nula.- El repositorio de lyogavin acumula 26.500 estrellas y 2.900 forks en GitHub.

Qué pasó

El changelog de AirLLM registró en julio de 2026 el soporte para Kimi K3, un modelo de 2,8 billones de parámetros que su propio proyecto describe como el mayor lanzamiento de pesos abiertos hecho público hasta la fecha. El dato central es la memoria: 3,72 GB de VRAM, medidos de principio a fin en una única RTX 6000 Ada.

Kimi K3 es un modelo disperso (sparse MoE), lo que cambia la estrategia de carga. En un modelo denso, AirLLM trae una capa completa a la GPU, la ejecuta y la descarta. En un MoE como Kimi K3, cada token solo activa un subconjunto de expertos, así que AirLLM trae del disco únicamente esos expertos en vez de la capa entera. Es la diferencia entre cargar todo un piso de un edificio o solo la oficina que realmente vas a usar.

El soporte llegó con tres requisitos que no son opcionales. El código del modelo exige flash-attn sin importar qué se pida al inicializarlo, así que hace falta instalar compressed-tensors y flash-attn aparte. Además, se necesita una build de torch con CUDA 12, porque todavía no existe una wheel prearmada de flash-attn para CUDA 13. Por último, el repositorio fija transformers en la serie 4.56.x: el código remoto de Kimi K3 no carga en la serie 5.x.

⚠️ Ojo: si ya tenés un entorno con transformers 5.x o una build de torch para CUDA 13, Kimi K3 no va a cargar. Armá un entorno virtual aparte antes de tocar tu setup habitual.

Contexto e historia

AirLLM nació en noviembre de 2023 con una promesa concreta: correr un Llama 2 de 70B en una GPU de 4 GB sin quantizar. Desde ahí, el proyecto de lyogavin fue sumando piezas una por una. En diciembre de 2023 llegó el soporte de safetensors y de los diez modelos principales del open LLM leaderboard, después ChatGLM, QWen, Baichuan, Mistral e InternLM, y con la versión 2.0 una compresión que triplicó la velocidad de ejecución. La 2.5 sumó prefetching (traer la siguiente capa mientras la actual todavía calcula), con una mejora de velocidad del 10%. La 2.6 unificó todo detrás de una sola clase AutoModel y la 2.7 sumó AirLLMMixtral. Para fin de año, la 2.8.2 ya dejaba correr un 70B en macOS.

En 2024 el foco pasó a los modelos de Meta y a la eficiencia: soporte nativo de Llama 3 en abril, Llama 3.1 de 405B junto con quantización de 8 y 4 bits en julio, inferencia por CPU en agosto y Qwen2.5 esa misma semana. Después hubo un salto grande hasta junio de 2026, cuando la versión 3.0 sumó soporte FP8 y bajó DeepSeek-V3 (671B) a unos 12 GB y Qwen3-235B-A22B a unos 3 GB, todo detrás de la misma interfaz AutoModel. Kimi K3 en julio de 2026 es la última pieza de esa progresión: de 70B en 4 GB a 2,8T en 3,72 GB en menos de tres años.
De Llama 2 70B en 4 GB (2023) a Kimi K3, 2.8T, en 3.72 GB (2026).

Detalles técnicos y rendimiento

El mecanismo de fondo se llama layer streaming: en lugar de cargar todos los pesos del modelo en VRAM antes de generar, AirLLM particiona el modelo por capas (o por expertos, en el caso de un MoE), lo guarda en disco de forma seccionada y va trayendo cada sección a la GPU justo antes de necesitarla, para descartarla apenas termina. Es la razón por la que un modelo de 70B, que normalmente pide más de 140 GB en precisión completa, puede correr en una tarjeta de 4 GB: nunca está entero en memoria al mismo tiempo.

Encima de ese streaming, AirLLM ofrece compresión basada en quantización por bloques, que según el propio proyecto puede acelerar la inferencia hasta 3 veces con una pérdida de precisión casi nula. Para activarla hace falta tener instalado bitsandbytes además de una versión reciente de airllm. La otra optimización documentada es el prefetching de la versión 2.5, que solapa la carga de la siguiente capa con el cómputo de la actual y aportó una mejora de velocidad del 10% frente a la versión anterior.
ModeloParámetrosVRAM aproximada con AirLLMDisponible desdeLlama 2/3 (base)70B4 GB2023/2024Llama 3.1405B8 GB2024/07DeepSeek-V3671B~12 GB2026/06 (v3.0)Qwen3-235B-A22B235B (22B activos)~3 GB2026/06 (v3.0)Kimi K32.8T3.72 GB (medido en RTX 6000 Ada)2026/07
En un modelo MoE como Kimi K3, el streaming por experto reemplaza al streaming por capa completa: el router del modelo decide qué expertos activa cada token, y AirLLM solo trae del disco esos expertos puntuales.

flowchart TD
A["Token de entrada"] --> B["Router de Kimi K3"]
B --> C["Selecciona expertos activos"]
C --> D["AirLLM carga esos expertos desde disco"]
D --> E["GPU ejecuta el forward pass"]
E --> F["Resultado y descarte de VRAM"]

Cómo empezar

La instalación es la misma librería de Python en cualquier sistema operativo; lo único que cambia es cómo armás el entorno virtual.

Linux / macOS:

python3 -m venv airllm-env
source airllm-env/bin/activate
pip install airllm

Windows (PowerShell):

python -m venv airllm-env
airllm-env\Scripts\Activate.ps1
pip install airllm

Con eso ya podés cargar casi cualquier modelo popular de Hugging Face con la misma clase AutoModel, sin importar cuál sea:

from airllm import AutoModel

MAX_LENGTH = 128
modelo = AutoModel.from_pretrained("Qwen/Qwen3-32B")

entrada = ["¿Cuál es la capital de El Salvador?"]

tokens_entrada = modelo.tokenizer(
    entrada,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False
)

salida = modelo.generate(
    tokens_entrada["input_ids"].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True
)

texto = modelo.tokenizer.decode(salida.sequences[0])
print(texto)

Para Kimi K3 hace falta instalar antes las dependencias específicas y fijar las versiones que el modelo exige:

# Prerrequisitos obligatorios para Kimi K3
pip install compressed-tensors flash-attn
pip install "transformers==4.56.*"
python -c "import torch; print(torch.version.cuda)"  # debe imprimir 12.x

💡 Tip: si querés el extra de velocidad de la compresión por bloques, instalá bitsandbytes antes de inicializar el modelo; según AirLLM, puede triplicar la velocidad de inferencia con una pérdida de precisión casi nula.

Para confirmar que el streaming está funcionando y que no cargaste el modelo completo en VRAM, abrí una segunda terminal mientras generás texto:

watch -n 1 nvidia-smi --query-gpu=memory.used --format=csv

Si el consumo de memoria se mantiene por debajo de los gigabytes que tiene tu tarjeta en vez de dispararse al tamaño total del modelo, el streaming por capas (o por experto) está activo. También conviene chequear la versión de transformers antes de cargar Kimi K3:

python -c "import transformers; print(transformers.__version__)"

Monitorear memoria.used con nvidia-smi confirma que el streaming está activo.

Impacto y análisis

Lo que cambia con AirLLM no es el modelo en sí, sino quién puede correrlo. Antes de esta técnica, evaluar Kimi K3 o DeepSeek-V3 localmente exigía un clúster de GPUs de centro de datos. Con streaming por capas o por experto, un desarrollador con una sola tarjeta de gama media puede cargar el mismo modelo, aunque sea para inferencia puntual y no para servir tráfico en producción.

Hay un costo real que conviene decir sin rodeos: traer pesos del disco en cada paso de generación es más lento que tener todo el modelo residente en VRAM. AirLLM no publica en su documentación una cifra de tokens por segundo para Kimi K3, así que la forma honesta de evaluar el trade-off es medirlo vos mismo con el comando de nvidia-smi de la sección anterior, junto con un cronómetro simple alrededor de la llamada a generate(). Esto hace que AirLLM encaje mejor en evaluación, prototipado o inferencia por lotes que en un servicio de baja latencia con múltiples usuarios concurrentes.

La otra cara es que este patrón de streaming por experto, pensado primero para MoE gigantes como Kimi K3, probablemente se vuelva el estándar de facto para correr cualquier modelo disperso grande en hardware de consumo, del mismo modo que el streaming por capa ya lo es para los modelos densos.

Qué sigue

El historial de actualizaciones de AirLLM (CPU en 2024, macOS a fines de 2023, FP8 en junio de 2026, streaming por experto en julio de 2026) sugiere que el próximo paso lógico es sumar el siguiente modelo MoE grande que se libere en pesos abiertos, con los mismos ajustes de dependencias que exigió Kimi K3. Vale la pena seguir la sección de Updates del repositorio para el próximo salto.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré pip install airllm y cargá un modelo con AutoModel.from_pretrained() ahora mismo para ver cuánta VRAM libera el streaming por capas en tu propia GPU.

Preguntas frecuentes

¿Qué es AirLLM?

Es una librería de Python que reduce drásticamente la memoria necesaria para correr modelos grandes de lenguaje, trayendo del disco solo las capas o expertos necesarios en cada paso, sin quantizar, destilar ni podar el modelo.

¿Necesito quantizar el modelo para usar AirLLM?

No. El streaming por capas funciona con el modelo en su precisión original. La compresión por bloques es una opción aparte, con bitsandbytes, que suma velocidad pero no es obligatoria para que el modelo entre en poca VRAM.

¿Por qué Kimi K3 exige flash-attn?

Porque el propio código del modelo lo pide de forma explícita, sin importar qué configuración le pases a AirLLM al cargarlo. Es un requisito del modelo, no de la librería.

¿Funciona en Mac o solo con GPU NVIDIA?

AirLLM sumó soporte de inferencia por CPU y de macOS ya en 2023 y 2024, pero las cifras de VRAM de este artículo (incluida la de Kimi K3) corresponden a ejecución en GPU NVIDIA.

¿Es más lento que correr el modelo completo en VRAM?

Sí, en general: traer pesos del disco en cada paso agrega latencia frente a tener todo el modelo ya cargado en la tarjeta. AirLLM no publica una cifra de velocidad para Kimi K3, así que conviene medirlo en tu propio hardware.

¿Qué modelos soporta además de Kimi K3?

Entre otros, Qwen3, la familia Llama 3.x/4, DeepSeek V2/V3, Phi-4 y Gemma, todos a través de la misma clase AutoModel.

Referencias

• Repositorio oficial de AirLLM en GitHub: código fuente, changelog completo y ejemplos de uso.- Paquete airllm en PyPI: página de instalación y versiones publicadas.- Documentación de Hugging Face Transformers: referencia de la librería que AirLLM usa como base para tokenización y generación.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.