Exécuter un LLM 70B sur GPU 4GB : guide honnête AirLLM

Oui, un LLM 70B peut s'exécuter en utilisant environ 4GB de mémoire GPU avec AirLLM, mais le modèle n'est pas stocké à l'intérieur d'une carte graphique 4GB. AirLLM conserve le point de contrôle sur disque, charge une couche de transformer dans la VRAM, la calcule, la libère et recommence. La technique échange la mémoire contre les entrées/sorties de stockage et la latence.^[1][2]

Cette distinction raconte toute l'histoire. Un modèle 70B nécessite encore environ 130GB de stockage de poids à la précision utilisée dans la démonstration originale. Le chiffre 4GB décrit la mémoire GPU de pointe lors d'une exécution d'inférence spécifiquement configurée, pas la mémoire machine totale, la taille du téléchargement ou les performances interactives.

TL;DR

• AirLLM rend le déchargement extrême possible. Il stocke les fragments de couche sur disque et déplace seulement la couche active vers le GPU.
• Le résultat original a mesuré moins de 4GB sur un Nvidia T4 16GB. Il n'a pas démontré un chatbot rapide tournant entièrement à partir d'une carte 4GB physique.^[1]
• La capacité et la vitesse du disque importent toujours. La première exécution télécharge et reconfigure les fragments du point de contrôle, et chaque token généré remet en place les poids à travers le périphérique de calcul.
• Un contexte court fait partie de l'astuce. L'exemple original utilisait une longueur d'entrée de 100 tokens ; un cache KV plus grand et les buffers d'exécution consomment plus de mémoire.^[1]
• Attendez-vous à des vitesses de recherche ou de traitement par lots, pas de chat réactif. L'auteur d'AirLLM positionne explicitement le matériel bas de gamme pour le travail hors ligne plutôt que pour les applications interactives.^[1]
• Utilisez une API quand la vitesse de sortie compte. Le déchargement local extrême est utile pour l'apprentissage et les tâches privées occasionnelles ; l'inférence hébergée est généralement la voie de production plus simple.

Ce que « exécuter un LLM 70B sur un GPU 4GB » signifie réellement

Quatre ressources différentes sont compressées dans un titre. Les séparer prévient la plupart des mauvaises décisions matérielles.

La démonstration originale de 2023 utilisait un point de contrôle 70B basé sur Llama 2 avec 80 couches de transformer. Une couche était estimée à environ 1.6GB, tandis que le cache KV pour son exemple de 100 tokens était d'environ 30MB. Le processus mesuré restait en dessous de 4GB de mémoire GPU sur un Nvidia T4.^[1]

Le référentiel actuel d'AirLLM étend la même idée à Llama 3.x, Qwen, DeepSeek, Mixtral, Phi, Gemma et d'autres familles. Son tableau de référence actuel liste toujours un point de contrôle Llama 3.x 70B en pleine précision fonctionnant à environ 4GB de VRAM.^[2] Traitez cela comme une revendication de projet et un objectif mémoire, pas un benchmark de débit pour chaque carte 4GB.

Comment fonctionne l'inférence par couche d'AirLLM

Un transformer exécute ses blocs en séquence. La couche 12 consomme l'état caché de la couche 11 ; la couche 13 attend la couche 12. AirLLM exploite cet ordre avec un pipeline en cinq parties.

1. Créer une coquille de modèle vide. Le méta-device de Hugging Face Accelerate initialise l'architecture sans allouer le vrai stockage pour chaque paramètre.^[3]
2. Reconfigurer le point de contrôle par couche. Les fichiers Safetensors sont réorganisés pour que le chargement d'une couche ne nécessite pas la lecture d'un fragment sans rapport de plusieurs gigabytes.
3. Charger une couche sur le périphérique de calcul. Seulement cette couche et les tenseurs d'exécution requis occupent le GPU à ce moment.
4. Calculer, libérer et continuer. L'état caché avance tandis que les poids de couche quittent la VRAM.
5. Répéter pour chaque token généré. La prélecture chevauche certaines entrées/sorties de stockage avec le calcul, mais elle ne peut pas éliminer le mouvement de données répété.

FlashAttention réduit la mémoire temporaire utilisée par l'attention par le calcul en tuiles et conscient des entrées/sorties.^[4] Cela aide la couche active à tenir, tandis que la diffusion en couche résout le problème distinct de l'endroit où les poids inactifs attendent.

