LLM auto hébergées · 14 October 2026

Faire tourner des LLM open source chez soi sans se ruiner : le guide 2026, du post-training RL aux MoE de 290B sur PC de gamer

Pendant des années, faire tourner un LLM chez soi signifiait télécharger un GGUF, le charger dans Ollama, et espérer un débit de tokens acceptable. En 2026, la donne a changé : l’étape qui sépare désormais les modèles open source des modèles propriétaires n’est plus l’inférence, mais le post-training par renforcement. Et cette bascule bouleverse l’infrastructure logicielle — du Ray Summit 2026 aux frameworks émergents — jusqu’à redéfinir ce qu’un hobbyiste peut raisonnablement accomplir avec une carte graphique grand public. Mais une autre révolution, plus silencieuse, se joue en parallèle : des moteurs comme FreeToken promettent de faire tourner des MoE de 290 milliards de paramètres sur un simple PC de gamer, en repensant radicalement la gestion de la mémoire. Entre ces deux mouvements — l’un qui tire les besoins matériels vers le haut, l’autre qui les fait redescendre — se dessine la vraie carte de l’IA locale en cette fin 2026.

Le post-training est le nouveau champ de bataille

Il y a deux ans, la question qui agitait la communauté open source était simple : « quel modèle open source se rapproche le plus de GPT-4 ? ». La réponse se mesurait en paramètres, en taille de contexte, en score MMLU. En 2026, la question a changé de nature. Les modèles ouverts ne sont plus jugés sur leur architecture ou leur pré-entraînement, mais sur ce qui se passe après : l’apprentissage par renforcement (RL) qui affine leurs comportements.

Cette évolution n’est pas anecdotique. Le Ray Summit 2026, qui s’est tenu du 24 au 26 août au San Francisco Marriott Marquis avec plus de 3 000 participants confirmés, a explicitement placé le RL post-training au centre des débats. Le titre de l’événement, rapporté par TechTimes, est sans ambiguïté : « RL post-training forces open-source AI infrastructure to converge ». La convergence, c’est le mot clé. L’inférence et l’entraînement, longtemps traités comme deux mondes séparés — vLLM d’un côté, Ray de l’autre — sont désormais condamnés à s’emboîter. Pourquoi ? Parce que le RL post-training exige une coordination en temps réel entre l’inférence (pour générer les rollouts, ces séquences de tokens que le modèle produit) et l’entraînement (pour mettre à jour les poids). Les pipelines qui servent le modèle et ceux qui l’entraînent doivent parler le même langage, sur la même infrastructure.

Pour le hobbyiste qui veut faire tourner des LLM chez soi, cette bascule a des conséquences directes. L’inférence seule ne suffit plus. Les modèles de pointe open source — DeepSeek, Qwen, GLM — sont désormais systématiquement affinés par RL, et cet affinage leur confère des capacités de raisonnement et de suivi d’instructions que le simple pré-entraînement ne donne pas. Vouloir « exécuter » un modèle localement, c’est désormais aussi se poser la question : ce modèle a-t-il été post-trainé ? Et est-ce que je peux, moi aussi, faire ce post-training sur mon matériel ?

RLHF, GRPO, RLVR : la mécanique qui fait grimper la facture VRAM

Pour comprendre pourquoi le RL post-training fait exploser les besoins matériels, il faut saisir ce qui distingue les trois approches qui dominent le paysage : le RLHF (Reinforcement Learning from Human Feedback), le GRPO (Group Relative Policy Optimization) et le RLVR (Rule-based Verifier). Une synthèse récente publiée par llm-stats.com sous le titre « Post-Training in 2026: GRPO, DAPO, RLVR & Beyond » confirme que ces familles structurent désormais l’essentiel des pipelines de post-training open source.

Le RLHF, popularisé par OpenAI avec InstructGPT, repose sur le PPO (Proximal Policy Optimization). Le principe : on entraîne un modèle de récompense (reward model) qui apprend à prédire les préférences humaines, puis on utilise ce modèle pour guider le policy model via PPO. Le coût mémoire est lourd : il faut charger le policy model, le modèle de référence (reference model, pour calculer la divergence KL), et le modèle de valeur (value model, pour l’estimation des avantages). Trois copies du modèle, plus les états d’optimisation.

