LLM auto hébergées · 3 November 2026

AirLLM en 2026 : faire tourner un 70B sur 4 Go de VRAM, vraiment ? Ce que la promesse cache (et ce qui marche vraiment)

La promesse circule partout : exécuter un modèle de 70 milliards de paramètres sur un GPU de 4 Go, voire un 405B sur 8 Go, sans quantification. Derrière le slogan, une technique d’inférence par couches qui déplace le goulot d’étranglement de la VRAM vers votre SSD. Décryptage sans complaisance — et confrontation avec ce que l’écosystème local de 2026 propose réellement.

4 Go de VRAM pour un 70B : la promesse qui fait grincer des dents

Il y a des affirmations qui, dans le petit monde de l’IA locale, déclenchent immédiatement un haussement de sourcils. « AirLLM 70B inference with single 4GB GPU » — c’est le titre du dépôt GitHub du projet, signé lyogavin, et c’est aussi la phrase qui résume à elle seule le paradoxe. Pour quiconque a déjà tenté de charger un modèle un tant soit peu sérieux sur une carte graphique grand public, ce chiffre sonne comme une erreur de frappe. Un 70B en FP16, c’est environ 140 Go de poids. Une RTX 4060 Ti, l’une des cartes les plus répandues du marché, embarque 8 ou 16 Go de VRAM. Une RX 7800 XT, citée dans nos propres relevés 2026, plafonne à 16 Go. Autrement dit : le rapport VRAM/paramètres, cette règle empirique qui veut qu’un modèle ait besoin de deux octets par paramètre en précision native, interdit mécaniquement l’opération. Sauf que.

Sauf qu’AirLLM ne prétend pas faire tenir le modèle en VRAM. Il prétend faire tourner le modèle avec 4 Go de VRAM. La nuance est capitale, et c’est précisément ce qui rend le sujet intéressant. Dans un contexte 2026 où la mémoire vidéo reste l’un des composants les plus chers du marché, où les mini-PC à mémoire unifiée comme l’AMD Ryzen AI Halo (128 Go, 3 999 $) ou le Strix Halo (64 à 128 Go selon configurations, à partir d’environ 1 500 $) redessinent la frontière du « local », et où les modèles MoE changent la donne, la question mérite d’être posée sérieusement : AirLLM est-il une vraie voie pour le grand public, ou un hack de spécialiste que l’on confond avec une solution ?

Nous allons décortiquer le mécanisme réel, mesurer les compromis, confronter la promesse aux alternatives que sont la quantification, l’offload de llama.cpp et les architectures MoE, puis trancher sur les cas d’usage défendables. Car entre-temps, l’écosystème a beaucoup bougé : la refonte de llama.cpp fusionnée en avril 2026, la montée en puissance d’Ollama et de son moteur MLX, l’arrivée de moteurs comme Strata qui revendiquent de faire tourner un Qwen 125B sur une carte graphique ordinaire, et la généralisation des MoE ont redistribué les cartes. AirLLM n’est plus seul sur la ligne de départ — et c’est tant mieux pour la clarté du débat.

Ce qu’AirLLM fait vraiment : charger une couche, calculer, jeter

Le principe tient en une phrase : les poids du modèle ne résident jamais entiers en VRAM. Ils sont streamés séquentiellement depuis le stockage, une couche à la fois, avec offload agressif des activations et du cache KV. C’est ce qu’on appelle l’inférence par couches (layer-wise inference), et l’idée n’est pas neuve — elle a été explorée dès les premières années des transformers trop gros pour une seule carte. Ce qui est nouveau, c’est le degré de systématisation qu’AirLLM en propose, et le fait que le projet refait surface en 2026 avec une promesse élargie : 70B sur 4 Go, 405B sur 8 Go, sans quantification.

Concrètement, le déroulé d’un token ressemble à ceci. Le moteur charge la couche 0 depuis le disque vers la VRAM, effectue le calcul, puis jette la couche 0 et charge la couche 1. Et ainsi de suite jusqu’à la couche N. Les activations intermédiaires — ces tenseurs qui transportent l’information d’une couche à l’autre — sont, elles aussi, déchargées vers la RAM système ou le disque entre deux étapes. Le cache KV, cette mémoire qui stocke les clés et valeurs des tokens déjà traités pour éviter de les recalculer, subit le même traitement. Résultat : à aucun moment le modèle complet n’a besoin de tenir dans la VRAM. Seule une couche, plus les activations courantes, doivent y résider simultanément.

