AirLLM : un 70B sur un GPU 4 Go, vraiment ? Test et limites

#La promesse AirLLM : un 70B sur 4 Go de VRAM

Un modèle 70B en quantization Q4 réclame environ 40 Go de VRAM pour être chargé entièrement en mémoire — soit une RTX 4090 (24 Go) plus une seconde carte, ou un Mac Studio à grosse mémoire unifiée. AirLLM prétend faire tenir le même modèle sur une carte à 4 Go, y compris une modeste GTX 1650 ou une T4 gratuite de Google Colab. Ce n'est pas un tour de passe-passe marketing sur la taille du modèle : c'est bien le 70B complet, en FP16 ou en 4/8 bits, qui produit les réponses.

Le secret tient en trois mots : le modèle n'est jamais chargé en entier dans la VRAM. AirLLM découpe le réseau en couches (layers), les stocke sur le disque, et ne charge dans le GPU qu'une seule couche à la fois pendant le calcul. La VRAM ne contient donc jamais que les poids d'un layer plus les activations courantes — d'où le besoin de seulement quelques gigaoctets.

#Comment marche le layer streaming

Un LLM de type transformer est une pile de couches identiques dans leur structure (attention + feed-forward), traversées les unes après les autres. Un Llama 70B en compte 80. L'inférence classique charge les 80 couches en VRAM d'un coup et les fait toutes résider en mémoire pendant toute la génération. AirLLM renverse ce principe.

Découpage disque

Au premier chargement, AirLLM éclate les poids du modèle en fichiers séparés, un par couche, stockés sur le SSD. Cette étape de conversion ne se fait qu'une fois par modèle.

Chargement à la volée

Pour générer un token, le moteur charge la couche 1 dans le GPU, calcule, libère la VRAM, charge la couche 2, calcule, et ainsi de suite jusqu'à la couche 80.

VRAM constante

À tout instant, seule une couche réside en VRAM. Le pic mémoire dépend de la plus grosse couche et de la longueur de contexte, pas de la taille totale du modèle.

Prefetch et quantization disque

AirLLM précharge la couche suivante pendant le calcul de la couche courante et peut compresser les poids sur disque (block-wise quantization) pour réduire le volume de données à lire.

Le goulot d'étranglement saute aux yeux : à chaque token généré, il faut lire l'intégralité des poids du modèle depuis le disque. Pour un 70B, cela représente plusieurs dizaines de gigaoctets transférés du SSD vers le GPU pour un seul token. C'est là que se joue toute la performance — et toute la limite — d'AirLLM.

#Prérequis et installation

AirLLM est une bibliothèque Python qui s'appuie sur PyTorch et l'écosystème Hugging Face. Elle ne s'utilise pas comme Ollama (pas de daemon, pas de commande run) : on l'importe dans un script Python. Voici ce qu'il faut avant de commencer.

GPU

N'importe quelle carte NVIDIA avec 4 Go de VRAM minimum (CUDA). Le support Apple Silicon (MPS) et le CPU existent mais sont encore plus lents.

Disque

Un SSD NVMe rapide est indispensable, plus l'espace pour stocker le modèle décompressé (≈40 Go pour un 70B, davantage en FP16).

RAM système

16 Go suffisent ; AirLLM ne charge pas le modèle en RAM, contrairement à un offload CPU classique.

Python

Un environnement Python 3.10+ avec PyTorch et CUDA correctement installés.

pip install airllm

#Lancer un 70B sur 4 Go : le test

