§ Plattform / Korrektheit
Bewiesen, nicht versprochen.
Consumer-GPUs unterscheiden sich, Treiber unterscheiden sich, und Fließkommazahlen interessieren sich nicht für deine Deadline — Korrektheit ist hier deshalb Maschinerie, keine Haltung. Eine CPU-Referenz verankert jeden Rechenpfad, alles Unverifizierte wird geprüft, bevor es zählt, und das Prüfwerkzeug selbst ist permissiv lizenziert veröffentlicht — keine Aussage auf dieser Seite musst du einfach glauben.
Jedes Ergebnis muss sich an einer Referenz messen
Die Engine hat genau einen Korrektheitsanker: eine CPU-Referenz, die für jede eingebaute Operation das gemeinte Ergebnis definiert. Jeder GPU-Kernel, auch die handoptimierten Pfade hinter dem Training im Browser, muss diese Referenz innerhalb einer deklarierten Toleranz reproduzieren — auf genau der Hardware, auf der er läuft. Ein fehlender GPU-Kernel ist ein Bug, nie ein stiller Rückfall auf die CPU: Eine Substitution, die deine Zahlen oder dein Tempo ändert, passiert hier nicht hinter deinem Rücken.
Toleranz ist Teil des Vertrags, nicht Folklore. Vier Klassen — exact, tight, default und loose — lösen sich je in ein deklariertes Paar aus absoluter und relativer Schranke auf, und die Klasse, die eine Operation beansprucht, muss zu dem passen, was sie tut: Eine Matrixmultiplikation kann sich nicht als loose deklarieren, um der Prüfung auszuweichen. Die deklarierte Klasse taucht im Katalog als Vertrauenssignal auf — ein locker toleriertes Trainings-Op ist sichtbar weniger vertrauenswürdig, bevor du dich darauf verlässt.
Jede Artefaktklasse verdient sich Vertrauen durch eine benannte Prüfung
| Artefakt | Geprüft durch | Die Regel |
|---|---|---|
| Eingebaute Kernel | die Referenz | Jede GPU-Implementierung muss der CPU-Referenz innerhalb ihrer deklarierten Toleranz entsprechen — auf jeder Art von Hardware. |
| Kernel, die du schreibst | Konformitäts-Evidenz | Gebunden an genau diesen Code und an die Hardware, auf der er bewiesen wurde; Pflicht vor vertrauenswürdiger, teilbarer Nutzung — auf deinem eigenen Gerät läuft er ohnehin. |
| Gradientenregeln | gradcheck | Finite Differenzen gegen den eigenen Forward-Pass — mit verpflichtender Negativkontrolle. |
| Kombinationsregeln | Property-Tests | Eine Regel, die behauptet, Teilergebnisse in beliebiger Reihenfolge kombinieren zu können, wird beidseitig getestet, bevor ein Planer sich darauf verlassen darf. |
| Ergebnisse anderer Geräte | Re-Ausführung · Quorum | Innerhalb der Toleranz verifiziert, bevor sie zählen — nie bei Ankunft vertraut und auf dem GPU-Pfad nie bit-genau verglichen. |
| Bytes & Caches | SHA-256 | Was seinen Hash verfehlt, ist Korruption — neu geladen, nie überklebt. |
Ein Checker, zwei Zielgruppen: Dieselbe Prüfung, die deine Inhalte beim Veröffentlichen freigibt, prüft auch unsere — Vertrauen wird verdient, und es interessiert sich nicht dafür, wer etwas geschrieben hat.
Vertrauen ist eine Eigenschaft des Artefakts — von Maschinerie verdient und direkt daneben festgehalten — und nie eine Eigenschaft dessen, wer es gemacht hat. Compute, das du selbst schreibst, durchläuft exakt die Prüfungen der mitgelieferten Inhalte, durch denselben Checker, und die Prüfungen setzen sich nach oben fort: Ein trainiertes Modell hält den Konformanzstatus von allem fest, womit es trainiert wurde. Ein Modell, das auf einem unverifizierten Gradienten trainiert wurde, bleibt von einem voll konformen unterscheidbar — und wird nie stillschweigend als gleichwertig ausgegeben.
Der Katalog zeigt das alles, bevor du dich auf irgendetwas verlässt: woher es kommt, wie weit ihm vertraut wird, ob es geprüft wurde und welche Toleranz es beansprucht — echte Signale auf der Karte, keine Dekoration. Community-Arbeit kann verified erreichen; official ist keine Abkürzung an den Prüfungen vorbei — denn einen Weg an den Prüfungen vorbei gibt es nicht.
Du wählst, wie reproduzierbar ein Lauf ist — nichts ändert das leise
| Einstellung | Garantie | Im Klartext |
|---|---|---|
| debug | Bitweise identisch — gleicher Seed, gleiches Gerät | Deterministischer GPU-Code: eine feste Reihenfolge der Operationen, keine Abkürzungen — ein realer, sichtbarer Preis an Tempo. |
| prod | Deterministisch innerhalb der deklarierten Toleranz | Die Arbeitseinstellung für Training und reproduzierbare Analysen — Übereinstimmung innerhalb der Schranken, die die Operation deklariert hat. |
| fast | Freiere Reihenfolge, nur wo als sicher deklariert | Maximaler Durchsatz; jede Lockerung ist deklariert, und keine ist still. |
| (nicht gesetzt) | Beim Kompilieren abgelehnt | Keine Einstellung, kein Lauf — eine benannte Diagnose, nie eine leise Annahme an deiner Stelle. |
Bit-Gleichheit über verschiedene Geräte hinweg gibt es nur auf dem CPU-Referenzpfad — GPU-Arithmetik addiert nicht in fester Reihenfolge, GPU-Läufe reproduzieren also bis zur deklarierten Toleranz. Eine physikalische Grenze, veröffentlicht in den ehrlichen Grenzen statt aufgerundet.
Wie exakt ein Lauf ist, ist ein Regler, den du stellst — und er wird bis ganz nach unten getragen, bis in den Code, der auf der GPU läuft, und mit jedem Lauf im Datensatz festgehalten. Der Regler hat keine versteckte Stellung: Ein Workflow ohne definierte Einstellung wird mit einer benannten Diagnose abgelehnt statt mit einem leisen Default geflickt. Denn eine falsche Zahl, die richtig aussieht, ist das Schlimmste, was ein wissenschaftliches Werkzeug produzieren kann.
Zufall ist fürs Wiederabspielen gebaut. Der Generator ist zählerbasiert: Derselbe Seed an derselben Position liefert auf jeder Hardware denselben Wert; Dropout, Shuffling und Augmentierung besitzen je einen eigenen benannten Strom; und der vollständige Zustand des Generators steckt in jedem Checkpoint. Ein fortgesetzter Trainingslauf setzt also exakt den Strom fort, den er verlassen hat, und ein Stück Arbeit, das auf einem anderen Gerät landet, zieht dort dieselben Zahlen.
Dein Kernel verdient sich Vertrauen genauso wie unsere
Schreib einen GPU-Kernel, und du paarst ihn mit einer eigenen Referenz. Die Konformanzprüfung generiert die Testfälle dann selbst — aus deiner Signatur und deinem Shape-Vertrag — und beweist, dass dein GPU-Code deiner Referenz innerhalb der Toleranz entspricht, die du deklariert hast. Ihn als vertrauenswürdiges Artefakt zu teilen, verlangt die daraus entstehende Konformitäts-Evidenz — gebunden an genau diesen Code und an die Hardware, auf der er bewiesen wurde: Der Rechner der nächsten Person wiederholt den Nachweis lokal, statt dein Vertrauen zu importieren.
Das Gate begrenzt Vertrauen, nie Ausführung: Dein eigenes Gerät führt deinen noch unbewiesenen Kernel jederzeit aus — die Prüfung regelt, was geteilt, fürs Training genutzt und als vertrauenswürdig ausgeführt werden darf, nicht, was du ausprobieren darfst. Gradienten klettern dieselbe Leiter: Ein deklarierter Gradient wird gegen finite Differenzen deines eigenen Forward-Pass geprüft, und der Harness besteht auf einer Negativkontrolle — er muss auch einen absichtlich falschen Gradienten fangen, sonst zählt die Prüfung selbst nicht. Die Grenze kommt gleich mit: Ein bestandener Gradienten-Check ist starke Evidenz, kein formaler Beweis.
Ergebnisse von anderen Geräten werden geprüft, nicht geglaubt
GPUs sind sich in den letzten Bits uneins: Fließkomma-Addition addiert nicht in fester Reihenfolge, und der GPU-Standard des Browsers verspricht keine Bit-Gleichheit über Geräte hinweg. Wenn Geräte also ihre Rechenleistung poolen, wird ein zurückgeliefertes Stück Arbeit nie per Hash-Vergleich verifiziert — es wird innerhalb seiner deklarierten Toleranz erneut ausgeführt oder per Übereinstimmung mehrerer Geräte entschieden, bevor es zählt. Reproduzierbarkeit ist in zwei ehrlichen Stufen deklariert: bit-exakt auf dem Referenzpfad, toleranzgebunden auf dem GPU-Pfad — und jeder Lauf sagt, welche von beiden er ist.
Selbst eine deklarierte Abkürzung wird getestet. Wenn Arbeit über Geräte verteilt wird, darf der Planer die Teilergebnisse in beliebiger Reihenfolge kombinieren — aber nur, wenn die Regel, die sie kombiniert, sagt, dass das sicher ist. Eine Regel, die das fälschlich sagt, würde still falsche Wissenschaft produzieren; die Behauptung wird deshalb property-getestet, bevor man sich je auf sie verlässt, Negativkontrolle inklusive. Eine Kombinationsregel, die ehrlicherweise nicht so arbeiten kann, verweigert die Abkürzung per Konstruktion und zahlt den ausgewiesenen Preis eines einzelnen Kollektors.
Jede Aussage auf dieser Seite kannst du unabhängig nachprüfen
Das Prüfwerkzeug selbst ist permissiv veröffentlicht, Apache-Klasse: die Spezifikationen und Schemata, das Konformanz-Korpus mit seinen deklarierten Toleranzen und die CPU-Referenz — der Interchange-Ring der Plattform. Jede und jeder — Reviewerin, Auditor, Konkurrent — kann die Prüfungen gegen dieselben Referenzen erneut laufen lassen und jede Korrektheitsaussage hier verifizieren, ohne um Erlaubnis zu fragen.
Der Beweis überlebt auch unsere Releases. Ein eingefrorenes Korpus von Arbeit aus früheren Engines läuft bei jedem Engine-Release automatisch erneut, ein Update kann also nie leise ändern, was eine alte Operation rechnet; dass deine Arbeit unsere Releases überlebt, wird getestet, nicht behauptet. Und jeder Lauf pinnt die Engine-Version und die Präzisions-Einstellung, die ihn erzeugt haben — ein reproduziertes Ergebnis benennt die exakte Engine, an der es sich messen lässt.