C’est là que la différence avec l’offload classique de llama.cpp devient cruciale. Quand llama.cpp « offload » un modèle, il garde un sous-ensemble des couches en VRAM et bascule le reste en RAM système, calculé par le CPU. Le modèle reste donc entièrement en mémoire vive, ce qui suppose d’avoir 64, 96, voire 128 Go de RAM. AirLLM, lui, se passe de cette contrainte : le modèle vit sur le disque, et seule la couche active transite. C’est un pari différent. llama.cpp parie sur la RAM ; AirLLM parie sur le débit disque.

Pourquoi ça permet théoriquement de faire tenir n’importe quel modèle dense dans une VRAM minuscule ? Parce que la VRAM n’est plus un espace de stockage, mais un espace de travail temporaire. La question n’est plus « est-ce que ça rentre ? » mais « est-ce que je peux lire les poids assez vite pour que le calcul ne soit pas ridiculement lent ? ». Et c’est là que le bât blesse.

Le vrai goulot d’étranglement n’est pas la VRAM, c’est votre SSD

Faisons le calcul. Un modèle 70B en FP16 pèse environ 140 Go. Pour générer un seul token, il faut — dans le pire cas, sans cache intelligent — relire l’intégralité de ces 140 Go depuis le disque. Pas une fois par session : une fois par token. Si vous générez 100 tokens, vous lisez 14 To. Si vous générez 1 000 tokens, vous lisez 140 To. C’est le cœur du problème, et c’est ce qui explique pourquoi la promesse marketing doit être lue avec précaution.

Les débits des supports de stockage donnent immédiatement l’échelle. Un SSD SATA tourne autour de 0,5 Go/s. Un NVMe Gen4 atteint environ 7 Go/s. Un NVMe Gen5 monte à environ 14 Go/s. Un disque dur mécanique, lui, est tout simplement disqualifié : à quelques centaines de Mo/s, le calcul d’un seul token prendrait des minutes. Même avec un Gen5, 140 Go lus à 14 Go/s représentent 10 secondes par token dans le pire cas absolu. Soit 0,1 token par seconde. Un dixième de token par seconde.

Évidemment, la réalité est moins brutale, pour plusieurs raisons. D’abord, les implémentations sérieuses ne relisent pas tout à chaque token : elles conservent en cache les couches déjà chargées tant que le contexte ne change pas de structure, et elles exploitent la localité des calculs. Ensuite, la quantification — même si AirLLM revendique de s’en passer — réduit mécaniquement le volume à lire. Un 70B en Q4 pèse environ 40 Go, soit trois fois moins. Enfin, les couches individuelles sont petites : charger une couche à la fois permet de saturer le débit disque plus efficacement qu’un chargement massif.

Reste que le goulot est structurel. Là où un modèle qui tient en VRAM lit ses poids à plusieurs centaines de Go/s depuis la mémoire vidéo, AirLLM lit à quelques Go/s depuis le disque. Le rapport est de deux ordres de grandeur. Aucune optimisation logicielle ne comble cet écart : c’est une limite physique du support. C’est d’ailleurs la conclusion des tests indépendants publiés en 2026 : ça tourne, mais le débit obtenu relève de l’expérience de validation, pas de l’usage quotidien.

Et il y a un coût caché que personne ne mentionne dans les vidéos de démonstration : l’usure du SSD. Chaque token généré consomme de l’écriture et de la lecture sur votre disque. Les SSD NVMe ont une endurance mesurée en TBW (téraoctets écrits). Un modèle 70B streamé intensivement peut consommer plusieurs téraoctets par session de génération longue. Sur un disque grand public, cela peut représenter une fraction non négligeable de sa durée de vie. Le « gratuit » de l’IA locale a un prix matériel — un point qui rejoint directement notre dossier sur le coût réel de l’IA à domicile.

70B sur 4 Go : combien de tokens par seconde, vraiment ?

Venons-en aux chiffres concrets, en restant honnête sur ce que les sources permettent d’affirmer. Le dépôt GitHub du projet annonce « 70B inference with single 4GB GPU », et les articles de présentation 2026 évoquent la possibilité d’exécuter des modèles jusqu’à 405B sur 8 Go de VRAM. Ces affirmations sont techniques : elles décrivent une capacité, pas une performance. La distinction est essentielle.

