Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Скрытые ошибки компилятора XLA:TPU научились находить и локализовать даже тогда, когда программа завершается без сбоев, но незаметно искажает числа. Система помогла устранить более 142 дефектов, хотя препринт не рецензирован и числа в нём получили сами авторы. Для команд со своим компилятором или ускорителем это готовая схема непрерывной проверки, которую можно встроить в уже работающий контур настройки производительности.
Почему набора регрессионных тестов недостаточно
XLA превращает граф тензорных операций в команды для TPU и по пути применяет аппаратно-зависимые оптимизации. Одна из ключевых — слияние нескольких операций в общее ядро, которое держит промежуточные данные в быстрой памяти ускорителя вместо записи во внешнюю память.
Такой конвейер создаёт слишком много сочетаний форм тензоров, способов разбиения данных, схем буферизации и настроек компилятора. Тест может пройти на обычной конфигурации и сломаться после того, как настройщик производительности выберет другой размер блока или иной порядок обработки данных.
Самые опасные дефекты не завершают процесс аварийно. Скомпилированная программа работает, но неверно вычисляет индекс, перезаписывает регистр или читает неподготовленный участок памяти. Результат выглядит как нестабильное обучение или ухудшение качества модели, а не как ошибка компилятора.
Проблему усиливает размер нагрузки: более 40% исследованных производственных графов содержали свыше 10 тысяч узлов, причём каждое объединённое ядро считалось одним узлом. Проверять такой граф вручную и затем разбирать внутренности ядра непрактично.
Как поиск проходит от целого графа до одной операции
Первый слой системы — управляемый шаблонами фаззинг, то есть автоматическая генерация множества корректных программ с необычными сочетаниями операций и форм тензоров. Генератор строит программу с учётом типов и ограничений операций, а затем сравнивает результат на TPU с эталонным вычислением.
Синтетических примеров оказалось недостаточно: они плохо воспроизводят структуру настоящих моделей и давление на память. Поэтому дифференциальную проверку, при которой два варианта исполнения получают одинаковый вход и должны дать близкий результат, встроили в производственную настройку производительности. Настройщик и так перебирает нестандартные конфигурации; теперь он одновременно проверяет их выходы относительно базового варианта.
Реальные трассы дают характерные для производства графы, а генератор исследует узкие места отдельных проходов компилятора. ИИ-агенты расширяют охват: изучают код прохода, создают направленные тесты, отбрасывают некорректные входы, уменьшают воспроизводящий пример и готовят исправление. Основная масса поисков идёт на симуляторах, а физические TPU используют для окончательного подтверждения.
Когда расхождение найдено в большой нагрузке, система последовательно делит граф и проверяет его части. Входы подбираются с учётом ограничений последующих операций, чтобы не получить недопустимые значения вроде отрицательного аргумента там, где операция принимает только положительные числа.
После локализации объединённого ядра проверка переходит внутрь него. Обычно промежуточные тензоры остаются в регистрах и недоступны обычным средствам диагностики; инструмент делает их наблюдаемыми и сравнивает с эталоном после отдельных операций. Так ошибка сужается от полного графа до конкретного шага внутри ядра.
Ещё 103 исправления на момент подготовки работы проходили проверку. При этом даже 5% ложных срабатываний команда считает достаточными, чтобы разработчики перестали доверять системе. Поэтому фильтрация недопустимых входов и точность эталонного вычислителя здесь не менее важны, чем генерация новых тестов.
Что менять в планах командам со своим компилятором
Работа меняет приоритеты для команд, которые разрабатывают компилятор моделей, собственные ядра или аппаратный серверный контур. Проверку корректности стоит связывать с настройкой производительности, а не оставлять только в непрерывной интеграции: именно настройщик регулярно попадает в редкие конфигурации, которые обычные тесты обходят.
Второй практический шаг — сочетать синтетические программы с сохранёнными производственными трассами. Первые быстро проверяют новые проходы и граничные случаи, вторые сохраняют реальные сочетания операций, требования к памяти и часто используемые пути генерации кода.
Автоматическая локализация важнее раннего подключения агентов. Сырые журналы расхождений редко превращаются в исправления, тогда как небольшой автономный тест даёт разработчику воспроизводимый дефект и одновременно ставит агенту проверяемую задачу.
Агентам в этой схеме подходят ограниченные роли: создать направленный тест, уменьшить пример, предложить компактную правку и прогнать проверки. Патчи готовятся в изолированных копиях кода, проходят независимую проверку другими агентами и поступают человеку только после фильтрации. Это снижает нагрузку на сопровождающих и не передаёт модели право самостоятельно менять производственный компилятор.
Масштаб проверки — XLA:TPU внутри производственной инфраструктуры Google, несколько поколений TPU и реальные графы моделей. Главный результат работы относится не к универсальному качеству конкретного фаззера, а к архитектуре процесса: искать расхождения на существующем потоке нагрузок, автоматически уменьшать область поиска и только затем подключать агентов к исправлению.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
