Hugging Face stellt Model Integration Contracts für Transformers vor

UMT5 lieferte im Training die Antwort, und fast zwei Monate lang merkte es niemand

Hugging Face stellt mit Model Integration Contracts (MICs) ein Testverfahren für die Bibliothek Transformers vor. Auslöser ist ein Fehler, der fast zwei Monate unentdeckt in main lag. Am 30. Juli 2026 aktivierte Transformers PyTorchs Scaled-Dot-Product-Attention (SDPA) für T5. Der Decoder von UMT5 konnte dadurch auf zukünftige Tokens zugreifen. Im Training sah er so die Antwort, die er vorhersagen sollte. Ein Absturz blieb aus. Gerade deshalb fiel der Fehler nicht auf.

Beim nachträglichen Wiederabspielen der Commits meldete ein kleines UMT5-Modell auf der CPU den Fehler bei jedem betroffenen Commit. Dafür musste SDPA getestet werden, der Standardpfad für Attention. Ein Test mit eager Attention allein hätte den Fehler laut hyper.ai übersehen.

Drei Bausteine: kleines Fixture, ausführbarer Nutzungspfad, geprüfte Baselines

Große Tests allein helfen hier nicht. Transformers unterstützt über 750 Modelltypen. Die Suite umfasst über 88.000 CPU-Tests auf main und über 200.000 GPU-Tests im täglichen Lauf. Integrationstests mit echten Checkpoints auf jedem Pull Request würden dauerhaft viele GPUs binden. Geplante Läufe wiederum entdecken Regressionen oft erst, wenn sie bereits in main stehen.

Der Ansatz verkleinert deshalb das Modell. Ein Fixture entsteht aus der Konfiguration des echten Checkpoints. Es hat weniger und schmalere Layer, behält aber alle Layer-Typen. Tokenizer- und Prozessor-Dateien bleiben unverändert. Das Fixture wird einmal veröffentlicht und danach wiederverwendet. Das experimentelle UMT5-Fixture hat 66 MB Gewichte; der Quell-Checkpoint wiegt 1.227 MB.

Laut Repo besteht ein MIC aus drei Teilen: dem Fixture, einem Usage Path und den Baselines. Der Usage Path ist ausführbares Markdown. Er beschreibt, was Nutzer tun, etwa Text erzeugen oder einen Trainingsschritt ausführen. Die Baselines sind die dabei erzeugten Ausgaben, die ein Mensch geprüft hat.

Fixtures laufen auf Framework-PRs, auf der CPU und in Sekunden. Echte Checkpoints laufen nach dem Merge, nachts und vor Releases. Das Werkzeug besteht aus der Kommandozeile tmic, einem Fixture-Builder und einem Runner. Die Fixtures liegen in der Hub-Organisation huggingface-mic.

Noch „proposed standard“: Ob MICs in der Transformers-CI verbindlich laufen, ist offen

Das Repo nennt MICs einen „proposed standard“ und begrenzt die Aussagekraft eines Fixture-Tests. Er sei ein schnelles Regressionssignal, aber kein Nachweis, dass das echte Modell besteht. Der hyper.ai-Bericht beschreibt das Ziel, Regressionen vor main abzufangen. Das ist eine Zielsetzung und kein belegter Zustand. Ob MIC-Läufe als PR-Check aktiv sind, geht aus dem Material nicht hervor. Die vorliegende Testdokumentation und die Release-Auszüge bis v5.22.1 erwähnen MICs nicht. Die Doku stammt möglicherweise aus einem älteren Stand. Einen Vorher-Nachher-Vergleich oder eine Fangquote gibt es nicht.

Betroffen wären zunächst Maintainer und Beitragende. Fixtures und Baselines könnten Mehraufwand bedeuten; wie groß er ausfällt, ist nicht beziffert. Mittelbar betrifft das auch Projekte wie vLLM, SGLang, llama.cpp und mlx, die auf den Modelldefinitionen von Transformers aufbauen. Eine Regression dort kann sich nach unten fortpflanzen.

Überprüfbar wären zwei Punkte: ob MIC-Läufe als PR-Check in huggingface/transformers aktiv sind, und ob sich bekannte Regressionen per Replay zuverlässig finden lassen.