AirLLM corre un modelo 70B en una GPU de 4GB: es verdad, y esa no es la parte interesante

El README de AirLLM abre con una línea que suena a que no puede ser verdad:

“AirLLM reduce drásticamente el uso de memoria de inferencia, permitiendo que modelos de lenguaje de 70B corran en una sola GPU de 4GB — sin cuantización, destilación ni poda.”

Así que vamos a comprobarlo de verdad. ¿Es real la afirmación? ¿Cómo se configura? Y — la pregunta que nadie hace en voz alta — ¿deberías usarlo?

TL;DR: La afirmación es técnicamente verdadera y la ingeniería es legítima.

El truco, en un párrafo

Esto es lo que hay que entender de un transformer: es una pila de capas, y las ejecuta en orden.

Entrada → Capa 1 → Capa 2 → Capa 3 → ... → Capa 80 → Salida

Mientras la Capa 1 está computando, las capas 2 a 80 están simplemente… sentadas en tu VRAM. Sin hacer nada. Ocupando espacio.

La inferencia normal carga las 80 capas en la memoria de la GPU porque mantenerlas ahí es rápido. AirLLM hace la pregunta de seguimiento obvia: ¿y si no lo hiciéramos? Cargar la Capa 1, ejecutarla, descartarla, cargar la Capa 2, ejecutarla, descartarla.

Ahora tu requisito de VRAM ya no es “el tamaño del modelo”. Es “el tamaño de la capa individual más grande”.

Para un modelo de 70B a precisión FP16 completa, eso es aproximadamente 1.75GB por capa. Que cabe en 4GB con espacio de sobra. El modelo sigue pesando 140GB — solo que vive en tu disco en lugar de en tu GPU, transmitiéndose en rebanadas de una a la vez.

Eso es todo. Esa es toda la idea. Y funciona de verdad.

Verificación de datos: ¿es real la afirmación?

Sí — con un asterisco del tamaño del propio modelo.

Vamos con las afirmaciones una por una.

”70B en una sola GPU de 4GB”

Real. Las matemáticas cuadran (~1.75GB por capa en FP16), y suficientes personas lo han reproducido de forma independiente como para que esto no esté en disputa.

”Sin cuantización, destilación ni poda”

Real, y esta es la parte genuinamente interesante. La mayoría de los trucos de “correr modelos grandes en hardware pequeño” funcionan empeorando el modelo — aplastando los pesos de 16 bits a 4, lo que te cuesta algo de precisión. AirLLM no tiene que hacer eso. Obtienes el modelo real, sin modificar, a precisión completa.

(La cuantización es opcional aquí — puedes pasar compression='4bit' para hacerlo más rápido. Pero no tienes que hacerlo, y esa es la distinción que están marcando.)

Los números más grandes también

La tabla de escalado del README parece absurda pero sigue la misma lógica:

Modelo	Tamaño	VRAM declarada
Llama 3.x 70B	70B	~4 GB
Llama 3.1 405B	405B	~8 GB
DeepSeek-V3	671B	~12 GB
Qwen3-235B (MoE)	235B	~3 GB
Kimi K3 (MoE)	2.8T	~3.7 GB

¿Notas algo raro? El modelo de 2.8 billones de parámetros necesita menos VRAM que el de 671B.

Eso no es un error. Son modelos de Mezcla de Expertos (MoE). Una capa MoE contiene cientos de sub-redes “expertas”, pero cada token solo se enruta a un puñado de ellas. Según las notas de la versión v3.1.0, Kimi K3 tiene 896 expertos por capa y enruta cada token a solo 16 — así que mientras los expertos de una capa completa se expanden a ~55GB, un token individual solo necesita ~1GB de ellos. AirLLM transmite solo esos expertos en lugar de la capa completa.

Modelo más disperso → conjunto de trabajo más pequeño → menos VRAM. Contraintuitivo, correcto.

Lo que el titular omite

Aquí está la parte que no está en la letra grande y negrita. De las propias notas de la versión v3.1.0 de AirLLM, medidas en una RTX 6000 Ada:

Métrica	Valor
VRAM máxima durante generación	3.72 GB
Inicialización única	900 segundos
Velocidad de generación	292 s/token, limitado por disco

Para ser claros sobre lo que eso significa: una respuesta de 100 tokens tomaría poco más de 8 horas.

