AirLLM: ¿un 70B en una GPU de 4 GB, de verdad? Prueba y limites

#La promesa de AirLLM: un 70B en 4 GB de VRAM

Un modelo de 70B con cuantización Q4 requiere aproximadamente 40 GB de VRAM para cargarse completamente en memoria: una RTX 4090 (24 GB) más una segunda tarjeta, o un Mac Studio con una gran capacidad de memoria unificada. AirLLM afirma que puede hacer que el mismo modelo quepa en una tarjeta de 4 GB, incluida una modesta GTX 1650 o una T4 gratuita de Google Colab. No se trata de un truco de marketing sobre el tamaño del modelo: es realmente el modelo completo de 70B, en FP16 o en 4/8 bits, el que produce las respuestas.

El secreto se resume en tres palabras: el modelo nunca se carga entero en la VRAM. AirLLM divide la red en capas (layers), las almacena en disco y solo carga una capa a la vez en la GPU durante el cálculo. Por tanto, la VRAM nunca contiene más que los pesos de una capa y las activaciones actuales; de ahí que solo se necesiten unos pocos gigabytes.

#¿Cómo funciona el streaming de capas?

Un LLM de tipo transformer es una pila de capas idénticas en su estructura (atención + feed-forward), que se atraviesan una tras otra. Un Llama 70B cuenta con 80. La inferencia clásica carga las 80 capas en VRAM de una sola vez y las mantiene todas en memoria durante toda la generación. AirLLM invierte este principio.

División de los pesos en archivos en disco

En la primera carga, AirLLM divide los pesos del modelo en archivos separados, uno por capa, almacenados en el SSD. Este paso de conversión se realiza solo una vez por modelo.

Carga sobre la marcha

Para generar un token, el motor carga la capa 1 en el GPU, calcula, libera la VRAM, carga la capa 2, calcula, y así sucesivamente hasta la capa 80.

VRAM constante

En cualquier momento, solo una capa reside en la VRAM. El pico de memoria depende de la capa más grande y de la longitud del contexto, no del tamaño total del modelo.

Prefetch y cuantización en disco

AirLLM carga previamente la capa siguiente durante el cálculo de la capa actual y puede comprimir los pesos en disco (cuantización por bloques) para reducir el volumen de datos que se deben leer.

El cuello de botella salta a la vista: por cada token generado, hay que leer todos los pesos del modelo desde el disco. Para un modelo de 70B, esto supone varias decenas de gigabytes transferidos del SSD a la GPU para un solo token. Ahí se determinan tanto el rendimiento como las limitaciones de AirLLM.

#Prerrequisitos e instalación

AirLLM es una biblioteca de Python que se basa en PyTorch y en el ecosistema Hugging Face. No se utiliza como Ollama (sin daemon, sin comando run): se importa en un script de Python. Esto es lo que necesitas antes de empezar.

GPU

Cualquier tarjeta NVIDIA con al menos 4 GB de VRAM (CUDA). También hay soporte para Apple Silicon (MPS) y CPU, pero la ejecución es aún más lenta en ambos casos.

Disco

Es indispensable contar con un SSD NVMe rápido, además de espacio para almacenar el modelo descomprimido (≈40 GB para un 70B, más en FP16).

RAM del sistema

16 GB son suficientes; AirLLM no carga el modelo en RAM, a diferencia de un offload CPU clásico.

Python

Un entorno de Python 3.10+ con PyTorch y CUDA correctamente instalados.

pip install airllm

#Ejecutar un 70B con 4 GB: el test

El código mínimo para cargar y consultar un Llama 70B cabe en unas quince líneas. AirLLM se encarga de dividirlo en capas en la primera llamada (calcula varios minutos para la conversión y la descarga del modelo desde Hugging Face).

from airllm import AutoModel

# Le modèle est découpé en couches au premier chargement
model = AutoModel.from_pretrained("meta-llama/Meta-Llama-3.1-70B-Instruct")

input_text = ["Explique le layer streaming en une phrase."]
input_tokens = model.tokenizer(input_text,
                               return_tensors="pt",
                               truncation=True,
                               max_length=128,
                               padding=False)

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

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

1. 01
   1. Primera carga

   AirLLM descarga el modelo y luego lo convierte en archivos por capa en el SSD. Este paso lleva tiempo, pero solo se realiza una vez: las ejecuciones posteriores reutilizan la caché de disco.
2. 02
   2. Ajuste de la compresión

   El parámetro compression='4bit' (o '8bit') reduce el volumen leído desde el disco y acelera así la inferencia, a costa de una ligera pérdida de calidad —el mismo compromiso que la cuantización clásica.
3. 03
   3. Generación

   Cada token desencadena una lectura completa de las 80 capas desde el SSD. La barra de progreso avanza capa por capa: es visualmente lento, y es normal.
4. 04
   4. Medición

   Mide el tiempo total y divídelo por el número de tokens generados para obtener tu velocidad real en tokens/s. Este es el único número que cuenta para decidir si la herramienta es usable en tu caso.

#Benchmark real: ¿cuántos tokens por segundo?

Es aquí donde la promesa se encuentra con la realidad física. Con un modelo de 70B cuyos datos se van leyendo desde un SSD NVMe, no se habla de tokens por segundo, sino a menudo de segundos por token. El orden de magnitud que conviene tener presente, según las configuraciones descritas y nuestras pruebas:

70B / NVMe PCIe 4.0 rápido

