ИИ-агент перенёс метеомодель CReSS на GPU: 250 000+ строк и ускорение в 5,1 раза

Авторы отмечают: развитие больших языковых моделей превратило ИИ-агентов, управляемых через командную строку (CLI), в практичный инструмент ускорения переноса на GPU для крупных научных приложений, унаследованных от прошлых десятилетий. Но такие приложения, не просто старый код: это накопленный за годы разработки, сверки с наблюдениями и практического использования актив, чья научная достоверность важна сама по себе, и перенос на GPU-ориентированные HPC-системы (высокопроизводительные вычислительные кластеры) обязан сохранить эту достоверность, а не просто ускорить исполнение. Проверяя эту идею на практике, авторы статьи предлагают рабочий процесс переноса на GPU, построенный вокруг проверки результатов, и испытывают его в кейс-стади: переносе CReSS, унаследованного метеорологического кода на Fortran объёмом более 250 000 строк, на GPU с помощью такого ИИ-агента.

Рабочий процесс состоит из нескольких шагов. Сначала ИИ-агент находит в коде OpenMP-регионы, участки, распараллеленные для CPU через стандарт OpenMP. Для каждого такого участка по дампу (снимку) физически значимого состояния реальной, а не синтетической, симуляции строится эталонный бенчмарк. Затем агент применяет к этому участку OpenACC-трансформации, переносит вычисления на GPU через директивы стандарта OpenACC. Наконец, результат проверяется дважды: поэлементным сравнением с дампом эталонных данных для каждого отдельного вычислительного ядра и отдельно, проверкой на уровне всего приложения целиком.

На данных реальной симуляции тайфуна этот процесс дал численно проверенные GPU-реализации для 162 целевых вычислительных ядер и ускорил работу всего приложения в 5,1 раза, авторы отмечают, что уложились в практически приемлемые сроки разработки, не приводя точных цифр трудозатрат. При этом в пяти ядрах проверка нашла численные расхождения, из-за различий в вычислениях с плавающей запятой и во встроенных функциях (intrinsic functions), включая расхождение ветвлений (branch divergence) вблизи пороговых значений и потерю точности при вычитании близких по величине чисел. Эти пять расхождений не остались незамеченными: о них сообщили разработчикам исходного приложения.

Кейс-стади наводит на более общий вывод: для подобных крупных научных приложений, где перенос нужно проверять по дампам, практический ИИ-перенос на GPU должен отдельно решать три проблемы, управлять контекстом, который выходит за рамки одной рабочей сессии агента, восстанавливать состояние программы во время выполнения для генерации дампов и дорого исправлять последствия даже небольших пропусков в статическом анализе кода. Итоговый тезис авторов: ИИ-перенос на GPU требует не только генерации кода агентом, но и отдельного продуманного рабочего процесса, ориентированного на проверку результатов. Препринт опубликован на arXiv 13 августа 2026 года; авторы указаны поимённо, но не называют ни организацию, ни конкретный инструмент или модель ИИ-агента, ни модель использованного GPU, ни базовую (CPU-only) скорость выполнения, от которой считали ускорение в 5,1 раза.

Ключевые факты

Кейс-стади: ИИ-агент, управляемый через командную строку, перенёс на GPU CReSS, унаследованный метеорологический код на Fortran объёмом более 250 000 строк.
Рабочий процесс: агент находит OpenMP-регионы, строит эталонные бенчмарки по дампам физически значимых состояний реальной симуляции, применяет OpenACC-трансформации и дважды проверяет результат, поэлементно по каждому ядру и на уровне всего приложения.
На данных реальной симуляции тайфуна получены численно проверенные GPU-реализации для 162 целевых вычислительных ядер и ускорение всего приложения в 5,1 раза.
В пяти ядрах найдены реальные численные расхождения из-за различий в вычислениях с плавающей запятой и встроенных функциях, о них сообщили разработчикам исходного кода.
Вывод авторов: ИИ-перенос на GPU для научных приложений нужно строить вокруг проверки результатов, а не только вокруг генерации кода, иначе трудно управлять контекстом между сессиями агента и дорого исправлять пропуски статического анализа.