Décomposons les scénarios. Un 70B dense non quantifié, streamé intégralement depuis un NVMe Gen4, donne des ordres de grandeur de fractions de token par seconde à quelques tokens par seconde selon les optimisations et la taille du contexte. C’est utilisable en batch — on lance une génération, on va faire autre chose, on revient — mais pas en conversation. La latence du premier token, elle, est encore plus révélatrice : il faut charger les premières couches, initialiser le cache, et le temps d’attente se compte en dizaines de secondes, voire en minutes selon la configuration.

Un 70B quantifié en Q4 pèse environ 40 Go. Le débit s’améliore mécaniquement, mais on reste dans des ordres de grandeur modestes comparés à un modèle qui tiendrait en VRAM. Un 405B sur 8 Go de VRAM, c’est encore une autre échelle : le volume de poids à streamer est tel que l’opération relève de l’expérience de laboratoire plutôt que de l’usage courant.

Comparons avec l’offload de llama.cpp, qui reste la référence mature. Sur un 70B en Q4 avec 8 à 12 Go de VRAM et 64 Go de RAM, llama.cpp atteint quelques tokens par seconde — un ordre de grandeur supérieur à ce que produit un streaming disque intégral. La raison est simple : la RAM système a une bande passante bien supérieure à celle d’un SSD, même NVMe. Garder le modèle en RAM et n’utiliser le GPU que pour les couches qui y tiennent est plus efficace que de tout faire transiter par le disque. Et depuis la refonte d’avril 2026 — générateur de kernels, KV cache contigu, dispatch unifié — llama.cpp revendique des gains substantiels sur les gros modèles, ce qui creuse encore l’écart avec une approche « tout streaming ».

Il faut aussi mentionner un effet souvent négligé : la taille du contexte. Plus le contexte s’allonge, plus le cache KV grossit. Or ce cache doit lui aussi être géré, et dans un modèle « tout en streaming », il casse l’hypothèse d’une mémoire de travail minuscule. À mesure que la conversation s’allonge, les besoins en mémoire augmentent, et le débit se dégrade. AirLLM n’échappe pas à cette contrainte — c’est le même piège que celui décrit dans notre dossier sur le Q4, où le KV cache grignote silencieusement le budget mémoire.

Ce que « ça tourne » veut dire, en clair : le modèle produit des tokens corrects, mais à un rythme qui exclut toute interaction fluide. C’est un outil de traitement par lots, pas un assistant.

Quantification, offload, MoE : les trois rivaux qu’AirLLM doit affronter

Pour juger AirLLM, il faut le replacer dans l’écosystème des solutions qui existent déjà et qui, pour la plupart des utilisateurs, font mieux.

Premier rival : la quantification. Un 70B en Q4 tient en environ 40 Go, en Q5 un peu plus, en Q8 environ 70 Go. La quantification réduit la précision des poids — 4 bits pour AWQ en W4A16, par exemple — au prix d’une légère dégradation de qualité, souvent imperceptible en usage courant. Les formats GGUF, bien documentés, permettent de choisir son niveau de quantification selon son matériel. Un 70B Q4 nécessite toujours un offload RAM sur une machine grand public, mais il reste plus rapide qu’un streaming disque intégral, parce que la RAM est plus rapide que le SSD. La quantification n’est pas l’ennemie d’AirLLM : c’est une approche complémentaire qui, appliquée seule, résout déjà une grande partie du problème pour un coût en qualité minime. Encore faut-il choisir son niveau avec discernement : notre dossier dédié montre que le Q4_K_M « par réflexe » craque sur le raisonnement multi-étapes, le code et les langues non anglaises, et qu’il est particulièrement piégeux sur les MoE et les contextes longs.

Deuxième rival : l’offload de llama.cpp et d’Ollama. C’est la solution mature, intégrée, documentée, avec un support partiel GPU+CPU qui fonctionne. Elle suppose de la RAM — 64 Go est un minimum confortable pour un 70B Q4 — mais elle offre un débit supérieur dans la plupart des configurations, et elle s’intègre dans des outils que tout le monde utilise déjà. Ollama, notamment, a considérablement progressé, avec un moteur MLX sur Mac qui double les performances selon les tests publiés, et un écosystème (Open WebUI, API compatible OpenAI, agents) qui en fait le standard de fait du local. Face à cela, AirLLM demande d’accepter une complexité supplémentaire pour un gain qui n’existe que dans un cas précis : quand on n’a pas la RAM.

