Ejecutar un LLM de 70B en 4GB GPU con AirLLM: la guía honesta

Sí, un LLM de 70B puede ejecutarse usando aproximadamente 4GB de memoria GPU con AirLLM—pero el modelo no cabe dentro de una tarjeta gráfica de 4GB. AirLLM mantiene el punto de control en disco, carga una capa de transformador en VRAM, calcula esa capa, la libera y repite. La técnica intercambia memoria por I/O de almacenamiento y latencia.^[1][2]

Esa distinción es toda la historia. Un modelo de 70B sigue necesitando aproximadamente 130GB de almacenamiento de pesos en la precisión utilizada en la demostración original. La cifra de 4GB describe el pico VRAM durante una ejecución de inferencia configurada de forma muy estrecha, no la memoria total de la máquina, el tamaño de descarga ni el rendimiento interactivo.

TL;DR

• AirLLM hace posible la descarga extrema. Almacena fragmentos por capas en disco y mueve solo la capa activa a la GPU.
• El resultado original midió menos de 4GB en una Nvidia T4 de 16GB. No demostró un chatbot rápido ejecutándose completamente desde una tarjeta física de 4GB.^[1]
• La capacidad y velocidad del disco siguen siendo importantes. La primera ejecución descarga y divide el punto de control, y cada token generado transmite repetidamente pesos a través del dispositivo de cálculo.
• El contexto corto es parte del truco. El ejemplo original usó una longitud de entrada de 100 tokens; una caché KV más grande y buffers de tiempo de ejecución consumen más memoria.^[1]
• Espera velocidades de investigación o lote, no chat receptivo. El autor de AirLLM posiciona explícitamente el hardware de nivel bajo para trabajo sin conexión en lugar de aplicaciones interactivas.^[1]
• Usa una API cuando la velocidad de salida importa. La descarga local extrema es útil para aprender y trabajos privados ocasionales; la inferencia hospedada es usualmente el camino de producción más simple.

Lo que "ejecutar un LLM de 70B en una GPU de 4GB" realmente significa

Cuatro recursos diferentes se comprimen en un titular. Separarlos previene la mayoría de las malas decisiones de hardware.

El tutorial original de 2023 utilizó un punto de control de 70B basado en Llama 2 con 80 capas de transformador. Se estimó que una capa era de aproximadamente 1.6GB, mientras que la caché KV para su ejemplo de 100 tokens era de aproximadamente 30MB. El proceso medido se mantuvo por debajo de 4GB de memoria GPU en una Nvidia T4.^[1]

El repositorio actual de AirLLM extiende la misma idea a Llama 3.x, Qwen, DeepSeek, Mixtral, Phi, Gemma y otras familias. Su tabla de referencia actual aún lista una ejecución de Llama 3.x 70B de precisión completa en aproximadamente 4GB VRAM.^[2] Trata eso como una afirmación del proyecto y un objetivo de memoria—no un benchmark de rendimiento para cada tarjeta de 4GB.

Cómo funciona la inferencia por capas de AirLLM

Un transformador ejecuta sus bloques en secuencia. La capa 12 consume el estado oculto de la capa 11; la capa 13 espera a la capa 12. AirLLM explota ese orden con un pipeline de cinco partes.

1. Crea un shell de modelo vacío. El dispositivo meta de Hugging Face Accelerate inicializa la arquitectura sin asignar almacenamiento real para cada parámetro.^[3]
2. Divide el punto de control por capa. Los archivos Safetensors se reorganizan para que cargar una capa no requiera leer un fragmento relacionado de múltiples gigabytes.
3. Carga una capa al dispositivo de cálculo. Solo esa capa y los tensores de tiempo de ejecución requeridos ocupan la GPU en ese momento.
4. Calcula, libera y continúa. El estado oculto avanza mientras los pesos de la capa abandonan VRAM.
5. Repite para cada token generado. La prefetch superpone algo de I/O de almacenamiento con computación, pero no puede eliminar el movimiento de datos repetido.

FlashAttention reduce la memoria temporal usada por la atención a través de cálculos conscientes de I/O en mosaico.^[4] Ayuda a que la capa activa se ajuste, mientras que el streaming de capas resuelve el problema separado de dónde esperan los pesos inactivos.

Hardware y almacenamiento que aún necesitas

La GPU es solo un componente. Antes de descargar un punto de control de 70B, verifica el resto de la máquina.

