Sur mon bureau, sous le Mac mini, un petit boîtier gris à 4 500 € : le DGX Spark de NVIDIA, un supercalculateur de poche conçu pour les chercheurs et les développeurs. Pendant six semaines, j’ai coupé Claude, Codex et Gemini pour lui confier mon travail.
Article très intéressant, bravo. Une pépite.
Quelques nuances cependant : Tu parle d’automatisation : Dans ton domaine sur les actualités tu automatise quoi ?
Je crois comprendre que tu automatise une veille d’actualité. Je trouve, que c’est donc de l’over kill.
SI je résume, tu balance une liste de site à surveiller + google actu, et il va voir si ça change ?
L’art de l’IA, si on peut dire ainsi, c’est de jongler selon les usages. Du Opus pour des actualités c’est une perte d’argent sûre. Pas besoin d’autant pour comprendre du texte « d’actualité ».
ON a l’impression, de ce que je comprends, que tu utilise un marteau pillon pour écraser une mouche.
Typiquement sur les tokens :
Elle lit quoi dans ton script d’automatisation ? Tout le site ? Donc tout le contenu pub, le bruit parasitaire etc ? Quelle perte sèche.
J’insiste sur un point : l’article est une pépite, mais j’aimerai un vrai usage « pro », non d’actualité. Exemple : Réponse via des RAG / base de connaissance à du support client etc.
1 « J'aime »
Dommage pas de comparaison avec la non utilisation de l’IA et pas de tableau récapitulatif des demandes et résultats
A côté de la moto et du camion j’ai l’impression d’être le piéton…qui a besoin d’aller à la boulangerie, chez le boucher, au supermarché du quartier, etc. et qui regarde la moto et le camion se faire chier pour une plus value inexistante mais le pilote et le conducteur sont fiers d’eux « T’as vu ma belle moto hein ? t’as vu mon beau camion ? »
1 « J'aime »
Article remarquable, bravo !
C’est la première fois que je passe autant de temps à lire un article sur Clubic.
On se pose de plus en plus la question de ce genre d’outil pour une PME avec quelques développeurs et pour interagir avec des outils SaaS via serveur MCP.
6 « J'aime »
Merci ! J’ai rajouté un schéma sur l’automatisation de ma veille parce que c’est plus complexe qu’une simple aspiration de flux RSS. Les articles sont scrapés et lus en intégralité, les faits sont extraits, vérifiés, etc. J’utilise des embeddings sur les faits (pas sur les seuls titres) pour regrouper, scorer, dédupliquer. Ce n’est qu’un exemple parmi d’autres ! Toutes les semaines, j’ai un agent local qui analyse les stats de mon app en ligne sur les stores, traite les commentaires utilisateurs pour déceler des bugs ou des besoins d’évolution produit, prépare le code que je n’ai plus qu’à reviewer. La liste de tâches que j’ai automatisée est trop longue pour la dérouler ici.
3 « J'aime »
Merci pour cet article très intéressant 
J’ai personnellement commencé avec un Mac mini M4 Pro doté de 64 Go de RAM. Puis, souhaitant utiliser les autres logiciels que j’ai créés avec de l’IA embarquée, je suis passé au MacBook Pro M5 Max avec 128 Go de RAM.
J’ai développé une vingtaine de logiciels à ce jour, par exemple pour gérer mes mails, créer des images, analyser et synthétiser des dossiers médicaux, juridiques, successoraux, immobiliers ou financiers, dédoublonner, classer et ranger des dossiers personnels et professionnels dans mes documents ou mes clouds, créer et corriger du code en CLI ou sous forme de chat, analyser des documents et des photos, transcrire du texte, traduire, etc.
La solution personnelle que j’utilise nécessite souvent quatre, et parfois cinq petits modèles d’IA tournant en parallèle, chacun ayant une tâche spécifique : par exemple, un modèle de triage, un modèle de vision pour analyser les documents et images que je lui fournis ou qu’il trouve, un modèle d’arbitrage et d’analyse, un modèle d’embeddings et, parfois, un modèle superviseur qui fait office de manager pour les différents « agents » que sont les quatre autres modèles. N’étant pas développeur, je tâtonne encore, mais globalement, c’est fonctionnel et plutôt qualitatif.
J’ai même développé une solution me permettant de solliciter mon MacBook Pro à distance, à travers le cloud Apple. Depuis certaines applications personnelles que j’ai créées, je peux choisir soit de faire tourner de toutes petites IA locales directement sur mon iPhone ou mon iPad Pro, soit de les faire tourner à distance sur mon MacBook Pro. Et tout cela à travers le cloud 
En tout cas, ça fait plaisir de voir quelqu’un s’intéresser à ce sujet qui me passionne depuis maintenant plus d’un an, lorsque j’ai commencé à utiliser des IA locales. Et ça m’a permis de découvrir le Gemma 4 26B, que je n’avais pas encore dans ma besace. Je vais donc refaire tous mes benchmarks afin de voir s’il apporte un réel gain chez moi : vitesse de lancement, nombre de tokens générés, qualité et score des réponses…
J’ajouterais un élément assez important : lorsqu’on charge un modèle sur un Mac, plusieurs logiciels peuvent ensuite le réutiliser à travers llama-server. Lorsque je m’en suis rendu compte, j’ai fait en sorte d’homogénéiser les modèles utilisés. On peut ainsi avoir trois, quatre ou cinq logiciels différents démarrés en même temps, utilisant les cinq mêmes modèles, sans surcharger davantage la RAM que si un seul logiciel était lancé 
Merci encore pour cet article !
1 « J'aime »
Très intéressant en effet.
Je serais peut-être un peu trop optimiste de dire que le futur de l’IA serait en local, sur un matériel qui est physiquement là et qu’on maîtrise plutôt que de dépendre de gros data centers. On se retrouverait alors à l’inverse que ce qu’on fait actuellement : on mobilise de grandes ressources, ça pollue, ça nécessite beaucoup d’eau pour refroidir… Et si au final tout ce que l’IA peut faire tient dans un petit boîtier chez soi? Pour l’instant ça nécessite pas mal de connaissances et une bonne dose de patience qu’une majorité de gens n’a pas (ex: rien que le fait par exemple d’installer un outil de génération d’images en local comme Stable Diffusion est encore réservé à des utilisateurs plus expérimentés.
Mais la question qui se poserait après, comment les sociétés ayant développé leurs IA monétiseraient leurs investissements colossaux? Créer des modèles? Louer ces matériels, un abonnement, une licence? Même là c’est encore flou, car il justement il existe des modèles open source… Bref, cet article met aussi en lumière un futur possible de l’utilisation de l’IA et la volonté d’indépendance par rapport à des mastodontes proposant des services en cloud et qui en plus sont susceptibles de couper à tout moment.
J’ai eu une conversation justement avec quelqu’un qui a basé tout le développement d’un projet sur Claude : de l’analyse au développement, il n’a pratiquement rien fait lui-même et tout son travail s’est résumé à des prompts. Il n’a tapé aucune ligne de code, ne sait pas ce que le code généré fait exactement etc. Si demain Anthropic coupe l’accès à Claude on fait quoi? Tout le projet est difficile à maintenir car il faudrait investir un temps énorme à relire tout le code, le comprendre, savoir où aller corriger un souci?
C’est un retour d’expérience passionnant et extrêmement honnête sur les limites ergonomiques du local. Cependant, l’article commet l’erreur classique de notre époque : résumer le paysage de l’IA Cloud aux seuls abonnements grand public d’OpenAI (ChatGPT), d’Anthropic (Claude) ou de Google (Gemini) à 20 € par mois.
Aujourd’hui, plus personne dans le milieu professionnel ne se limite à ce trio. Le marché a été totalement bouleversé par des acteurs comme DeepSeek, MiniMax, Zhipu, Xiaomi, ou encore Meta et Grok.
Chez Minimax, pour ne prendre que cet exemple, par exemple, les quotas d’usage sont énormes. L’équivalent de 1.7 milliards de tokens par mois pour 20 dollars par mois seulement, avec un modèle Minimax M3 à un niveau de performance assez proche de Opus 4.6.
https://platform.minimax.io/subscribe/token-plan
Dans cette nouvelle configuration, la véritable référence de l’IA est devenue OpenRouter. C’est le hub absolu où l’on trouve tous les modèles du marché, et c’est là que se joue la guerre ultra-concurrentielle du rapport qualité/prix. L’avenir de l’IA ne réside plus dans les abonnements rigides des créateurs de modèles, mais bien chez ces providers d’inférence qui achètent de la puissance de calcul en masse pour casser les prix à l’utilisation.
Faisons l’exercice de comparer l’achat de cette machine locale à 4 500 € (pour faire tourner le modèle Gemma 4 26B sur un DGX Spark) avec l’usage du même modèle dans le Cloud via OpenRouter.
https://openrouter.ai/google/gemma-4-26b-a4b-it
Pour être parfaitement juste, prenons en compte la structure réelle des coûts d’API (où l’écriture coûte plus cher que la lecture) :
- Le token d’entrée (input) est à 0,06 $ le million.
- Le token de sortie (output/génération) est à 0,33 $ le million.
- Sur un usage mixte classique de développeur ou de rédacteur (comprenant environ 75 % de contexte lu et 25 % de texte généré), on arrive à un coût moyen très conservateur de 0,15 $ (environ 0,15 €) le million de tokens.
Refaisons le calcul avec ce tarif réel :
Volume de tokens possible= 4500€ / 0,15€} * 1000000 = 30 milliards de tokens
Pour que l’on se rende compte de ce que représentent 30 milliards de tokens dans les cas d’usage décrits par l’auteur (rédaction, génération de code, revues de presse) :
- Un roman moyen représente environ 100000 mots (soit environ 130000 tokens). Avec 4 500 €, vous pouvez analyser ou générer l’équivalent de 230 000 romans.
- Si vous consommez du code et du texte à hauteur de 5 millions de tokens par jour (ce qui est un volume colossal pour un indépendant, équivalent à lui faire réécrire l’intégralité d’un gros projet logiciel chaque matin), vos 4 500 € vous couvrent pour 6 000 jours d’activité, soit plus de 16 ans de travail quotidien sans interruption.
Et si l’on craint pour la confidentialité de ses données avec des modèles ultra-compétitifs comme DeepSeek V4 Flash (mieux positionné que Gemma 4), il suffit d’utiliser un fournisseur d’inférence américain comme DeepInfra (9 cts le million de tokens) : vous profitez de tarifs dérisoires avec la garantie contractuelle que 0 % de vos données ne transitent par la Chine.
Le constat de ce dossier est sans appel : pour un indépendant, s’imposer la maintenance et le coût d’une machine locale à 4 500 € pour faire tourner des modèles intermédiaires est un non-sens économique. Le Cloud à l’usage offre une flexibilité et un coût d’exploitation imbattables.
Pour autant, les LLM locaux ne sont pas à jeter. Ils représentent une part indéniable de l’avenir de l’informatique personnelle. Mais pour que cette transition soit viable, il faudra attendre que le marché du matériel s’assainisse. L’explosion récente des prix de la mémoire vive (RAM/VRAM) indispensable pour faire tourner ces modèles gonfle artificiellement le coût de ces configurations. Dès que les capacités mondiales de production de puces auront augmenté et que le prix de la RAM sera revenu à la normale, le local aura une vraie carte à jouer.
En attendant, consommer de l’API à la demande via des routeurs de cloud reste la décision la plus pragmatique et la plus rentable.
2 « J'aime »
Pour l’auteur de l’article, avec les mêmes pérégrinations, voici mon daily-runner:
~/llama.cpp/build/bin//llama-server -hf deepreinforce-ai/Ornith-1.0-35B-GGUF:Q4_K_M \
--model ornith-1.0-35b-Q4_K_M.gguf \
--mmproj mmproj-BF16.gguf \
--spec-draft-model Qwen3.5-35B-A3B-MTP-ONLY-BF16.gguf \
--chat-template-file chat_template.jinja.1 \
--host 0.0.0.0 --port 8080 \
--ctx-size 262144 \
--yarn-orig-ctx 131072 --rope-scale 2.0 --rope-scaling yarn \
--override-kv qwen35moe.context_length=int:262144 \
--cache-type-k q8_0 --cache-type-v q8_0 \
--no-mmap -b 4096 -ub 2024 \
--jinja --gpu-layers 999 \
--spec-type draft-mtp --spec-draft-n-max 2 \
--spec-draft-p-min 0.1 --spec-draft-p-split 0.1 \
--reasoning on --reasoning-budget 512 \
--samplers "top_k;top_p;min_p;temperature;typ_p" \
--min-p 0.024 --temperature 0.75 --top-k 40 --top-p 0.95 \
--swa-checkpoints 48 \
--cache-reuse 256 \
--kv-unified --cont-batching -fa on \
--image-min-tokens 3072 \
--metrics --props \
--chat-template-kwargs '{"preserve_thinking":true, "auto_disable_thinking_with_tools":false}'
Ornith1.0-35B est le meilleur modèle pour le codage en open weight actuellement pour ceux qui n’ont pas 512Go de mémoire GPU (après vrais tests, pas un benchmark qui a servi à l’entraînement/RL). Il tourne sans problème sur une machine à 64Go (type NVidia AGX Orin et Apple Mx). Si vous avez 128Go, vous pouvez passer le contexte de 262144 tokens à 524288 voire à 1 million, en doublant les chiffres dans la ligne VoodooSpell ci dessus.
Les fichiers à télécharger sont disponibles sur Hugginface (chat-template.jinja, mmproj-BF16.gguf, Qwen3.5-35B-A3B-MTP-ONLY-BF16.gguf) faciles à trouver dans la section commentaires de la page du modèle. Il faut construire son propre llama-cpp, mais c’est 3 commandes classiques qui sont disponibles partout sur le web.
Notez que pour le DGX Spark (ou n’importe quel GB10 à 128GB), il devrait être possible de faire tourner une version limitée de GLM5.2 (le meilleur modèle open source général très proche ou meilleur que de Opus 4.8) lorsque les 2 technologies suivantes seront atteintes: la quantification à 1 bit de Bonsai (cherchez PrismLM), pour réduire l’empreinte mémoire du modèle à 104GB, et l’utilisation du moteur Colibri (sur Github) pour ne charger que les poids nécessaires pour l’inférence.
Un autre point que vous n’avez pas abordé dans votre article, c’est le nombre d’utilisateurs simultanés du modèle. C’est bien beau d’annoncer des tokens/s, mais ça ne veut rien dire si on n’a pas le nombre de clients concurrents associé. Car avec VLLM ou SGLang, un DGX Spark peut taquiner le millier de tokens/s avec 256 clients concurrents sur GPT OSS120B. Ce qui fait carrément sens pour une PME par exemple (un seul Spark sert tous les utilisateurs de l’entreprise sans perte de performance) et moins pour un particulier (qui ne va probablement jamais lancer plus que 2 ou 3 sous agents.
Dans la VoodooSpell ci dessus, j’utilise llama-cpp qui n’est pas fait pour avoir de nombreux utilisateurs parallèles: comprendre, ça marche très bien jusqu’à 3 requêtes concurrentes, mais après ça s’effondre et il faut entrer dans l’enfer de la configuration vLLM pour extraire plus de jus du système.
1 « J'aime »
intéressant surtout le meme jour l’article sur PrismML qui a fait qwen 3.6 27b qui tient sur 4go de VRAM donc meme un GPU de 8go fare très bien le job. donc hors du code poussé et si beaucoup d’actualité pas trop d’intérêt a l’abonnement
@Funkee Merci à toi pour ce retour d’expérience des plus intéressants. Cela change des articles bas de gamme et « orientés » sur l’IA proposés par d’autres auteurs…
Personnellement, j’aurais aimé pouvoir consulter les résultats ainsi que le protocole de test.
Tu soulignes certains problèmes concernant la qualité des réponses, qui auraient peut-être pu être corrigés avec un bon harnais.
Utiliser Codex avec GPT-OSS (en CLI sous Linux), semble pertinent pour exploiter au mieux ce modèle. Même chose pour Gemma 4 avec Google Antigravity.
Il existe une troisième option qui reste intéressante lorsque l’on n’a pas besoin d’un niveau de confidentialité élevé : faire tourner un gros modèle local via un abonnement cloud à 20 dollars par mois.
J’ajouterais un dernier point : le DGX sparks de Nvidia a 128 go de mémoire unifiée et soudée, le jour où de nouveaux modèles locaux réclament plus de mémoire tu l’as dans l’os… Il n’est même pas possible de faire un upgrade de mémoire…
Donc @Funkee t’as mis un appareil qui manifestement chauffe de manière importante dans ton placard électrique ? J’espère que ton assureur ne lit pas Clubic 
Ce qui me fait le plus peur, c’est cette nouvelle vision du journalisme technique qui, au lieu d’aller interviewer nos chercheurs ou nos entreprises, préfère faire du scanning dans les nouvelles que d’autres publient et copier-coller ou traduire automatiquement leur contenu.
Oui un article sur les IA locales serait très intéressant.
Il y a des applications d’IA comme ComfyUI ou Pinokio qui méritent d’être connues ça évite de gérer soit même Python et tous les trucs compliqués souvent liés à l’IA.
Pour le code j’aimerais bien savoir comment faire pour un projet complet. J’ai essayé Olloma mais il n’accepte pas les .zip en entrée et est incapable aussi de lire un github.
Juste merci pour cette découverte et la facilité de lecture pour un sujet
Votre raisonnement économique est globalement pertinent, mais il présente plusieurs limites.
D’abord, vous comparez surtout le coût d’un modèle local avec les offres API les moins chères du marché. Cela montre effectivement qu’un DGX Spark est difficilement rentable pour un indépendant consommant seulement quelques millions de tokens par jour, mais pas que le cloud est toujours préférable. Le local peut répondre à d’autres objectifs : fonctionnement hors ligne, contrôle de l’environnement d’exécution, stabilité d’accès au modèle, absence de quotas ou de dépendance tarifaire, possibilité de modifier les poids et mutualisation entre plusieurs utilisateurs.
Mais c’est surtout votre argument relatif à la confidentialité qui est trop catégorique. Le fait qu’un prestataire affirme que les données ne transitent pas par la Chine, ne sont pas utilisées pour l’entraînement et ne sont normalement pas conservées sur disque constitue une protection appréciable, mais ce n’est pas l’équivalent d’un traitement local.
Avec une API, les prompts, documents et réponses quittent nécessairement l’ordinateur de l’utilisateur. Ils sont transmis au fournisseur, déchiffrés sur son infrastructure et traités en mémoire par ses systèmes. Le chiffrement de la connexion protège principalement les données pendant leur transport ; il n’empêche pas le prestataire qui réalise l’inférence d’y avoir techniquement accès pendant le traitement.
Dans le cas de DeepInfra, la documentation indique que les requêtes ordinaires ne sont pas utilisées pour entraîner les modèles et ne sont normalement pas stockées de manière persistante. MAIS elle prévoit qu’une petite proportion des requêtes puisse être journalisée pour le débogage, la sécurité ou la prévention des abus, ainsi que certains stockages temporaires pour des fonctions particulières. Parler d’une garantie de «0%» est donc excessif, à moins de disposer d’un contrat spécifique excluant explicitement toute journalisation, tout accès humain, toute sous-traitance et toute conservation, y compris temporaire.
Il faut aussi distinguer plusieurs notions souvent regroupées sous le terme de confidentialité : absence d’entraînement sur les données, absence de conservation, absence d’accès humain, localisation géographique du traitement, juridiction applicable, recours éventuel à des sous-traitants et possibilité d’audit. Une promesse portant sur l’un de ces aspects ne garantit pas automatiquement les autres.
Enfin, passer par OpenRouter ajoute potentiellement un intermédiaire supplémentaire entre l’utilisateur et l’hébergeur du modèle. Cela ne signifie pas nécessairement que les données sont mal protégées, mais cela élargit la chaîne de traitement et oblige à examiner les politiques de chacun des acteurs ainsi que le routage réellement utilisé.
La comparaison des performances mérite elle aussi davantage de prudence. Deux modèles obtenant des scores proches sur un agrégat de benchmarks ne sont pas nécessairement équivalents en rédaction, fiabilité, raisonnement agentique, multimodalité ou robustesse. DeepSeek V4 Flash et MiniMax M3 peuvent être extrêmement compétitifs sans remplacer Opus ou Gemma dans tous les usages.
Certaines formulations sont également exagérées : OpenRouter n’est pas la « référence absolue » pour tous les professionnels. Beaucoup d’entreprises privilégient les API directes, Azure, AWS, Google Cloud ou des déploiements privés pour bénéficier de contrats adaptés, de garanties de localisation, de contrôles d’accès, de journaux d’audit, de SLA et d’engagements de conformité. De même, l’équivalence exprimée en nombre de romans mélange tokens d’entrée et de sortie, alors qu’un roman effectivement généré serait surtout facturé au tarif, plus élevé, des tokens de sortie.
Votre conclusion centrale reste donc valable dans le cas étudié : à volume modéré et sans exigence forte de souveraineté ou de confidentialité, l’API est nettement moins chère. Mais une API assortie de bonnes garanties contractuelles reste un traitement externalisé ; elle n’offre pas le même degré de maîtrise qu’un modèle exécuté localement sur une machine isolée ou contrôlée par l’utilisateur.
2 « J'aime »
Bien sûr on peut faire des choses très bien avec des IA locales avec des avantages réels via à vis des modèles cloud. La preuve.
Vous évoquez la stabilité d’accès et l’absence de quotas comme des arguments en faveur du local. En pratique, c’est souvent l’inverse qui se produit.
S’appuyer sur un modèle local ou un serveur privé unique, c’est s’exposer à un point de défaillance unique (panne matérielle, coupure réseau, coupure électrique). À l’inverse, utiliser un agrégateur comme OpenRouter offre la meilleure garantie de haute disponibilité du marché. Si un fournisseur d’inférence (provider) subit une panne, l’infrastructure bascule automatiquement et de manière transparente sur dix autres alternatives.
Un déploiement local est par définition limité par son matériel. Si votre application connaît une hausse soudaine de trafic ou nécessite d’absorber des contextes lourds (jusqu’à 1 million de tokens) pour plusieurs utilisateurs simultanés, la mémoire (VRAM) s’effondre instantanément. Les fournisseurs d’inférence disposent d’infrastructures professionnelles redondées (groupes électrogènes, refroidissement industriel) capables d’encaisser ces pics de charge sans investissement initial lourd.
Votre mise au point sur le fait que 0 % de risque n’existe pas dans un environnement externalisé est juridiquement exacte. Néanmoins, il convient de contextualiser ce risque par rapport aux pratiques réelles du marché.
Il y a un fossé stratégique entre les éditeurs historiques (OpenAI, Anthropic, Google) et les pure players de l’inférence (comme DeepInfra). Les éditeurs ont un intérêt vital à collecter la donnée pour entraîner et améliorer leurs futurs modèles. Pour un fournisseur d’inférence, la donnée n’a aucune valeur marchande ; son seul métier est de vendre de la puissance de calcul brute. Leur intérêt économique est de traiter le token le plus vite possible et de purger la mémoire pour optimiser leurs coûts.
Plus de 95 % des entreprises actuelles (petites ou grandes) confient déjà leurs données les plus critiques (comptabilité, CRM, RH, emails) à des tiers en mode SaaS (Salesforce, Google Workspace, Microsoft 365) dont les politiques de journalisation et de maintenance technique sont strictement identiques, voire plus permissives, que celles de DeepInfra. Blâmer l’API d’inférence reviendrait à rejeter l’intégralité du modèle cloud mondial.
Vous soulignez, à juste titre, que les grandes entreprises privilégient des acteurs comme AWS ou Azure pour leurs clauses contractuelles (SLA, conformité). C’est un fait, mais il relève davantage de l’inertie administrative que de la supériorité technique.
Azure ou AWS ne font pas tourner les modèles open-source différemment ou « mieux » qu’un DeepInfra. La différence majeure réside dans le fait qu’ils sont déjà référencés auprès des départements d’achats et juridiques des grands groupes.
Ces acteurs historiques profitent d’une situation de rente et déploient un discours marketing protecteur pour justifier des tarifs parfois prohibitifs. La concurrence montante des fournisseurs spécialisés propose une qualité d’exécution technique strictement équivalente, l’agilité et l’optimisation des coûts en plus.
Enfin, le local souffre d’un enfermement technologique. Choisir une infrastructure locale, c’est se lier à un hardware spécifique pour quelques modèles précis.
Les catalogues des fournisseurs d’inférence sont gigantesques et mis à jour en temps réel. Ils permettent de basculer instantanément d’un modèle ultra-optimisé pour le code à un modèle plus performant en logique agentique ou en rédaction. Cette agilité permet de couvrir des scopes fonctionnels bien plus larges sans jamais subir l’obsolescence rapide du matériel informatique.
Votre analyse a le mérite de rappeler la rigueur théorique indispensable à la gestion des données. Le local reste le sanctuaire absolu pour les données d’État ou le secret défense.
Cependant, pour l’immense majorité des projets professionnels, l’arbitrage penche définitivement en faveur de l’API. Les économies d’échelle réalisées par les géants de l’inférence (batching de prompts, optimisation électrique, mutualisation du matériel) rendent le coût au token imbattable, tandis que l’architecture moderne en réseau résout nativement les problèmes de disponibilité que le local ne pourra, pour l’instant, combler à un coût raisonnable. Encore une fois, le local fait clairement partie de l’avenir mais pas au prix des machines actuelles.
Je suis jaloux, j’aimerais aussi une machine comme ça (plutôt AMD dans mon cas, du coup) 
Merci pour cet article et cette expérimentation. Je suis personnellement persuadé que l’avenir de l’usage quotidien passera de plus en plus par le local, sans pour autant remplacer le cloud. Pour moi, la vraie ligne de partage, c’est : le local pour la souveraineté et le quotidien, et le cloud (les modèles flagship) pour les travaux d’envergure - ceux qu’un utilisateur moyen, et même une entreprise, ne réalise pas tous les jours.
On est évidemment bloqués pour l’instant par la crise de la RAM, qui va avoir un effet ralentisseur sur l’adoption. L’avantage, dans ce malheur, c’est que le jour où la RAM redeviendra accessible, ces machines verront leur prix divisé par trois, avec en prime des CPU plus performants. C’est justement pour ça qu’acheter maintenant n’a pas vraiment de sens.
Mon seul bémol sur le sujet, c’est que 128 Go de RAM reste encore un peu juste pour gérer dans la durée un serveur type OpenClaw. Je pense qu’il faudrait viser 256 Go pour être vraiment à l’aise sur le long terme et l’expérimentation (on est encore largement sur une période « early adopter »).
Mais avec ce genre de machine, vous faites tourner Ollama, et d’ici quelques mois, avec des modèles Mixture of Experts (MoE) fiables, vous pourrez faire tourner des MoE de plus de 200 milliards de paramètres confortablement. Et dans quelques années, ce type de machine sera très probablement largement exploitable, puisque les modèles seront toujours plus performants et moins coûteux.
Excellent article 
J’ai aussi un ASUS Ascent GX10 et j’arrivais aux mêmes conclusions, qui poura part me devait au niveau de la vitesse d’inférence… Jusqu’à ce que je découvre Atlas Inference!
Je rempile maintenant Gemma et Qwen3.6-35B à 130 tokens / seconde et Qwen3.5-122B à 70 tokens / seconde… Ça change le GB10 du tout au tout!