Le code minimal pour charger et interroger un Llama 70B tient en une quinzaine de lignes. AirLLM se charge du découpage en couches au premier appel (comptez plusieurs minutes de conversion et le téléchargement du modèle depuis 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. Premier chargement

   AirLLM télécharge le modèle puis le convertit en fichiers par couche sur le SSD. Cette étape est longue mais unique : les exécutions suivantes réutilisent le cache disque.
2. 02
   2. Réglage de la compression

   Le paramètre compression='4bit' (ou '8bit') réduit le volume lu depuis le disque et accélère donc l'inférence, au prix d'une légère perte de qualité — le même compromis que la quantization classique.
3. 03
   3. Génération

   Chaque token déclenche une lecture complète des 80 couches depuis le SSD. La barre de progression avance couche par couche : c'est visuellement lent, et c'est normal.
4. 04
   4. Mesure

   Chronométrez le temps total et divisez par le nombre de tokens générés pour obtenir votre débit réel en tokens/s. C'est le seul chiffre qui compte pour décider si l'outil est utilisable dans votre cas.

#Benchmark réel : combien de tokens par seconde ?

C'est ici que la promesse rencontre la réalité physique. Sur un 70B streamé depuis un SSD NVMe, on ne parle pas de tokens par seconde mais souvent de secondes par token. L'ordre de grandeur à retenir, selon les configurations rapportées et nos essais :

70B / NVMe PCIe 4.0 rapide

de l'ordre de 0,1 à 0,5 token/s, soit 2 à 10 secondes pour produire un seul mot. Une réponse de 200 tokens prend plusieurs minutes.

70B / SSD SATA

2 à 5x plus lent encore : la bande passante disque plafonne à ~500 Mo/s, on tombe sous 0,1 token/s.

Comparaison 70B chargé en VRAM (2x RTX 4090)

15 à 30 tokens/s. L'écart avec AirLLM est d'un facteur 30 à 300 selon le disque.

Modèle 8B en Q4 sur une seule RTX 3060 12 Go

40 à 80 tokens/s, sans aucun streaming — pour rappeler l'échelle du confort perdu.

La formule est simple : à chaque token, il faut relire tout le modèle depuis le disque. Un 70B en 4 bits pèse ~40 Go ; à 5 Go/s de lecture NVMe, cela fait déjà 8 secondes de pure entrée/sortie par token, avant même le calcul. Aucune optimisation logicielle ne peut contourner cette barrière tant que les poids vivent sur le disque. C'est un ralentissement de 5 à 30x dans le meilleur des cas (petits modèles, disque très rapide, compression agressive) et bien davantage sur les gros modèles.

#Cas d'usage honnêtes

À 0,2 token/s, AirLLM est inutilisable pour discuter. Mais il existe de vrais scénarios où la lenteur ne pose pas de problème, parce que personne n'attend devant l'écran.

Traitement par lots (batch) hors ligne

Un script qui doit passer 500 documents dans un 70B pendant la nuit se moque qu'un document prenne 3 minutes : le résultat est là au matin. C'est le cas d'usage le plus légitime.

Expérimentation ponctuelle

Vérifier ce qu'un 70B précis répond sur quelques prompts, sans louer un GPU cloud ni acheter de matériel, pour décider s'il vaut l'investissement.

Extraction structurée non urgente

Générer un jeu de données, annoter un corpus, produire des embeddings ou des synthèses en tâche de fond, où le débit importe peu.

Accès à un modèle géant sans budget

Étudiant, chercheur ou curieux avec une seule petite carte, qui veut toucher un modèle qu'il ne pourrait pas faire tourner autrement.

#Quand c'est du marketing

La formule « un 70B sur 4 Go » est techniquement vraie mais éditorialement trompeuse dès qu'on sous-entend un usage normal. Voici les situations où AirLLM ne tient pas ses promesses implicites.

Chat interactif

Attendre plusieurs minutes une réponse tue toute conversation. Pour discuter, un 8B ou 14B local instantané est infiniment plus utile qu'un 70B qui répond à la vitesse d'un fax.

Assistant de code en temps réel

L'autocomplétion et le pair-programming exigent des réponses en une poignée de secondes. AirLLM en est à des années-lumière.

Serveur multi-utilisateurs

Impossible de servir plusieurs personnes : chaque token monopolise déjà toute la bande passante disque pour une seule requête.

Production

Aucun service en ligne ne peut reposer sur AirLLM. La latence et l'usure du SSD (lectures massives permanentes) l'excluent d'emblée.

#Alternatives : la quantization classique d'abord

Avant de recourir au layer streaming, épuisez les solutions qui gardent le modèle en mémoire — elles sont presque toujours préférables. La question n'est pas « comment faire tenir un 70B sur 4 Go » mais « quel modèle répond réellement à mon besoin ».

Descendre en quantization

Un 70B en Q4_K_M tient sur ~40 Go, en Q2/Q3 sur beaucoup moins. Mais un 70B trop agressivement quantisé perd de sa qualité : mieux vaut souvent un 32B en Q4 bien chargé.

Choisir un modèle plus petit et récent

Un 32B (≈19 Go VRAM) ou un 14B (≈9 Go) de 2026 rivalise avec un 70B de 2024 sur la plupart des tâches, tout en tournant instantanément sur une seule carte.

Offload CPU/GPU d'Ollama ou llama.cpp

Ces moteurs déchargent une partie des couches en RAM système quand la VRAM manque. C'est plus lent qu'un chargement full-GPU, mais bien plus rapide qu'AirLLM, car la RAM est cent fois plus rapide qu'un SSD.

Louer un GPU cloud pour un besoin ponctuel

Pour tester un vrai 70B rapidement une seule fois, une heure de GPU loué coûte peu et donne un débit normal — souvent plus rentable que des heures d'attente en local.

#Pour aller plus loin

AirLLM est un outil de contournement : avant d'y recourir, il vaut mieux maîtriser les leviers classiques de la VRAM et du choix de modèle. Trois guides du site complètent le tableau.

Choisir sa quantification (Q4, Q5, Q8, FP16)

Comprendre combien de qualité un modèle perd en Q4 ou Q3, et comment faire rentrer un gros modèle dans une VRAM limitée sans passer par le streaming disque.

Choisir son GPU pour l'IA locale

Les arbitrages VRAM/budget/performance, du RTX 3060 12 Go au Mac Studio Ultra, pour savoir quelle taille de modèle votre matériel encaisse vraiment.

llama.cpp vs vLLM vs Exllama

Les moteurs d'inférence et leur gestion de l'offload CPU/GPU, l'alternative sérieuse à AirLLM quand la VRAM manque un peu.