LLM auto hébergées · 14 October 2026

Le NAS devient une station d’inférence : ce que vaut vraiment l’IA locale hors du PC gamer

Pendant vingt ans, le NAS a été la boîte qu’on oublie dans un placard, à ronronner en silence pour sauvegarder nos photos. En 2026, une poignée d’utilisateurs y font tourner des LLM open-weights, sans carte graphique dédiée, sans PC allumé en permanence. Est-ce une vraie bascule architecturale ou un gadget de geek bien emballé ? Décryptage.

Le NAS sort du placard : comment une boîte de stockage est devenue une station d’inférence

L’histoire commence par un constat contre-intuitif. Pendant que le débat sur l’IA locale tournait autour d’une seule question — « quelle carte graphique acheter ? » —, une frange d’utilisateurs a posé une question différente : et si le matériel était déjà là ? Le NAS qui tourne 24/7 dans le salon, celui qui consomme moins qu’une ampoule et qu’on n’entend pas, contient déjà un CPU, de la RAM, des baies NVMe et un système d’exploitation capable de faire tourner des conteneurs. Il ne manquait qu’une chose : un moteur d’inférence assez mature pour se contenter de ce qu’il offre.

Cette maturité est arrivée. Le guide de référence sur llama.cpp v0.5.0, publié fin septembre 2026, documente un backend, un serveur et une gestion GGUF qui ne supposent plus une carte graphique dédiée comme prérequis absolu. Autrement dit : l’outillage a cessé de traiter le GPU comme le centre de gravité de l’inférence. Ollama, llama-server et les runtimes dérivés savent désormais exploiter un iGPU, un NPU ou même un CPU seul avec des performances qui, sans être spectaculaires, deviennent utilisables pour des usages réels.

Le signal le plus parlant vient d’un retour d’expérience publié par XDA Developers, dont le titre résume la bascule : « J’ai fait tourner un LLM local entièrement depuis un NAS, et cela a transformé ma boîte de stockage en station d’hébergement d’IA. » Ce n’est pas un benchmark de laboratoire, c’est un témoignage d’usage. Et c’est exactement ce qui distingue 2026 des années précédentes : le NAS-IA n’est plus une curiosité théorique, c’est une configuration que des gens installent chez eux.

Pourquoi maintenant, et pas en 2023 ? Trois facteurs se sont alignés. D’abord, la mémoire unifiée a cessé d’être une exclusivité Apple : les plateformes à mémoire partagée entre CPU, GPU et NPU se sont multipliées, et cette architecture change fondamentalement le rapport entre taille de modèle et matériel. Ensuite, les runtimes d’inférence ont appris à streamer les poids quantifiés depuis le stockage plutôt que d’exiger que tout tienne en VRAM. Enfin, le format GGUF et ses variantes de quantification, bien documentés dans des guides comme celui de convly.ai sur les types de quantification, ont rendu les compromis taille/qualité lisibles pour des non-spécialistes.

Le résultat est une inversion de la charge mentale. On ne se demande plus « quel GPU puis-je me permettre ? » mais « quel modèle mon matériel existant peut-il absorber ? ». C’est une différence de posture qui ouvre l’IA locale à un public bien plus large que les possesseurs de tours gaming.

Mémoire unifiée, cache NVMe, PCIe : l’anatomie d’un NAS-IA

Pour comprendre ce qui se joue, il faut regarder sous le capot. Un PC d’inférence classique fonctionne sur une hiérarchie stricte : les poids du modèle doivent tenir dans la VRAM de la carte graphique, et si ce n’est pas le cas, on descend en RAM système avec une pénalité de bande passante brutale. Un NAS-IA fonctionne différemment, parce que la mémoire y est souvent unifiée : le CPU, le GPU intégré et le NPU puisent dans le même pool de LPDDR5.