• Una ruta de cálculo compatible. Las demostraciones en el titular se orientan a Nvidia CUDA. AirLLM también documenta rutas de Apple Silicon y CPU, pero sus características de memoria y rendimiento son diferentes.^[2]
• Suficiente disco para el punto de control y la conversión. El proyecto advierte que la división de capas de primera ejecución consume mucho disco. Su opción delete_original puede eliminar el punto de control original después de la conversión cuando el almacenamiento es escaso.
• Almacenamiento local rápido. NVMe no hace gratuito el streaming de capas, pero una unidad de disco duro lenta empeora sustancialmente un bucle ya I/O-limitado.
• Un contexto inicial y salida cortos. Comienza con un prompt minúsculo y 20-40 tokens nuevos. Un contexto más largo aumenta la caché KV, mientras que una salida más larga repite el recorrido completo de capas más veces.
• Acceso al modelo. Los puntos de control Meta cerrados requieren un token de Hugging Face y aceptación de la licencia del modelo.

No comiences con una descarga de 70B solo para probar si el entorno funciona. Ejecuta un modelo de 8B o más pequeño compatible primero, verifica las rutas CUDA y almacenamiento, luego escala.

Cómo probar AirLLM con un modelo de 70B

El inicio rápido del proyecto actual usa AutoModel, que elige la implementación apropiada de un ID de repositorio de Hugging Face.^[2] Instala primero una compilación de PyTorch compatible con tu controlador CUDA, luego instala AirLLM.

python -m venv .venv
source .venv/bin/activate
pip install airllm

Mantén secretos en variables de entorno en lugar de código fuente:

export HF_TOKEN="your_hugging_face_token"

Luego ejecuta una generación deliberadamente pequeña:

import os

from airllm import AutoModel

MODEL_ID = "meta-llama/Llama-3.3-70B-Instruct"
MAX_LENGTH = 128

model = AutoModel.from_pretrained(
    MODEL_ID,
    hf_token=os.environ["HF_TOKEN"],
    layer_shards_saving_path="/data/airllm-shards",
)

prompt = ["Explain layer-wise inference in three short sentences."]
tokens = model.tokenizer(
    prompt,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False,
)

result = model.generate(
    tokens["input_ids"].cuda(),
    max_new_tokens=32,
    use_cache=True,
    return_dict_in_generate=True,
)

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

Esta es una adaptación mínima del inicio rápido del repositorio, no un lockfile universal de entorno. AirLLM, Transformers, PyTorch, CUDA y el código remoto de un modelo pueden tener restricciones específicas de versión, así que revisa los problemas actuales del repositorio antes de instalarlo en una máquina de producción.

Qué sucede en la primera ejecución

La primera ejecución no es representativa de ejecuciones posteriores. AirLLM debe descargar el modelo, inspeccionar su arquitectura, dividir el punto de control en fragmentos de capa y escribir esos fragmentos en la ruta configurada. Interrumpir esa conversión o quedarse sin disco puede dejar un encabezado safetensors incompleto; las preguntas frecuentes del proyecto recomiendan limpiar la caché incompleta y volver a ejecutar después de hacer espacio. ^[2]

Monitorea cuatro señales por separado:

nvidia-smi -l 1          # Memoria y utilización GPU
free -h                  # Memoria del sistema
df -h /data              # Espacio libre en disco
iostat -xz 1             # Saturación de almacenamiento, si sysstat está instalado

Un número bajo de VRAM no es éxito por sí solo. Registra tiempo al primer token, segundos por token de salida, volumen de lectura en disco y si las ejecuciones repetidas reutilizan fragmentos completados.

Por qué AirLLM es lento incluso cuando se ajusta

La inferencia normal de GPU carga pesos una vez y los reutiliza para muchos tokens y solicitudes. La descarga extrema de capas invierte esa ventaja. Cada token nuevo debe pasar por la pila completa del modelo mientras los pesos se mueven del almacenamiento a la GPU en piezas pequeñas.

AirLLM agregó prefetch para superponer carga con computación y ofrece compresión de pesos por bloques de 4-bit u 8-bit para reducir el tráfico de disco. El repositorio reporta hasta una mejora de tres veces de la compresión, pero el rendimiento real depende del modelo, almacenamiento, GPU, contexto y versiones de software.^[2]

Esto hace que el método sea más creíble para:

• evaluación única de un modelo que de otro modo no podría cargarse;
• clasificación o extracción de documentos sin conexión;
• procesamiento por lotes privado de bajo volumen donde la latencia es secundaria;
• estudiar programación de memoria y arquitectura de modelos.

Es una opción predeterminada pobre para chat en vivo, bucles de agentes, alta concurrencia o cualquier API con un objetivo de latencia.

