@OpenGradient Die erste Warnung tauchte auf, als wir gerade ein großes Modell hochgeladen haben.

Ein Knoten hörte auf zu antworten. Der Client versuchte es erneut, und dann rutschte die Fortschrittsanzeige so weit zurück, dass ich anfing, den Netzwerkverkehr anstelle des Uploads zu beobachten.

Ich hatte angenommen, dass der schwierige Teil die Speicherung des Modells war.

Das war es nicht. Der erneute Versuch offenbarte ein anderes Problem: wie oft die gleichen Gigabytes bewegt werden müssen, bevor das Modell irgendwo anders nutzbar wird.

Hier kommt Walrus für OpenGradient ins Spiel, jedoch nicht auf die saubere Weise, wie es Speicherdiagramme normalerweise suggerieren. Validatoren müssen das vollständige Grundmodell nicht mit sich führen, nur um zuzustimmen, dass es existiert. Die Kette behält einen kompakten Verweis. Walrus übernimmt das schwerere Objekt.

Dennoch entfernt eine Blob-ID nicht die Distanz.

Ein Inferenzknoten muss möglicherweise das Modell abrufen, verifizieren, es in den Speicher laden und dann entscheiden, ob es den Platz wert ist, es in der Nähe zu behalten. Ein populäres Modell wird langsam zur lokalen Infrastruktur. Ein selten verwendetes bleibt kalt und wartet darauf, wieder ein Bandbreitenproblem zu werden.

Ich komme immer wieder auf die Caching-Entscheidung zurück.

Zu wenig speichern und die Latenz tritt während Nachfragespitzen auf. Zu viel speichern und die Betreiber schaffen die Speicherlast neu, die die Architektur zu vermeiden versuchte.

Der Upload wurde schließlich abgeschlossen.

Was ich immer noch nicht weiß, ist, wie dasselbe System reagiert, wenn fünf kalte Knoten gleichzeitig dieses Modell anfordern.#OPG #opg

$OPG

Was wird entscheiden, ob Walrus die OpenGradient-Modelle während gleichzeitiger Kaltstartanforderungen skalieren kann?