Hugging Face hat Model Integration Contracts (MICs) vorgeschlagen – eine Möglichkeit, bei Pull Requests schlanke Prüfungen für Transformers-Modelle auszuführen. Ziel ist es, Regressionen zu erkennen, bevor sie in die Haupt-Codebasis gelangen, ohne für jede Änderung die vollständige Integrationssuite auf GPUs ausführen zu müssen.

Der Vorschlag geht auf einen Fehler bei der T5-Attention zurück. Am 30. Juli 2026 aktivierte Transformers PyTorchs Scaled Dot-Product Attention für T5. Dadurch konnte während des Trainings auch der Decoder von UMT5 auf zukünftige Tokens zugreifen. Das Problem blieb bis zu seiner Behebung am 28. September im Haupt-Branch bestehen. Als das Team die dazwischenliegenden Commits erneut ausführte, meldete eine kleine UMT5-Fixture auf der CPU die Regression.

Transformers unterstützt mehr als 750 Modelltypen. Sein Haupt-Branch umfasst über 88.000 CPU-Tests, während ein täglicher Testlauf mehr als 200.000 GPU-Tests enthält. Vollständige Integrationstests laden echte Checkpoints und führen Modelle auf echter Hardware aus. Würde man sie jedoch bei jedem Pull Request alle ausführen, müssten die GPUs den ganzen Tag ausgelastet sein. Geplante Testläufe können ein Problem außerdem erst erkennen, nachdem es den Haupt-Branch erreicht hat.

MICs schaffen einen Ausgleich, indem sie kleinere Fixtures testen, die auf Konfigurationen echter Checkpoints basieren. Sie behalten die verschiedenen Layer-Typen eines Modells bei, verwenden aber weniger und schmalere Layer; Dateien für Tokenizer und Prozessoren bleiben unverändert. Die Fixtures werden einmal veröffentlicht und in schnellen Integrationstests auf der CPU wiederverwendet. In der UMT5-Studie belegten die Gewichte der Fixture 66 MB, verglichen mit 1.227 MB für den ursprünglichen Checkpoint. Mit diesem Ansatz lassen sich auch sehr große Modelle abdecken, die nicht auf standardmäßige GPU-Runner passen.

Jeder Vertrag besteht aus drei Teilen: einer festgelegten Fixture, einem ausführbaren Beispiel für eine Modellaufgabe und Output-Baselines, die bei einem bekanntermaßen funktionierenden Lauf aufgezeichnet und von einer Person überprüft wurden. Die Prüfung ist erfolgreich, wenn der anhand der Fixture ausgeführte Beispielcode mit diesen Baselines übereinstimmt. Ein Vertrag bezieht sich auf eine Architektur und einen Nutzungspfad statt auf einen einzelnen Checkpoint. So können kompatible Checkpoints eine Fixture gemeinsam nutzen und zugleich ihre jeweils eigenen erwarteten Ergebnisse beibehalten.

Beispiele können mehr prüfen, als ob ein Modell geladen werden kann und einen Forward Pass abschließt. Ein SmolLM-Vertrag etwa generiert Text aus einem Prompt und vergleicht die resultierenden Token-IDs mit einer aufgezeichneten Antwort. Außerdem prüft er den Trainingsverlust, verifiziert, dass die Gradienten endlich sind, und bestätigt, dass ein Optimizer-Schritt die Gewichte verändert. Bei Pull Requests wählt CI die Verträge anhand der geänderten Dateien aus.

Der UMT5-Replay zeigte, warum der getestete Pfad wichtig ist: Die Log-Wahrscheinlichkeiten der Labels wichen um 1,22 von der überprüften Baseline ab, der Trainingsverlust um etwa 0,20. Der Vertrag verwendete SDPA, den standardmäßigen Attention-Pfad; hätte man nur die Eager-Attention-Variante getestet, wäre das Problem unentdeckt geblieben. Durch das Zurücksetzen der Fehlerbehebung in einem Transformers-CI-Proof-Branch ließ sich der Fehler reproduzieren. Der Runner-Schritt des ausgewählten T5-Vertrags dauerte auf der CPU 13,4 Sekunden, ohne die Einrichtung.

Das Verfahren zum Erstellen von Fixtures wurde auch für gemischte Architekturen angepasst. Es reduziert die Modelldimensionen und behält dabei unterschiedliche Layer-Typen bei, darunter Kombinationen wie Sliding und Full Attention oder Dense- und Mixture-of-Experts-Layer. Vorverarbeitungsressourcen wie Vokabular und spezielle Tokens bleiben erhalten; ebenso das ursprüngliche Format der Gewichtsdateien, sodass der Code zur Checkpoint-Konvertierung weiterhin getestet wird. Die Builds werden auf reaktionsfähige Ausgaben und endliche Ergebnisse geprüft und anschließend mit überprüften Baselines für unterstützte Plattformen und Präzisionen fixiert.

Das Ausmaß der Verkleinerung zeigt eine Llama-4-Scout-Fixture: Aus 108,6 Milliarden Parametern werden 44,7 Millionen, wobei die geprüften Layer-Typen und der MoE-Routing-Stil erhalten bleiben. Das Kommandozeilen-Tool tmic erstellt Verträge und Fixtures. Bei neuen Modellen kann ein LLM den Nutzungscode und das Manifest entwerfen, doch geänderte Erwartungen müssen von Menschen überprüft werden. Der lokale Workflow kann einen Vertrag erstellen und testen, ohne ihn hochzuladen.

Das Team verglich außerdem zufällige Fixture-Gewichte mit Gewichten, die anhand einiger Beispiele trainiert wurden. In einer Studie mit synthetischen Fehlern erkannten zufällig initialisierte Whisper-Fixtures 18 von 24 eingeschleusten Problemen, während Fixtures, die mit einer kleinen Zahl von Beispielen trainiert wurden, alle 24 erkannten. Die Autoren warnen davor, daraus abzuleiten, welcher Ansatz in der Praxis besser ist: Die Tests verwendeten synthetische Fehler, und beide Varianten übersahen einen Fehler beim Assisted Decoding, der durch den echten Whisper-Checkpoint sichtbar wurde. Der aktuelle Ansatz behält zufällige Gewichte bei, wenn sie die Validierung bestehen, und verwendet Overfitting, wenn höhere Empfindlichkeit oder besser lesbare Ausgaben erforderlich sind.

Am 1. November 2026 meldet der MIC-Job in der Transformers-CI Fehler, blockiert Pull Requests jedoch nicht. Das Team sagt, es müsse noch messen, wie viele echte Fehler die Prüfungen erkennen, wie oft sie Fehlalarme auslösen und wie viel Aufwand die Überprüfung der Baselines erfordert. Die Abdeckung ist weiterhin unvollständig; das Projekt plant, Nutzungspfade zu ergänzen, wenn Regressionen Lücken aufdecken. Vorhandene Tests bleiben bestehen, bis ihre Abdeckung berücksichtigt wurde.

Quellen: Hugging Face Blog.