Electrosens R&D
Electrosens LLM auto hébergées · 6 November 2026

Faire tourner des LLM open source chez soi sans se ruiner : iGPU, mémoire unifiée et le vrai basculement de 2026

Pendant une décennie, faire tourner un LLM chez soi rimait avec une carte graphique dédiée NVIDIA et un budget à quatre chiffres. En 2026, ce dogme s’effondre sous nos yeux : les iGPU AMD RDNA3/RDNA4 et Intel Arc intégrés deviennent des cibles de première classe pour llama.cpp, portés par des optimisations Vulkan et des formats de quantification qui changent la donne. Mais le vrai changement n’est pas là où on l’attend : il est dans la mémoire unifiée, dans la maturité d’un écosystème logiciel qui a enfin appris à composer avec la diversité matérielle, et dans une arithmétique économique que les PME commencent à faire sérieusement. Panorama d’un basculement qui redessine l’IA locale — et mode d’emploi pour ne pas se ruiner.


Le dogme « il te faut une RTX » : comment l’IA locale s’est retrouvée prisonnière du GPU dédié

Il y a une ironie savoureuse dans l’histoire de l’IA locale. Le mouvement open-weights, né en réaction aux API fermées et aux abonnements mensuels, s’est lui-même enfermé dans une dépendance matérielle : le GPU dédié NVIDIA. Pendant des années, la réponse à « comment faire tourner un LLM chez moi ? » tenait en une phrase : « il te faut une RTX ». Une RTX 3060 12 Go si tu étais raisonnable, une 4090 si tu voulais respirer.

Cette prison n’était pas qu’une affaire de marketing. Elle reposait sur une réalité technique brutale : CUDA. L’écosystème logiciel de l’inférence locale — llama.cpp, mais aussi les couches PyTorch, les bindings, les optimisations de noyaux — s’est construit prioritairement autour de CUDA, parce que c’est là que se trouvaient les utilisateurs, et que les utilisateurs y étaient parce que c’est là que le logiciel fonctionnait. Un cercle vertueux pour NVIDIA, vicieux pour tout le monde.

Les signaux faibles se sont pourtant accumulés. D’un côté, le marché des GPU dédiés grand public a stagné : des générations successives à gains marginaux, des prix qui ne baissent pas, une disponibilité chaotique. De l’autre, les iGPU ont discrètement changé de nature. AMD a poussé RDNA3 puis RDNA4 dans ses APU mobiles, Intel a fait de même avec ses Xe-LPG et Xe2 intégrés. Ces puces, conçues pour le jeu et l’affichage, se sont retrouvées avec des capacités de calcul généraliste — et une caractéristique que les GPU dédiés n’auront jamais : l’accès à une mémoire unifiée, potentiellement énorme.

L’année 2026 marque le point de bascule visible. Les annonces de mini-PC « IA » se multiplient, avec des configurations qui auraient semblé absurdes deux ans plus tôt : un AMD Ryzen AI Halo à 3 999 $ avec 128 Go de mémoire unifiée capable de faire tourner des modèles jusqu’à 120B+, un Acer mini-PC IA avec 128 Go de mémoire unifiée annoncé pour des modèles jusqu’à 200B, un AMD Gorgon Halo visant 192 Go de mémoire unifiée pour des modèles 200B+. Le dogme ne tient plus. Reste à comprendre ce qui a réellement changé sous le capot — et ce que cela implique quand on veut équiper un foyer ou une PME sans hypothéquer trois ans de budget informatique.

780M, Strix Halo, Arc intégré : anatomie d’un iGPU qui fait tourner un LLM

Un iGPU moderne n’est pas un GPU dédié en miniature. C’est une créature hybride, et c’est précisément cette hybridation qui le rend intéressant pour l’inférence locale.

Source : orchestrator.dev

