30 июля 2026 года в библиотеке Transformers была внедрена возможность использования масштабированного внимания (scaled dot-product attention, SDPA) для модели T5. Это привело к тому, что декодер UMT5 получил возможность обращать внимание на будущие токены, что в свою очередь дало ему возможность заглядывать в ответ, который он должен был предсказать. Несмотря на это, никаких сбоев не произошло, и ошибка оставалась в основной ветке почти два месяца. Позже, при воспроизведении этих коммитов, небольшая модель UMT5, работающая на CPU, зафиксировала эту ошибку на каждом из них. В этой статье мы расскажем о модели и тестах, построенных вокруг нее.

Почему ошибки попадают в основную ветку

Библиотека Transformers поддерживает более 750 типов моделей, и ее тестовый набор довольно обширен: более 88,000 тестов для CPU на основной ветке и более 200,000 тестов для GPU, выполняемых ежедневно. Тесты моделей составляют лишь часть этого набора: мы также тестируем пайплайны, обучение, распределенное выполнение, квантование и ядра внимания. Интеграционные тесты загружают реальные контрольные точки и проверяют API модели на реальном оборудовании. Выполнение всех этих тестов для каждого pull request (PR) означало бы, что много GPU было бы занято на протяжении всего дня, что не является практичным. К моменту, когда запланированный запуск обнаружит регрессию, она уже может находиться в основной ветке.

Подход к тестированию: уменьшение модели

Наш подход заключается в уменьшении модели. Мы создаем фикстуру: небольшую модель, созданную на основе конфигурации реальной контрольной точки, с меньшим количеством и шириной слоев, но с сохранением всех типов слоев, а также неизменными файлами токенизатора и процессора. Эта фикстура публикуется один раз и затем переиспользуется. Мы запускаем "быстрые интеграционные тесты" на недорогом CPU-исполнителе. В нашем исследовании на CPU экспериментальная фикстура UMT5 использовала 66 МБ весов, в то время как исходная контрольная точка занимала 1,227 МБ. Это также охватывает очень большие модели: некоторые из них не помещаются на наши стандартные GPU-исполнители, но их фикстуры могут работать на CPU.

Стандарты тестирования: Контракты интеграции моделей

Предложенный стандарт для упаковки этих тестов называется transformers-mic. Контракт интеграции модели (Model Integration Contract, MIC) состоит из трех частей:

Фикстура: уменьшенная модель, описанная выше, опубликованная один раз.

Путь использования: исполняемый пример в формате Markdown, показывающий, как использовать модель, например, для генерации текста или выполнения шага обучения.

Базовые линии: результаты, записанные при выполнении этого примера, проверенные человеком.

Контракт считается действительным, если выполнение пути использования на фикстуре по-прежнему дает те же базовые линии. Контракт охватывает архитектуру и путь использования, а не одну контрольную точку: совместимые контрольные точки могут делить фикстуру, в то время как каждая из них сохраняет свои ожидаемые результаты. Мы публикуем их в huggingface-mic.

Регрессия UMT5

Мы воспроизвели замороженные MIC на протяжении пяти месяцев коммитов в Transformers. Небольшая фикстура UMT5 зафиксировала регрессию с момента ее появления 30 июля 2026 года до момента исправления 28 сентября. Логарифмические вероятности меток отличались от проверенной базовой линии на 1.22, а потеря при обучении — примерно на 0.20. Один важный момент: контракт использовал SDPA, стандартный путь внимания. Запуск только варианта eager attention не выявил ошибку. Фикстура помогает только в том случае, если она проходит через тот же код, что и реальная контрольная точка.

Как модели уменьшаются

Первый рецепт был прост: уменьшить размеры и оставить меньше слоев. Однако этого было недостаточно для смешанных архитектур. Теперь рецепт включает четыре шага: 1. Уменьшение конфигурации: начинаем с реальной контрольной точки и уменьшаем размеры скрытых слоев, количество голов внимания и глубину. Сохраняем разные виды слоев, включая смеси скользящего и полного внимания или плотных и MoE слоев. 2. Сохранение предварительной обработки: сохраняем словарь, специальные токены и размеры входных данных, копируя файлы токенизатора и процессора побайтово. 3. Создание и валидация весов: пробуем случайные веса и изменяем входные данные, чтобы проверить, как модель реагирует. Если она не реагирует, пробуем обучить ее на небольшом наборе примеров. 4. Заморозка и запись: сохраняем принятые веса и измеряем повторяемые результаты на известной хорошей сборке Transformers.

Использование агентов для создания MIC

Наш CLI, tmic, создает контракт и строит фикстуру. Для новой модели LLM (Large Language Model) генерирует код использования и манифест, а запуски на CPU и GPU измеряют кандидатные базовые линии. LLM генерирует, но не утверждает. Измененные ожидания требуют человеческой проверки.

Открытые вопросы

На 1 ноября 2026 года работа MIC в CI Transformers сообщает о сбоях, не блокируя PR. Должна ли она блокировать, зависит от того, сколько реальных ошибок она находит в PR, а не только в воспроизведениях. Мы также не знаем, сколько ошибок, таких как ошибка с помощью декодирования Whisper, проявляются только с реальными весами, или поймает ли переобучение реальные ошибки, которые пропустят случайные веса. Мы продолжим существующие тесты, пока их покрытие не будет учтено. В конечном итоге мы хотели бы связать оригинальные страницы моделей Hub с их MIC, чтобы разработчик или агент, использующий контрольную точку, могли начать с примера, протестированного на этой контрольной точке, ее окружении и ожидаемыми результатами.