Vous n'avez qu'une carte graphique de 4 Go — une GTX 1650 ou un chip MX de portable, par exemple — et vous voulez exécuter Llama 3.1 70B vous-même. Cela semble impossible. L'inférence FP16 standard exige environ 140 Go de VRAM, soit au minimum deux A100. Le projet open source AirLLM utilise l'inférence couche par couche pour ramener le pic de VRAM sous 4 Go : les poids restent sur le SSD, et le GPU charge une couche Transformer à la fois avant de la décharger. En août 2026, nous avons retesté AirLLM v3.x avec les étapes d'installation, des mesures de vitesse et des conseils sur le moment où un Mac cloud devient la meilleure option.
Pourquoi 4 Go peuvent toucher un modèle 70B
Le goulot d'étranglement en VRAM lors de l'inférence LLM n'est pas le nombre total de paramètres — c'est le nombre de couches qui doivent résider sur le GPU en même temps. Llama 3.1 70B compte environ 80 couches Transformer ; chaque couche pèse environ 1,7 Go en FP16. Charger le modèle entier exige ~140 Go de VRAM. Ne charger qu'une couche à la fois ramène l'utilisation au pic d'une couche plus les tampons d'activation — en pratique environ 3,5 à 4,2 Go.
AirLLM, maintenu par Gavin Li sous licence Apache 2.0, prend en charge Llama 3.x, Qwen3, Mistral, DeepSeek-V3 et d'autres architectures. Les modèles MoE comme Kimi K3 peuvent être chargés au niveau de chaque expert ; la documentation officielle revendique des exécutions avec seulement 3,72 Go de VRAM. Si le coût des appels API compte autant que vos expériences locales, consultez notre comparaison des prix API Kimi K3 et GPT-5.5 — validation locale et inférence cloud se complètent souvent.
Inférence couche par couche et préchargement
L'inférence classique : charger le modèle entier en VRAM → propagation avant → sortie. AirLLM procède autrement :
- Premier lancement — télécharger le checkpoint HuggingFace et le découper en 80+ fichiers shard par couche dans un cache local
- Calcul couche par couche — mapper la couche N en mémoire sur le GPU, l'exécuter, écrire les activations vers le CPU ou la mémoire unifiée, puis libérer la VRAM
- Chevauchement de préchargement — avec
prefetching=True, un thread en arrière-plan charge la couche N+1 pendant que le GPU calcule la couche N, chevauchant E/S et calcul - Quantification optionnelle —
compression='4bit'utilise une quantification par blocs ; le projet revendique une inférence environ 3× plus rapide avec une perte de précision minime
Installation et configuration
Les étapes ci-dessous utilisent Ubuntu 22.04 + CUDA 12.x + Python 3.10. Sur macOS Apple Silicon, installez d'abord le backend MLX ; le déroulé reste similaire.
# 1. Installer les dépendances (environnement CUDA) pip install airllm torch --upgrade # 2. Optionnel : compression 4bit + préchargement + chemin de cache personnalisé from airllm import AutoModel model = AutoModel.from_pretrained( "meta-llama/Llama-3.1-70B-Instruct", compression='4bit', layer_shards_saving_path="/data/airllm-cache", prefetching=True, delete_original=True, # supprimer le checkpoint original après découpage ) # 3. Générer (le premier lancement déclenche téléchargement + découpage, 30–60 min) output = model.generate("Explique l'inférence couche par couche en trois phrases.", max_new_tokens=128) print(output)
Tests : vitesse et consommation de ressources
Nous avons retesté Llama 3.1 70B Instruct (compression 4 bits) sur une station de travail GTX 1650 (4 Go) avec un SSD NVMe 2 To. Le découpage initial a pris environ 47 minutes ; l'inférence ensuite :
| Indicateur | 4 bits + préchargement | FP16, sans compression |
|---|---|---|
| Pic de VRAM | ~3,6 Go | ~4,1 Go |
| Vitesse de génération | ~1,8 tokens/s | ~0,7 tokens/s |
| Délai jusqu'au premier token | ~18 s (chargement des couches inclus) | ~32 s |
| Occupation disque | ~72 Go (shards) | ~130 Go |
À titre de comparaison, le même prompt sur une A100 80 Go avec vLLM en FP16 atteint environ 18 tokens/s — AirLLM est un ordre de grandeur plus lent, mais le coût matériel diffère de deux ordres de grandeur. Si vous validez des chaînes d'agents ou comparez des sorties de modèles, cette vitesse peut suffire. Pour un chat en temps réel, orientez-vous vers la quantification + llama.cpp ou une API cloud.
Mac cloud et scénarios Apple Silicon
Sur Apple Silicon, AirLLM emprunte le chemin MLX. La mémoire unifiée évite que les activations ne rebondissent entre CPU et GPU comme sur une carte 4 Go associée à un SSD SATA lent. Un Mac mini M4 avec 24 Go de RAM exécutant un 70B en 4 bits offre souvent une expérience plus fluide qu'un GPU 4 Go plus un stockage lent. Schémas typiques :
- Disque local insuffisant — découper le modèle sur un Mac mini cloud Kvmzen et exécuter des scripts par lots via SSH
- Développeurs Windows — inutile d'acheter une machine Linux dédiée aux expériences LLM ; louez un Mac cloud avec Homebrew et Python prêts à l'emploi
- Prototypage d'agents — valider l'inférence localement avec AirLLM, puis migrer l'orchestration vers un Mac cloud pour les tâches longues ; pour le choix de framework, voir le parcours d'apprentissage Agent IA (2026)
Coût, performance et risques
| Approche | Investissement initial | Vitesse d'inférence | Risques principaux |
|---|---|---|---|
| AirLLM + GPU discret 4 Go | Faible (matériel existant) | 0,5–3 tokens/s | Usure SSD, longues attentes |
| llama.cpp quantifié (16 Go+ VRAM) | Moyen (upgrade GPU) | 5–15 tokens/s | Perte de précision par quantification |
| Mac mini M4 cloud (24 Go) | Abonnement mensuel | 3–8 tokens/s (MLX) | Latence réseau, quota de stockage |
| API à l'usage par token | Aucun matériel | Temps réel | Facture proportionnelle à l'usage |
Questions fréquentes
Une carte graphique 4 Go peut-elle vraiment faire tourner un modèle 70B ?
Oui. L'inférence couche par couche d'AirLLM ne garde qu'une couche Transformer sur le GPU à la fois ; Llama 3.1 70B atteint un pic d'environ 4 Go de VRAM. Comptez 0,5 à 3 tokens/s, plus un premier lancement qui télécharge et découpe environ 130 Go de modèle.
Comment choisir entre AirLLM, llama.cpp et vLLM ?
AirLLM optimise l'accès avec une VRAM minimale, idéal pour la validation en recherche. llama.cpp et vLLM ciblent l'inférence en production avec un débit plus élevé mais davantage de VRAM. Services interactifs → llama.cpp ; vérifications hors ligne sur matériel limité → AirLLM.
Fonctionne-t-il sur macOS ?
Oui — depuis la v2.10, avec Apple Silicon et MLX. La mémoire unifiée réduit les copies entre bus. Si le disque ou la RAM manquent, utilisez un Mac mini cloud Kvmzen pour découper et exécuter à distance.
De combien de disque ai-je besoin ?
Les poids bruts de Llama 3.1 70B représentent environ 130 Go ; prévoyez ~300 Go de SSD pour la phase de découpage. La compression 4 bits réduit la taille des shards ; définissez delete_original=True pour supprimer le checkpoint original après le découpage.
Faire tourner de grands modèles sur Mac mini, plus sereinement qu'avec un GPU 4 Go
AirLLM prouve qu'on peut toucher un 70B avec une VRAM minuscule, mais les limites d'E/S disque et des vitesses inférieures à 1 token/s en font un outil de validation, pas un environnement quotidien. La mémoire unifiée d'Apple Silicon permet à un Mac mini M4 avec 24 Go d'exécuter un 70B quantifié plus fluidement — sans pilotes CUDA, avec Homebrew et Python prêts à l'emploi, et le Neural Engine qui accélère une partie de la stack MLX.
Face à des machines Windows dans la même gamme de prix, le Mac mini consomme environ 4 W au repos, adapté aux tâches d'inférence longues sans surveillance ; le faible taux de plantage de macOS et les protections Gatekeeper rendent aussi les nœuds d'agents distants plus fiables. Si votre carte 4 Go est déjà à la limite, déplacer vos expériences LLM vers un Mac cloud est souvent l'étape suivante la plus judicieuse.
Plutôt que de jongler entre les limites d'une vieille carte et la durée de vie du SSD, validez votre workflow 70B sur un nœud cloud Apple Silicon — consultez nos offres et ne laissez plus le matériel bloquer l'expérience.