Писать быстрые GPU‑ядра вручную долго и требует узкой экспертизы: нужно понимать модель памяти, эффективные паттерны доступа к памяти, ограничения конкретного бэкенда и уметь быстро разбираться в compile и runtime ошибках. При этом выигрыш от кастомного kernel’а может быть очень заметным. Поэтому автоматизация и упрощение процесса разработки ядер — практически важная задача.
В этой статье расскажу о KernelEvo — новом фреймворке от команды «Вычислительный интеллект» Института AIRI, позволяющем по исходному коду автоматически искать эффективные cuda и triton реализации. Ключевая идея простая: вместо ручного цикла «написал → проверил → увидел ошибку → переписал» мы строим автоматический search loop. В типовом сценарии на одну задачу уходит до ~1 млн токенов, что делает такой поиск достаточно выгодным для регулярных запусков.
Подробности далее.
Какие существуют варианты для создания kernel’а
Сегодня у разработчика, которому необходимо ускорить CUDA/Triton‑реализацию, есть четыре рабочих пути:
-
Написать и оптимизировать kernel вручную.
-
Использовать LLM как «копилота» и вручную её направлять.
-
Использовать LLM с автоматическим циклом обратной связи (KernelEvo).
-
Использовать автономного агента, который сам проектирует шаги поиска (типа OpenClaw).
Все они имеют право на жизнь и имеют свой баланс необходимой экспертизы, времени инженера и денежных затрат.
Написать и оптимизировать kernel вручную
Вы сами пишете код, сами профилируете его, сами разбираете ошибки и шаг за шагом улучшаете реализацию.
Плюсы:
-
Минимальные прямые денежные затраты.
-
Полный контроль над процессом.
Минусы:
-
Нужен высокий уровень GPU‑экспертизы.
-
Цикл разработки может затягиваться (всегда есть идеи, что бы ещё попробовать).
-
Плохо масштабируется: каждую новую задачу приходится решать заново.
Это лучший вариант, если задача критична, а в команде уже есть сильный специалист по оптимизациям на GPU.
Использовать LLM как «копилота»
Здесь модель уже помогает писать код, но человек остаётся «у руля»: подсказывает направление, скидывает логи и трейсы ошибок, уточняет ограничения, просит переписать проблемные места и вручную отбирает удачные решения.
Плюсы:
-
Заметно ниже порог входа.
-
Первые рабочие версии можно получить быстрее.
-
Хорошо подходит для точечной помощи.
Минусы:
-
Все еще нужна активная вовлеченность.
-
Нужно понимать, как выглядит «хорошее» решение.
-
Остается много ручной работы.
Хороший компромисс для получения хоть какого‑то решения. Для GPU‑специалиста это ещё и удобный способ быстро генерировать гипотезы.
Использовать LLM с автоматической обратной связью
Это режим, ради которого и сделан KernelEvo. Человек задаёт исходную конфигурацию, а дальше запускается автоматический цикл: генерация → проверка → починка → повторная попытка.
Плюсы:
-
Достаточно один раз настроить задачу.
-
Снижается объём ручной рутины.
-
Один и тот же подход можно переиспользовать на разных задачах.
Минусы:
-
Нужен начальный сетап.
-
Стоимость выше, чем у ручного режима.
-
Стабильность зависит от модели, seed«ов и качества тестов.»
На практике именно этот вариант даёт лучший баланс между качеством, затратами и требуемой экспертизой.
Использовать автономного агента
Самый «ленивый» режим с точки зрения участия человека: задаете цель, ограничения и тесты, а дальше агент сам исследует пространство решений, сам придумывает промежуточные шаги и сам же их проверяет.
Плюсы:
-
Минимальная вовлечённость человека.
-
Низкий порог входа.
-
Иногда может находить неочевидные ходы.
Минусы:
-
Стоимость легко раздувается до 100–1000 долларов.
-
Время прогона обычно дольше.
-
Поведение менее предсказуемо.
-
Агент может тратить бюджет на лишние промежуточные действия, которые в специализированном фреймворке уже зафиксированы.
-
Качество сильно зависит от того, насколько агент вообще умеет удерживать задачу и не уходить в нецелевые действия.
Для production‑процесса это пока скорее инструмент дорогого исследования, чем повседневный рабочий путь.
Что по стоимости и времени
Получается такая картина:
-
Ручной путь: деньги почти не тратятся, но времени уходит много.
-
LLM как copilot: стоимость низкая (достаточно обычной подписки), время — от нескольких часов на задачу.
-
Kernel evolution: стоимость уже заметная, но остаётся контролируемой. Типично это 30 минут на сетап и затем несколько часов автоматического прогона.
-
Автономный агент: стоимость может быть практически неограниченной, если дать агенту долго «играть» в поиск. Времени на ожидание результата в итоге уйдет много.
Главный вывод здесь такой: по мере перехода от первого пункта нашего списка к последнему растёт денежная стоимость решения, но падает требуемая экспертиза. На практике именно второй и третий варианты дают лучший баланс. Второй хорош как быстрый вход для специалистов, KernelEvo (третий) — как основной инструмент для генерации kernel«ов или идей для дальнейшей оптимизации руками — именно на нём мы и остановились.»
Далее я расскажу о том, как устроено наше решение.
Архитектура решения
Архитектурно система разделена на следующие компоненты:
-
Task Setuper задаёт шаблон, входные параметры и формирует саму задачу эволюции.
-
Gigaevo выступает оркестратором: принимает задачу, запускает pipeline и хранит общее состояние процесса.
-
Redis нужен как внешнее хранилище состояния: в нём живут конфиги, промежуточные результаты и лучший найденный кандидат.
-
Pipeline Builder управляет жизненным циклом одной эволюции: решает, когда запросить новый код, когда отправить его на проверку и когда запустить repair‑цикл.
-
Code Module генерирует очередного кандидата.
-
Repair Module пытается чинить неудачные варианты. Это важно, потому что даже сильные модели регулярно производят код, который компилируется или исполняется некорректно.
-
Validator Server проверяет решение: проходит ли оно тесты, соблюдает ли ограничения и даёт ли ускорение. Логи валидации видны прямо в сервере.
Подходящие модели
Мы прогнали доступные на момент выхода статьи популярные модели в openrouter и увидели довольно простой критерий отбора: для этой задачи мало «в целом уметь программировать». Вообще говоря, модель должна также нормально знать синтаксис CUDA/Triton и уметь чинить собственный код по логам. На практике же многие модели выдают правдоподобный, но падающий при запуске код и затем не могут исправить его даже за несколько итераций.
Имеет смысл начинать с относительно дешевой Gemini Flash 3. Среди подходящих моделей — эта самая дешевая (при этом достаточно быстрая).
Из open‑source‑кандидатов неплохо подошли всего 2 кандидата:
-
glm5. Хотя предыдущие версии постоянно уходили в цикл, пятая оказалась хороша.
-
gpt‑oss-120b. Модель не так умна, но знает синтаксис достаточно, чтобы получить ускорения на небольших ядрах. На сложных задачах, к сожалению, ее не хватает.
Общая рекомендация — начните с моделей выше, и, когда настроите эволюцию и увидите хороший результат, пробуйте дорогие фронтирные модели.
Эксперименты
Сетап
Для тестирования ускорения мы используем KernelBench. Бенчмарк содержит задачи разного уровня и проверяет не только корректность сгенерированного kernel’а, но и реальное ускорение относительно reference baseline.
Интересно, что всего год назад на нём замеряли то, «как близко можно приблизиться к pytorch». Сегодня — уже можем обогнать реализации бенчмарка.
Level 1
Задачи Level 1 — самые изолированные с инженерной точки зрения. Здесь выигрыш обычно достигается за счёт более удачной реализации одного конкретного ядра.
На таких задачах можно увидеть и наибольшее ускорение:
Level 2
На Level 2 постановка немного другая. Здесь задача редко сводится к «написать более быстрый kernel». Обычно исходная реализация — цепочка нескольких элементарных операций. Основной источник ускорения — фьюзинг операций вместе — позволяет избегать лишних промежуточных записей и синхронизаций между шагами.
Соответственно и результат оптимизации таких задача как правило хуже, тем не менее все еще полезен на практике.
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 решений). Но и количество запросов к LLM и реальное время шага эволюции — вырастет.
Выводы
Ручной путь по‑прежнему остаётся самым дешёвым по деньгам и наиболее контролируемым, но он требует высокой экспертизы и плохо масштабируется. LLM как «копилот» помогает ускориться, но оставляет на человеке почти весь операционный контроль.
Наш KernelEvo интересен тем, что автоматизирует самый продолжительный участок работы — повторяющийся цикл генерации, проверки и исправления кандидатов. За счёт этого он уже полезен не как «забавное демо», а как инженерный инструмент для поиска первых быстрых реализаций, перебора гипотез и генерации идей, которые потом можно дожать вручную.
Будем рады вашим звёздам на нашем GitHub!
Канал автора по инфраструктуре нейросетей.
Автор: svtDanny