Matériel et stockage que vous avez toujours besoin

Le GPU n'est qu'un seul composant. Avant de télécharger un point de contrôle 70B, vérifiez le reste de la machine.

• Un chemin de calcul compatible. Les démonstrations de titre ciblent Nvidia CUDA. AirLLM documente également les chemins Apple Silicon et CPU, mais leurs caractéristiques de mémoire et de performance sont différentes.^[2]
• Assez de disque pour le point de contrôle et la conversion. Le projet avertit que la division des couches de première exécution est gourmande en disque. Son option delete_original peut supprimer le point de contrôle d'origine après conversion quand le stockage est limité.
• Stockage local rapide. NVMe ne rend pas la diffusion en couche gratuite, mais un disque dur lent aggrave considérablement une boucle déjà limitée par les entrées/sorties.
• Un contexte initial et une sortie courts. Commencez avec une invitation minuscule et 20-40 nouveaux tokens. Un contexte plus long augmente le cache KV, tandis qu'une sortie plus longue répète la traversée complète de la couche plus de fois.
• Accès au modèle. Les points de contrôle Meta contrôlés d'accès nécessitent un token Hugging Face et l'acceptation de la licence du modèle.

Ne commencez pas par un téléchargement 70B juste pour tester si l'environnement fonctionne. Exécutez d'abord un modèle de 8B ou plus petit supporté, vérifiez les chemins CUDA et de stockage, puis augmentez la taille.

Comment essayer AirLLM avec un modèle 70B

Le démarrage rapide du projet actuel utilise AutoModel, qui choisit l'implémentation appropriée à partir d'une ID de référentiel Hugging Face.^[2] Installez d'abord une compilation PyTorch compatible avec votre pilote CUDA, puis installez AirLLM.

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

Gardez les secrets dans les variables d'environnement plutôt que le code source :

export HF_TOKEN="your_hugging_face_token"

Ensuite, exécutez une génération délibérément petite :

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]))

C'est une adaptation minimale du démarrage rapide du référentiel, pas un fichier de verrouillage d'environnement universel. AirLLM, Transformers, PyTorch, CUDA et le code distant d'un modèle peuvent avoir des contraintes spécifiques à la version, alors vérifiez les problèmes actuels du référentiel avant de l'installer sur une machine de production.

Ce qui se passe à la première exécution

Le premier lancement n'est pas représentatif des lancements ultérieurs. AirLLM doit télécharger le modèle, inspecter son architecture, fractionner le point de contrôle en fragments de couche et écrire ces fragments dans le chemin configuré. Interrompre cette conversion ou manquer d'espace disque peut laisser une en-tête safetensors incomplète ; la FAQ du projet recommande d'effacer le cache incomplet et de réexécuter après avoir libéré de l'espace. ^[2]

Surveillez quatre signaux séparément :

nvidia-smi -l 1          # Mémoire GPU et utilisation
free -h                  # Mémoire système
df -h /data              # Espace disque libre
iostat -xz 1             # Saturation de stockage, si sysstat est installé

Un nombre VRAM bas n'est pas un succès en soi. Enregistrez le temps jusqu'au premier token, les secondes par token de sortie, le volume de lecture disque et si les exécutions répétées réutilisent les fragments complétés.

Pourquoi AirLLM est lent même quand cela tient

L'inférence GPU normale charge les poids une fois et les réutilise pour de nombreux tokens et requêtes. Le déchargement des couches extrêmes inverse cet avantage. Chaque nouveau token doit traverser la pile complète du modèle tandis que les poids se déplacent du stockage dans le GPU en petits morceaux.

AirLLM a ajouté la prélecture pour chevaucher le chargement avec le calcul et offre une compression de poids bloc-wise 4 bits ou 8 bits pour réduire le trafic disque. Le référentiel rapporte une amélioration jusqu'à trois fois la compression, mais la performance réelle dépend du modèle, du stockage, du GPU, du contexte et des versions de logiciel.^[2]

Cela rend la méthode plus crédible pour :

• l'évaluation ponctuelle d'un modèle qui ne peut pas se charger ;
• la classification ou l'extraction de documents hors ligne ;
• le traitement par lots privé à faible volume où la latence est secondaire ;
• l'étude de la programmation de la mémoire et de l'architecture du modèle.