Le GRPO, popularisé par DeepSeek-R1, simplifie radicalement la boucle. Il supprime le modèle de valeur, qui est remplacé par une comparaison entre plusieurs échantillons générés pour une même requête. On génère un groupe de rollouts (par exemple 64 ou 256), on calcule les récompenses, et on normalise les avantages à l’intérieur du groupe. Résultat : plus besoin de value model, mais il reste le policy model et le reference model. Et surtout, la génération de rollouts massifs demande une puissance d’inférence considérable.

Le RLVR, enfin, remplace le reward model par un vérificateur de règles — un programme qui vérifie si la réponse est correcte (par exemple, si le résultat d’un calcul mathématique est exact, ou si le code compile). C’est l’approche utilisée pour des modèles comme DeepSeek-R1 ou Qwen2.5-Math. Elle élimine le coût d’entraînement d’un reward model, mais elle ne réduit pas la charge de génération des rollouts.

La facture VRAM grimpe donc pour une raison simple : le RL post-training ne se contente pas d’entraîner un modèle — il faut en servir plusieurs simultanément, générer des milliers de tokens par échantillon, et répéter l’opération sur des millions de requêtes. Un simple SFT (fine-tuning supervisé) avec LoRA ne charge qu’un modèle et quelques adaptateurs. Un loop GRPO sur un 7B ou un 13B exige de charger policy + reference + les rollouts en mémoire. Les chiffres exacts dépendent de la taille de batch et de la longueur de séquence, mais l’ordre de grandeur est clair : là où un SFT LoRA sur un 7B tient dans 16 Go de VRAM, un GRPO sur le même modèle peut nécessiter le double ou le triple, surtout avec des groupes de rollouts élevés.

Ray Summit 2026 : la convergence forcée de l’infrastructure open source

Le Ray Summit 2026 n’a pas seulement mis le RL post-training à l’honneur — il a montré comment l’infrastructure open source se réorganise autour de cette contrainte. L’événement, qui s’est tenu du 24 au 26 août à San Francisco, a réuni plus de 3 000 participants, et le programme a mis en avant des personnalités comme Bryan Catanzaro de NVIDIA, qui a donné une keynote sur la coordination entre inférence et entraînement.

La convergence se manifeste à plusieurs niveaux. D’abord, les pipelines de training et de serving se fusionnent. vLLM, le moteur d’inférence open source le plus utilisé pour la production, n’est plus seulement un outil de serving : il s’intègre désormais dans les boucles de RL pour générer les rollouts à grande vitesse. Ray Data, le module de traitement de données distribué de Ray, joue un rôle central pour streamer ces rollouts vers les workers d’entraînement. C’est une architecture en flux continu, où l’inférence et l’entraînement s’alimentent mutuellement en temps réel.

Une nouveauté notable de cette édition 2026 : la co-localisation avec l’Inferact vLLM Conference, qui se tenait sous le même toit, avec un seul pass donnant accès aux deux pistes. Ce n’est pas un hasard logistique — c’est le signe que les deux communautés, celle de l’inférence et celle de l’entraînement, sont désormais condamnées à travailler ensemble. Comme le souligne TechTimes, « agentic RL requires data generation, inference, and model weight updates to run in balance across CPUs and GPUs simultaneously ». Si l’inférence s’arrête pour laisser l’entraînement rattraper son retard, l’utilisation du GPU s’effondre ; si l’inférence va trop vite, la politique contre laquelle le modèle s’entraîne devient obsolète. Ray est la couche d’orchestration qui maintient ces trois charges de travail en équilibre.

Les annonces concrètes de l’été 2026 confirment cette tendance. Google GKE Labs a publié en juin 2026 OpenRL, une API de post-training auto-hébergée (en research preview). OpenRL implémente une API compatible avec Tinker, le framework de Thinking Machines, qui cache toute l’infrastructure derrière quatre primitives API. L’idée est simple : permettre aux équipes de lancer des jobs RL parallèles sur un cluster Kubernetes ou des VMs, en développant localement sur un Mac, puis en exécutant à distance. C’est la promesse d’une abstraction qui rend le RL post-training aussi simple qu’un appel d’API.

