@OpenGradient Der Knoten in Frankfurt war näher, also habe ich den nächsten OpenGradient-Inferenz-Batch dorthin gesendet.

Drei Anfragen überschritten die Retry-Grenze fast sofort.
Zuerst machte ich die Timeout-Einstellungen verantwortlich. Dann die Warteschlange. Für ein paar Minuten vermutete ich sogar, dass eine Modellveröffentlichung schlecht geladen wurde. Aber ein weiter entfernter Knoten lieferte weiterhin die gleiche Arbeitslast ohne Probleme.

Die Koordinaten waren korrekt. Die Entfernungsberechnung war hilfreich, aber nicht hilfreich genug.

Haversine zeigte den kürzeren geografischen Pfad. Es zeigte nicht, dass unser Verkehr in einen überlasteten Austausch einging, Carrier wechselte und dann an einer regionalen Routing-Grenze ins Stocken geriet. Die längere Route blieb auf einem Backbone und erreichte die Inferenz reibungslos.

Selbst das war nur die halbe Lösung.

Der Frankfurter Knoten nahm Anfragen schnell an, aber die Bestätigungs-Events für die Verifizierung trafen ungleichmäßig ein. So sah die Anwendung schnelle Inferenz gemischt mit verzögerten Vertrauenssignalen, und dann wurde Arbeit erneut ausgeführt, die tatsächlich nicht fehlgeschlagen war.

Das macht die Platzierung von OpenGradient-Knoten schwieriger, als Kapazität nahe an der Nachfrage zu platzieren. Ein geografisch naher Knoten kann dennoch mehr Warteschlangendruck erzeugen, doppelte Ausführung und Abrechnungsrauschen, wenn der gesamte Pfad instabil ist.

Ich behalte Haversine weiterhin im Platzierungsmodell. Es zu entfernen wäre eine Überreaktion.

Aber ich lasse es nicht mehr die finale Auswahl treffen.
#OPG #opg $OPG

Welches Metrik sollte die Auswahl des OpenGradient-Knotens steuern, wenn die Latenz unvorhersehbar wird?