Troisième rival, et c’est le plus important en 2026 : les MoE. Un modèle Mixture of Experts n’active qu’une fraction de ses paramètres par token. Un modèle « 70B » au sens du nombre total de paramètres peut n’en activer que 10 ou 15 milliards à chaque token, ce qui le rend confortable sur 24 Go de VRAM avec un débit élevé. C’est la vraie réponse de 2026 au problème que prétend résoudre AirLLM. Les modèles MoE comme Mixtral, DeepSeek ou Qwen-MoE ont changé la donne : au lieu de faire tenir un modèle dense de 70B dans une VRAM minuscule au prix d’un débit catastrophique, on fait tenir un modèle à activation partielle dans une VRAM raisonnable au prix d’un débit tout à fait correct. Le compromis n’est plus le même.

Un quatrième acteur s’est invité dans le débat à l’automne 2026 : les moteurs dits « spécialisés » comme Strata, qui revendiquent de faire tourner un Qwen 125B sur une carte graphique ordinaire. La communauté r/LocalLLaMA en discute âprement, parlant de « moteurs d’inférence surentraînés » — comprenez : des moteurs dont l’ingénierie compense les limites matérielles par des astuces d’orchestration. AirLLM appartient à cette même famille d’approches, mais avec une différence de taille : là où un Strata vise la performance sur du matériel grand public, AirLLM vise l’exploit de la VRAM minimale. Deux philosophies, deux publics.

Ce que la mémoire unifiée change à l’équation

Il serait malhonnête de juger AirLLM sans évoquer la troisième voie qui s’est imposée en 2026 : la mémoire unifiée. Les mini-PC à mémoire partagée entre CPU et GPU — AMD Ryzen AI Halo (128 Go, 3 999 $, jusqu’à 120B+ de paramètres), Gorgon Halo (192 Go visés, 200B+), et les Mac Apple Silicon — ont déplacé le problème. Là où un GPU discret bute sur ses 16 Go de VRAM, une machine à mémoire unifiée de 128 Go fait tenir un modèle de 70B quantifié sans offload disque, avec un débit qui reste modeste mais utilisable.

C’est un point que notre dossier sur OpenClaw et la mémoire unifiée développe longuement : la question « faire tourner des LLM chez soi » ne se pose plus seulement en termes de VRAM, mais en termes d’architecture mémoire. AirLLM répond à une contrainte (4 Go de VRAM) qui, pour beaucoup d’utilisateurs 2026, n’est plus la bonne contrainte. Si vous disposez de 64 Go de RAM et d’un GPU modeste, l’offload llama.cpp est plus rapide. Si vous disposez de 128 Go de mémoire unifiée, vous n’avez même plus besoin de streaming disque. AirLLM n’est pertinent que dans l’angle mort : peu de VRAM, peu de RAM, mais un bon SSD NVMe.

Alors, AirLLM est-il utile ? Les cas d’usage défendables

Après ce réquisitoire, il faut être équitable. AirLLM n’est pas un jouet, et il rend un service réel dans plusieurs scénarios précis.

Premier cas : le batch offline sur matériel contraint. Vous avez un vieux PC avec 4 Go de VRAM, 16 Go de RAM et un NVMe correct. Vous voulez faire tourner un 70B pour traiter un lot de documents pendant la nuit, sans interaction. AirLLM le permet là où llama.cpp échouerait faute de RAM. Le débit médiocre n’est pas un problème : personne n’attend devant l’écran.

Deuxième cas : l’expérimentation et la recherche. Pour valider un comportement de modèle, comparer des sorties, faire de l’évaluation à grande échelle sans se ruiner en GPU, le streaming disque offre une voie économique. C’est un outil de laboratoire, et il assume ce rôle.

Troisième cas : la démonstration pédagogique. Comprendre l’inférence par couches, voir concrètement où se situe le goulot, mesurer l’écart entre VRAM et disque : AirLLM est un excellent support pour cela.

En revanche, pour un assistant conversationnel, un agent, un RAG interactif ou un usage quotidien, il faut regarder ailleurs : Ollama avec un modèle MoE quantifié, llama.cpp post-refonte avec offload, ou une machine à mémoire unifiée. Et si vous vous lancez, ne négligez pas la sécurité : notre guide sur l’OWASP LLM Top 10 2026 rappelle que « c’est en local, je suis safe » est la phrase qui coûte cher — poids empoisonnés sur Hugging Face, injections de prompt via documents, fuites de données par le RAG. AirLLM ne vous protège de rien de tout cela.