La différence fondamentale tient à la mémoire. Un GPU dédié possède sa propre VRAM, rapide mais plafonnée : 8, 12, 16 Go, rarement plus dans les gammes accessibles. Un iGPU, lui, puise dans la mémoire système, partagée avec le CPU. Cette mémoire est plus lente — c’est le revers de la médaille — mais elle peut atteindre des capacités qu’aucune carte grand public ne propose. Le Strix Halo d’AMD, avec son bus 256 bits et sa LPDDR5X offrant 256 Go/s de bande passante, incarne cette approche : 64 à 128 Go de mémoire unifiée selon les configurations, de quoi faire tenir des modèles qui exigeraient sinon plusieurs cartes en SLI.

Le second pilier, c’est le logiciel. Quatre backends se partagent désormais le terrain sur les iGPU, et un panorama technique publié en mai 2026 permet d’y voir clair. Vulkan joue le rôle de passe-partout universel : il fonctionne sur AMD, Intel, et même NVIDIA, avec des performances qui dépendent fortement des pilotes — c’est, selon cette analyse, « la seule option véritablement multi-vendeurs et multiplateforme », idéale quand la portabilité compte plus que la performance brute. ROCm, la pile compute d’AMD, a franchi un cap avec ROCm 7, arrivé en septembre 2025 avec le support natif de Windows et une intégration PyTorch dès le premier jour ; le support des iGPU reste toutefois plus délicat que celui des Instinct. SYCL/oneAPI, l’équivalent Intel, sert de pont vers les Arc intégrés. Et Metal 4, dévoilé à la WWDC 2025, fusionne l’apprentissage automatique dans la chronologie de commandes du GPU — c’est la voie royale sur Apple Silicon, avec son modèle de mémoire unifiée.

Et c’est là que llama.cpp entre en scène. Le projet, devenu la référence de l’inférence locale, a progressivement traité ces backends comme des citoyens de première classe. Le mécanisme clé s’appelle MMVQ — pour Matrix Multiplication with Vector Quantization. Il s’agit d’une technique qui combine la multiplication matricielle (le cœur de l’inférence) avec la déquantification à la volée, permettant d’exécuter des modèles quantifiés sans les décompresser entièrement en mémoire. Sur un GPU dédié, c’est un confort. Sur un iGPU à bande passante limitée, c’est une nécessité vitale.

Le troisième pilier, c’est l’offloading. Comme la mémoire unifiée est partagée, llama.cpp peut choisir dynamiquement quelles couches du modèle résident sur le iGPU et lesquelles restent sur le CPU. Cette souplesse, impossible avec un GPU dédié à VRAM fixe, permet de faire tourner des modèles qui « ne rentrent pas » — au prix d’un débit réduit.

Reste un facteur souvent négligé : l’architecture mémoire elle-même. La largeur du bus, le type de RAM (DDR5 vs LPDDR5X), le TDP alloué au iGPU déterminent le plafond de performance bien plus que le nombre de cœurs graphiques. Un iGPU bridé à 15 W ne fera jamais tourner un 70B, quelle que soit la finesse de ses optimisations logicielles.

Vulkan, ROCm, MMVQ : les optimisations qui ont changé la donne

Si 2026 marque un basculement, c’est parce que le logiciel a rattrapé le matériel. Et les chiffres d’amélioration sont éloquents.

Prenons le cas emblématique du Radeon 780M, l’iGPU RDNA3 qui équipe les Ryzen 7040 et 8040. Deux optimisations récentes de llama.cpp ont transformé son profil de performance. La première, documentée dans un retour technique détaillé, apporte « 50 % d’inférence Vulkan plus rapide » ainsi qu’un réglage d’évitement du mmap — le mmap étant ce mécanisme de mappage mémoire qui, sur iGPU, peut créer des contentions coûteuses. La seconde, plus ciblée, affine le réglage de MMVQ pour les 780M et Strix, avec à la clé « 12,9 % d’inférence Vulkan plus rapide ».

Ces gains ne sont pas anecdotiques. Ils s’additionnent, se cumulent avec les progrès des pilotes Mesa RADV, et transforment une expérience marginale en usage viable. Un modèle qui peinait à 6 tokens/s devient confortable à 10-12.