Cette architecture a une conséquence directe : la taille maximale du modèle n’est plus dictée par une VRAM figée, mais par la quantité de RAM installée et la bande passante du bus. Les plateformes à mémoire unifiée les plus discutées en 2026 en donnent la mesure. AMD Strix Halo, lancé en 2025, embarque 16 cœurs Zen 5, un GPU intégré RDNA 3.5, un bus mémoire de 256 bits et une bande passante de 256 Go/s — des chiffres qui, sans égaler une carte graphique dédiée, changent radicalement ce qu’on peut faire tourner. Les déclinaisons plus récentes vont plus loin : l’AMD Ryzen AI Halo propose 128 Go de mémoire unifiée et revendique le support de modèles jusqu’à 120B+, tandis que l’AMD Gorgon Halo vise 192 Go et des modèles de 200B+. Acer a annoncé de son côté un mini-PC IA avec 128 Go de mémoire unifiée et un support de modèles jusqu’à 200B.

Le point crucial, c’est que ces plateformes ne sont pas des NAS au sens strict — ce sont des mini-PC à mémoire unifiée. Mais elles dessinent le plafond technique vers lequel les NAS-IA tendent, et elles expliquent pourquoi l’idée même de faire tourner un gros modèle sur un boîtier compact n’est plus absurde.

Reste le deuxième pilier : le cache NVMe. Un modèle quantifié en Q4_K_M pèse plusieurs gigaoctets, et un modèle de 70B peut dépasser la quarantaine de gigaoctets. Personne ne veut charger ça en RAM à chaque requête. Le rôle du NVMe est de servir de réservoir où les poids sont lus à la demande, avec un débit séquentiel élevé qui masque partiellement la latence. C’est là que le PCIe entre en jeu : un slot PCIe 4.0 ou 5.0 alimente le SSD en bande passante suffisante pour que le streaming des poids ne devienne pas le facteur limitant. Certains NAS récents offrent aussi un slot PCIe pour une carte low-profile — mais nous y reviendrons, car c’est précisément là que les promesses se heurtent au réel.

Troisième pilier : l’isolation. Faire tourner un moteur d’inférence sur un NAS qui sert aussi de serveur de fichiers, de serveur multimédia et de cible de sauvegarde, c’est risquer qu’une génération de tokens monopolise les ressources et fasse ramer tout le reste. La réponse est la virtualisation : conteneurs Docker avec passthrough GPU, ou machines virtuelles dédiées. Les runtimes modernes s’y prêtent bien, et l’intégration Docker est justement l’un des points de satisfaction récurrents des utilisateurs de NAS.

Le tableau suivant résume les différences structurelles entre les trois grandes familles de configuration.

Tokens par seconde, latence, watts : ce que disent vraiment les chiffres

C’est ici que le discours doit se durcir, parce que les chiffres disponibles racontent une histoire nuancée. Commençons par la référence la plus accessible : l’iGPU AMD Radeon 780M, présent dans de nombreux mini-PC et certaines plateformes compactes. Les mesures documentées donnent environ 10-12 tok/s sur Llama 3 8B en Q4 via Vulkan, 8-11 tok/s sur Mistral 7B Q4_K_M, et 10-12 tok/s sur Qwen 2.5 7B. Ces débits ont bénéficié d’optimisations réelles : +50 % grâce au backend Vulkan de llama.cpp, et +12,9 % supplémentaires via un réglage MMVQ. Autrement dit, le logiciel a rattrapé une partie du retard matériel.

Montez d’un cran avec AMD Strix Halo, et le tableau change : ~40-60 tok/s sur Llama 3 8B Q4 en Vulkan. C’est un débit confortable, proche de ce qu’on attend d’une expérience de chat fluide. Mais dès qu’on passe à un modèle plus lourd, la réalité rattrape : Mixtral 8x7B en Q4_K_M tombe à ~5-10 tok/s. Le message est clair — la mémoire unifiée permet de charger des modèles plus gros, pas nécessairement de les faire tourner vite.

C’est là que la notion de coût au watt devient décisive. Un NAS tourne 24/7. Un PC gamer allumé en permanence pour servir un assistant local, c’est une facture électrique qui s’accumule mois après mois. Le NAS-IA gagne précisément sur ce terrain : consommation très basse en veille, silence, et un rapport tokens/s/W qui, pour un usage intermittent (quelques requêtes par heure), écrase un PC dédié. Mais pour un usage intensif — génération continue, agents qui tournent en boucle — le calcul s’inverse, parce que le débit maximal du NAS-IA plafonne bien plus bas.

