Modellgewichts-Registry: Warum ein Name nicht ausreicht für KI-Modelle

Die Bezeichnung eines KI-Modells ist kein ausreichender Beweis für seine Identität. Ein Repository, ein Tag oder ein menschlich lesbarer Name kann zwar auf ein nützliches Software-Tool verweisen, doch stabile Gewissheit über die tatsächlichen Modellgewichte entsteht erst durch die exakten Byte-Daten, die geladen werden.

Diese Unterscheidung ist besonders relevant für KI-Systeme, die mit Blockchain-Technologien interagieren. On-Chain-Behauptungen sind kostspielig zu korrigieren, sobald Nutzer sich auf sie verlassen. Wenn ein Smart Contract, ein Agent oder eine Audit-Trail von „Modell X“ spricht, lautet die nächste entscheidende Frage: Welche Datei, Revision, Größe, Prüfsumme und Empfangsbestätigung gehören dazu?

Byte-Identität: Die Grundlage für stabile Nachweise

Eine Prüfsumme identifiziert Byte-Folgen unter Verwendung eines festgelegten Algorithmus. Der NIST-Standard FIPS 180-4 definiert sichere Hash-Algorithmen, während RFC 6920 die namensbasierte Information mit Hashes beschreibt.

Diese Unterstützung ist zwar präzise, aber begrenzt. Eine SHA-256-Prüfsumme bestätigt, dass die Dateibytes mit einem aufgezeichneten Wert übereinstimmen – sie gibt jedoch keine Auskunft über Sicherheit, Ausrichtung, Lizenzierung, Nützlichkeit oder Trainingsdaten.

Empfangsbestätigungen: Klare Grenzen statt Übertreibungen

Die praktische Lösung besteht in einer Empfangsbestätigung, die keine unbegründeten Behauptungen aufstellt. Statt eines vollständigen JSON-Objekts kann das Registry eine Prüfzeile mit klar definierten Feldern bereitstellen:

• `ai.weight_hash_receipt.v1` – Trennt die Bestätigung von Modellkarten oder Benchmarks ab
• Modellbezeichnung – Beispiel: org/model-name; dient als menschlich lesbarer Verweis
• Quell-Revision – Vollständiger Commit-Hash, um fließende Branches als Identität zu vermeiden
• Dateipfad – Beispiel: model.safetensors; benennt das genaue Artefakt innerhalb der Quelle
• Format und Größe – Beispiel: safetensors, Byte-Anzahl; erkennt Konvertierungs- und Beschneidungsfehler
• Hash – Beispiel: sha256:<64 Hex-Ziffern>; identifiziert die exakte Byte-Folge
• Inhaltsadresse (optional) – Beispiel: CID plus Konstruktionshinweise; verhindert CID-Datei-Hash-Konfusion
• Aussteller und Signatur – Beispiel: Registry-Schlüssel-ID, EIP-712-Profil; gibt an, wer die Aussage getroffen hat

Diese Empfangsbestätigung ist kein universeller Standard, sondern ein defensiver Rahmen für Registries, die exakte Artefakt-Identität von Marketing-Labels trennen möchten.

Kanonische Darstellung: Warum JSON-Standardisierung entscheidend ist

Wenn die Empfangsbestätigung selbst gehasht oder signiert wird, spielt ihre Darstellung eine zentrale Rolle. RFC 8785 zeigt, warum JSON vor dem stabilen Hashen oder Signieren kanonisiert werden muss.

Das Registry muss daher entscheiden, was gehasht wird: die Modelldatei, die kanonische Empfangsbestätigung oder beides. Die Vermischung dieser Angaben führt dazu, dass ein Registry-System von „verifiziert“ spricht, ohne zu präzisieren, was tatsächlich überprüft wurde.

Muster aus der Software-Lieferkette: Vertrauenswürdige Provenienz

Software-Lieferketten-Systeme nutzen bereits das Subjekt-Plus-Digest-Muster. Die SLSA-Provenienz und die in-toto-Erklärungsspezifikation verbinden Subjekte mit Namen und Prüfsummen in Provenienz-Erklärungen.