Le verdict : un exploit technique, pas une solution grand public

AirLLM fait exactement ce qu’il annonce : il fait tourner un 70B avec 4 Go de VRAM. C’est un tour de force d’ingénierie, et il faut le saluer. Mais la promesse marketing — « un 70B sur un GPU de 4 Go » — est trompeuse si on la lit comme une invitation grand public. Elle décrit une capacité, pas une expérience utilisateur. Le goulot d’étranglement s’est déplacé de la VRAM vers le SSD, et ce déplacement a un coût : débit en fractions de token par seconde, latence de premier token élevée, usure du disque, dégradation avec la longueur du contexte.

En 2026, l’utilisateur qui veut faire tourner un LLM chez soi sans se ruiner a trois meilleures options, par ordre de pertinence : un modèle MoE quantifié sur une VRAM raisonnable (24 Go), l’offload llama.cpp/Ollama si la RAM le permet, ou une machine à mémoire unifiée si le budget suit. AirLLM reste l’outil du cas extrême : peu de VRAM, peu de RAM, un bon SSD, et aucune exigence d’interactivité.

La vraie leçon de l’affaire n’est pas technique, elle est éditoriale : dans l’IA locale, méfiez-vous des chiffres qui font le buzz. « 70B sur 4 Go » ne dit rien de la vitesse, de la qualité, ni du coût réel. La question qui compte n’est pas « est-ce que ça rentre ? », mais « à quelle vitesse, pour quel usage, et à quel prix matériel ? ». Tant que les démonstrations ne répondront pas à ces trois questions, elles resteront des curiosités — brillantes, mais des curiosités.

Sources

• Dépôt GitHub AirLLM (lyogavin) — « AirLLM 70B inference with single 4GB GPU » : https://github.com/lyogavin/airllm
• NerdLevelTech — « AirLLM Tested: Run a 70B LLM on a 4GB GPU — Does It Work? » (2026) : https://nerdleveltech.com/airllm-run-70b-llm-single-4gb-gpu
• QuellLLM — « AirLLM : un 70B sur un GPU 4 Go, vraiment ? Test et limites » (2026) : https://quelllm.fr/guide/airllm-70b-gpu-4gb-verite-limites
• Magazine — « llama.cpp en 2026 : ce que la grande réécriture a vraiment changé » (refonte d’avril 2026, gains 2,1x sur 70B, 1,4x sur 7B)
• Magazine — « Ollama en 2026 : le standard de fait de l’IA locale » (moteur MLX sur Mac, écosystème Open WebUI/API)
• Magazine — « Le vrai coût du Q4 : ce que la quantification GGUF fait vraiment à vos modèles en 2026 » (Q4_K_M, KV cache, pièges MoE)
• Magazine — « OpenClaw, Mac mini et mémoire unifiée : ce que "faire tourner des LLM chez soi" veut vraiment dire en 2026 »
• Magazine — « OWASP LLM Top 10 2026 : sécuriser un LLM open-source qui tourne chez soi »
• ai-stat.ru — « Почему все говорят о Strata: эпоха переобученных движков » (Strata, Qwen 125B sur carte graphique ordinaire, débat r/LocalLLaMA, 5 octobre 2026) : https://ai-stat.ru
• Brief IA — « Faire tourner une IA en local en 2026 : guide complet » (18 septembre 2026) : https://briefia.fr
• PromptQuorum — « Moteurs d’inférence et runtimes locaux : comparatif 2026 » (20 septembre 2026) : https://promptquorum.com
• Techgenyz — « Windows ML: 2026 Updates for GGUF Models and Local AI » (9 octobre 2026) : https://techgenyz.com
• Microsoft Foundry on Windows Blog — « AI Development on Windows: from PyTorch and llama.cpp to Windows ML » (7 octobre 2026) : https://devblogs.microsoft.com
• Faits matériels 2026 : AMD Ryzen AI Halo (128 Go, 3 999 $, jusqu’à 120B+), AMD Gorgon Halo (192 Go visés, 200B+), AMD RX 7800 XT (16 Go), AMD RX 9070 XT 16 Go GDDR6 (690–740 $).

Article recherché et rédigé automatiquement · Magazine Electrosens