Sur les quantifications, la hiérarchie est bien établie. Q4_K_M reste le compromis de référence : taille raisonnable, qualité préservée. Q5_K_S monte d’un cran en fidélité pour un coût mémoire modéré. Q8_0 se rapproche de la qualité native mais double presque l’empreinte — un choix qui n’a de sens que si la RAM et la bande passante suivent, ce qui est rarement le cas sur un NAS.

À noter : les configurations NAS précises (modèles de boîtiers, CPU exacts) ne sont pas documentées avec des benchmarks chiffrés dans nos sources. Toute affirmation de débit pour un NAS spécifique relèverait donc de l’extrapolation, et nous nous en tenons aux plateformes à mémoire unifiée mesurées.

Les goulots d’étranglement que personne ne voit venir

Le premier piège est la bande passante mémoire. La comparaison est brutale : une plateforme à mémoire unifiée comme Strix Halo plafonne à 256 Go/s, là où une carte graphique dédiée en GDDR6X dépasse allègrement les 500 Go/s. Pour un modèle dense de taille moyenne, ça passe. Pour un modèle large ou un MoE, la bande passante devient le mur contre lequel on bute — et aucune optimisation logicielle ne le contourne.

Le deuxième piège est le KV cache. Chaque token de contexte consomme de la mémoire, et cette consommation croît avec la longueur du contexte. Un contexte long, indispensable pour du RAG sur documents ou pour un agent qui doit garder l’historique d’une conversation, peut faire exploser l’empreinte mémoire bien au-delà des poids du modèle. Sur un NAS dont la RAM est partagée entre le système, les services de fichiers et le moteur d’inférence, la marge de manœuvre fond vite. Les travaux récents sur les « greffes de KV cache » et l’efficacité quantifiée, évoqués dans une analyse sur les nouvelles normes de l’inférence locale, montrent que la communauté cherche activement des parades — mais elles restent expérimentales.

Le troisième piège est thermique. Un NAS est conçu pour dissiper la chaleur d’un ou deux disques durs et d’un CPU au repos. Le faire calculer en continu pendant des heures, c’est chauffer un boîtier qui n’a pas été pensé pour ça. Les ventilateurs montent en régime, le bruit apparaît, et la longévité des composants devient une question ouverte. C’est un grief récurrent dans la communauté, et il n’est pas anecdotique : un boîtier silencieux qui devient bruyant perd l’un de ses principaux arguments.

Le quatrième piège est logiciel. Le passthrough GPU sur NAS est limité, souvent dépendant du constructeur, et les pilotes NPU restent largement propriétaires — Intel NPU, AMD XDNA — avec un support inégal selon les distributions et les versions de noyau. Résultat : une accélération annoncée sur le papier peut s’avérer inaccessible en pratique, ou casser à la première mise à jour.

NAS-IA vs PC dédié vs mini-PC vs cloud : le vrai match sur 3 ans

Sur trois ans, le calcul de coût total de possession penche différemment selon les profils. Un PC gamer dédié coûte cher à l’achat, consomme beaucoup en veille, mais offre le débit maximal et une flexibilité totale — on peut changer la carte graphique, ajouter de la RAM. Un mini-PC IA à mémoire unifiée comme l’AMD Ryzen AI Halo, à 3 999 $, offre des performances nettement supérieures à un NAS mais soudées : aucune mise à jour possible, ni GPU ni mémoire. Le cloud, enfin, a un coût marginal nul à l’entrée mais facture à l’usage et pose la question de la confidentialité — argument central pour l’IA locale.

Le NAS-IA gagne sur trois terrains : la consommation 24/7, le silence (si le boîtier tient la charge), et l’intégration du stockage. Il perd sur trois autres : le débit maximal, la latence en contexte long, et le support logiciel. Le tableau ci-dessous résume ce match.

Ce qu’on fait vraiment tourner depuis un NAS en 2026

