Договори за интеграция на модели Transformers

Договори за интеграция на модели в Transformers

Публикувано 3 ноември 2026 г.

На 30 юли 2026 г. Transformers активира мащабиранoто скаларно произведение на вектори (SDPA) на PyTorch за T5. Като страничен ефект декодерът на UMT5 можеше да обръща внимание на бъдещи токени. По време на обучението той можеше да надникне в отговора, който трябваше да предскаже. Нищо не се срина и грешката остана в основния клон почти два месеца.

Когато по-късно повторихме изпълнението на тези комити, малък модел UMT5, работещ на CPU, сигнализира за нея при всеки от тях. Тази публикация е за този модел и тестовете, изградени около него.

Защо грешките достигат до основния клон

Transformers поддържа над 750 типа модели, а тестовият му пакет е голям: над 88 000 CPU теста в основния клон плюс над 200 000 GPU теста при ежедневно изпълнение. Тестовете на моделите са само част от него: също така тестваме конвейери, обучение, разпределено изпълнение, квантизация и ядра за внимание.

Интеграционните тестове зареждат реални контролни точки и използват API на модела върху реален хардуер. Изпълнението на всичко това при всяка заявка за промяна би означавало да поддържаме много графични процесори заети през целия ден, което не е практично. Докато планирано изпълнение открие регресия, тя може вече да е попаднала в основния клон.

Нашият подход е вместо това да намалим размера на модела. Изграждаме тестов екземпляр: малък модел, създаден от конфигурацията на реалната контролна точка, с по-малко и по-тесни слоеве, но с всеки вид слой, който тя има, като файловете на токенизатора и процесора му остават непроменени. Той се публикува веднъж и след това се използва повторно. Изпълняваме „бързи интеграционни тестове“ с него на евтин CPU изпълнител. В нашето CPU проучване експерименталният екземпляр на UMT5 използваше 66 MB тегла; изходната контролна точка е 1 227 MB.

Това обхваща и много големи модели: някои не се побират на стандартните ни GPU изпълнители, но техните екземпляри работят на CPU.

Интеграторите на модели вече създават малки тестови модели (контролните точки tiny-random-* на Transformers). Искахме обща рецепта и проверки, които надхвърлят зареждането на модела и изпълнението на права посока. Грешката в UMT5 би преминала без проблем проверка само с права посока.

Екземплярите няма да заменят пълните интеграционни тестове, но при заявките за промяна ни дават шанс да откриваме грешки, преди да достигнат основния клон.

Представяне на договорите за интеграция на модели

transformers-mic е предложен стандарт за пакетиране на тези тестове. Договорът за интеграция на модел (MIC) има три части:

тестов екземпляр: описаният по-горе свит модел, публикуван веднъж и фиксиран
път на използване: изпълним Markdown пример на нещо, което хората правят с модела, например генериране на текст или изпълнение на стъпка от обучението
базови резултати: резултатите, записани при изпълнението на този пример и прегледани от човек

Договорът е валиден, ако изпълнението на пътя на използване върху екземпляра все още дава базовите резултати.

Договорът обхваща архитектура и път на използване, а не една контролна точка: съвместимите контролни точки могат да споделят екземпляр, като всяка запазва собствените си очаквани резултати. Публикуваме ги в huggingface-mic.

Например договорът за SmolLM генерира от подсказки като „The capital of France is“ и сравнява идентификаторите на токените им със записан отговор. След зареждане на модела и токенизатора кодът за генериране, опростен до една подсказка, е:

inputs = tokenizer("The capital of France is", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=4, do_sample=False)
new_tokens = outputs[:, inputs["input_ids"].shape[1]:]
print(tokenizer.batch_decode(new_tokens, skip_special_tokens=True))

Той също сравнява загубата при обучение, проверява дали градиентите са крайни и потвърждава, че стъпка на оптимизатора променя теглата. Вижте пълния usage.md.

Набор от данни за флота в Hub фиксира всеки MIC към замразена ревизия заедно с версиите на пакетите, използвани за записване на базовите резултати. Всяко CI изпълнение записва ревизията на флота, която е използвало, за да можем да го възпроизведем по-късно.

При заявка за промяна избираме MIC според файловете, които пачът променя.

Регресията в UMT5

Повторихме изпълнението на замразени MIC за комитите на Transformers в продължение на пет месеца. Малкият екземпляр на UMT5 сигнализира за регресията от въвеждането ѝ на 30 юли 2026 г. до отстраняването ѝ на 28 септември. Логаритмичните вероятности на етикетите се различаваха от прегледаната базова стойност с 1,22, а загубата при обучение с около 0,20.

Един детайл беше от значение: договорът използваше SDPA, пътя за внимание по подразбиране. Изпълнението само на варианта с нетърпеливо внимание пропусна грешката. Един екземпляр помага само ако преминава през същия код като реалната контролна точка.

След това отменихме поправката в доказателствен клон в CI на Transformers. Проверката се провали със същите разлики, а стъпката за изпълнение на избрания договор за T5 отне 13,4 секунди на CPU, без да се включва настройката.

Резултатите от повторното изпълнение и демонстрацията на CI съдържат измерванията и подробностите за възпроизвеждане.

Как се свиват моделите

Първата рецепта беше проста: да намалим размерностите и да запазим по-малко слоеве. Това не беше достатъчно за смесени архитектури. Няма полза да запазим два слоя, ако и двата използват плъзгащо внимание и слоевете с пълно внимание изчезнат.

Рецептата вече има четири стъпки:

