Was „das Backend ist ein Mock“ hier bedeutet
Veröffentlicht
Jedes Projekt, das sich keine GPU leisten kann, kennt den Moment, in dem es in Versuchung gerät, die Demo wie das Produkt aussehen zu lassen. Dieses hat stattdessen eine Regel aufgeschrieben: Täusche niemals einen Lauf vor. Das Backend ist ein Mock, und der Mock muss es im Banner, in den maschinenlesbaren Metadaten jeder Antwort und im Ausgabetext jedes Ergebnisses sagen.
Der Mock muss durch das echte Gate
Es gibt einen offensichtlich billigen Weg, einen Mock zu bauen: eine leicht routingfähige Modell-ID erfinden und die Policy-Engine nie berühren. Das wurde verworfen. Der Mock läuft unter einer echten, zulässigen Modell-ID aus der Registry, sodass die Planungsentscheidung, die er ausübt, die echte ist. Die ID ist eine Routing-Kennung und sonst nichts: Sie ist kein Beleg dafür, dass ein Modell geladen wurde, und das Projekt sagt das im selben Satz, in dem es die ID nennt.
Damit bleiben zwei benannte Defekte statt eines. Eine Registry-Zeile für einen Mock zu erfinden ist ein Defekt, und ein Modell anzukündigen, das die Policy nicht routen kann, ebenfalls. Ein Konfigurationswert, der ein nicht zulässiges Modell nennt, wird beim Start laut verweigert – das einzige Verhalten, das verhindert, dass der Mock still etwas beweist, was das Produkt nicht kann.
Ein gekennzeichneter Fake auf jeder Ebene
Dieselbe Regel wiederholt sich überall dort, wo das Projekt sich selbst beschreibt. Das Architektur-Dokument kennzeichnet jede Komponente damit, was sie ist, und nicht damit, was sie sein wird: Koordinator und Worker-Runtime sind als implementiert markiert, und der Abrechnungspfad wird über echtes HTTP mit zwei Contributor-Prozessen ausgeübt – während dieselbe Seite festhält, dass nichts davon bedeutet, dass echte Inferenz lief, weil das einzige Backend der gekennzeichnete Mock ist. Die Statustabelle geht weiter und datiert ihre eigenen Zahlen: Die Gate-Ergebnisse wurden auf dem zusammengesetzten Baum durch Ausführen der Befehle gemessen, und das Mock-Label erscheint im Banner, in den Antwort-Metadaten und in jedem Ergebnistext.
Selbst der Mock hat eine Schnittstelle, die er nicht überschreiten darf. Einem Gerät darf nur ein Job für ein Modell angeboten werden, das es lokal bereits hält; ein Mock, der vorgäbe, ein Modell sei heruntergeladen worden, beschriebe also eine Warteschlange mit Zusatzschritten statt eines Schwarms. Die Ehrlichkeitsregel und die Planungsregel erweisen sich damit als dieselbe Regel an zwei Stellen.
Wie die Kennzeichnung von außen aussieht
- Das Backend heißt dev-mock im Banner, in den Antwort-Metadaten und im Ausgabetext, sodass es auch ein Leser sieht, der den Quellcode nie öffnet.
- Es ist ein Backend-Label und niemals eine Region. Die Capability-Prüfung verlangt einen zweibuchstabigen Ländercode; ein Gerät mit der Angabe dev-mock kann sich also gar nicht registrieren.
- Zwei Komponenten haben diesen Platzhalter als Region ausgeliefert, bevor es auffiel, und keine von beiden konnte sich registrieren. Die ehrliche Beschreibung dieses Fehlers ist, dass ein Mock-Label in ein Jurisdiktionsfeld gelangt ist, und die Korrektur war Validierung statt Dokumentation.
Was der Mock belegt hat und was nicht
Der Abnahmetest ist der Teil, der nicht veraltet. Er betreibt einen echten Koordinator, zwei echte Contributor-Prozesse und ein echtes Dashboard über Loopback-HTTP, ohne dass ein Test-Double das Produkt ersetzt, und er läuft auf dem zusammengesetzten Baum durch. Die Verkabelung ist damit ausgeübt: Registrierung, Versand, Claim, Ergebnis, Verifikation, Abrechnung, der Verweigerungspfad der Policy und das Dashboard beim Lesen von Live-Werten.
Dasselbe Repository listet auf, was dieses Grün nicht bedeutet. Auf dem Build-Rechner gibt es keine diskrete GPU und im Repository keinen Weight-Loader, also lief nirgends echte Inferenz und das einzige Backend ist der Mock. Die Browser-Worker-Seite wurde nie in einem echten Browser betrieben, weil das Projekt keine Browser-Automatisierung als Abhängigkeit zulässt; ihr Rendering und Layout sind daher ungemessen. Auch einen TypeScript-Compiler gibt es im Repository nicht; die Schnittstellentypen fangen Abweichungen also nur für jemanden ab, der eine Typprüfung laufen lässt, und zur Laufzeit gar nichts.
Zwei aufgeführte Verhaltensweisen verdienen eine eigene Zeile, und keine davon ist eine Zahl. Das End-to-End-Skript ist bekanntermaßen schon an der Dashboard-Prüfung gescheitert, die das live gelesene Guthaben anzeigt; das Projekt hält den Abnahmetest deshalb als nicht immer grün fest und ein einzelner roter Lauf ist nicht automatisch eine Regression. Und Registry wie Ledger liegen im Speicher, deshalb vergisst ein Neustart Geräte und Gutschriften, und eine Persistenzbehauptung gibt es nirgends.
Warum die Grenzen Teil des Produkts sind und keine Entschuldigung
Wer Compute aus einem Mock bewertet, bekommt Zahlen in Mock-Größe, und die Spezifikation sagt, dass die Beträge so gesetzt sind, dass der Mechanismus testbar ist, nicht damit sie wirtschaftlich endgültig sind. Ein Mock-Job meldet eine kurze Dauer, die Auszahlung fällt entsprechend klein aus: die ehrliche Größe eines Mock-Jobs und keine Preisliste.
Das alles auf die Seite zu schreiben kostet nichts und ändert, was die Sache ist. Eine Demo, die benennt, welche Aussagen sie nicht belegt, ist eine Spezifikation mit laufender Prüfung. Eine, die schweigt, ist eine Marketingseite mit einer Prozess-ID, und es ist deutlich unangenehmer, dabei später erwischt zu werden.
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.