Dans la même veine, RadixArk a publié le 1er juillet 2026 le framework open-source « Miles », qui unifie SGLang, NVIDIA Megatron-LM et Ray pour le post-training RL. L’ambition est de créer un pipeline unique où l’inférence (SGLang), l’entraînement (Megatron-LM) et l’orchestration (Ray) travaillent de concert. Ces initiatives ne sont pas des prototypes : elles répondent à un besoin réel, documenté par des études de marché — TechSiddhi rapporte que 45,5 % des décideurs IA citent les coûts élevés comme barrière principale, et que le marché des plateformes IA passera de 109,9 milliards de dollars (2025) à 181,3 milliards (2026).

Framework	Éditeur	Date de publication	Approche
OpenRL	Google GKE Labs	Juin 2026 (research preview)	API compatible Tinker, jobs RL parallèles, développement sur Mac
Miles	RadixArk	1er juillet 2026	Unification de SGLang, Megatron-LM et Ray
RL-Kernel	RL-Align (GitHub)	2026	Optimisations mémoire pour GRPO (réduction VRAM jusqu’à 10x)

Le grand écart matériel : entre A100 et RTX 4090

La réalité des besoins matériels en 2026 est brutale. Le RL post-training exige des multi-modèles et des rollouts massifs. Les benchmarks publiés par RL-Kernel, un dépôt GitHub auto-publié, sont éloquents : sur un NVIDIA A100 80 Go, avec un modèle Llama-3-8B (vocabulaire 128 256, séquence de 512 tokens), la consommation VRAM passe de 15,66 Go (avec un groupe de 64) à 63,12 Go (avec un groupe de 256) en PyTorch natif. RL-Kernel revendique une réduction de VRAM jusqu’à 10x pour les workloads GRPO, et un speedup de la phase d’échantillonnage allant jusqu’à 163x (de 176,79 ms à 1,08 ms) en utilisant des kernels FlashInfer fusionnés, sur un batch de 32, testé sur A100 80 Go avec Qwen3-30B-A3B.

Mais ces chiffres sont à prendre avec précaution : ils proviennent d’un dépôt GitHub auto-publié, sans validation indépendante. Et surtout, ils concernent un GPU datacenter — un A100 80 Go — pas une carte grand public. La question est donc : une RTX 3090 24 Go peut-elle suffire pour un GRPO sur un 7B ? Les données disponibles ne permettent pas de l’affirmer avec certitude. Ce qui est sûr, c’est que la génération de rollouts massifs (groupes de 64 à 256) nécessite une mémoire qui dépasse les 24 Go d’une carte grand public, même avec les optimisations. Les cartes 48 Go (comme certaines RTX prosumer) ou 96 Go (comme les A6000 ou les solutions multi-GPU) deviennent plus réalistes. Et l’Apple Silicon M4 Ultra, avec sa mémoire unifiée de 128 Go et sa bande passante de 546 Go/s, est une option sérieuse pour charger des modèles 70B en Q4/Q5 (44-50 Go) — mais pour du RL, la bande passante mémoire et la capacité de calcul sont des facteurs limitants.

Les coûts réels, eux, restent élevés. Une RTX 4090 coûte encore cher en 2026 (une configuration tour complète avec RTX 4090 revient à environ 2 900 $), une A100 d’occasion est un investissement de plusieurs milliers d’euros, et un cluster de 4 à 8 GPU devient une affaire de budget professionnel. Le grand écart est là : le matériel grand public peut servir de l’inférence, mais le post-training RL reste largement un jeu de datacenter — sauf à utiliser des optimisations comme celles de RL-Kernel, qui restent à valider sur des cartes grand public.

FreeToken : la fin du GPU à 3000 € pour faire tourner les MoE de pointe ?

Pendant que le RL post-training tire les besoins matériels vers le haut, une autre révolution se joue sur le terrain de l’inférence. Un projet nommé FreeToken, porté par l’organisation FlashML, prétend faire tourner des modèles Mixture of Experts (MoE) de 290 milliards de paramètres et plus sur un simple PC de gamer. L’argument est séduisant : « Unlock datacenter-class intelligence on the hardware you already own — Run 290B+ frontier MoE models locally on your gaming PC at blistering interactive speeds. »

