Ich hatte heute einen kleinen Realitätscheck.
Eine Inferenzanfrage ist dreimal innerhalb von weniger als einer Minute fehlgeschlagen.
Mein erster Gedanke war: Das Netzwerk muss überlastet sein.
Dann habe ich das Dashboard geöffnet.
Viele Nodes waren online.
Also bin ich auf die Suche gegangen.
Ein Node hatte nicht das Modell, das ich brauchte. Ein anderer hatte keine freie Kapazität. Ein dritter konnte die Anfrage verarbeiten, aber nicht den Verifikationspfad bereitstellen, den die Anwendung erwartete.
In dem Moment hat es klickgemacht.
Ich habe sehr viel Zeit damit verbracht, Infrastruktur anhand von Kopfzahlen zu betrachten.
Mehr Operatoren. Größere Zahlen. Gesünderes Netzwerk.
Aber Nutzer erleben keine Node-Anzahlen.
Sie erleben Ergebnisse.
Eine Anfrage funktioniert entweder – oder sie funktioniert nicht.
Und plötzlich ist die Frage nicht mehr:
„Wie viele Nodes sind online?“
Sondern:
„Wie hoch ist die Wahrscheinlichkeit, dass genau diese Anfrage im selben Moment das richtige Modell findet, die passende Hardware verfügbar ist, die Latenz akzeptabel ist und der gültige Beweisweg verfügbar ist?“
Das ist eine völlig andere Art, über Resilienz nachzudenken.
Ich habe sogar angefangen zu überlegen, wie viele „unabhängige“ Operatoren wirklich unabhängig sind. Einige teilen möglicherweise dieselbe Cloud-Region, Software-Abhängigkeiten oder ökonomische Gründe, um abzuschalten, wenn sich die Belohnungen abschwächen.
Vielleicht ist das der Grund, warum ich die Teilnahme nicht mehr als Kopfzahl behandle.
Ich beobachte jetzt Wahrscheinlichkeiten.
Denn Infrastruktur wird nicht danach gemessen, wie viele Operatoren sagen: „Ich bin da.“
Sie wird danach gemessen, ob die richtige Fähigkeit genau dann auftaucht, wenn ein echter Nutzer sie braucht.
Und ich glaube, die größten Ausfälle in verteilten Systemen entstehen selten dadurch, dass es zu wenige Nodes gibt.
Sie entstehen dadurch, dass man entdeckt, dass alle an derselben Stelle standen
@OpenGradient #OPG $OPG
Eine Inferenzanfrage ist dreimal innerhalb von weniger als einer Minute fehlgeschlagen.
Mein erster Gedanke war: Das Netzwerk muss überlastet sein.
Dann habe ich das Dashboard geöffnet.
Viele Nodes waren online.
Also bin ich auf die Suche gegangen.
Ein Node hatte nicht das Modell, das ich brauchte. Ein anderer hatte keine freie Kapazität. Ein dritter konnte die Anfrage verarbeiten, aber nicht den Verifikationspfad bereitstellen, den die Anwendung erwartete.
In dem Moment hat es klickgemacht.
Ich habe sehr viel Zeit damit verbracht, Infrastruktur anhand von Kopfzahlen zu betrachten.
Mehr Operatoren. Größere Zahlen. Gesünderes Netzwerk.
Aber Nutzer erleben keine Node-Anzahlen.
Sie erleben Ergebnisse.
Eine Anfrage funktioniert entweder – oder sie funktioniert nicht.
Und plötzlich ist die Frage nicht mehr:
„Wie viele Nodes sind online?“
Sondern:
„Wie hoch ist die Wahrscheinlichkeit, dass genau diese Anfrage im selben Moment das richtige Modell findet, die passende Hardware verfügbar ist, die Latenz akzeptabel ist und der gültige Beweisweg verfügbar ist?“
Das ist eine völlig andere Art, über Resilienz nachzudenken.
Ich habe sogar angefangen zu überlegen, wie viele „unabhängige“ Operatoren wirklich unabhängig sind. Einige teilen möglicherweise dieselbe Cloud-Region, Software-Abhängigkeiten oder ökonomische Gründe, um abzuschalten, wenn sich die Belohnungen abschwächen.
Vielleicht ist das der Grund, warum ich die Teilnahme nicht mehr als Kopfzahl behandle.
Ich beobachte jetzt Wahrscheinlichkeiten.
Denn Infrastruktur wird nicht danach gemessen, wie viele Operatoren sagen: „Ich bin da.“
Sie wird danach gemessen, ob die richtige Fähigkeit genau dann auftaucht, wenn ein echter Nutzer sie braucht.
Und ich glaube, die größten Ausfälle in verteilten Systemen entstehen selten dadurch, dass es zu wenige Nodes gibt.
Sie entstehen dadurch, dass man entdeckt, dass alle an derselben Stelle standen
@OpenGradient #OPG $OPG