Il faut y ajouter la maturation générale du moteur. La grande réécriture de llama.cpp, fusionnée en avril 2026, a redessiné les fondations : générateur de kernels, KV cache contigu, dispatch unifié. La version v0.5.0 qui en découle a consolidé ces acquis, avec un backend unifié, une gestion GGUF simplifiée et un serveur local (llama-server) plus robuste. Pour l’utilisateur d’iGPU, cela se traduit par moins de régressions de backend, un dispatch plus prévisible et une meilleure exploitation des chemins Vulkan.

Le second front, c’est celui des formats de quantification. L’arrivée des modèles Q4_0 ROCmFP4 — un format de quantification associé à ROCm — ouvre la voie à des modèles plus compacts et plus rapides à déquantifier. Le principe : réduire la précision des poids (4 bits au lieu de 16) tout en préservant suffisamment d’information pour que le modèle reste cohérent. Sur un iGPU, où la bande passante est le goulot d’étranglement, chaque octet économisé se traduit directement en tokens par seconde.

Il faut toutefois tempérer l’enthousiasme. Le support de ROCm sur iGPU RDNA3 reste, selon les retours disponibles, limité voire expérimental — ce qui signifie que ROCmFP4 n’est pas applicable en pratique sur un 780M aujourd’hui. C’est Vulkan qui porte l’essentiel de la charge sur ces puces. La promesse ROCm existe, et ROCm 7 l’a rendue plus crédible qu’avant, mais elle vise davantage les configurations Strix Halo et au-delà, voire les GPU dédiés RDNA4.

Enfin, il ne faut pas oublier le versant Intel. Le recyclage d’un Intel Arc GPU en serveur LLM local illustre une tendance parallèle : les puces graphiques Intel, y compris intégrées, trouvent une seconde vie dans l’inférence locale grâce au backend SYCL de llama.cpp. Les résultats sont décrits comme « étonnamment décents » — un euphémisme qui en dit long sur le chemin parcouru. Et côté Windows, l’écosystème se structure : Windows ML a ajouté en octobre 2026 un support expérimental de llama.cpp pour les modèles GGUF, une API locale compatible OpenAI et la génération de texte ONNX, tandis que Microsoft documente les améliorations croisées de PyTorch, llama.cpp et Windows ML. Autrement dit : le chemin « iGPU + llama.cpp » n’est plus un bricolage de Linuxien, il devient un scénario supporté.

Tokens/s réels : ce que disent les benchmarks sur 780M, Strix Halo et Arc intégré

Passons aux chiffres. Ils proviennent de benchmarks communautaires — issues GitHub de llama.cpp, forums r/LocalLLaMA, tests de médias spécialisés — et doivent être lus avec les précautions d’usage : forte variabilité selon les pilotes, les versions de llama.cpp, le contexte et le batch.

Source : collectivitenumerique.fr
Configuration Llama 3 8B Q4 Mistral 7B Q4_K_M Qwen 2.5 7B Mixtral 8x7B Q4_K_M
AMD Radeon 780M (Vulkan) ~10-12 tok/s ~8-11 tok/s ~10-12 tok/s Ne tient pas en mémoire partagée
AMD Strix Halo (Vulkan) ~40-60 tok/s Non précisé Non précisé ~5-10 tok/s (bandwidth-bound)
Intel Arc intégré (Vulkan/SYCL) ~10-15 tok/s Non précisé Non précisé Non précisé
NVIDIA RTX 3060 12 Go (CUDA) ~45-60 tok/s Non précisé ~45-60 tok/s ~15-25 tok/s (offload partiel)
NVIDIA RTX 4060 8 Go (CUDA) ~50-70 tok/s Non précisé Non précisé Non précisé