C'est un mauvais défaut pour le chat en direct, les boucles d'agents, la haute concurrence ou tout API avec un objectif de latence.

AirLLM contre quantization contre une API

Choisissez AirLLM quand l'expérience est le point. Choisissez un modèle quantisé plus petit quand l'interactivité locale est le point. Choisissez une API quand le modèle 70B et le temps de réponse utilisable sont les deux conditions.

La même distinction s'applique à des affirmations beaucoup plus grandes. Notre analyse Kimi K3 sur un GPU 4GB explique pourquoi les experts clairsemés changent l'unité de diffusion mais n'effacent pas le point de contrôle. Pour un exemple actuel d'API long contexte, consultez le guide API MiniMax M3, ou parcourez le catalogue de modèles en direct.

Une liste de contrôle de décision pratique

Avant de tenter un LLM 70B sur un GPU 4GB, répondez à ces questions :

1. L'objectif est-il de prouver l'exécution ou de construire un produit réactif ?
2. Le disque peut-il contenir le modèle d'origine et sa copie en fragments de couche lors de la conversion ?
3. L'architecture du point de contrôle est-elle explicitement supportée par la version actuelle d'AirLLM ?
4. La charge de travail peut-elle tolérer un long temps jusqu'au premier token et un faible débit ?
5. La licence du modèle autorise-t-elle l'utilisation prévue ?
6. Avez-vous d'abord testé la même pile de logiciels avec un petit point de contrôle ?

Si la réponse aux questions deux à quatre est non, le titre 4GB n'est pas un plan de déploiement utile.

FAQ

Un LLM 70B peut-il vraiment s'exécuter sur un GPU 4GB ?

Oui, par diffusion extrême en couche. Seulement une petite partie du modèle est résidente en VRAM à la fois ; le point de contrôle complet reste sur disque. Ce n'est pas la même chose que de charger un modèle 70B en 4GB.

Le test AirLLM d'origine a-t-il utilisé une véritable carte graphique 4GB ?

L'article de 2023 dit que l'équipe testait sur un Nvidia T4 16GB et mesurait moins de 4GB d'utilisation de mémoire GPU.^[1] Le référentiel actuel liste séparément Llama 3.x 70B à environ 4GB VRAM.

Combien d'espace disque un modèle 70B nécessite-t-il ?

Cela dépend de la précision et du format du point de contrôle. La démonstration originale décrivait environ 130GB de paramètres, et la conversion de couche peut temporairement nécessiter à la fois les copies d'origine et converties. Vérifiez les fichiers du référentiel avant de télécharger et laissez de la place pour les conversions interrompues ou partielles.

AirLLM est-il assez rapide pour un chatbot ?

Habituellement pas sur du matériel bas de gamme. L'auteur original avertit qu'une installation T4 est lente et mieux adaptée au travail hors ligne.^[1]

AirLLM entraîne-t-il un modèle 70B en 4GB ?

Non. L'entraînement doit retenir ou recalculer les activations et les gradients pour la rétropropagation. La technique en couche d'AirLLM adresse l'inférence, pas l'entraînement complet.^[1]

Un modèle 70B 4 bits est-il assez petit pour 4GB VRAM ?

Non. Soixante-dix milliards de paramètres à quatre bits nécessitent une valeur théorique de 35GB uniquement pour les poids bruts, avant les métadonnées de quantification et la mémoire d'exécution. La quantification aide, mais elle ne ferme pas cet écart.

Le verdict honnête sur l'inférence 70B avec 4GB VRAM

AirLLM transforme un plafond mémoire dur en un problème de programmation. C'est un véritable résultat technique : un LLM 70B peut s'exécuter avec environ 4GB de VRAM quand l'exécution diffuse les fragments de couche à partir d'un stockage beaucoup plus grand. Le prix est des entrées/sorties répétées, une génération lente, un grand point de contrôle et une pile logicielle fragile.

Utilisez-le pour étudier l'inférence extrême ou terminer des tâches hors ligne à faible volume. Pour une application interactive, utilisez un modèle local plus petit ou appelez un modèle hébergé via le démarrage rapide reAPI. La leçon utile n'est pas que 70B soit devenu un modèle 4GB. C'est que la VRAM n'a plus besoin de contenir chaque poids à la fois.

Références

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