KernelEvo — автоматическая генерация GPU-ядер

Писать быстрые GPU‑ядра вручную долго и требует узкой экспертизы: нужно понимать модель памяти, эффективные паттерны доступа к памяти, ограничения конкретного бэкенда и уметь быстро разбираться в compile и runtime ошибках. При этом выигрыш от кастомного kernel'а может быть очень заметным. Поэтому автоматизация и упрощение процесса разработки ядер — практически важная задача.

В этой статье расскажу о KernelEvo — новом фреймворке от команды «Вычислительный интеллект» Института AIRI, позволяющем по исходному коду автоматически искать эффективные cuda и triton реализации. Ключевая идея простая: вместо ручного цикла «написал → проверил → увидел ошибку → переписал» мы строим автоматический search loop. В типовом сценарии на одну задачу уходит до ~1 млн токенов, что делает такой поиск достаточно выгодным для регулярных запусков.

Подробности далее.

Какие существуют варианты для создания kernel’а

Сегодня у разработчика, которому необходимо ускорить CUDA/Triton‑реализацию, есть четыре рабочих пути:

1. Написать и оптимизировать kernel вручную.

2. Использовать LLM как «копилота» и вручную её направлять.

3. Использовать LLM с автоматическим циклом обратной связи (KernelEvo).

4. Использовать автономного агента, который сам проектирует шаги поиска (типа OpenClaw).

Все они имеют право на жизнь и имеют свой баланс необходимой экспертизы, времени инженера и денежных затрат.

Написать и оптимизировать kernel вручную

Вы сами пишете код, сами профилируете его, сами разбираете ошибки и шаг за шагом улучшаете реализацию.

Плюсы:

• Минимальные прямые денежные затраты.

• Полный контроль над процессом.

Минусы:

• Нужен высокий уровень GPU‑экспертизы.

• Цикл разработки может затягиваться (всегда есть идеи, что бы ещё попробовать).

• Плохо масштабируется: каждую новую задачу приходится решать заново.

Это лучший вариант, если задача критична, а в команде уже есть сильный специалист по оптимизациям на GPU.

Использовать LLM как «копилота»

Здесь модель уже помогает писать код, но человек остаётся «у руля»: подсказывает направление, скидывает логи и трейсы ошибок, уточняет ограничения, просит переписать проблемные места и вручную отбирает удачные решения.

Плюсы:

• Заметно ниже порог входа.

• Первые рабочие версии можно получить быстрее.

• Хорошо подходит для точечной помощи.

Минусы:

• Все еще нужна активная вовлеченность.

• Нужно понимать, как выглядит «хорошее» решение.

• Остается много ручной работы.

Хороший компромисс для получения хоть какого‑то решения. Для GPU‑специалиста это ещё и удобный способ быстро генерировать гипотезы.

Использовать LLM с автоматической обратной связью

Это режим, ради которого и сделан KernelEvo. Человек задаёт исходную конфигурацию, а дальше запускается автоматический цикл: генерация → проверка → починка → повторная попытка.

Плюсы:

• Достаточно один раз настроить задачу.

• Снижается объём ручной рутины.

• Один и тот же подход можно переиспользовать на разных задачах.

Минусы:

• Нужен начальный сетап.

• Стоимость выше, чем у ручного режима.

• Стабильность зависит от модели, seed«ов и качества тестов.»

На практике именно этот вариант даёт лучший баланс между качеством, затратами и требуемой экспертизой.

Использовать автономного агента

Самый «ленивый» режим с точки зрения участия человека: задаете цель, ограничения и тесты, а дальше агент сам исследует пространство решений, сам придумывает промежуточные шаги и сам же их проверяет.

Плюсы:

• Минимальная вовлечённость человека.

• Низкий порог входа.

• Иногда может находить неочевидные ходы.

Минусы:

• Стоимость легко раздувается до 100–1000 долларов.

• Время прогона обычно дольше.

• Поведение менее предсказуемо.

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

• Качество сильно зависит от того, насколько агент вообще умеет удерживать задачу и не уходить в нецелевые действия.

Для production‑процесса это пока скорее инструмент дорогого исследования, чем повседневный рабочий путь.

Что по стоимости и времени

Получается такая картина:

• Ручной путь: деньги почти не тратятся, но времени уходит много.

• LLM как copilot: стоимость низкая (достаточно обычной подписки), время — от нескольких часов на задачу.

• Kernel evolution: стоимость уже заметная, но остаётся контролируемой. Типично это 30 минут на сетап и затем несколько часов автоматического прогона.

• Автономный агент: стоимость может быть практически неограниченной, если дать агенту долго «играть» в поиск. Времени на ожидание результата в итоге уйдет много.

Главный вывод здесь такой: по мере перехода от первого пункта нашего списка к последнему растёт денежная стоимость решения, но падает требуемая экспертиза. На практике именно второй и третий варианты дают лучший баланс. Второй хорош как быстрый вход для специалистов, KernelEvo (третий) — как основной инструмент для генерации kernel«ов или идей для дальнейшей оптимизации руками — именно на нём мы и остановились.»

Далее я расскажу о том, как устроено наше решение.

Архитектура решения

Архитектурно система разделена на следующие компоненты:

1. Task Setuper задаёт шаблон, входные параметры и формирует саму задачу эволюции.