Le principe technique est radicalement différent de celui d’Ollama. Les modèles MoE comme DeepSeek V4-Flash (284 milliards de paramètres au total, mais seulement ~13 milliards activés par token) posent un défi unique : l’intégralité des poids doit résider quelque part, même si seule une fraction est activée à chaque token. FreeToken traite les ressources hétérogènes d’une machine de bord — GPU, CPU, mémoire hôte, interconnexions — comme une plateforme d’inférence unifiée et élastique. Concrètement, il combine plusieurs briques :

Une politique de co-exécution CPU–GPU adaptative à la bande passante (dite politique $q^\star$), qui décide en temps réel où placer chaque expert selon la bande passante disponible ;
Un pré-remplissage (prefill) en double buffering sur toutes les couches, qui recouvre le chargement des poids par le calcul ;
Un cache global d’experts de type LRU (Least Recently Used), qui garde en mémoire les experts les plus fréquemment sollicités ;
Le format de poids rapide FTW (Fast Weight format), conçu pour accélérer le chargement ;
Un cache sémantique avec des points d’ancrage pour l’état récurrent et le KV cache, qui évite de recalculer inutilement le contexte lors des éditions agentiques (appels d’outils, blocs de réflexion).

L’approche est documentée par un article arXiv (2608.16157) référencé directement dans le dépôt GitHub, ce qui lui donne une base plus solide que la plupart des projets « miracle » qui fleurissent sur les réseaux. Selon stork.ai, FreeToken revendique des performances jusqu’à 3x supérieures à Ollama sur des modèles MoE massifs, sur des GPU grand public.

Faut-il y croire ? La prudence reste de mise. Comme le détaille notre enquête dédiée (« FreeToken : faire tourner un MoE de 284B sur un PC de gamer — autopsie d’une promesse (enfin) documentée »), les chiffres annoncés par le projet n’ont pas tous été reproduits indépendamment, et le véritable goulot d’étranglement n’est pas la VRAM mais la bande passante PCIe et la latence mémoire. Un MoE de 284B en Q4 pèse environ 140-160 Go : il ne tient sur aucune carte grand public, mais il peut résider en RAM système (128 Go sur un Mac Studio M5 Max, 128 Go sur un mini PC à mémoire unifiée, 192 Go en cible sur AMD Gorgon Halo). FreeToken ne supprime donc pas le besoin de mémoire — il déplace le problème du GPU vers la RAM et l’interconnexion, et exploite le fait qu’un MoE n’active qu’une fraction de ses experts à chaque token.

C’est là toute la nuance : FreeToken ne rend pas un 290B « léger », il rend son exécution possible sur du matériel non-datacenter, à condition d’accepter un débit inférieur à celui d’un GPU unique dédié. Pour un hobbyiste, c’est néanmoins une porte ouverte : là où il fallait auparavant un cluster, une station à mémoire unifiée peut désormais servir un modèle de frontière, lentement mais réellement.

Le guide VRAM par palier : ce qui tourne vraiment chez vous en 2026

La bonne nouvelle, c’est que tout le monde n’a pas besoin de faire du RL post-training ni de servir un MoE de 290B. Pour l’immense majorité des usages — chat, code, résumé, RAG local — l’inférence d’un modèle de taille raisonnable suffit. Et en 2026, la question n’est plus « quel modèle est le meilleur ? » mais « qu’est-ce qui tient dans ma mémoire ? ». Voici la carte par palier, synthétisée à partir de notre guide VRAM détaillé et des données de la communauté r/LocalLLaMA.

8 Go (laptop d’entrée de gamme, iGPU) : c’est le palier du possible mais contraint. On y fait tourner des modèles 1-3B quantifiés en Q4, avec des débits modestes. Sur un Raspberry Pi 5 (8 Go), Ollama et un LLM 1-3B offrent un usage offline crédible, à quelques tokens par seconde. L’iGPU AMD Radeon 780M, avec les optimisations Vulkan de llama.cpp, atteint environ 10-12 tok/s sur Llama 3 8B Q4 et Qwen 2.5 7B, et 8-11 tok/s sur Mistral 7B Q4_K_M — le gain Vulkan atteignant +50 %, dont +12,9 % via le réglage MMVQ.