Sources : benchmarks communautaires llama.cpp, Reddit r/LocalLLaMA, issues GitHub #4167 et #5217, tests Phoronix et Level1Techs. Conditions typiques : contexte 512-4096, batch 1-512, quantification Q4_0 ou Q4_K_M, drivers Mesa RADV ou ROCm 6.x/7.x.

Que retenir de ce tableau ? D’abord, que le 780M est parfaitement capable de faire tourner un modèle 7-8B en Q4 à une vitesse utilisable — autour de 10 tokens/s, soit environ 400-500 mots par minute, plus rapide que la lecture. C’est le seuil psychologique du « ça marche ».

Ensuite, que le Strix Halo change de catégorie. Avec ses 256 Go/s de bande passante, il atteint des débits comparables à une RTX 3060 sur les modèles 8B — tout en pouvant charger des modèles bien plus gros grâce à sa mémoire unifiée de 64 à 128 Go. C’est le point d’inflexion : pour la première fois, un iGPU ne se contente pas de « faire tourner » un LLM, il le fait tourner confortablement — et il peut viser des modèles de 120B, voire 200B sur les configurations Acer et Gorgon Halo annoncées.

Les limites apparaissent dès qu’on monte en taille. Mixtral 8x7B, avec ses ~26 Go en Q4_K_M, ne tient tout simplement pas sur un 780M ou un Arc intégré dont la mémoire partagée est contrainte. Sur Strix Halo, il rentre — mais le débit s’effondre à 5-10 tok/s, victime de la bande passante. La RTX 3060, avec ses 12 Go, doit recourir à l’offload partiel et plafonne à 15-25 tok/s. Aucune de ces configurations n’est idéale pour du MoE volumineux.

Un mot sur les conditions de mesure, car elles expliquent une grande partie de la variance. Les benchmarks cités utilisent typiquement un contexte de 512 à 4096 tokens, un batch de 1 à 512, et des builds récents de llama.cpp. Les drivers varient : Mesa RADV côté Vulkan sous Linux, Adrenalin sous Windows, ROCm 6.x/7.x pour les rares configurations supportées. Un même 780M peut afficher 8 ou 12 tok/s selon ces paramètres. Il faut donc lire ces chiffres comme des ordres de grandeur, pas comme des vérités absolues.

Bande passante, fragmentation logicielle : les limites qui persistent

L’enthousiasme ne doit pas masquer les obstacles. Trois limites structurelles empêchent encore les iGPU de détrôner totalement le GPU dédié.

La bande passante mémoire. C’est le facteur limitant numéro un. Un GPU dédié dispose de GDDR6 à plusieurs centaines de Go/s, parfois plus d’un To/s sur les modèles haut de gamme. Un iGPU avec DDR5-5600 dual-channel plafonne autour de 90 Go/s. Le Strix Halo, avec sa LPDDR5X à 256 Go/s, comble une partie de l’écart — mais reste en dessous des GPU dédiés récents. Or l’inférence de LLM est fondamentalement memory-bound : chaque token généré nécessite de lire l’intégralité des poids du modèle. La vitesse de génération est donc, en première approximation, le quotient de la bande passante par la taille du modèle. C’est une loi d’airain que nulle optimisation logicielle ne contourne.

La fragmentation logicielle. Vulkan fonctionne partout, mais avec des performances inégales selon les pilotes. ROCm 7 a réduit l’écart sur les GPU Instinct et RDNA récents, mais son support des iGPU reste expérimental. SYCL côté Intel est fonctionnel mais moins mature que CUDA. Cette fragmentation a un coût concret : un utilisateur qui change de machine doit souvent réapprendre quel backend fonctionne, quels réglages activer, quelles variables d’environnement définir. Le panorama de mai 2026 le dit sans détour : ces plateformes « ne sont pas toujours des alternatives — les systèmes de production réels les superposent souvent ». Pour l’amateur, cela signifie des soirées de débogage ; pour la PME, cela signifie un coût d’intégration non négligeable.

