J’ai eu une petite remise en perspective aujourd’hui.
Une requête d’inférence a échoué trois fois en moins d’une minute.
Ma première pensée a été : Le réseau doit être surchargé.
Puis j’ai ouvert le tableau de bord.
Beaucoup de nœuds étaient en ligne.
Alors j’ai commencé à creuser.
Un nœud n’avait pas le modèle dont j’avais besoin. Un autre n’avait aucune capacité disponible. Le troisième pouvait traiter la requête, mais ne pouvait pas fournir le chemin de vérification attendu par l’application.
Et c’est à ce moment-là que j’ai compris.
J’ai passé énormément de temps à analyser l’infrastructure en fonction des effectifs.
Plus d’opérateurs. Des chiffres plus grands. Un réseau plus sain.
Mais les utilisateurs ne vivent pas la comptabilité des nœuds.
Ils vivent des résultats.
Une requête fonctionne ou elle ne fonctionne pas.
Et soudain, la question n’est plus :
« Combien de nœuds sont en ligne ? »
Elle devient :
« Quelle est la probabilité que cette requête précise trouve le bon modèle, que le matériel soit disponible, que la latence soit acceptable et que le chemin de preuve soit valide, le tout au même moment ? »
C’est une manière entièrement différente de penser la résilience.
Je me demande même combien d’opérateurs « indépendants » sont réellement indépendants. Certains peuvent partager la même région cloud, des dépendances logicielles ou des raisons économiques de se mettre hors service quand les récompenses faiblissent.
C’est peut-être pour ça que j’ai cessé de traiter la participation comme un simple effectif.
Je surveille désormais des probabilités.
Parce que l’infrastructure ne se mesure pas au nombre d’opérateurs qui disent : « Je suis là. »
Elle se mesure au fait que la bonne capacité apparaisse exactement quand un utilisateur réel en a besoin.
Et je pense que les plus gros échecs des systèmes distribués viennent rarement du fait qu’il y a trop peu de nœuds.
Ils viennent de la découverte que tout le monde se tenait au même endroit
@OpenGradient #OPG $OPG
Une requête d’inférence a échoué trois fois en moins d’une minute.
Ma première pensée a été : Le réseau doit être surchargé.
Puis j’ai ouvert le tableau de bord.
Beaucoup de nœuds étaient en ligne.
Alors j’ai commencé à creuser.
Un nœud n’avait pas le modèle dont j’avais besoin. Un autre n’avait aucune capacité disponible. Le troisième pouvait traiter la requête, mais ne pouvait pas fournir le chemin de vérification attendu par l’application.
Et c’est à ce moment-là que j’ai compris.
J’ai passé énormément de temps à analyser l’infrastructure en fonction des effectifs.
Plus d’opérateurs. Des chiffres plus grands. Un réseau plus sain.
Mais les utilisateurs ne vivent pas la comptabilité des nœuds.
Ils vivent des résultats.
Une requête fonctionne ou elle ne fonctionne pas.
Et soudain, la question n’est plus :
« Combien de nœuds sont en ligne ? »
Elle devient :
« Quelle est la probabilité que cette requête précise trouve le bon modèle, que le matériel soit disponible, que la latence soit acceptable et que le chemin de preuve soit valide, le tout au même moment ? »
C’est une manière entièrement différente de penser la résilience.
Je me demande même combien d’opérateurs « indépendants » sont réellement indépendants. Certains peuvent partager la même région cloud, des dépendances logicielles ou des raisons économiques de se mettre hors service quand les récompenses faiblissent.
C’est peut-être pour ça que j’ai cessé de traiter la participation comme un simple effectif.
Je surveille désormais des probabilités.
Parce que l’infrastructure ne se mesure pas au nombre d’opérateurs qui disent : « Je suis là. »
Elle se mesure au fait que la bonne capacité apparaisse exactement quand un utilisateur réel en a besoin.
Et je pense que les plus gros échecs des systèmes distribués viennent rarement du fait qu’il y a trop peu de nœuds.
Ils viennent de la découverte que tout le monde se tenait au même endroit
@OpenGradient #OPG $OPG