- július 30-án a Transformers könyvtárban a T5 modellnél engedélyezték a PyTorch skálázott pont-termék figyelmét (SDPA). Ennek mellékhatásaként az UMT5 dekóder képes volt a jövőbeli tokenekre figyelni, tehát a tanítás során „beleste” a helyes választ. A hiba nem omlasztotta össze a rendszert, és majdnem két hónapig a main ágban maradt; visszajátszáskor azonban egy kisméretű UMT5 CPU-futtatáson minden érintett commitnál jelezte a problémát. Ez az írás erről a kis modellről és a köré épített tesztekről szól.
Miért jutnak hibák a mainbe
A Transformers több mint 750 modelltípust támogat, és a tesztkészlet nagy: a mainen 88,000+ CPU-teszt fut, és naponta további 200,000+ GPU-teszt. A modellellenőrzések csak egy részét jelentik: pipeline-okat, trenírozást, disztribúciót, kvantálást és figyelem-kernelt is tesztelnek. A teljes ellenőrzés minden PR-en napi szinten sok GPU-t kötne le, ezért gyakran csak ütemezett futásoknál derül ki regresszió, amikor az már a mainben van.
Helyettük a Transformers csapata a modellt kicsinyíti: egy fixture-t építenek — ez a valódi checkpoint konfigurációjából származó, de kevesebb és keskenyebb rétegeket tartalmazó modell, amely minden réttípust megőriz, míg a tokenizer és processor fájlok változatlanok. Ez egyszer publikált, majd újrahasználható. Ezekkel „gyors integrációs teszteket” futtatnak olcsó CPU futtatókon. A publikált UMT5 kísérletben a fixture 66 MB súlyokat használt, miközben a forrás checkpoint 1,227 MB volt. Nagy modelleknél, melyek nem férnek el a szabvány GPU-kon, a fixture CPU-n még lefut.
A fixture-ek nem helyettesítik a teljes integrációs teszteket, de PR-eknél nagyobb esélyt adnak a hibák korai elkapására.
Model Integration Contracts (MIC)
A transformers-mic egy javasolt szabvány ezeknek a teszteknek a csomagolására. Egy Model Integration Contract három részből áll:
- fixture: egyszer publikált, zárolt, kicsinyített modell
- usage path: futtatható, példamutató Markdown példa az adott használatra (például generálás vagy egy trenírozási lépés)
- baselines: ember által felülvizsgált, rögzített kimenetek, amelyekhez a futtatás eredményét viszonyítják
A szerződés akkor áll fenn, ha a fixture-en a usage path lefuttatva megegyezik a baselines-szal. A MIC architektúrát és használati utat fedi le, nem egyetlen checkpointot: kompatibilis checkpointok osztozhatnak fixture-en, de mindegyik saját várt eredményt tart meg. A publikálás a huggingface-mic tárolóban történik. Egy példa (SmolLM) egyszerű promptokra generál és az új token ID-kat hasonlítja össze a rögzített válasszal; van hasonló ellenőrzés trenírozási lossra, gradiens-létrehozásra és optimizáló lépés hatására is.
A Hub-on egy fleet dataset minden MIC-et egy megfagyasztott revízióhoz köt, a baselines rögzítésekor használt csomagverziókkal együtt. Minden CI futás naplózza, mely fleet revíziót használta, hogy később reprodukálható legyen a környezet.
PR esetén a módosított fájlok alapján választunk MIC-eket. A UMT5 regresszió például a lefutott, fagyasztott MIC-ek visszajátszásakor 2026 július 30-tól szeptember 28-ig jelezte a problémát.
Az UMT5 regresszió részletei
A replay öt hónapnyi Transformers commiton megmutatta, hogy a kicsi UMT5 fixture a hibát az előfordulásától (2026-07-30) a javításáig (2026-09-28) jelezte. A label log-probabilitások az ember által felülvizsgált baseline-hoz képest 1.22-es különbséget mutattak, a trénelési loss pedig ~0.20 körüli eltérés volt. Fontos részlet: a szerződés az SDPA-t (a default attention útvonalat) használta; ha csak az eager attention variánst futtattuk, a hiba elkerülte a detektálást. Tehát a fixture csak akkor segít, ha ugyanazt a kódutat járja, mint a valódi checkpoint.
A hibajavítás visszavonásakor egy bizonyítóágban a check ugyanazokkal az eltérésekkel bukott meg; a kiválasztott T5 szerződés futtató lépése CPU-n 13.4 másodpercet vett igénybe, a setup nélküli mérés szerint. A replay eredmények és a CI demo részletes mérési adatokat és reprodukciós lépéseket tartalmaznak.
Hogyan zsugorítjuk a modelleket
A korai, egyszerű recept: méretek csökkentése és kevesebb réteg tartása — ez azonban nem elég vegyes architektúrákhoz. A mostani négylépcsős recept:
- Konfiguráció zsugorítása: reális checkpointból kiindulva csökkentjük a hidden size-okat, attention head-eket és a mélységet, megtartva az eltérő réttípusokat (például sliding vs full attention, dense vs MoE). A ModelTester teszteket is figyelembe vesszük, ami kézzel választ kis konfigurációkat.
- Előfeldolgozás változatlanul tartása: vocab, speciális tokenek és input-dimenziók, valamint a tokenizer és processor fájlok byte-for-byte másolása. A betöltés és előfeldolgozás tesztelése cél.
- Súlyok építése és validálása: próbálkozunk seedelt véletlenszerű súlyokkal, változtatjuk bemeneteket, ha nem reagál a modell, megpróbáljuk néhány batch-en trenírozni, majd újratöltjük és ellenőrizzük az outputokat, loss-t és gradiensek véges értékét. Sikertelen buildet elutasítunk.
- Freeze és baseline rögzítése: elfogadott súlyokat elmentjük, mérhető, reprodukálható kimeneteket rögzítünk egy known-good Transformers builden, felülvizsgáljuk a baseline-okat platformonként és precizitásonként, majd publikáljuk a pinned snapshotot. A CI újrahasználja ezt a snapshotot; nem építi újra minden PR esetén.
A zsugorításhoz megtartjuk az eredeti súlyfájl-formátumot is, hogy a checkpoint betöltése során futó konverziók is ellenőrzés alatt maradjanak. Példaként a Llama 4 Scout zsugorításánál 108.6 milliárd paraméterből 44.7 millió lett; a vision stack 34 rétegről 2-re, a language stack 48-ról 4-re csökkent, miközben megőrizték a réttípusokat és a MoE routing stílust.
MIC készítése ügynökökkel és a CLI
A tmic CLI létrehozza a szerződést és építi a fixture-t. Új modellnél egy LLM vázolja a usage kódot és a manifestet, majd CPU és GPU futtatások mérik a jelölt baseline-okat; az LLM tervezetet készít, de nem hagyja jóvá azokat — a változó elvárásokat ember ellenőrizni kell. A tmic lokálisan is futtatható, a dokumentációban szereplő parancs például a helyi szerkesztéshez és fixture-only futtatáshoz használható, és minden lépésnél felkéri a felhasználót a felülvizsgálatra, feltöltés előtt megáll.
A csapat ügynököket használt MIC-ek építésére különböző modellcsaládokban; amikor élő eset ütötte meg a határesetet, a receptet javították, nem pedig csak az egyes fixture-öket, model-szakértők bevonásával. A publikált modellek és még hiányzó lefedettségi területek a coverage space-ben találhatók.
Véletlenszerű vs túlillesztett súlyok
Véletlenszerű súlyokkal a Whisper fixture alig reagált audio változásokra, így bár lefutott, rossz teszt volt az audio út számára. Ezért egy rövid, néhány hangra túlillesztett trénelést alkalmaztak (például hangok párosítva a "red" vagy "green" szavakkal), hogy az audio változások láthatók legyenek a kimenetben. A weight-initialization tanulmány szerint a random Whisper fixture 18/24 befecskendezett hibát fogott, míg a overfit fixture az összeset. Ennek megfelelően két építési mód van:
- kezdetnek véletlenszerű súlyok fix seed-del
- túlillesztés néhány példára, hogy érzékenyebb, olvasható válaszokat adjon
A végeredmény nem döntötte el egyértelműen, melyik jobb: még nem találtak valódi regressziót, amit csak az overfit változat észlelt volna. Mindkettőt használják, ahol indokolt; a túlillesztés néhány másodpercet vesz igénybe és egy újabb potenciális hibaforrást jelenthet (konvergencia). Mindkét változat összehasonlítása dokumentált.
Nyitott kérdések
- november 1-jei állapot szerint a Transformers CI-ben a MIC munka hibákat jelent, de még nem blokkol PR-eket. A blokkolás szükségessége több mérésen múlik:
- Hány valódi hibát fog el PR-eknél (nem csak visszajátszásoknál)?
- Milyen gyakran ad téves riasztást?
- Mennyi emberi munka a baseline-ok felülvizsgálata?
Nem tudjuk azt sem pontosan, hogy hány hiba — mint a Whisper segített-dekódolási eset — csak valódi súlyokkal jelenik meg, vagy hogy az overfitting elkap-e valódi regressziókat, amelyeket a véletlensúlyok elmulasztanak. A lefedettség továbbra is részleges a modellcsaládok és a használt API-k szerint. Amikor egy regresszió átcsúszik, hozzáadhatunk hiányzó usage path-okat és visszajátszhatjuk a hibás és javított verziókon.
Végezetül cél a Hub modelloldalak és azok MIC-jeinek összekapcsolása, hogy fejlesztők vagy agentek a checkpointhoz kapcsolódó tesztelt példát, környezetet és várt kimeneteket közvetlenül megtalálhassák.
Hogyan segíthetsz
Ha szeretnél hozzájárulni: válassz ki egy nem lefedett modellt a coverage space-ből, próbáld ki a tmic munkafolyamatot, és járulj hozzá egy usage path-hoz vagy nézd át egy generált szerződés baseline-jait.