Ein Modell-Registry kann sich diese Praxis aneignen, ohne die Herausforderung als gelöst zu betrachten. Die Prüfsumme liefert die Artefakt-Identität, die Provenienz-Erklärung den Kontext von Aussteller und Prozess – doch keine der beiden Methoden beweist das Verhalten des Modells.

Tags vs. stabile Identität: Die Lektion aus Container-Registries

Container-Registries machen das Problem der Zeiger gut verständlich. Die OCI-Beschreibung identifiziert Inhalte über Medientyp, Prüfsumme und Größe, während Tags weiterhin praktische Bezeichnungen bleiben, die sich verschieben können.

KI-Gewichte benötigen dieselbe Disziplin. Bezeichnungen wie „latest“, „main“ oder „production“ sind betriebliche Zeiger. Eine Prüfsumme und Größe hingegen bilden den Anfang einer stabilen Artefakt-Identität.

Revisionen: Warum Repository-Namen allein nicht ausreichen

Modell-Hubs wie der Hugging Face Hub bieten bereits eine bessere Lösung als fließende Namen. Die Dokumentation beschreibt revisionsgebundene Downloads, die Branches, Tags und Commit-Identifier einbeziehen.

Das Registry sollte die Revision und den Dateipfad dokumentieren, nicht nur den Repository-Namen. Ohne diese Angaben bleibt die Aussage „Wir haben org/model-name verwendet“ ein Hinweis, keine Identität.

Inhaltsadressierung: Präzision statt Vereinfachung

Inhaltsadressierung kann hilfreich sein, doch ein Modell-Registry sollte nicht jeden CID einfach als „Datei-Hash“ darstellen. Die IPFS-Dokumentation erklärt inhaltsbasierte Bezeichner, wobei die CID-Konstruktion von Darstellungsdetails abhängt.

Diese Einschränkung gehört in die Empfangsbestätigung. Ein CID ist nützlich, wenn das Registry die CID-Version, den Codec, die Chunking-Methode oder Importdetails sowie die Beziehung zwischen CID und Datei-Prüfsumme dokumentiert.

Signierte Aussagen: Wer steht hinter der Behauptung?

Eine signierte Empfangsbestätigung kann die Authentizität der Aussage bestätigen. EIP-712 unterstützt strukturierte Datensignaturen mit Domänentrennung, was besser zu einer Registry-Empfangsbestätigung passt als eine undurchsichtige Zeichenfolge.

Die Signatur hat jedoch klare Grenzen. Eine falsche Empfangsbestätigung bleibt falsch – selbst wenn sie signiert ist. Eine signierte Byte-Identitäts-Empfangsbestätigung bestätigt weder Sicherheit, Lizenzrechte noch Trainingsdaten.

Dateiformat: Ein oft übersehener Faktor

Das Dateiformat ist Teil der Empfangsbestätigung, da Modellgewichte mehr sind als nur Namen. SafeTensors bietet einen konkreten Kontext für Tensor-Dateien und Metadaten.

Das Format-Feld verhindert einen häufigen Fehler: die Annahme, dass ein konvertiertes Artefakt dasselbe Objekt darstellt, ohne die Konvertierung zu dokumentieren. Die Byte-Identität ändert sich, wenn sich die Serialisierung ändert – selbst wenn das Modell beabsichtigt ist, sich ähnlich zu verhalten.

Klare Grenzen für jede Angabe

Das Registry sollte jede Behauptung in ihrem eigenen Kontext belassen. Die folgende Tabelle fasst zusammen, was möglich – und was nicht möglich ist:

| Feld | Was es aussagen kann | Was es nicht aussagen kann | |------|----------------------|---------------------------| | Modellbezeichnung | Menschlich lesbarer Verweis | Stabile Identität | | Revision | Zustand der Quelle oder Commit-Kontext | Qualität oder Sicherheit | | Dateibytes ohne Pfad und Prüfsumme | – | Stabile Identität | | Prüfsumme | Exakte Bytes unter einem Algorithmus | Gültigkeit oder Lizenz | | CID | Inhaltsadressierter Objektverweis | Rohdatei-Hash |

Die zentrale Botschaft lautet: Ein Modell-Registry muss präzise bleiben, um Vertrauen zu schaffen. Namen und Tags sind nützlich für die menschliche Kommunikation, doch die technische Identität beginnt mit den exakten Daten.