Le dimanche, je suis allé parcourir mes favoris et j’ai vu une feuille de comparaison des concurrents sur les pistes « AI on-chain » que j’avais recopiée il y a environ un semestre. Le nombre de modèles affichés par chaque équipe variait : certains avaient deux chiffres, d’autres trois. J’ai ouvert, au passage, le panneau on-chain du @OpenGradient . Sur Model Hub, plus de 4 500 modèles sont déjà hébergés : plusieurs fois la somme de tous les projets figurant sur mon tableau de l’époque. Je n’ai pas tout de suite été impressionné ; je voulais comprendre si ce volume correspondait à une vraie capacité de charge ou s’il s’agissait simplement d’un tas de fichiers vides jamais appelés.
J’ai choisi une semaine de travail de cinq jours, puis j’ai extrait, depuis Model Hub, les modèles qui avaient été appelés ce jour-là selon quatre dimensions : le hash des poids, la répartition des nœuds hébergeurs, les journaux de planification du middleware de routage des capacités, et les accusés de réception de la Verification Layer. Chaque jour, j’ai tiré douze échantillons, soit soixante jeux de données ; à chaque fois, j’ai consigné dans un tableau l’heure de mise en ligne, la latence du premier appel et la signature de l’accusé, puis j’ai tout recoupé ligne par ligne. Résultat : assez net. Parmi plus de 4 500 modèles, une part significative avait eu du trafic réel sur la semaine écoulée ; la traîne longue pouvait aussi être « relancée » via le démarrage à froid.
Les discussions grand public portent sur le nombre de modèles hébergés, et l’essentiel se focalise sur les comparaisons de quantités. La différence réellement vérifiable chez OpenGradient est, elle, plus froide : le volume n’est pas une simple addition de compteurs d’upload. Chaque jeu de poids est découpé et stocké dans Walrus ; au moment de l’appel, le middleware de routage des capacités les recompose selon la disponibilité, puis la Verification Layer appose son sceau. Pour être « accroché », il faut attacher une capacité de stockage ; pour être « appelé », il faut laisser une trace dans l’accusé de réception. Le coût de chargement de données est plus élevé que le coût de faire le travail. Les 4 500 modèles, c’est un ensemble qui porte vraiment la charge — ce n’est pas juste une ligne dans un tableau.
Il faut aussi changer d’indicateurs. Je ne m’intéresse pas à combien de modèles OpenGradient a cumulativement « mis en ligne ». Je fixe plutôt un indicateur non consensuel : la proportion de modèles qui, au moins une fois par semaine, ont été relevés par un appel payant réel et ont laissé un accusé de réception via la Verification Layer. La première mesure évalue l’inscription dans la base ; la seconde mesure si cette couche d’hébergement est réellement utilisée par des développeurs.
Si le $OPG ne faisait que prendre une commission de mise en relation pour un appel de modèle, alors il ressemble davantage à un jeton de facturation d’appels. Mais si, à l’avenir, la capacité d’hébergement sert de garantie, que des incitations au démarrage à froid, la délivrance des accusés, la répartition des revenus sur la traîne longue et même les pénalités en cas de retrait des modèles « zombies » se construisent autour de lui en formant une boucle fermée, alors sa fonction n’est plus celle d’un simple jeton de facturation. Il devient une forme d’actif de crédit de capacité pour ce réseau d’hébergement de modèles.
Pas pressé de tirer des conclusions. L’avantage de volume doit être validé à répétition dans la traîne longue pour compter ; je suis prêt à continuer d’observer les échantillons que fournissent le réseau principal d’OpenGradient et les équipes qui y branchent leurs modèles ensuite.
#opg