Écrit par :@KSimback
Compilé par :AididiaoJP
Scénario hypothétique : que se passe-t-il si les modèles de pointe sont bloqués ?
Nous sommes en octobre 2026, dans seulement quatre mois. GLM-6 vient d'être publié, surpassant Fable-5.1 (version castrée et republiée du modèle interdit) dans les benchmarks principaux, et égalant les performances de Mythos. Le gouvernement américain ne peut pas le désactiver directement, alors il émet une série d'interdictions : interdiction pour tout fournisseur de proposer le modèle GLM-6, ses mises à jour, ses services d'inférence, son déploiement géré ou son support technique sur le territoire américain ou à des citoyens américains.
Amazon Bedrock, Google Vertex et Microsoft Azure se déclarent rapidement conformes, refusant d'héberger le modèle pour leurs clients entreprises. Les principales plateformes d'agrégation comme OpenRouter, Vercel, Cloudflare, TogetherAI acceptent également de ne pas le lister. GitHub supprime toutes les traces liées sur sa plateforme. Hugging Face, dernier bastion de résistance, finit par retirer tous les modèles liés à GLM-6 du téléchargement.
Ce scénario n'est pas le résultat idéal que nous souhaitons, mais dans un monde où les modèles d'IA progressent de façon exponentielle tandis que la politique avance à la vitesse d'un escargot, c'est une issue tout à fait plausible.
Ce résultat, ou un autre scénario où l'IA de pointe reste monopolisée par quelques entités centralisées, est précisément la raison fondamentale pour laquelle l'IA décentralisée est si importante.
Cet article est le compagnon du guide d'introduction précédent de l'auteur, « Proof of Useful Work », adoptant la même approche pragmatique et se concentrant sur un autre angle clé du crypto-AI (les deux se chevauchent en partie). L'auteur décompose en profondeur les défis que l'IA décentralisée doit résoudre, les projets suivis, le cadre d'analyse, et son jugement personnel après une recherche approfondie.
Pourquoi l'inférence décentralisée est-elle inévitable ?
Suite au scénario ci-dessus, vous avez probablement déjà pensé à l'inférence décentralisée. Sinon, poursuivons le raisonnement.
Une fois les poids du modèle GLM-6 publiés, des copies se répandront instantanément sur Internet – aucune interdiction ou mesure corrective ne pourra éliminer les milliers de copies déjà existantes. Ces copies seront servies sur des réseaux d'inférence décentralisés, car il n'y existe aucune autorité centrale pouvant agir contre elles, et aucune interdiction d'un seul nœud ne peut paralyser l'ensemble du réseau.
Je tiens à être clair : je ne discute pas de savoir si c'est une bonne ou une mauvaise chose. Si un nouveau modèle open-weight est publié et pourrait causer des dommages graves par abus, je ne recommanderais jamais de rester les bras croisés. Mon point est : les modèles finiront inévitablement entre les mains de ceux qui ne veulent pas être censurés.
C'est la prémisse centrale de l'inférence décentralisée – c'est une couverture contre la censure institutionnelle, qu'elle vienne des gouvernements ou des laboratoires de pointe. D'autres arguments, comme des tokens moins chers, une inférence vérifiable, la protection de la vie privée, etc., sont secondaires. Le pari central n'est qu'un : atténuer le risque de censure.
L'inférence décentralisée est vraiment difficile, quatre défis majeurs se présentent
Pour la plupart des startups, résoudre un ou deux problèmes difficiles est déjà un énorme défi. Les projets d'inférence décentralisée doivent relever simultanément quatre défis véritablement épineux. La façon dont chaque projet les aborde est précisément ce qui distingue la substance du battage médiatique, l'alpha du bruit.
Défi 1 : Exécuter des modèles qui ne tiennent pas sur une seule machine
L'idée centrale est de créer un essaim (swarm) de GPU, utilisant le parallélisme par pipeline (pipeline parallelism) pour servir les modèles que les utilisateurs veulent vraiment. En bref, chaque nœud ne détient qu'une petite tranche des poids du modèle, et son propre morceau du KV-cache, des tranches suffisamment petites pour tenir sur des GPU grand public 3090/4090, voire des H100 de plus haute spécification. Combiner suffisamment de nœuds permet d'héberger des modèles massifs comme GLM.
Petals a prouvé la faisabilité de cette approche dès 2022 avec BLOOM-176B sur des GPU grand public dans un essaim de style BitTorrent, mais à une vitesse d'environ 1 token par seconde. Cette vitesse était évidemment inutilisable, donc l'innovation ultérieure s'est concentrée sur la façon d'accélérer l'exécution du modèle.
Le goulet d'étranglement réellement fatal est le réseau. Dans un centre de données, les GPU communiquent via NVLink à des vitesses de téraoctets par seconde ; sur l'Internet public, la latence aller-retour (RTT) atteint des dizaines de millisecondes. Le processus de décodage est séquentiel, un essaim naïf paie le coût d'un aller-retour réseau pour chaque token généré.
La solution la plus courante est le décodage spéculatif (speculative decoding) : un petit modèle draft bon marché propose d'abord K tokens candidats, puis le modèle massif et partagé (sharded) vérifie ces K tokens en une seule passe de pipeline, conservant la plus longue séquence correspondante. Ainsi, un passage réseau coûteux rapporte plusieurs tokens, pas un seul.
Des niveaux d'environ 30-40 tokens par seconde ont déjà été atteints sur de vraies liaisons Internet, un progrès significatif, mais cela n'est pas encore pleinement validé à grande échelle et aux vitesses réellement nécessaires pour les utilisateurs. C'est un défi nécessitant de véritables compétences d'ingénierie.
Note : Servir l'inférence va bien au-delà de l'assemblage de FLOPs
Il y a un piège courant lorsqu'on compare toute méthode d'essaim à un modèle hébergé dans le cloud : les gens ne regardent que les tokens par seconde, pensant que c'est tout.
Mais l'inférence de niveau production doit bien faire beaucoup de choses, indépendantes de la puissance de calcul brute :
- Équilibre entre le temps du premier token (TTFT) et la latence inter-token
- Deux phases : préremplissage (prefill) et décodage (decode) (exigences matérielles totalement opposées)
- Placement et transmission du KV-cache
- Diffusion en continu (streaming), traitement par lots continu (continuous batching) et taux d'utilisation sous charge mixte
- Comportement en contexte long, démarrage à froid et préchauffage du modèle
- Fluctuation des nœuds (churn)
Point d'analyse : lorsqu'un projet cite des chiffres de débit, demandez toujours à quoi il se compare. Les déploiements centralisés de vLLM ou SGLang (utilisant un préremplissage dissocié et un traitement par lots continu) sont le véritable benchmark, et ce benchmark s'accélère chaque trimestre. « Nous atteignons 30 tokens par seconde sur Internet » semble impressionnant, mais peut encore manquer de compétitivité.
Défi 2 : Prouver que vous avez réellement obtenu le modèle pour lequel vous avez payé
Si vous ne faites pas confiance aux nœuds, comment savoir qu'ils exécutent réellement le modèle annoncé, et n'ont pas secrètement basculé vers une version quantifiée moins chère ? Surtout dans un réseau impliquant des tokens minés, les fournisseurs pourraient facilement « jouer au jeu », semblant servir le vrai modèle mais exécutant en réalité quelque chose de moins cher.
Il existe actuellement cinq principales approches :
- ZKML : Preuve à divulgation nulle de la passe avant. Solide cryptographiquement, mais avec un surcoût d'environ 10 000x par rapport au natif. Générer un token pour un modèle Llama-3 prendrait environ 150 secondes. Impossible à court terme à l'échelle de pointe.
- opML : La sortie est accompagnée d'un dépôt de garantie, ouvrant une fenêtre de contestation, avec résolution des litiges par preuve de fraude (fraud-proof) binaire en une étape, réexécutée par un arbitre. Vitesse quasi-native, mais la finalité nécessite d'attendre la fenêtre, et il y a un « dilemme du vérificateur » (si le coût de vérification dépasse la valeur de détection de la triche, personne ne vérifie).
- Ré-exécution déterministe : Rendre l'inférence reproductible au niveau des octets, les litiges ne vérifiant que l'égalité des octets. Surcharge inférieure à 2%, garantie par de l'ETH re-staké.
- Empreintes statistiques : Hachage ou échantillonnage de calcul peu coûteux, attrapant la plupart des tricheries la plupart du temps. Pas absolument correct, mais rapide et adapté aux GPU hétérogènes, nécessaire pour un essaim sans permission.
- Preuves de poids en direct (Live-weight proofs) : Échantillonnage direct des tenseurs réellement présents pendant l'exécution du service, comparé à un manifeste du modèle approuvé. Vérifie « ce qui est chargé », pas « ce qui est produit », surcoût d'environ 0.1%. C'est une approche vraiment différente.
Le compromis réel est : vous ne pouvez obtenir que deux des trois suivants simultanément – intégrité cryptographique, faible latence, efficacité des coûts. ZKML obtient l'intégrité, mais sacrifie latence et coût ; les autres méthodes obtiennent latence et coût, mais ne peuvent satisfaire qu'une intégrité économique ou statistique.
Point d'analyse : Demandez quelle méthode un projet utilise, pourquoi, et l'impact de ce compromis sur le produit final.
Défi 3 : Comment rendre le prompt véritablement confidentiel ?
Prouver que la sortie est correcte est un problème complètement différent de cacher l'entrée. Dans un essaim partagé (sharded), chaque nœud doit décrypter les activations pour calculer – le chiffrement protège uniquement la ligne de transmission, pas le nœud lui-même.
Les activations d'un Transformer sont en réalité très faciles à reconstruire à rebours. Un article CCS 2025 a montré une précision de reconstruction du prompt d'entrée à partir des activations intermédiaires dépassant 90%. L'article « Hidden No More » d'ICML 2025 a atteint une récupération quasi parfaite et a battu les défenses courantes de bruit-et-permutation utilisées dans les essaims.
La seule solution de réparation robuste actuelle est un schéma de séquence-partagée (sequence-sharded) plus lourd, que personne dans le camp des GPU grand public n'a vraiment déployé, donc cela reste un problème largement non résolu.
Un essaim peut prétendre « aucun nœud ne détient le modèle entier », mais il divulguera toujours chaque prompt à n'importe quel nœud sur le chemin. « Aucun nœud ne détient le modèle » n'a jamais été un attribut de confidentialité.
Ce qui peut réellement fournir de la confidentialité, ce sont le matériel ou les mathématiques, pas la topologie du réseau. Les TEE (environnements d'exécution de confiance) – comme la solution de Phala sur GPU, celle de Darkbloom sur Apple silicon, le mode Pro de Venice – déplacent la confiance vers une racine matérielle et utilisent l'attestation.
Le chiffrement entièrement homomorphe (FHE) peut calculer directement sur du texte chiffré, ne faisant confiance à rien, mais son coût est actuellement prohibitif pour les grands modèles.
Point d'analyse : Un projet a soit vraiment l'une de ces solutions, soit n'a pas de confidentialité, peu importe comment la page d'accueil l'emballe.
Rappel important : Privé n'est pas égal à sans confiance (trustless). Les TEE n'éliminent pas la confiance, ils la transfèrent simplement des opérateurs de nœuds aux fabricants de matériel, à la chaîne de micrologiciels, aux services d'attestation et à l'implémentation de l'enclave.
La vraie question est : À qui acceptez-vous de faire confiance comme racine ? Le fabricant de puces ? L'ensemble des validateurs re-stakés ? Le réseau TEE ? Ou les mathématiques pures ?
Défi 4 : Comment construire un véritable marché bilatéral ?
Les trois premiers sont des défis techniques, le quatrième est un défi commercial.
Pour un réseau d'inférence décentralisé servant des modèles open-weight, qui est le client idéal (ICP) ?
La plupart des consommateurs ordinaires tirent actuellement une énorme valeur des plans d'abonnement – 20-200 $ par mois pour beaucoup d'intelligence. Ces plans subventionnés pourraient disparaître ou être limités à l'avenir, mais aujourd'hui, vendre de l'inférence à la demande via API est très difficile à vendre côté consommateur.
Les entreprises ne seront pas non plus de gros acheteurs à court terme. Peut-être que cela changera, mais ne comptez pas là-dessus rapidement.
Les deux catégories d'utilisateurs restantes sont : 1) les startups et entreprises intégrant l'inférence dans leur pile produit, qui ont naturellement besoin de plans API ; 2) les agents IA autonomes cherchant leur propre capacité d'inférence.
La catégorie startup est un marché en croissance, une niche où il est possible de capter des revenus significatifs, mais avec un plafond de capture de valeur évident à court terme. Les agents IA en tant qu'acheteurs sont plus spéculatifs – à court terme, quelqu'un doit encore les payer.
C'est là le défi : comment agréger une offre significative des modèles que les gens veulent vraiment, alors que le groupe d'utilisateurs cible a peu de chances d'être un gros dépensier sur le réseau ?
Le seul endroit actuellement viable est celui des fournisseurs de GPU décentralisés. Des projets comme io.net, Akash, Render, Aethir, Nosana font cela depuis des années, louant via un marché coordonné par token des GPU entiers ou la capacité d'un modèle entier par nœud à des payeurs. Il y a un précédent.
Point d'analyse : Demandez quel est l'ICP du projet, et comment ils capturent simultanément les utilisateurs cibles et satisfont le côté offre. Si tout repose sur l'attente spéculative d'une hausse du token, c'est un signal clair.
Qui résout vraiment ces défis ? Tour d'horizon des projets principaux
De nombreux projets sont actuellement classés dans la catégorie « inférence décentralisée », mais la plupart ne résolvent pas les quatre défis de manière égale, chacun ayant son accent.
Petals : Le pionnier absolu de l'inférence décentralisée. A prouvé en 2022 que BLOOM-176B pouvait fonctionner sur des GPU grand public dans un essaim de style BitTorrent, significatif conceptuellement, mais n'a pas résolu les problèmes d'incitation, de confidentialité et de monétisation. Les projets qui sont essentiellement « l'architecture Petals + un token » sont probablement du larp.
Dolphin Network : L'équipe derrière la série de modèles ouverts non censurés Dolphin (plus de 5 millions de téléchargements sur Hugging Face). L'origine est un besoin utilisateur réel, puis l'emballage en réseau. Point fort technique : preuves de poids en direct (surcharge 0.1%), superposées avec des empreintes logprob, des contrôles d'intégrité logicielle et du bonding au niveau du compte. Plus de 3.2 milliards de tokens générés, bande passante soutenue d'environ 9400 t/s, représentant une exécution forte axée sur le produit.
Inference.net (anciennement Kuzco) : L'une des tentatives les plus matures de validation de modèles « sauvages ». Le mécanisme unique LOGIC capture le remplacement de modèle via des tests statistiques logprob, en production depuis environ 18 mois, flotte de milliers de GPU, un des rares projets ayant à la fois une primitive de validation et un historique opérationnel réel.
Morpheus : Couche de routage et de récompense décentralisée, fournissant une API compatible OpenAI + un wrapper d'agent intelligent. Point fort technique : validation des fournisseurs supportée par TEE (Intel TDX + attestation GPU NVIDIA déjà en ligne). À surveiller : les émissions de MOR et les preuves de demande externe réelle.
Chutes (sous-réseau 64 de Bittensor) : Côté utilisateur, une API compatible OpenAI ; backend, des déploiements chute empaquetés dans Docker vers les mineurs GPU de Bittensor. Avantages évidents en distribution et échelle, mais des lacunes subsistent en vérification et confidentialité.
c0mpute : Nouveau projet natif de Solana, le moteur Shard répartit les modèles de pointe sur des GPU grand public. Démonstrations réelles déjà publiques pour GLM-5.2 744B et gpt-oss-120B (30-40 t/s). Artefact technique vérifiable, mais encore très tôt (dépôt en ligne depuis quelques jours, fondateurs anonymes, token à micro-capitalisation pump.fun).
Parallax (Gradient Network) : Framework d'inférence LLM distribué P2P, supportant le partage par pipeline parallèle sur des GPU grand public et Apple Silicon, permettant aux individus ou petites organisations d'exécuter des « clusters souverains ». Parrainage institutionnel solide (levée de 10M$ en seed par Pantera et Multicoin), mais la solution de confidentialité n'est pas claire.
Darkbloom : Permet aux utilisateurs de transformer la puissance de calcul inutilisée de leur Mac en un marché d'inférence privé. Chaque Mac exécute le modèle entier, la confidentialité assurée par l'attestation Secure Enclave. Ne suit pas la voie de l'essaim partagé, pile d'attestation rigoureuse. Passée de la préversion de recherche à l'alpha public, la traction réelle mérite d'être surveillée (la décentralisation ne nécessite pas forcément un token).
MeshLLM : Maillage d'inférence P2P sans permission construit par une équipe liée à Jack Dorsey / Block. Découverte de nœuds basée sur Nostr, pas de serveur central, plus proche de BitTorrent que de Bittensor. Protocole d'abord, pas de token, anticensure.
Venice et son écosystème de revente : Un exemple dans tout le domaine pour trouver le PMF et un modèle commercial viable. Lui-même est un proxy consommateur centralisé mais à confidentialité stratifiée, ayant effectivement résolu certains défis. Autour de lui s'est formé un sous-écosystème de revendeurs comme UsePod, AntSeed, Surplus Intelligence, faisant principalement de l'agrégation de demande et du règlement, pas de la fourniture directe de puissance de calcul décentralisée.
Le terrain décisif de l'inférence décentralisée
L'avantage de coût n'existe que si l'on considère séparément la latence et le débit. Ce sont deux produits différents, la décentralisation est une taxe pour l'un, une caractéristique pour l'autre.
Scénarios où la centralisation gagne clairement (la décentralisation est une taxe) : Chat interactif de type ChatGPT, agent de codage en temps réel, voix à faible latence, appels d'outils à haute fréquence, SLA de latence p95 stricte pour les entreprises, service de latence compétitif pour les modèles de pointe denses.
Scénarios où la décentralisation peut gagner (avantage d'agrégation de l'offre) : Génération de données synthétiques, évaluation hors ligne, embeddings par lots, RAG par lots, tâches de recherche d'agents à long terme, file d'attente de génération d'images/vidéos, inférence de modèles ouverts non urgente (coût marginal du matériel inactif proche de zéro).
Cadre simple : Quand la latence est importante, la décentralisation est une taxe ; quand le débit est important, la décentralisation peut devenir un avantage d'agrégation de l'offre.
Valeur à long terme cachée : La boucle de données
Les réseaux d'inférence décentralisés peuvent également collecter des données précieuses en grande quantité – données d'entraînement synthétiques, données de préférence, traces d'agents, sorties d'évaluation, données de fine-tuning, environnements de RL, traces d'utilisation d'outils, etc. Ces données peuvent nourrir les réseaux d'entraînement décentralisés (comme les projets de style Nous Psyche, Prime Intellect, Gensyn), produisant des modèles open-weight mis à jour, qui reviennent ensuite dans le réseau d'inférence.
À long terme, ce n'est pas un pari séparé sur « l'entraînement décentralisé » ou « l'inférence décentralisée », mais une boucle fermée : L'inférence génère des traces → Les traces deviennent des données d'entraînement → L'entraînement met à jour le modèle → Le modèle mis à jour retourne à l'inférence.
Les meilleurs projets feront de cette boucle une stratégie centrale, et les projets d'entraînement et d'inférence convergeront davantage à l'avenir.
Liste d'analyse pratique : Répondez simplement à ces sept questions
- Est-il véritablement décentralisé ? Concrètement à quels niveaux ? (Beaucoup ont juste une étiquette parce qu'ils ont un token)
- Pouvez-vous faire confiance que la sortie provient du modèle pour lequel vous avez payé ? (Déterministe, preuve, empreinte, ou rien du tout)
- Après déduction des coûts des tokens et de la coordination, est-il vraiment moins cher que la centralisation ? (En production, pas en théorie)
- Le prompt est-il véritablement caché à l'opérateur ? (Seuls TEE/FHE comptent, le simple partage ne compte pas)
- Le système fonctionne-t-il de manière stable lorsque les nœuds sont peu fiables, dispersés sur Internet ?
- Y a-t-il vraiment des gens qui paient, et pour quelque chose qu'ils ne pourraient pas obtenir moins cher de manière centralisée ?
- L'équipe possède-t-elle de véritables compétences techniques en IA ? (La plus importante)
Conseil supplémentaire : Méfiez-vous des « solutions techniques élégantes » sans plan de distribution crédible.
Mon jugement final
Je suis globalement sceptique envers les catégories qui n'attirent que les natifs du crypto (le TAM me semble d'un attrait limité). Je préférerais voir des projets attrayants pour les utilisateurs non-crypto, avec les mécanismes crypto cachés en arrière-plan.
L'inférence décentralisée est l'un des rares secteurs du crypto ayant un véritable potentiel de percée – tout le monde a besoin d'inférence, elle peut être servie comme un fournisseur traditionnel, même de manière transparente via des plateformes comme OpenRouter. La clé réside dans le coût, les performances et la confidentialité.
Conseil : Soutenez les projets qui peuvent expliquer clairement quelle couche ils décentralisent, et savent clairement qui sont leurs acheteurs. Éloignez-vous des projets qui utilisent simplement « IA décentralisée » comme slogan, suivi d'une pièce.
Divulgation : L'auteur original détient des tokens de certains projets mentionnés, n'est influencé ou compensé par aucun projet, les jugements sont des opinions personnelles.