Crédito donde corresponde — el mantenedor publica esto honestamente en las notas de la versión. Simplemente no es el número de la línea de marketing.

Para configuraciones más típicas, los reportes de la comunidad aterrizan en el rango de:

70B en un NVMe decente: aproximadamente 5–35 segundos por token
70B en una MacBook: reportes de hasta ~0.07 tokens/seg (~14 s/token)
Para comparar, llama.cpp con un 70B cuantizado en una RTX 4090: 8–15 tokens por segundo

Así que la versión honesta de la afirmación es:

AirLLM no hace que 70B sea rápido en una GPU de 4GB. Hace que 70B sea posible en una GPU de 4GB.

Por qué es lento (haz esta matemática una vez y nunca volverás a estar confundido)

Vale la pena internalizar esto, porque lo explica todo y no es complicado.

Para generar un token, el modelo debe ejecutar cada una de las capas. Lo que significa que AirLLM debe leer el modelo completo desde el disco — por cada token.

Entonces:

segundos por token ≈ tamaño del modelo en disco ÷ velocidad de lectura del disco

Hagamos el cálculo con un modelo de 70B en FP16 (~140GB):

Almacenamiento	Velocidad	Tiempo por token
SSD NVMe Gen4	~7 GB/s	~20 s
SSD NVMe Gen3	~3.5 GB/s	~40 s
SSD SATA	~0.5 GB/s	~280 s
HDD giratorio	~0.15 GB/s	demasiado lento para creerlo

Tu disco es tu motor de inferencia. La GPU apenas trabaja — está sentada esperando datos. Es por esto que los usuarios de AirLLM reportan que sus ventiladores gritan y que su laptop se vuelve inutilizable: el cuello de botella es I/O y CPU, no cómputo.

Dos consecuencias que salen directamente de esta fórmula:

Usa compression='4bit'. Reduce los bytes que tienes que leer ~4x. El README promociona hasta 3x de aceleración, y ahora sabes exactamente por qué — esto no se trata de matemáticas más rápidas, se trata de mover menos datos.
La RAM es secretamente tu mejor mejora. Si tu RAM del sistema puede contener una buena parte del modelo, la caché de páginas del SO sirve las capas desde la memoria en lugar del disco. Es por esto que la gente con máquinas de 128GB reporta números dramáticamente mejores de lo que la matemática cruda del disco predice.

Setup

Requisitos — lee esta parte antes de empezar

El espacio en disco es la cosa #1 que te va a morder. AirLLM descarga el modelo, y luego lo descompone en fragmentos por capa. Durante un tiempo, tienes ambas copias en disco.

Para un modelo de 70B en FP16, presupuesta:

~140GB (descarga original)
+ ~140GB (fragmentos por capa)
= ~280GB de espacio libre

El error más común en el FAQ del repo — safetensors_rust.SafetensorError: Error while deserializing header: MetadataIncompleteBuffer — es, según los mantenedores, casi siempre simplemente que te quedaste sin disco.

También vas a querer:

Un SSD NVMe (no SATA, definitivamente no HDD)
Tanta RAM del sistema como puedas conseguir
Un token de Hugging Face para modelos con acceso restringido como Llama
Paciencia. Paciencia real, genuina.

1. Instalación

pip install airllm

Para la aceleración por compresión de 4 bits (recomendada — ver la matemática arriba):

pip install -U bitsandbytes

2. Ejecutarlo

from airllm import AutoModel

model = AutoModel.from_pretrained(
    "Qwen/Qwen3-32B",
    compression='4bit',        # ~3x más rápido; omítelo para precisión completa
    delete_original=True,      # borra el original después de dividirlo — ahorra ~50% de disco
    profiling_mode=True,       # registra tiempos por capa para que veas el cuello de botella
)

input_text = ['¿Cuál es la capital de Perú?']

input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=128,
    padding=False,             # evita un error común del tokenizer
)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True,
)

print(model.tokenizer.decode(generation_output.sequences[0]))

Esa es toda la API. Cambiar a un modelo de 671B es un cambio de una línea:

model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")   # 671B, ~12GB VRAM

Empieza pequeño. Por favor, corre primero un modelo de 8B para validar tu setup antes de comprometer 280GB y varias horas a una descarga de 70B.

3. Flags de configuración útiles