2. Gigaevo выступает оркестратором: принимает задачу, запускает pipeline и хранит общее состояние процесса.

3. Redis нужен как внешнее хранилище состояния: в нём живут конфиги, промежуточные результаты и лучший найденный кандидат.

4. Pipeline Builder управляет жизненным циклом одной эволюции: решает, когда запросить новый код, когда отправить его на проверку и когда запустить repair‑цикл.

5. Code Module генерирует очередного кандидата.

6. Repair Module пытается чинить неудачные варианты. Это важно, потому что даже сильные модели регулярно производят код, который компилируется или исполняется некорректно.

7. Validator Server проверяет решение: проходит ли оно тесты, соблюдает ли ограничения и даёт ли ускорение. Логи валидации видны прямо в сервере.

Подходящие модели

Мы прогнали доступные на момент выхода статьи популярные модели в openrouter и увидели довольно простой критерий отбора: для этой задачи мало «в целом уметь программировать». Вообще говоря, модель должна также нормально знать синтаксис CUDA/Triton и уметь чинить собственный код по логам. На практике же многие модели выдают правдоподобный, но падающий при запуске код и затем не могут исправить его даже за несколько итераций.

Имеет смысл начинать с относительно дешевой Gemini Flash 3. Среди подходящих моделей — эта самая дешевая (при этом достаточно быстрая).
Из open‑source‑кандидатов неплохо подошли всего 2 кандидата:

1. glm5. Хотя предыдущие версии постоянно уходили в цикл, пятая оказалась хороша.

2. gpt‑oss-120b. Модель не так умна, но знает синтаксис достаточно, чтобы получить ускорения на небольших ядрах. На сложных задачах, к сожалению, ее не хватает.

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

Эксперименты

Сетап

Для тестирования ускорения мы используем KernelBench. Бенчмарк содержит задачи разного уровня и проверяет не только корректность сгенерированного kernel’а, но и реальное ускорение относительно reference baseline.

Интересно, что всего год назад на нём замеряли то, «как близко можно приблизиться к pytorch». Сегодня — уже можем обогнать реализации бенчмарка.

Level 1

Задачи Level 1 — самые изолированные с инженерной точки зрения. Здесь выигрыш обычно достигается за счёт более удачной реализации одного конкретного ядра.

На таких задачах можно увидеть и наибольшее ускорение:

На задачах Level 1 KernelEvo быстро находит первые улучшения, но максимальное ускорение может появиться только после плато. Это особенно хорошо видно на Task 40, где финальный скачок происходит существенно позже первого качественного улучшения.

Level 2

На Level 2 постановка немного другая. Здесь задача редко сводится к «написать более быстрый kernel». Обычно исходная реализация — цепочка нескольких элементарных операций. Основной источник ускорения — фьюзинг операций вместе — позволяет избегать лишних промежуточных записей и синхронизаций между шагами.

Соответственно и результат оптимизации таких задача как правило хуже, тем не менее все еще полезен на практике.

В задачах Level 2 основной выигрыш даёт не микрооптимизация одного kernel’а, а удачный fusion нескольких операций. Поэтому итоговые ускорения скромнее, но и сами задачи ближе к реальным прикладным сценариям.

Triton vs cuda_inline

Оба бекенда доступны для генерации в рамках KernelEvo. Шаблон nn.Module в KernelEvo остаётся одним и тем же - меняется только реализация вычислительного ядра.

Triton удобен тем, что предоставляет упрощенный способ реализации ядер и на задачах Level 1 ведет себя в целом стабильнее.

CUDA inline / C++ extension даёт другой путь: код компилируется и вызывается как часть C++/CUDA‑расширения. Это может быть удобнее, если нужен более низкоуровневый контроль или решение предназначается для Edge устройств.

По нашим замерам однозначного победителя нет, результат отличается от задачи к задаче. Разве что triton на Level 1 сходится в среднем быстрее.

При этом и начинать явно будет проще с triton.

Воспроизводимость

Время до нахождения сильного решения заметно зависит от seed«а. На одних прогонах система находит хороший кандидат довольно быстро, на других — может долго топтаться на месте. Поэтому на практике разумное правило простое: если за условные 30 итераций нет заметного прогресса, лучше перезапустить эволюцию, чем ждать просветления текущей траектории.»

Даже при одинаковой конфигурации отдельные seed’ы могут вести себя радикально по‑разному. Поэтому рестарт — нормальная часть рабочего процесса. На графике — среднее время операции на разных итерациях и запусках на одних и тех же параметрах.

Данный эффект можно снизить, увеличив число островов для эволюции (тогда в начале будет сразу много разных seed решений). Но и количество запросов к LLM и реальное время шага эволюции — вырастет.

Выводы

Ручной путь по‑прежнему остаётся самым дешёвым по деньгам и наиболее контролируемым, но он требует высокой экспертизы и плохо масштабируется. LLM как «копилот» помогает ускориться, но оставляет на человеке почти весь операционный контроль.

Наш KernelEvo интересен тем, что автоматизирует самый продолжительный участок работы — повторяющийся цикл генерации, проверки и исправления кандидатов. За счёт этого он уже полезен не как «забавное демо», а как инженерный инструмент для поиска первых быстрых реализаций, перебора гипотез и генерации идей, которые потом можно дожать вручную.

Будем рады вашим звёздам на нашем GitHub!

Канал автора по инфраструктуре нейросетей.

Источник