Le TDP et le refroidissement. Un iGPU de laptop bridé à 15-25 W ne pourra jamais exploiter pleinement sa bande passante théorique. Les mini-PC à mémoire unifiée, eux, assument des enveloppes thermiques plus généreuses — c’est précisément ce qui les rend pertinents. Mais il faut le savoir : le même silicium, dans un châssis fin et dans un mini-PC ventilé, ne donne pas les mêmes tokens/s.

À ces limites techniques s’ajoute une contrainte économique souvent oubliée : l’énergie. Un GPU dédié qui tourne 24/7 pour servir un agent ou un RAG maison consomme bien plus qu’un mini-PC à iGPU. La question du coût total de possession — matériel, électricité, temps d’ingénierie — devient centrale dès qu’on quitte le bricolage pour un usage régulier.

L’équation économique : ce que « sans se ruiner » veut vraiment dire en 2026

C’est ici que le basculement prend tout son sens. Parce que la vraie question n’est pas « quel matériel fait tourner un LLM ? » — beaucoup le font désormais — mais « quel matériel fait tourner le LLM dont j’ai besoin, au coût le plus bas sur trois ans ? ».

Le calcul de rentabilité est devenu un sujet de dirigeants. Comme le note le Journal du Net en octobre 2026, héberger son propre LLM pour réduire la facture IA séduit de plus en plus, mais la rentabilité dépend de deux paramètres : le volume d’usage et le coût du matériel amorti. En dessous d’un certain seuil d’appels quotidiens, une API cloud reste moins chère. Au-dessus, le local gagne — à condition de ne pas surdimensionner la machine.

C’est là que les iGPU et la mémoire unifiée changent l’arithmétique. Un GPU dédié de 24 Go coûte à lui seul plus cher que certains mini-PC complets à 128 Go de mémoire unifiée. Or ces mini-PC peuvent charger des modèles que le GPU dédié ne peut pas accueillir. Le compromis est clair : on échange de la vitesse brute contre de la capacité et de la sobriété énergétique. Pour un usage domestique — un assistant personnel, un RAG sur ses documents, un agent qui tourne en tâche de fond — c’est presque toujours le bon arbitrage. Pour du batch intensif ou du serving multi-utilisateurs, le GPU dédié garde l’avantage.

Le guide PME 2026 du magazine confirme cette lecture : le bon ratio perf/prix dépend du profil d’usage, et le trio « GPU d’occasion, Apple Silicon, CPU seul » n’est plus la seule grille de lecture — les mini-PC à mémoire unifiée s’y ajoutent comme quatrième voie. Un GPU d’occasion (une RTX 3060 12 Go, par exemple) reste une excellente entrée de gamme pour qui veut de la vitesse sur des modèles 7-8B. Mais dès qu’on vise des modèles plus gros ou qu’on veut limiter la consommation, la mémoire unifiée devient imbattable en rapport capacité/prix.

Il faut aussi compter le coût caché : l’énergie, la sécurité, l’exploitation. Un serveur local qui tourne en permanence, c’est une facture électrique, une surface d’attaque à sécuriser (voir notre dossier sur l’OWASP LLM Top 10 2026), et du temps de maintenance. Un mini-PC à iGPU, plus sobre, réduit les deux premiers postes. C’est un argument que les benchmarks en tokens/s ne capturent pas, mais qui pèse lourd dans la décision.

Choisir sa pile logicielle : Ollama, llama.cpp, LM Studio, et les autres

Le matériel ne fait pas tout. En 2026, l’écosystème des moteurs d’inférence locaux s’est structuré, et le choix du logiciel détermine largement l’expérience.

llama.cpp reste la référence bas niveau. C’est lui qui porte les optimisations Vulkan, MMVQ, les backends SYCL et ROCm. Si vous voulez exploiter un iGPU au maximum, c’est par lui — ou par un outil qui l’encapsule — que vous passerez. La version v0.5.0 a simplifié l’installation et le serveur local, avec une API compatible OpenAI qui facilite l’intégration dans des applications existantes.