Les cas d’usage réalistes se répartissent en deux familles. D’un côté, les usages légers à modérés : assistant domotique local via Home Assistant, génération de résumés pour un serveur Jellyfin ou Plex, classification et tri de documents. Ces tâches tolèrent des débits de 10-20 tok/s et des contextes courts — 8k suffit largement. Un iGPU de type Radeon 780M, avec ses ~10-12 tok/s sur un 8B, les absorbe sans transpirer.

De l’autre côté, les usages gourmands : RAG sur documents personnels avec LlamaIndex, agents de code avec Continue.dev, conversations longues nécessitant 32k à 128k de contexte. Là, les besoins explosent. Un RAG qui doit ingérer des dizaines de documents et maintenir un contexte étendu sollicite à la fois la bande passante mémoire et le KV cache. Un agent de code, qui enchaîne les allers-retours, exige une latence faible — et c’est précisément là que le NAS-IA montre ses limites.

La frontière est donc nette : le NAS-IA excelle dans les usages intermittents et légers, et bute sur les usages continus et gourmands. Ce n’est pas un défaut de conception, c’est une conséquence directe de l’architecture.

Ce que disent les utilisateurs : satisfactions, griefs et angles morts

Les retours convergent vers quelques points. Les satisfactions d’abord : la consommation en veille, le silence quand la charge reste modérée, et l’intégration Docker qui permet d’isoler proprement le moteur d’inférence du reste des services. Pour beaucoup, c’est la promesse tenue — un assistant local qui ne coûte presque rien à faire tourner et qu’on oublie dans un coin.

Les griefs ensuite, et ils sont récurrents : la thermique et le bruit des ventilateurs quand la charge dure, le passthrough GPU limité qui bride l’accélération, et les pilotes NPU propriétaires dont le support varie au gré des mises à jour. À cela s’ajoute un angle mort : la documentation. Les benchmarks chiffrés sur des NAS précis sont rares, ce qui oblige les utilisateurs à expérimenter eux-mêmes — un frein réel pour qui veut savoir avant d’acheter.

Pour qui le NAS-IA est une vraie option — et pour qui c’est encore un gadget coûteux

Le verdict, en 2026, est celui d’une technologie qui a franchi un seuil mais pas encore tous. Le NAS-IA est une vraie option pour les foyers déjà équipés d’un NAS performant, avec des usages légers à modérés, une contrainte de silence et de consommation, et une exigence de confidentialité. C’est aussi une option pertinente pour qui veut tester l’IA locale sans investir dans une tour dédiée.

Il reste un gadget coûteux pour qui a besoin de débit élevé, de modèles au-delà de 14B, de contextes très longs ou d’une flexibilité GPU. Pour ces profils, un mini-PC IA à mémoire unifiée — malgré son prix — ou un PC dédié restent plus rationnels.

Ce que ce basculement annonce, en revanche, dépasse le cas d’espèce. La convergence entre stockage et calcul redessine la frontière entre « serveur de fichiers » et « nœud de calcul ». Les plateformes à mémoire unifiée qui visent 192 Go et des modèles de 200B+ montrent où va le matériel. Le jour où un NAS grand public embarquera cette classe de mémoire, la question ne sera plus « peut-on faire tourner un LLM sur un NAS ? » mais « pourquoi voudrait-on le faire ailleurs ? ». Nous n’y sommes pas encore. Mais la direction est tracée, et elle est étonnamment silencieuse.

Sources

• I ran a local LLM entirely off a NAS — XDA Developers
• llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API — gyanaangan.in
• Modèles GGUF : types de quantification et exécution — convly.ai
• New Norms in Local Inference: KV Cache Transplants, Quantized Swift Efficiency Revolutions — note.com
• Best Hardware for Running Open-Source AI Models Locally in 2026 — memeburn.com
• Best Open-Source Agent Harnesses for Local LLMs in 2026 — marktechpost.com
• Performance LLM sur GPU AMD Radeon 9070XT — quelllm.fr
• LLM sur Raspberry Pi 5 : IA locale embarquée — QuelLLM.fr
• Open-weights ou open-source ? La différence qui compte — QuelLLM.fr

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