del orden de 0,1 a 0,5 token/s, es decir, de 2 a 10 segundos para producir una sola palabra. Una respuesta de 200 tokens tarda varios minutos.

70B / SSD SATA

Entre 2 y 5 veces más lento todavía: el ancho de banda del disco alcanza como máximo unos 500 MB/s y la velocidad cae por debajo de 0,1 token/s.

Comparación con un 70B cargado en VRAM (2x RTX 4090)

15 a 30 tokens/s. La diferencia con AirLLM es de un factor de 30 a 300, según el disco.

Modelo de 8B en Q4 en una sola RTX 3060 de 12 GB

De 40 a 80 tokens/s, sin ningún streaming, para recordar cuánta comodidad se pierde.

La fórmula es sencilla: por cada token, hay que volver a leer todo el modelo desde el disco. Un 70B en 4 bits pesa aproximadamente 40 GB; a 5 GB/s de lectura con NVMe, eso ya supone 8 segundos de entrada/salida pura por token, antes incluso del cálculo. Ninguna optimización de software puede eludir esta barrera mientras los pesos estén en el disco. Se trata de una ralentización de 5 a 30 veces en el mejor de los casos (modelos pequeños, disco muy rápido, compresión agresiva) y mucho mayor con los modelos grandes.

#Casos de uso realistas

A 0,2 token/s, AirLLM es inútil para conversar. Pero existen escenarios reales en los que la lentitud no es un problema, porque nadie espera frente a la pantalla.

Procesamiento en lote (batch) offline

A un script que debe procesar 500 documentos con un modelo de 70B durante la noche le da igual que un documento tarde 3 minutos: el resultado está listo por la mañana. Es el caso de uso más legítimo.

Experimentación puntual

Comprobar qué responde un modelo 70B concreto a unos cuantos prompts, sin alquilar una GPU en la nube ni comprar hardware, para decidir si merece la inversión.

Extracción estructurada no urgente

Generar un conjunto de datos, anotar un corpus, producir embeddings o resúmenes en segundo plano, donde la tasa de procesamiento importa poco.

Acceso a un modelo gigante sin presupuesto

Estudiante, investigador o curioso con una sola tarjeta pequeña, que quiere probar un modelo que de otro modo no podría ejecutar.

#Cuando es marketing

La expresión «un 70B con 4 GB» es técnicamente cierta, pero engañosa desde el punto de vista editorial cuando se da a entender un uso normal. Estas son las situaciones en las que AirLLM no cumple sus promesas implícitas.

Chat interactivo

Esperar varios minutos para obtener una respuesta acaba con cualquier conversación. Para conversar, un modelo local de 8B o 14B que responda al instante es infinitamente más útil que un 70B que responde a la velocidad de un fax.

Asistente de código en tiempo real

El autocompletado y la programación en pareja requieren respuestas en unos pocos segundos. AirLLM está a años luz de conseguirlo.

Servidor multiusuario

Imposible atender a varias personas: cada token ya monopoliza todo el ancho de banda del disco para una sola solicitud.

Producción

Ningún servicio en línea puede basarse en AirLLM. La latencia y el desgaste del SSD (lecturas masivas continuas) lo excluyen de forma inmediata.

#Alternativas: la cuantización clásica primero

Antes de recurrir al layer streaming, agota las soluciones que mantienen el modelo en memoria: casi siempre son preferibles. La cuestión no es «cómo hacer que un 70B quepa en 4 GB», sino «qué modelo responde realmente a mi necesidad».

Reducir la precisión de cuantización

Un 70B en Q4_K_M cabe en unos 40 GB, y en Q2/Q3 necesita mucha menos memoria. Pero un 70B cuantizado de forma demasiado agresiva pierde calidad: a menudo es preferible un 32B en Q4 bien cargado.

Elegir un modelo más pequeño y reciente

Un modelo de 32B (≈19 GB de VRAM) o de 14B (≈9 GB) de 2026 rivaliza con uno de 70B de 2024 en la mayoría de las tareas y se ejecuta instantáneamente en una sola tarjeta.

Offload entre CPU y GPU en Ollama o llama.cpp

Estos motores trasladan parte de las capas a la RAM del sistema cuando falta VRAM. Es más lento que cargar todo en la GPU, pero mucho más rápido que AirLLM, porque la RAM es cien veces más rápida que un SSD.

Alquilar una GPU en la nube para una necesidad puntual

Para probar un verdadero 70B rápidamente una sola vez, alquilar una hora de GPU cuesta poco y proporciona un rendimiento normal — a menudo más rentable que esperar horas localmente.

#Para ir más allá

AirLLM es una herramienta para sortear limitaciones: antes de recurrir a ella, conviene dominar las formas habituales de gestionar la VRAM y elegir el modelo. Tres guías del sitio completan el panorama.

Elegir tu cuantización (Q4, Q5, Q8, FP16)

Comprender cuánta calidad pierde un modelo en Q4 o Q3 y cómo hacer que un modelo grande quepa en una VRAM limitada sin recurrir al streaming desde el disco.

Elegir tu GPU para IA local

Los compromisos entre VRAM, presupuesto y rendimiento, desde la RTX 3060 de 12 GB hasta el Mac Studio Ultra, para saber qué tamaño de modelo soporta realmente tu hardware.

llama.cpp vs vLLM vs Exllama

Los motores de inferencia y su gestión del offload CPU/GPU, la alternativa seria a AirLLM cuando la VRAM es un poco escasa.