Свиване на конфигурацията. Започваме от реална контролна точка и намаляваме скритите размери, главите за внимание и дълбочината. Запазваме различните видове слоеве, включително смеси от плъзгащо и пълно внимание или плътни и MoE слоеве. Някои архитектури се нуждаят от допълнителни правила, за да запазят съвместимостта на компонентите си. Разглеждаме и собствените тестове на модела в Transformers: ModelTester в test_modeling_<model>.py вече избира малка конфигурация ръчно, така че използваме нейните размери за всяка ширина, която общото ни правило не разпознава по име.
Запазване на предварителната обработка без промени. Запазваме речника, специалните токени и входните размери и копираме файловете на токенизатора и процесора байт по байт. Зареждането и предварителната обработка са част от нещата, които искаме да тестваме.
Изграждане и валидиране на теглата. Изпробваме случайни тегла с фиксирано начално число и променяме входовете, за да проверим дали моделът реагира. Ако не реагира, опитваме да го обучим върху малката партида примери на договора. Зареждаме отново записания модел и проверяваме дали изходите, загубата и градиентите са крайни. Отхвърляме неуспешните компилации.
Замразяване и записване. Запазваме приетите тегла и измерваме възпроизводими изходи върху доказано добра компилация на Transformers. Преглеждаме базовите резултати за всяка поддържана платформа и точност, след което публикуваме фиксирана моментна снимка. CI я използва повторно; не изгражда екземпляра при всяка заявка за промяна.

Запазваме и оригиналния файлов формат на теглата. В противен случай бихме пропуснали кода за преобразуване, който се изпълнява, когато потребител зарежда реалната контролна точка. Пълната рецепта съдържа повече подробности.

Докладът за свиването на Llama 4 Scout показва как изглежда това при голям модел. 108,6 милиарда параметъра стават 44,7 милиона. Зрителният стек преминава от 34 слоя към 2, а езиковият стек — от 48 към 4, като запазва проверените видове слоеве и стила на маршрутизиране на MoE.

Изграждане на MIC с агенти

Нашият CLI, tmic, създава договора и изгражда екземпляра. За нов модел LLM създава чернова на кода за използване и манифеста, а изпълненията на CPU и GPU измерват кандидатите за базови резултати. LLM създава черновата; той не я одобрява. Променените очаквания изискват човешки преглед.

За да го изпробвате на своята машина, използвайте изходната си контролна точка вместо org/model:

pip install "transformers-mic[runtime]" "hf-doc-builder @ git+https://github.com/huggingface/doc-builder.git"
hf auth login
tmic run org/model --local-only --fixtures-only --no-history --bill-to ''

Той създава чернова на договора, изгражда екземпляра и записва базовите му резултати на вашата машина, като ви моли да прегледате всяка стъпка и спира, преди да качи каквото и да било. За нов модел черновата идва от LLM чрез Inference Providers и се таксува към вашия акаунт (--bill-to ''). Документацията на CLI описва отделните стъпки.

Използвахме агенти за изграждане на MIC в различни семейства модели. Когато се сблъскваха с краен случай, поправяхме самата рецепта, а не единичния екземпляр, с помощта на експерти по модели. Публикуваните модели и оставащите пропуски са в пространството за покритие.

Случайни тегла срещу донапасване

При случайни тегла нашият екземпляр на Whisper почти не реагираше на промени в аудиото. Работеше, но това го правеше слаб тест на аудио пътя.

Затова го обучихме върху няколко тона, съчетани с думи като „red“ и „green“. Не го учехме на разпознаване на реч, а просто правехме промените в аудиото видими в изходите му. В нашето проучване на инициализацията на теглата случайните екземпляри на Whisper откриха 18 от 24 изкуствено въведени грешки. Екземплярите с донапасване откриха и 24-те.

Това ни дава два начина за изграждане на теглата:

Започваме със случайни тегла и фиксирано начално число.
Донапасваме върху няколко примера, например „The capital of France is“ => „Paris“.

Резултатът за Whisper не определя кой подход е по-добър. Това бяха синтетични грешки и не сме открили реална регресия, прихваната само от версията с донапасване. И двете версии пропуснаха грешка при асистирано декодиране, която реалната контролна точка на Whisper разкри.

Затова запазваме случайните тегла, когато преминат проверките, и използваме донапасване, когато ни е нужна по-добра чувствителност или четими отговори. Обучението отнема секунди, но е още една стъпка, която може да не достигне сходимост, и още нещо за поддръжка. Сравнението съдържа резултатите и за двата подхода.

Отворени въпроси

Към 1 ноември 2026 г. MIC задачата в CI на Transformers съобщава за грешки, без да блокира заявките за промяна. Дали трябва да ги блокира зависи от неща, които все още не сме измерили:

Колко реални грешки открива при заявките за промяна, а не само при повторно изпълнение?
Колко често ни кара да преследваме фалшиви сигнали?
Колко работа отнемат прегледите на базовите резултати?

Също така не знаем колко грешки, като тази при асистираното декодиране на Whisper, се появяват само с реални тегла или дали донапасването открива реални грешки, които случайните тегла пропускат.

Покритието все още е частично — както по отношение на семействата модели, така и на API-тата, които хората използват. Когато регресия се промъкне, можем да добавим липсващия път на използване и да го повторим върху повредената и поправената версия. Ще запазим съществуващите тестове, докато покритието им не бъде отчетено.

Накрая бихме искали да свържем оригиналните страници на моделите в Hub с техните MIC, така че разработчик или агент, използващ контролна точка, да може да започне от пример, тестван върху тази контролна точка, нейната среда и очакваните ѝ изходи.

Искате да помогнете? Изберете модел без покритие от пространството за покритие, изпробвайте работния процес на tmic и допринесете с път на използване или прегледайте генериран договор.