Flag	Qué hace
`compression`	Cuantización por bloques `'4bit'` o `'8bit'` — la mayor palanca de velocidad
`delete_original`	Borra la descarga original después de dividir; reduce el uso de disco a la mitad
`layer_shards_saving_path`	Pon los fragmentos en un disco diferente (más rápido/más grande)
`profiling_mode`	Registra el tiempo de consumo por capa
`hf_token`	Para modelos con acceso restringido (Llama, etc.)
`prefetching`	Superpone carga y cómputo (~10% de ganancia); activado por defecto

Errores comunes, decodificados

Error	Causa real
`MetadataIncompleteBuffer`	Te quedaste sin espacio en disco. Básicamente siempre es esto.
`401 Client Error... Repo is gated`	Pasa `hf_token='...'`
`Asking to pad but the tokenizer does not have a padding token`	Pon `padding=False`
`ValueError: max() arg is an empty sequence`	Usa `AutoModel`, no una clase de modelo específica

macOS

Funciona solo en Apple Silicon. Instala mlx además de torch, y asegúrate de estar usando Python nativo (no Rosetta). Por lo demás, el mismo código.

¿Vale la pena?

Depende completamente de cuál de estos casos seas tú.

Sáltatelo si quieres chatear con un modelo grande

Esta es la fantasía que atrae a la gente, y simplemente no funciona. El chat interactivo necesita ~20+ tokens/seg. AirLLM te da segundos a minutos por token. No vas a tener una conversación.

Sáltatelo si manejas volumen serio

Cada token lee decenas de GB de tu SSD. Los NVMe de consumo están clasificados para un número finito de terabytes escritos; martillar uno con lecturas continuas del modelo completo y reescrituras de fragmentos no es para lo que fue diseñado. Además, tu máquina será efectivamente inutilizable mientras corre.

Es genuinamente excelente para trabajo batch offline

Este es el caso de uso real, y está subestimado.

La idea clave: la parte cara es cargar una capa, no usarla. Así que si cargas la Capa 1 y pasas 50 prompts a través de ella antes de seguir adelante, amortizas ese costo de 50 formas.

Un benchmark reportado: 35 s/token para un solo prompt vs 5.3 s/token al hacer batch de 50 — una mejora de 6.6x gratis.

Así que si tienes 10,000 documentos que clasificar durante la noche y no tienes presupuesto de GPU, AirLLM es una herramienta legítimamente razonable. La latencia no importa cuando nadie está esperando.

Es excelente si necesitas precisión completa, específicamente

Investigación sobre efectos de cuantización, reproducibilidad numérica, evaluar un modelo tal como fue publicado — casos donde una aproximación de 4 bits derrota el propósito. AirLLM es casi la única forma de hacer esto en hardware que ya tienes.

Un apunte para el contexto LATAM

Esto importa doblemente en nuestra región, donde el acceso a GPUs de gama alta (y a los precios de la nube en dólares) sigue siendo un lujo. Para un equipo pequeño en Perú, México o Colombia que necesita correr un modelo de 70B a precisión completa para una auditoría o un trabajo de investigación con deadline, AirLLM convierte una laptop vieja con buen SSD en un laboratorio de inferencia funcional. No es la herramienta para producción — pero como herramienta de validación y experimentación, abre puertas que antes requerían una tarjeta de crédito corporativa.

El veredicto

La afirmación es real. 70B en 4GB de VRAM, precisión completa, sin trucos en el sentido de “mentira”. La ingeniería es inteligente y el trabajo de transmisión de expertos MoE es legítimamente impresionante.

El encuadre es el problema. “Corre 70B en una GPU de 4GB” implica que obtienes respuestas de calidad 70B en hardware barato. Lo que realmente obtienes es respuestas de calidad 70B eventualmente — a un ritmo medido en minutos por token, con tu SSD como motor y tu GPU mayormente inactiva.

AirLLM no eliminó el costo de correr un modelo enorme. Lo movió — fuera de la VRAM, hacia el tiempo y el I/O de disco. Si ese es un buen intercambio depende completamente de si tienes más tiempo que dinero.

Enlaces:

AirLLM en GitHub

¿Realmente lo has corrido en hardware real? Me encantaría escuchar tus tokens/seg y tu configuración de disco en los comentarios — los números de la comunidad varían muchísimo y más puntos de datos ayudarían a todos.

Sigue explorando estos temas en el blog de DojoFullStack — si te interesó correr modelos grandes en hardware modesto, te va a gustar nuestro contenido sobre agentes de IA, inferencia local y optimización de LLMs.