12-16 Go (cartes milieu de gamme) : le sweet spot. Une AMD RX 7800 XT (16 Go) ou une RX 9070 XT 16 Go GDDR6 (690 à 740 $) fait tourner confortablement des 7B-13B en Q4/Q5, et des 30B MoE compacts. C’est le palier où les modèles sous 7B — Qwen, Gemma, Llama, Phi, Mistral, SmolLM, Granite — deviennent réellement utiles, comme le détaille notre article sur « Le grand écart des petits modèles ».

24 Go (RTX 4090/5090) : le plafond des 70B. Une RTX 4090 24 Go fait tourner des 70B en Q4 (environ 40 Go… non, cela ne tient pas : il faut descendre en Q3 ou utiliser un offload partiel). En pratique, le 24 Go est le palier des 30B-34B confortables et des 70B en quantification agressive avec offload CPU.

48 Go (double GPU, Mac Studio) : le no man’s land. Deux cartes de 24 Go ou un Mac Studio à mémoire unifiée permettent de charger des 70B en Q4/Q5 sans offload, avec un débit correct.

96-128 Go (Mac Studio M5 Max, AMD Strix Halo, mini PC à mémoire unifiée) : les 70B confortables, et l’entrée dans les MoE massifs. L’AMD Strix Halo, avec ses 16 cœurs Zen 5, son GPU RDNA 3.5 et son bus mémoire 256 bits à 256 Go/s, atteint environ 40-60 tok/s sur Llama 3 8B Q4 (Vulkan) et 5-10 tok/s sur Mixtral 8x7B Q4_K_M. Les mini PC à mémoire unifiée de 128 Go (Acer, AMD Ryzen AI Halo à 3 999 $, supportant jusqu’à 120B+) et les cibles à 192 Go (AMD Gorgon Halo, 200B+) ouvrent la porte aux modèles de frontière.

Le point crucial : la bande passante mémoire, plus que la capacité, détermine le débit. Un Mac Studio M5 Max à 128 Go peut charger un 70B, mais ses tokens par seconde dépendent de sa bande passante unifiée, pas de sa seule capacité. C’est pourquoi les MoE — qui n’activent qu’une fraction des poids par token — sont particulièrement adaptés à ces architectures à mémoire unifiée.

Les moteurs d’inférence : le vrai levier « sans se ruiner »

Si le matériel est le plancher, le moteur d’inférence est le levier. En 2026, le paysage des runtimes s’est stabilisé autour de quelques acteurs, et le choix du moteur peut doubler ou tripler le débit à matériel constant.

llama.cpp reste le socle invisible de l’IA locale. Sa version 0.5.0, documentée en septembre 2026, a refondu le backend, le scheduler, l’offload et le KV cache, et repensé l’API locale via un serveur intégré (llama-server). C’est le moteur qui fait tourner les GGUF sur à peu près tout — Windows, macOS, Linux, Raspberry Pi. Face à lui, vLLM vise la production et l’intégration dans les boucles RL ; TensorRT-LLM optimise pour NVIDIA ; MLX exploite l’Apple Silicon ; Ollama et LM Studio offrent l’ergonomie. Le match des runtimes 2026, détaillé dans notre autopsie de llama.cpp 0.5.0, montre que le « meilleur » moteur dépend du matériel : llama.cpp pour la portabilité et les GGUF, MLX pour les Mac, vLLM pour le serving à grande échelle.

Un nouveau venu mérite l’attention : Strata, un moteur qui, selon ai-stat.ru (5 octobre 2026), parvient à lancer un Qwen 125B sur une carte graphique ordinaire. La communauté r/LocalLLaMA parle à son sujet de « moteurs d’inférence sur-entraînés » (переобученных движков инференса) — une nouvelle philosophie où le moteur lui-même est optimisé de façon agressive pour un matériel donné. C’est la même tendance que FreeToken : déplacer l’intelligence du matériel vers le logiciel.

