AirLLM con 4 GB de VRAM: cómo funciona la inferencia por capas

Sí, AirLLM puede ejecutar un modelo mucho mayor que la VRAM de la GPU. Eso no significa que el modelo quepa en la tarjeta. El checkpoint sigue en disco. AirLLM carga la capa o los expertos necesarios, calcula, libera memoria y repite. Cambia residencia en memoria por movimiento de datos.

Un pico de 4 GB no revela el espacio en disco, el tiempo de preparación, la latencia, el contexto útil ni la concurrencia. Verificamos esta guía el 20 de agosto de 2026 y le damos un intent acotado: explicar AirLLM con poca VRAM y decidir cuándo merece un piloto comercial. Para elegir un modelo local convencional que sí encaje en tu equipo, usa nuestra guía de hardware para LLM locales.

¿Qué es AirLLM?

AirLLM es una librería Python con licencia Apache 2.0. Divide checkpoints transformer compatibles en shards menores y los carga bajo demanda. El repositorio oficial de AirLLM anuncia soporte para Llama, Qwen, DeepSeek, Mistral, Phi, Gemma, Kimi K3 y otras familias mediante AutoModel. También ofrece compresión opcional de pesos en 4 u 8 bits, ejecución CPU, Apple Silicon y prefetch limitado.

Su beneficio es el acceso. Permite examinar un checkpoint que fallaría al cargar por falta de VRAM. El precio son transferencias repetidas. Un servidor GPU normal conserva pesos residentes y los reutiliza para cada token. AirLLM los recupera desde un nivel más lento porque prioriza capacidad sobre throughput.

¿Cómo reduce VRAM la inferencia por capas?

1. Divide el checkpoint. AirLLM crea archivos por capa. El original y la copia transformada pueden coexistir durante el setup.
2. Conserva el estado de ejecución. Activaciones, atención, KV cache y buffers aún necesitan RAM o VRAM.
3. Carga la capa actual. Transfiere el bloque, calcula y reutiliza la memoria para el siguiente.
4. Repite por token. El decode autorregresivo vuelve a recorrer el modelo. Sin caché, vuelve el tráfico de disco.

El pico de VRAM depende de la capa mayor, las activaciones y el workspace, no de la suma de parámetros. El disco sigue dependiendo del checkpoint completo. Los contextos largos, batches grandes y varias solicitudes aumentan la memoria de ejecución.

¿Por qué Kimi K3 puede reportar menos VRAM que un 70B denso?

Kimi K3 no es un modelo denso. El repositorio oficial de Kimi K3 documenta 93 capas, 896 expertos enrutados, 16 expertos seleccionados por token y 104.000 millones de parámetros activos. AirLLM carga solo los expertos elegidos. Ese working set puede ser menor que una capa densa de 70B aunque la biblioteca completa sea muchísimo mayor.

La cifra de memoria máxima no reduce el download. El checkpoint publicado ronda 1,6 TB. Moonshot recomienda vLLM, SGLang y TokenSpeed para producción. AirLLM es una ruta experimental de acceso, no la receta de serving estándar del fabricante.

La frase «sin cuantización» necesita una corrección

AirLLM no exige cuantizar todos los checkpoints. Pero Kimi K3 se entrenó con quantization-aware training y se publicó con pesos MXFP4 y activaciones MXFP8. La afirmación viral confunde compresión añadida por el runtime con el formato descargado.

Los tamaños también necesitan contexto. El repositorio oficial de DeepSeek-V3 enumera 671.000 millones de parámetros principales, 37.000 millones activos por token y 14.000 millones adicionales en el módulo de predicción multitoken. «671B con 12 GB» describe VRAM máxima, no 671B pesos residentes.

¿Qué ocultan los 4 GB de VRAM?

• Disco: original y shards pueden coexistir. En Kimi K3, solo el checkpoint fuente ronda 1,6 TB.
• I/O: capas y expertos fríos cruzan almacenamiento, RAM y a veces PCIe. Prefetch no convierte NVMe en memoria GPU.
• Velocidad: el README no publica una tabla reproducible de tokens/s para los grandes titulares.
• Contexto: KV cache, activaciones y batching siguen consumiendo memoria.

Una auditoría pública de evidencia en el repositorio señala que el notebook 405B carece de resultados ejecutados de tiempo y memoria y utiliza un modelo pre-cuantizado de 4 bits. La velocidad es desconocida hasta fijar checkpoint, revisión, prompt, contexto, hardware y salida.

AirLLM frente a un modelo que sí cabe

El offload a disco crea capacidad, pero luego la arquitectura debe recuperar velocidad. El paper de PRIMA.CPP usa memory mapping, pipeline, prefetch y colocación de capas por dispositivo para modelos de 30B a 70B. No es un benchmark de AirLLM. Demuestra que la diferencia entre «ejecuta» y «ejecuta de forma útil» es un problema de sistemas.

¿Cuándo tiene sentido comercial un piloto?

Prueba AirLLM para acceso offline ocasional, investigación de modelos, batches grandes o formación con hardware limitado. Descártalo si el cliente exige respuesta interactiva, hay varios usuarios simultáneos, se procesan datos regulados sin revisión de seguridad o un modelo cuantizado de 7B a 70B ya supera la misma evaluación.

Plan de benchmark para decidir

1. Fija ID, revisión, formato de pesos, commit de AirLLM y versiones del runtime.
2. Mide pico de VRAM, RAM, swap, checkpoint, shards y espacio temporal.
3. Separa descarga, split, arranque frío, prefill, primer token y decode.
4. Prueba contexto, herramientas, idiomas, batch y concurrencia reales.
5. Compara calidad y coste por tarea aceptada con un baseline alojado.

Después aplica nuestro modelo de break-even entre LLM local y API. Para términos, datos y compra, consulta la review de Kimi K3 para empresas de la UE. Para otra arquitectura NVMe con velocidad publicada, revisa el análisis de Colibri.

Fuentes y límites

AirLLM aporta funciones y cifras de pico. Moonshot documenta arquitectura K3 y MXFP4. DeepSeek aporta sus parámetros. La auditoría pública documenta el hueco del notebook 405B. PRIMA.CPP da contexto independiente, pero no valida AirLLM. Wavect no descargó los checkpoints de terabytes ni reprodujo los picos.