Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Официальный чекер KernelBench систематически принимает ошибочные GPU-кернелы за правильные. В препринте, который не проходил рецензирование и содержит замеры самих авторов, проверка пропустила 16,9% дефектов, которые заведомо можно обнаружить. Если её вердикт служит наградой при обучении модели, модель может научиться проходить тесты вместо того, чтобы писать корректный код.
Как измеряли силу проверки
Проверяющий оракул в KernelBench состоит из эталонной реализации, входных данных и правил сравнения чисел с плавающей точкой. Несколько случайных входов подают на эталонный и сгенерированный кернелы, после чего результаты сравнивают с допустимым отклонением. Такой протокол выдаёт ответ «верно» или «неверно», но сам по себе не показывает, какую долю возможных ошибок он видит.
Работа переносит на GPU-кернелы мутационный анализ — проверку тестов с помощью намеренно испорченных программ. Исходный корректный CUDA-код меняют небольшими детерминированными правками: удаляют барьер синхронизации, путают оси индексации, меняют округление размера сетки, снижают точность накопления или сдвигают границу условия. Затем каждый испорченный вариант прогоняют через проверку.
Эксперимент охватил 188 задач KernelBench. Правила породили 10 303 компилируемых варианта с дефектами, но в итоговый расчёт вошли только 7 384 варианта, для которых нашли хотя бы один допустимый вход, надёжно выявляющий ошибку. Этот «свидетель» не даёт занизить результат эквивалентными правками или дефектами, которые числовая проверка в принципе не различает.
Допустимость входа проверяли отдельно. Слишком агрессивные значения могут заставить две корректные реализации разойтись из-за разного порядка операций с плавающей точкой. Без такого фильтра усиленный тест начинает браковать правильные кернелы и выглядит строгим лишь потому, что путает численную погрешность с ошибкой.
Допуск скрывает ошибки, а случайные входы их не возбуждают
Самый наглядный промах возникает у softmax по 393 216 элементам. Эталонный результат настолько мал, что при абсолютном допуске 10−2 кернел, возвращающий одни нули, проходит все официальные испытания. Чем длиннее редукция и меньше отдельные значения результата, тем шире слепая зона проверки.
Повторный запуск с другими случайными числами не исправляет дефект распределения. Официальные входы положительны, поэтому удаление ReLU не меняет результат. Те же входы не доводят экспоненту до переполнения, и проверка не замечает удалённую стабилизацию softmax.
Ошибки распределились по типам неравномерно. Проверка обычно ловила простые замены арифметических операций, но пропускала 78,6% дефектов точности. Ошибки на границах блоков скрывались на выровненных размерах, а дефекты синхронизации — на небольших однородных нагрузках.
Матрица «дефект — вход» позволила не только оценивать готовые протоколы, но и собирать наборы тестов автоматически. Оптимизация выбрала по два взаимодополняющих входа на задачу и достигла 98% обнаружения; на отложенных дефектах результат составил 94,8%. Полезной оказалась связка из плотного случайного входа и входа, нацеленного на структуру задачи: только специальные значения тоже оставляют слепые зоны.
Что менять в планах команд
Работа не даёт оснований отказаться от KernelBench, но меняет смысл его результата. Прохождение официальной проверки нельзя считать достаточным доказательством корректности, особенно для кернелов с редукциями, накоплением в пониженной точности, остаточными блоками и сложной синхронизацией.
Для сравнительного бенчмарка стоит публиковать не только долю прошедших задач, но и мутационное покрытие самого чекера. Тогда добавленный набор входов можно оценить по конкретным семействам дефектов, а не по нескольким вручную выбранным примерам. Ужесточение допуска и новые распределения входов решают разные проблемы, поэтому их эффект следует измерять отдельно.
Для обучения с подкреплением риск выше: слепая зона становится частью функции награды. В контур проверки стоит включить входы разных форм и структур, тесты остаточных блоков и отдельные сценарии для точности и синхронизации. Каждый сгенерированный вход должен сначала пройти фильтр на корректных реализациях, иначе модель получит штраф за допустимую численную разницу.
Метод остаётся относительной мерой, а не доказательством правильности. Он видит только классы ошибок, представленные правилами мутации; исследование проводили на LLM-сгенерированных эталонных CUDA-реализациях и одной генерации GPU — H100. Правила не покрывают часть реализаций с tensor cores, двойной буферизацией и несколькими взаимодействующими дефектами.
Практический результат — проверку теперь можно улучшать как измеряемую систему. Сначала команда задаёт модель характерных ошибок, затем строит матрицу обнаружения, выбирает дополняющие друг друга входы и повторяет замер после каждого изменения. Такой процесс не сертифицирует кернел, но показывает, какую именно слепую зону закрывает новый тест.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