Le format GGUF, lui, reste central. Comme l’explique convly.ai (9 septembre 2026), le choix de la quantification (Q4_K_M, Q5_K_M, Q8_0…) détermine directement la taille du fichier et donc ce qui tient en mémoire. Pour un 7B, Q4_K_M est le compromis standard ; pour un 70B, il faut souvent descendre en Q3 ou Q4 avec offload. Le speculative decoding, qui utilise un petit modèle « draft » pour accélérer un grand modèle, est devenu une technique standard pour gagner des tokens par seconde sans changer de matériel.

Le coût total de possession : le vrai calcul

« Sans se ruiner » ne veut pas dire « gratuit ». Le vrai calcul est un coût total de possession (TCO) qui intègre le matériel, l’électricité, et le temps.

Côté matériel, les ordres de grandeur 2026 sont clairs : une configuration tour complète avec RTX 4090 revient à environ 2 900 $ ; une RX 9070 XT 16 Go se situe entre 690 et 740 $ ; un mini PC AMD Ryzen AI Halo à mémoire unifiée de 128 Go coûte 3 999 $ ; un Mac Studio M5 Max à 128 Go se situe dans une fourchette comparable. À l’opposé, une A100 80 Go d’occasion reste un investissement de plusieurs milliers d’euros, et un cluster de 4 à 8 GPU relève du budget professionnel.

Côté électricité, une RTX 4090 consomme jusqu’à 450 W en charge, un mini PC à mémoire unifiée beaucoup moins (souvent 65-120 W). Sur une année d’usage intensif, l’écart de facture énergétique peut dépasser le prix d’une carte d’entrée de gamme.

Côté logiciel, la bonne nouvelle est que l’écosystème open source est gratuit : llama.cpp, Ollama, LM Studio, vLLM, MLX, FreeToken, Strata. Le coût caché est le temps d’apprentissage — configurer les quantifications, les offloads, les paramètres de contexte. Mais c’est un investissement unique, pas un abonnement.

La comparaison avec le cloud est éclairante. Une API propriétaire facture au token ; un modèle local, une fois le matériel amorti, ne coûte plus que l’électricité. Pour un usage régulier, le point d’équilibre se situe souvent autour de quelques mois à un an. C’est pourquoi des initiatives comme Portable Computer de Perplexity et Nvidia (25 août 2026) — une version entièrement locale de la plateforme agentique, sans coûts de tokens — signalent un vrai basculement : même les acteurs du cloud investissent dans le local.

Ce qu’un hobbyiste peut raisonnablement faire en 2026

Résumons. En 2026, l’IA locale s’est scindée en deux mondes.

Le premier, celui du post-training RL, reste largement hors de portée du hobbyiste. Faire du GRPO sur un 7B demande plus de VRAM qu’une carte grand public n’en offre, et les frameworks comme OpenRL ou Miles visent des clusters Kubernetes, pas des tours de bureau. C’est le domaine des équipes, pas des individus — sauf à se contenter de SFT LoRA, qui reste accessible sur 16-24 Go.

Le second, celui de l’inférence, n’a jamais été aussi accessible. Grâce à des moteurs comme llama.cpp 0.5.0, FreeToken ou Strata, et à des architectures à mémoire unifiée de 128 à 192 Go, un particulier peut désormais faire tourner des modèles qui exigeaient hier un datacenter. Un MoE de 284B sur un PC de gamer n’est plus une absurdité — c’est une promesse documentée, avec des limites honnêtes (bande passante, latence, débit).

La règle d’or reste la même qu’en 2024, mais avec des chiffres différents : choisissez d’abord ce qui tient dans votre mémoire, ensuite le moteur, et seulement après le modèle. Un 3B bien choisi et bien servi écrase un 70B mal servi. Et à l’heure où les modèles de frontière se disputent les gros titres — Kimi K3, DeepSeek V4 Pro, Qwen —, la contre-révolution silencieuse des petits modèles et des moteurs optimisés est peut-être ce qui compte le plus pour votre bureau.

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.

Le RL post-training change la donne : comment l’open source réinvente son infrastructure (et ce que ça change pour votre setup local)