Residenz ist ein Filter, niemals eine Präferenz
Veröffentlicht
Residenz ist der Grund, warum es dieses Projekt gibt, und damit auch die Stelle, an der eine kleine Bequemlichkeit zu einem großen Problem wird. Eine Anfrage führt einen Regionsfilter mit. Jedes Kandidatengerät wird dagegen geprüft. Was passiert, wenn nichts diesen Filter erfüllt, ist das eigentliche Design, und die Antwort lautet: Es wird nichts eingeplant.
Ein Filter und eine Präferenz sind verschiedene Produkte
Eine Präferenz würde passende Geräte zuerst ordnen und erst dann auf andere zurückgreifen, wenn keines passt. Ein Filter gibt stattdessen eine Verweigerung zurück. Die Folge ist sichtbar und langweilig, und genau das ist beabsichtigt: Erfüllt kein Gerät die Anfrage, gibt es einen ausdrücklichen Fehler, und nirgends wird Arbeit ausgeführt. Der Versandpfad kann die Suche nicht ausweiten, weil es keinen Zweig gibt, der sie ausweitet.
Jede Verweigerung hat einen Namen
Der Vertrag definiert eine Union von Policy-Verweigerungen, und eine Ablehnung nennt immer eine davon. Es gibt keine Verweigerung ohne Code, und genau das macht eine Prüfung möglich: Man kann lesen, welche Regel einen Job gestoppt hat.
- no_candidate_for_policy: Kein Gerät erfüllt die Anfrage überhaupt. Das ist der Fall, in dem der Filter niemals aufgeweicht wird.
- model_not_held: Geräte existieren, aber keines hält das Modell bereits. Ein Job, der einen Download bräuchte, wird nicht eingeplant.
- insufficient_memory: Kein Kandidat erreicht die Speicheruntergrenze, die das Modell braucht – ein hartes Filterkriterium, keine Punktzahl.
- no_matching_accelerator: Kein Kandidat meldet einen Beschleuniger, auf dem das Modell laufen kann.
- region_not_permitted: Der Regionsfilter schließt jeden Kandidaten aus.
- epoch_stale: Der Capability-Anspruch des Kandidaten wurde durch eine neuere Epoche entzogen.
- device_over_daily_ceiling: Der Kandidat hat seine tägliche Verdienstobergrenze erreicht.
Die Region ist eine Jurisdiktion, und eine ungewählte Region ist eine Falschaussage
Weil eine Region ein Residenzanspruch ist und kein Routing-Hinweis, verlangt die Capability-Prüfung einen zweibuchstabigen Ländercode nach ISO 3166-1 alpha-2 und verweigert alles andere mit einem 400 region_invalid. Das Backend-Label dev-mock ist kein Land; ein Gerät mit dieser Angabe kann sich also gar nicht registrieren.
Der Headless-Contributor verlangt, dass seine Region gesetzt ist. Es gibt keinen Standardwert: Ohne Angabe verweigert er den Start und beendet sich, bevor er einen einzigen Netzwerkaufruf macht. Ein fehlerhafter Wert wie dev-mock wird genauso verweigert. Der frühere Standardwert war der interessante Defekt: Eine Maschine in Frankreich, Polen oder anderswo konnte auf dem Versandpfad deutsche Residenz behaupten, während ein Kommentar daneben das Gegenteil behauptete. Gefunden wurde das durch den Betrieb des zusammengesetzten Produkts und nicht durch einen Unit-Test; belegt ist die Korrektur durch eine Prüfung, die HTTP-Aufrufe zählt und null findet, nicht bloß durch einen Exit-Code.
Bei Residenz geht es darum, welches Recht Offenlegung erzwingen kann
Eine weitere Unterscheidung verhindert, dass die Regel als Leistungseinstellung gelesen wird. Der Sinn von EU-Residenz ist, welches Recht Offenlegung erzwingen kann, nicht wo ein Rechenzentrum zufällig steht. Eine Region in Frankfurt, betrieben von einem Unternehmen mit Sitz anderswo, bleibt nach dem Recht dieses Landes erreichbar, während ein in der EU ansässiger Anbieter so nicht erreicht wird. Das ist als Tatsache über Jurisdiktion formuliert und nicht als Urteil über einen Anbieter.
Dieselbe Referenz macht die Residenzfrage marktspezifisch. Für Nutzer im Vereinigten Königreich unterscheidet sich die Angemessenheitslage von der in der EU. Residenzentscheidungen sollten also je Markt getroffen und nicht aus einer europäischen Adresse abgeleitet werden. Ein Filter, der stillschweigend jede europäische Region als eine Jurisdiktion behandelt, läge genau für die Nutzer falsch, bei denen es richtig sein muss.
Die Prüfung, auf die es hier ankommt
Der Abnahmetest startet den echten Koordinator, zwei echte Contributor-Prozesse und das Dashboard über HTTP und prüft, dass ein Gerät außerhalb der angefragten Regionen keinen Job erhält und keine Gutschrift fließt. Der Verweigerungscode ist der Code der Policy-Engine selbst und keine Zeichenkette, die für den Test geschrieben wurde.
Die ehrliche Grenze ist die, die dasselbe Dokument nennt: Das ist Durchsetzung über einem Mock-Backend. Es lief kein echtes Modell, belegt sind also die Routing-Entscheidung und die Geldbewegung, nicht dass ein konformes Gerät eine gute Antwort erzeugt hat.
Warum das als Regel festgehalten ist
Die Projektregeln nennen eine Residenz-Umgehung einen P0-Defekt, und diese Schwere ist bewusst gewählt. Ein stiller Rückfall sähe von außen nicht wie ein Fehler aus. Er sähe wie ein funktionierender Dienst aus, der eine Anfrage beantwortet hat, und genau deshalb darf er keine Laufzeitoption sein, die eine spätere Änderung still einschalten kann.
Wo sich das nachprüfen lässt
Der unten zitierte Leitfaden ist die Quelle, die die Zeilen der Modellregistry für jede hier wiederholte Modelltatsache nennen. Er ist nicht die Quelle der Routing-Entscheidungen selbst: Dieses Projekt dokumentiert sie in docs/01-architecture.md, docs/07-swarm-v1-spec.md, docs/08-credits-and-chain.md und data/models.mjs im Repository llmeuchain, das selbst gehostet wird und kein öffentliches Remote hat, auf das man verlinken könnte. Bis es veröffentlicht ist, gelten die internen Zahlen hier für Leser als unverified und nur gegen das Repository prüfbar.
Quellen
Jeder Link führt zu der Quelle, die der Beitrag nennt. Wo eine Quelle eine Angabe nicht hergibt, zeigt der Beitrag sie als unverified, statt sie zu füllen.