Почему это важно

Научные коды вроде CReSS копят доверие десятилетиями: их результаты сверяют с реальными наблюдениями, и на них годами опираются прикладные исследования. Перенос такого кода на GPU ради скорости рискует незаметно сломать численную точность и обесценить это доверие. Кейс-стади показывает, что ИИ-агент способен не просто механически переписать код под GPU, а делать это с постоянной проверкой: сверять каждое перенесённое вычислительное ядро с эталонными дампами и отдельно проверять итог на уровне всего приложения. Это предметный пример того, что перенос научного кода ИИ-агентом может быть не только быстрым, 5,1-кратное ускорение, но и численно доказуемо корректным.

Кому это важно

Инженерам и научным группам, которые держат крупные унаследованные приложения на Fortran или C, климатические, метеорологические, физические модели, и рассматривают перенос на GPU-кластеры. Разработчикам HPC-инструментов и всем, кто оценивает, можно ли доверить ИИ-агентам перенос кода, где ошибка в вычислениях, не просто баг, а искажение научного результата. Шире, всем, кто использует ИИ-агентов, управляемых через командную строку, для крупного рефакторинга унаследованного кода вообще: описанная в статье методика проверки (дамп состояния плюс поэлементное сравнение) не привязана конкретно к метеорологии.

Как это применить

Схема из статьи воспроизводима как рецепт: 1) найти в коде OpenMP-регионы, участки, распараллеленные для CPU, это естественные кандидаты на перенос; 2) для каждого такого участка снять дамп физически значимого состояния реальной (не синтетической) симуляции и превратить его в эталонный бенчмарк; 3) поручить ИИ-агенту применить к участку OpenACC-трансформации; 4) сверить результат с дампом поэлементно, ядро принимается только при полном совпадении. Шаги 1, 4 в кейс-стади повторили для 162 целевых ядер; отдельно, уже для перенесённого приложения целиком, проверили совпадение результата на данных реальной симуляции тайфуна.

Можно ли доверять

Главный довод в пользу доверия, не заявленное ускорение само по себе, а то, что метод поймал реальные ошибки: пять ядер с расхождениями из-за особенностей вычислений с плавающей запятой и встроенных функций были обнаружены и переданы разработчикам исходного кода, то есть проверка сработала не формально. Но это препринт на arXiv (опубликован 13 августа 2026 года), без указания площадки публикации сверх категории по параллельным и распределённым вычислениям; авторы указаны поимённо, но без организации в доступном тексте. Не названы ни конкретный инструмент или модель ИИ-агента, ни модель GPU, ни базовая (CPU-only) скорость выполнения, от которой считали ускорение в 5,1 раза, ни точные трудозатраты разработки, сказано лишь, что они уложились в практически приемлемые сроки. Повторить точные условия эксперимента по одному препринту нельзя, хотя сама методика проверки описана предметно.

Риски и подводные камни

Это кейс-стади на одном приложении и одном классе задач, метеомодели для симуляции тайфуна; переносится ли методика на код другой природы, авторы не проверяли. Не указано, сколько всего вычислительных ядер в полном 250-тысячном кодовом объёме и какую долю от них составляют перенесённые 162, масштаб покрытия неясен. Сами авторы называют три предметные сложности: контекст, который выходит за рамки одной рабочей сессии агента, приходится сохранять и передавать между сессиями; состояние программы во время выполнения нужно восстанавливать заново для генерации дампов; а исправление даже небольших пропусков статического анализа кода обходится дорого по времени. Ускорение в 5,1 раза, заявленный итоговый показатель без названного базового (CPU-only) значения для сравнения, поэтому напрямую оценить его в других условиях, другое железо, другая нагрузка, невозможно.

«Эти результаты показывают, что ИИ-перенос на GPU требует не только генерации кода, но и построения рабочего процесса, ориентированного на проверку результатов.»

— авторы работы