La métrique la plus révélatrice pour l’IA locale n’est pas imprimée en gros sur l’emballage. Elle s’appelle la bande passante mémoire, se mesure en gigaoctets par seconde, et décide si un modèle tourne fluidement sur votre machine ou bégaie lentement jusqu’à mourir. Quiconque veut sérieusement expérimenter l’IA et se fie aux chiffres de TOPS et de NPU cherche au mauvais endroit. La puissance de calcul est devenue bon marché. La bande passante est la ressource rare.

Cela sonne contre-intuitif, et c’est le cas. C’est pourquoi cela vaut la peine de regarder de près — non pas les classements de benchmarks, mais ce qui se passe réellement dans le châssis quand un modèle compose jeton par jeton.

Pourquoi la bande passante gagne

Les modèles de langue fonctionnent de manière autorégressive. Chaque mot suivant n’apparaît qu’après que tout le poids produit jusqu’alors ait traversé la mémoire une fois. Les unités de multiplication n’attendent pas une mathématique lourde — elles attendent la mémoire. Comprenez cela, et vous comprenez pourquoi un GPU avec peu de VRAM ne sert à rien face à un grand modèle, aussi vite que cadencent ses shaders : le modèle doit tenir et circuler, à chaque étape.

En gros : les jetons par seconde approchant la bande passante mémoire divisée par la taille du modèle. Un modèle de soixante-dix milliards de paramètres en quantification 4 bits occupe près de quarante gigaoctets. Sur un tuyau de 273 Go/s, cela donne théoriquement environ sept jetons par seconde — moins les frais généraux, moins le cache KV, moins tout ce que le système d’exploitation fait à côté. Sur une DDR d’ordinateur portable ordinaire à 64 Go/s, le même calcul devient un exercice de patience. Les deux fois, les cœurs de calcul restent oisifs. La différence tient uniquement à la largeur du tuyau.

C’est précisément pourquoi certains chips sont devenus intéressants dernièrement alors que personne ne les aurait mis sur une liste « d’accélérateurs IA ».

Deux chips que personne n’avait sur sa liste

Considérez d’abord l’Apple M4 Pro. Apple annonce environ 273 Go/s de bande passante mémoire unifiée — stockage partagé entre CPU et GPU, configurable jusqu’à 48 gigaoctets. Rien n’en fait un accélérateur de centre de données. Mais parce que la mémoire est largement raccordée et également visible par le CPU et l’unité graphique, les modèles de taille moyenne tournent avec une fluidité étonnante. Ce n’est pas magie marketing ; c’est physique.

Ensuite, l’AMD Ryzen AI Max+ 395, nom de code Strix Halo. AMD spécifie jusqu’à 256 Go/s, là encore unifié, et la plateforme accueille jusqu’à 128 gigaoctets de LPDDR5X. On le trouve dans des mini-PC compacts, des portables station de travail et des appareils comme le Framework Desktop. Encore une fois : ni H100 ni machine miraculeuse. Mais quiconque peut loger entièrement un grand modèle dans une mémoire rapide pendant qu’une carte concurrente étouffe dans du swap hors-noyau obtient soudain des débits réalistes pour un argent qui ailleurs n’achètera qu’une fraction d’une carte professionnelle.

L’honnêteté est ici obligatoire. Aucun des deux chips n’est magique. Le thermal throttling sous charge soutenue est réel, surtout dans des boîtiers fins. La maturité des pilotes et des runtimes diffère : le chemin Metal d’Apple est fluide ; la voie ROCm/OpenCL d’AMD s’est améliorée mais reste plus rugueuse que le monde CUDA auquel tout se mesure. Et bien sûr, un seul chip de bureau traîne de loin ce qu’une carte H200 ou B200 délivre dans un rack. Affirmer que le matériel grand public est « tout aussi bon » n’a aucun sens. Affirmer qu’il est sans intérêt n’en a aucun non plus.

Une observation sèche : les diagrammes de benchmark mentent routineusement, car ils mesurent la latence jusqu’au premier jeton sur un cache chaud — pas mardi après-midi, six onglets ouverts, la moitié du modèle swappée. Planifiez l’IA sous charge, pas en laboratoire.

Phase un : cliquer et s’émerveiller