Ollama reste le choix de la simplicité : une commande, un modèle, ça tourne. Il encapsule llama.cpp et gère les téléchargements, les tags de modèles, le serving. Pour un usage domestique ou une PME qui veut démarrer vite, c’est souvent le bon point d’entrée — au prix d’un contrôle moins fin sur les réglages de backend.

LM Studio et Jan offrent une interface graphique, ce qui les rend accessibles à qui ne veut pas toucher à un terminal. Un comparatif de 48 outils publié en septembre 2026 recense l’ensemble des moteurs, runtimes et passerelles, avec leurs licences, leur support GPU et leur compatibilité API OpenAI — une ressource précieuse pour cartographier le terrain.

AnythingLLM, testé par le Journal du Net en septembre 2026, pousse la logique plus loin : transformer n’importe quel PC en ChatGPT privé, avec RAG intégré, sans abonnement ni données envoyées dans le cloud. L’outil « tient sa promesse, à condition d’accepter quelques compromis » — typiquement, un modèle plus petit pour rester fluide sur un iGPU.

Enfin, il faut mentionner les moteurs de nouvelle génération. Strata, dont parle la communauté r/LocalLLaMA depuis l’automne 2026, revendique de faire tourner un Qwen 125B sur une carte graphique ordinaire — une prouesse qui repose sur une philosophie différente, celle des « moteurs non sur-entraînés ». Et le décodage spéculatif, documenté en septembre 2026, offre « le seul gain de vitesse sans perte » : un petit modèle brouillon propose des tokens que le grand modèle valide, accélérant la génération sans dégrader la qualité. Sur un iGPU où chaque token compte, ces techniques valent le détour.

Le choix, au fond, dépend de trois questions : voulez-vous la performance maximale (llama.cpp brut), la simplicité (Ollama), ou l’intégration applicative (AnythingLLM, API OpenAI-compatible) ? Et acceptez-vous de mettre les mains dans les réglages pour gagner 20 à 50 % de débit ?

Le mot de la fin : un arbitrage, pas une religion

Le basculement de 2026 n’est pas l’histoire d’un matériel qui en remplace un autre. C’est l’histoire d’un écosystème qui cesse d’être monoculture. Pendant des années, « faire de l’IA locale » signifiait acheter une NVIDIA et prier pour que CUDA fasse le reste. Aujourd’hui, l’utilisateur a le choix : un iGPU RDNA3 pour démarrer à petit prix, un mini-PC à mémoire unifiée pour viser des modèles de 100B+, un GPU dédié d’occasion pour la vitesse brute sur du 7-8B, ou un Mac à mémoire unifiée pour la sobriété et l’écosystème Metal.

Ce choix a un prix — au sens propre. Il faut accepter que l’iGPU ne battra pas le GPU dédié en tokens/s. Il faut accepter que la fragmentation logicielle persiste, que ROCm sur iGPU reste expérimental, que Vulkan dépend des pilotes. Mais il faut aussi reconnaître ce qui a changé : les optimisations Vulkan de llama.cpp (+50 %, +12,9 % sur le 780M), la maturité de ROCm 7, l’arrivée de Windows ML et du support GGUF, les formats de quantification compacts, les mini-PC à mémoire unifiée à des prix qui restent sous la barre des GPU haut de gamme. Tout cela mis bout à bout fait qu’en 2026, on peut faire tourner un LLM utile chez soi pour le prix d’un ordinateur portable correct — et sans sacrifier ni la confidentialité, ni le contrôle, ni le budget.

La vraie question n’est donc plus « puis-je me le permettre ? » mais « quel compromis suis-je prêt à faire ? ». Vitesse contre capacité. Simplicité contre contrôle. Consommation contre performance brute. C’est un arbitrage, pas une religion. Et c’est précisément ce qui rend l’IA locale enfin adulte.

Sources

Article recherché et rédigé automatiquement · Magazine Electrosens
📬 Restez à la pointe
Recevez chaque semaine les nouveautés de ce magazine par email.
💬 Une remarque, une correction ?
Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *