@OpenGradient Ich habe ein Routing-Szenario für OpenGradient getestet, als eine Anfrage immer wieder ihr Latenzziel verfehlte.

Der Scheduler wählte den nächstgelegenen Inferenzknoten. Auf dem Papier war das die offensichtliche Entscheidung. Nur war das Modell auf diesem Knoten nicht bereit.

Er begann, das Modell zu ziehen, während ein anderer Knoten, der etwas weiter weg war, bereits warm und größtenteils untätig war. Der kürzere Netzwerkpfad wurde zum langsameren Ausführungspfad.

Das war das erste Missverhältnis.

Ich hatte die Platzierung der Knoten wie ein geografisches Problem behandelt. Es ist näher an einem Koordinationsproblem mit Geografie darin. Entfernung ist wichtig, aber auch GPU-Kapazität, Druck in der Warteschlange, Modellzustand und ob der Backup-Knoten tatsächlich anders ausfällt als der primäre.
Die Karte sah verteilt aus. Der Abhängigkeitsgraph jedoch nicht.

Zwei Knoten in verschiedenen Städten können immer noch einen Cloud-Anbieter, einen Operator oder einen regionalen Netzwerkfehler teilen. Und die vollständigen Knoten sollten nicht unbedingt derselben Karte wie die Inferenzknoten folgen. Sie optimieren die Beweisübertragung und Unabhängigkeit bei Ausfällen, nicht nur die Antwortzeit für Benutzer. Datenknoten führen eine ganz andere Richtung ein, da die Nähe zur Quelle wichtiger sein kann als die Nähe zum Benutzer.

Facility-Standortmodelle helfen, diese Trade-offs sichtbar zu machen, aber ich bin mir über die Anreizschicht weniger sicher.

Der echte Test ist, wo die nächsten Knoten erscheinen – und ob sie die Verzögerungen und gemeinsamen Ausfälle reduzieren, die Benutzer tatsächlich spüren können.
#opg #OPG

$OPG Was ist am wichtigsten, wenn OpenGradient-Knoten global platziert werden?