Le point d’entrée naturel passe par les applications de bureau. Ollama tire un GGUF ; LM Studio offre une interface soignée pour parcourir les modèles, comparer les quantifications, essayer. C’est précieux. C’est le moyen le plus rapide de sentir comment se comportent un modèle 8B, 13B ou 32B, où la courbe de qualité s’incurve, où le 4 bits reste acceptable et où il ne l’est plus.

Cette phase est ludique, et elle doit l’être. Quiconque crie « architecture ! » à ce stade manque le point : il faut sentir ce que les outils font avant de les formaliser. Mais les limites apparaissent vite. Tout est attaché à une machine, un utilisateur, une session graphique. Au moment où une deuxième personne veut le modèle, où un script nocturne doit inférer automatiquement, la GUI devient un obstacle. L’accès réseau semble collé, pas pensé.

Phase deux : le bureau devient serveur

À un moment, cela ne suffit plus. Vous voulez un endpoint que tout le bureau, tout le réseau domestique, toutes les automatisations peuvent atteindre. Vous liez Ollama ou un runner léger à ::, placez OpenWebUI devant — plusieurs utilisateurs, authentification, sélection de modèles, discussion documentaire — et pointez des outils comme opencode, l’agent de codage en ligne de commande, vers l’endpoint local compatible OpenAI.

Soudain, la station de travail est une infrastructure. Chaque éditeur, chaque collègue, chaque pipeline parle à la même adresse. C’est un véritable changement de paradigme même si techniquement petit : une application est devenue un service. Et avec le service viennent les devoirs familiers de l’infrastructure — chiffrement de transport, authentification, journalisation, mises à jour, gouvernance des modèles. Celui qui franchit cette étape a cessé de bricoler et commencé à exploiter. Beaucoup ne le remarquent que lorsque quelqu’un d’autre accède au modèle pour la première fois.

Phase trois : quand ça cesse d’être un jouet

L’ambition croissante apporte le prochain niveau d’outils. vLLM est le moteur qui a rendu l’inférence GPU économique — batching continu, PagedAttention, haut débit, gestion propre de nombreuses requêtes simultanées. LiteLLM se place devant lui comme proxy et routeur : une API uniforme façon OpenAI au-dessus de nombreux backends, gestion des clés, chemins de repli, routage budgétaire, intégration avec les systèmes de métriques et de logs. Et Bifrost est le genre de projet que l’on rencontre dès qu’on commence à mutualiser et partager la capacité GPU entre charges de travail ou locataires plutôt que de consacrer une carte à un seul processus — utilisation plutôt que machines héros.

Ces outils récompensent un matériel plus conséquent : plusieurs GPU par nœud, liens NVLink, un rack plutôt qu’un bureau. Mais ils punissent aussi la négligence plus sévèrement. Le batching continu aide seulement quand assez de requêtes arrivent simultanément — pour l’utilisateur puissant isolé, les frais généraux ne se rentabilisent jamais. Un routeur ne vaut rien avec derrière un backend poussif. La mutualisation ne fonctionne que si l’équité, la profondeur de file et les démarrages à froid sont gérés sérieusement. En bref : à ce stade, l’expérimentation cesse et commencent les systèmes distribués. Supervision, ordonnancement, imputation des coûts, stratégies de mise à jour — tous sujets connus de l’exploitation classique, désormais partie inattendue de l’IA.

Beaucoup d’amateurs de homelab heurtent ce mur et choisissent entre deux voies : reculer vers une seule machine confortable suffisamment bonne — ou faire consciemment le pas vers une vraie exploitation. L’un et l’autre légitime. Croire qu’un clic de plus vous en tirera est une erreur.

L’art difficile : penser matériel et logiciel ensemble

Là gît la vraie difficulté. Ni le matériel seul ni le logiciel seul ne gagnent. L’appariement compte tout.

Acheter un immense GPU et le piloter via un runner mono-flux sans batching gaspille quatre-vingt-dix pour cent de sa capacité. Monter vLLM pour un poste avec un seul utilisateur paie des frais généraux sans retour. Écraser un grand modèle en 4 bits là où 8 bits était qualitativement nécessaire économise de la mémoire et perd de la précision. À l’inverse, tout faire tourner en FP16 parce que « supérieur sonne mieux », loger moins en VRAM, et figer. La quantification n’est pas un interrupteur mais un curseur. Refroidissement, bruit et consommation électrique en régime permanent décident si un appareil peut vivre dans le salon ou appartient au labo du sous-sol. L’amortissement entre dans le calcul, pas en note de bas de page.