AirLLM vs cuantificación vs una API

Elige AirLLM cuando el experimento es el punto. Elige un modelo cuantificado más pequeño cuando la interactividad local es el punto. Elige una API cuando el modelo de clase 70B y el tiempo de respuesta utilizable son ambos requisitos.

La misma distinción se aplica a afirmaciones mucho más grandes. Nuestro análisis de Kimi K3 en una GPU de 4GB explica por qué los expertos dispersos cambian la unidad de streaming pero no borran el punto de control. Para un ejemplo actual de API de contexto largo, consulta la guía de API de MiniMax M3, o examina el catálogo de modelos en vivo.

Una lista de verificación práctica de decisiones

Antes de intentar un LLM de 70B en una GPU de 4GB, responde estas preguntas:

1. ¿El objetivo es probar la ejecución o construir un producto receptivo?
2. ¿Puede el disco contener el modelo original y su copia dividida en capas durante la conversión?
3. ¿La arquitectura del punto de control es explícitamente soportada por la versión actual de AirLLM?
4. ¿Puede la carga de trabajo tolerar un tiempo largo al primer token y bajo rendimiento?
5. ¿Permite la licencia del modelo el uso previsto?
6. ¿Has probado la misma pila de software con un punto de control pequeño primero?

Si la respuesta a las preguntas dos a cuatro es no, el titular de 4GB no es un plan de despliegue útil.

FAQ

¿Puede un LLM de 70B realmente ejecutarse en una GPU de 4GB?

Sí, a través del streaming de capas extremo. Solo una pequeña parte del modelo es residente en VRAM a la vez; el punto de control completo permanece en disco. Eso no es lo mismo que cargar un modelo de 70B en 4GB.

¿Usó la prueba original de AirLLM una tarjeta gráfica real de 4GB?

El artículo de 2023 dice que el equipo probó en una Nvidia T4 de 16GB y midió menos de 4GB de uso de memoria GPU.^[1] El repositorio actual enumera por separado Llama 3.x 70B en aproximadamente 4GB VRAM.

¿Cuánto espacio en disco necesita un modelo de 70B?

Depende de la precisión y formato del punto de control. El tutorial original describió aproximadamente 130GB de parámetros, y la conversión de capas puede requerir temporalmente copias tanto originales como convertidas. Revisa los archivos del repositorio antes de descargar y deja espacio para conversiones incompletas o parciales.

¿Es AirLLM lo suficientemente rápido para un chatbot?

Usualmente no en hardware de nivel bajo. El autor original advierte que la configuración de T4 es lenta y más adecuada para trabajo sin conexión.^[1]

¿Entrena AirLLM un modelo de 70B en 4GB?

No. El entrenamiento debe retener o recomputar activaciones y gradientes para retropropagación. La técnica por capas de AirLLM aborda la inferencia, no entrenamiento completo.^[1]

¿Es un modelo de 70B de 4-bit lo suficientemente pequeño para 4GB VRAM?

No. Setenta mil millones de parámetros en cuatro bits requieren teóricamente 35GB solo para pesos brutos, antes de metadatos de cuantificación y memoria de tiempo de ejecución. La cuantificación ayuda, pero no cierra esa brecha.

El veredicto honesto sobre inferencia de 70B con 4GB VRAM

AirLLM convierte un techo de memoria duro en un problema de programación. Ese es un resultado técnico real: un LLM de 70B puede ejecutarse con aproximadamente 4GB de VRAM cuando el tiempo de ejecución transmite fragmentos de capas desde almacenamiento mucho más grande. El precio es I/O repetido, generación lenta, un punto de control grande y una pila de software frágil.

Úsalo para estudiar inferencia extrema o terminar trabajos sin conexión de bajo volumen. Para una aplicación interactiva, usa un modelo local más pequeño o llama a un modelo hospedado a través del inicio rápido de reAPI. La lección útil no es que 70B se haya convertido en un modelo de 4GB. Es que VRAM ya no tiene que contener cada peso al mismo tiempo.

References

1. Gavin Li. Unbelievable! Run 70B LLM Inference on a Single 4GB GPU with This New Technique. November 30, 2023. huggingface.co/blog/lyogavin/airllm
2. AirLLM. AirLLM repository, current quickstart, supported models, configuration, and FAQ. Retrieved August 2, 2026. github.com/lyogavin/airllm
3. Hugging Face Accelerate. Big Model Inference and the meta device. huggingface.co/docs/accelerate/usage_guides/big_modeling
4. Dao et al. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. NeurIPS 2022. arxiv.org/abs/2205.14135