Et puis l’éléphant que personne n’aime voir : la tarification des API. Elle paraît bon marché — quelques centimes par million de jetons — jusqu’à ce que le volume grimpe. Les boucles agentic multiplient les requêtes par dix, par cent. Tempêtes de retries, passages de récupération redondants, prompts système verbeux renvoyés à chaque tour, modèle mal calibré pour une tâche triviale : une expérience bon marché devient une facture mensuelle à quatre chiffres. La méthode détermine le prix plus que le tarif.

L’auto-hébergement inverse cela : coût fixe au lieu de variable. Quelque part ça devient économique, mais seulement avec une charge respectable. Un GPU qui tourne au ralenti toute la journée cumule les inconvénients des deux mondes — dépense d’investissement et coût d’opportunité. La romance n’y aide pas. Il y faut de l’arithmétique, et l’honnêteté d’évaluer sa propre charge de façon réaliste plutôt qu’idéalisée.

Une raison de fêter

Au-delà de l’effort, il y a une raison de fêter, et elle pèse : toute l’échelle décrite ci-dessus est open source. Ollama, llama.cpp, vLLM, LiteLLM, Bifrost, OpenWebUI, opencode — construits par la communauté, inspectables, auditables, forçables. Personne ne peut vous les retirer, personne ne peut en réécrire les conditions du jour au lendemain sans vous laisser l’option de rester immobile.

Une nuance appartient ici : LM Studio est pratique, mais il n’est pas libre au sens OSI. Gratuit pour un usage personnel, licencié commercialement sinon. Qui tient à un logiciel constamment libre choisira la voie Ollama et llama.cpp. Ce n’est pas un dogme ; c’est un éclaircissement utile à connaître avant de bâtir des architectures dessus.

Vu plus largement : l’IA a ébranlé nos vies professionnelles — toutes, d’une certaine façon. Elle est arrivée, et elle reste ; j’en suis certain. La nier est nostalgie. Mais la naïveté est l’exact opposé et tout aussi erronée. Le confort masque la dépendance, et masque des coûts qui montent en silence. La posture savante est : utiliser l’IA délibérément, à vos propres conditions, comprenant ce qu’elle coûte, ce qu’elle sait faire et où elle échoue. Ce n’est pas une posture contre la technologie. C’est une posture pour votre propre capacité d’action.

Ce que cela a à voir avec libcom.de

Depuis un quart de siècle, moi — Jochen Demmer, libcom.de — je construis sur des infrastructures open source. Ces dernières années, cela inclut de plus en plus l’exploitation de stacks IA sur matériel propriétaire : analyse de logs, rédaction, revue de code, systèmes d’assistance internes, recherche documentaire. Pas en démonstration, mais en pratique quotidienne et sur des systèmes clients.

De cette pratique viennent des jugements qu’aucun tutoriel n’enseigne : où le seuil de rentabilité entre API et auto-exploitation bascule, comment se règle le curseur quantification-qualité pour quelle charge, quelle architecture réseau et sécurité exige un endpoint d’inférence exposé proprement en entreprise — et où passe la frontière entre un jouet de homelab et un service maintenu. La tâche la plus fréquente n’est pas de procurer du matériel, mais d’apparier le bon matériel avec la bonne stratégie de serving, plutôt que d’acheter d’abord une boîte coûteuse et de chercher ensuite un logiciel qui la justifie.

Si vous vous demandez si l’IA locale a du sens pour votre environnement, quel matériel convient au logiciel prévu, et à quoi ressemble une stack qui ne s’effondre pas après trois mois : écrivez à contact@libcom.de. Nous faisons l’inventaire honnêtement — ouvertement, sans pression commerciale, avec le regard sur ce qui dure à long terme.

Ça commence par la curiosité et finit, pour qui prend ça au sérieux, par une infrastructure. Entre les deux se trouve le plus beau métier en train d’être réinventé — pièce par pièce, sur votre propre matériel, avec des outils libres.

Note : cet article offre une orientation générale sur les choix matériels et logiciels ainsi que sur les considérations de coûts et ne remplace ni conseil d’achat ni avis juridique. Les performances et prix indiqués sont illustratifs et peuvent varier selon la configuration, l’état des pilotes et l’évolution du marché ; toutes les indications sont fournies sans garantie.