GPU-решатели CFD: когда переход окупается и чем вы платите

Два расчёта, одно решение

Расчёт на GPU закончился до обеда. Тот же случай на CPU-кластере простоял в очереди всю ночь и считался почти всё следующее утро. Коэффициенты сопротивления совпадают до третьего знака, температура на выходе отличается на полградуса, и кто-то на совещании спрашивает, зачем команда вообще ещё считает на CPU.

Вопрос справедливый. Но сначала стоит задать более скучный. Под каким из двух ответов вы готовы поставить подпись?

Решатель CFD на GPU окупается, когда выполнены три условия: задача помещается в память GPU, использует только модели, которые поддерживает GPU-решатель, и достаточно велика, чтобы ускорение перекрыло более высокую почасовую стоимость оборудования. В этой статье показано, как проверить каждое условие до покупки или аренды, чем GPU-решатель отличается от своего CPU-собрата и на какую послеобеденную проверку я потратил бы время, прежде чем доверить ему решение.

Что на самом деле работает на GPU?

Под одними и теми же тремя буквами продают две совершенно разные вещи.

• Нативные GPU-решатели переносят на карту всю итерацию: сборку матрицы, решение линейной системы, градиенты, всё целиком. Так устроен GPU-решатель Fluent, и другие коммерческие пакеты теперь тоже предлагают нативные GPU-решатели. Именно отсюда берутся большие ускорения.
• Выгрузка на GPU оставляет решатель на CPU и отправляет на карту одну дорогую часть, обычно линейную систему для давления. Это помогает, но остальной цикл по-прежнему идёт со скоростью CPU.

Первый вариант требует перестройки мышления. GPU-решатель Fluent читает тот же case-файл, что и CPU-решатель, но это отдельная реализация. Он работает только с 3D-задачами. В нём одна схема градиентов, Least Squares Cell Based. Его схема Linear для давления отличается от CPU-версии, и, по словам Ansys, она точнее на неравномерных сетках. Он считает с одинарной или двойной точностью. Всё это задокументировано, и вместе это делает расчёт на GPU второй численной постановкой вашей задачи, близкой к первой и немного от неё отличающейся.

В этом весь смысл статьи, поэтому скажу один раз. Новая численная постановка заслуживает доверия так же, как любая другая: совпадением с эталоном на задаче, которую вы понимаете.

Насколько это быстрее на самом деле?

Цифры ускорения похожи на цифры расхода топлива. Они настоящие, их измеряли, и получены они на маршруте, по которому вы никогда не поедете.

Компания SimuTech Group посчитала во Fluent стационарную задачу сопряжённого теплообмена примерно на 16 миллионов ячеек и сравнила одну карту NVIDIA RTX 6000 с CPU-узлами. Против 16 ядер GPU оказался примерно в 2,5 раза быстрее процессоров AMD и в 3,5 раза быстрее процессоров Intel. Против 96 и 128 ядер выиграли CPU. Одна карта среднего уровня против скромной CPU-задачи даёт явный выигрыш; та же карта против CPU-задачи нормального размера проигрывает.

Бенчмарки производителей с несколькими GPU и сетками в сотни миллионов ячеек показывают гораздо большие ускорения. Меньшие задачи выигрывают меньше, потому что части расчёта, которые плохо распараллеливаются, занимают большую долю времени.

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

Поместится ли моя задача?

Память GPU это жёсткая стена. CPU-задача, которой не хватает памяти, замедляется; GPU-задача, которой не хватает памяти, просто не запускается.

Документация Fluent даёт ориентир для планирования: около 1 ГБ памяти GPU на миллион ячеек для турбулентной задачи на гексаэдральной сетке с одинарной точностью. Двойная точность требует на 50% больше, а полиэдральная сетка добавляет ещё от 20 до 40%. Химические компоненты, излучение и другие модели добавляют свою долю, а точная цифра зависит от задачи.

Пример расчёта. Турбулентная задача на полиэдральной сетке в 40 миллионов ячеек, двойная точность:

Для карты на 80 ГБ это где-то между «впритык» и «не помещается вовсе», ещё до того, как вы добавили хотя бы одну химическую компоненту. Та же сетка с одинарной точностью требует от 48 до 56 ГБ и помещается с запасом. Выбор точности это одновременно решение о памяти, стоимости и точности, и он заслуживает минуты размышлений, прежде чем стать настройкой по умолчанию.

Достаточно ли одинарной точности?

Обычно да, для тех величин, которые инженеры указывают в отчётах. Одинарная точность даёт около семи значащих цифр. Этого с избытком хватает для поля скорости или для перепада давления в несколько сотен паскалей. Запас становится тонким, когда ответ представляет собой малую разность двух больших чисел: несколько паскалей перепада давления на фоне десяти бар, десятая доля градуса в твёрдом теле при 400 K, небольшой результирующий тепловой поток между двумя большими.

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

На практике проявляется ещё один эффект. В сравнении SimuTech GPU считал с одинарной точностью, а CPU с двойной, и GPU понадобилось больше итераций до сходимости, при почти одинаковых температурах в итоге. Поэтому сравнивайте реальное время до сошедшегося ответа. Более быстрая итерация, которых нужно вдвое больше, даёт меньший выигрыш, чем кажется.

Дешевле ли расчёт на GPU-решателе CFD?

Арифметика простая, и её почти никто не делает.

Здесь C это стоимость одного расчёта, r почасовая ставка оборудования, t реальное время до сошедшегося ответа, а S = t_CPU / t_GPU ускорение, измеренное на вашей задаче.

Пример с выдуманными ставками. Допустим, час работы GPU-узла стоит в четыре раза дороже, чем CPU-ресурсы, которыми обычно пользуется ваша команда. Тогда GPU должен быть на вашей задаче хотя бы в четыре раза быстрее, просто чтобы выйти в ноль. При ускорении в 2,5 раза расчёт обходится дороже, но ответ приходит раньше. При ускорении в 8 раз он вдвое дешевле и тоже быстрее. Оба варианта могут быть правильными. Быстрее и дешевле это разные вопросы, и опаздывающий проект охотно заплатит за первое.

Три вида затрат прячутся за пределами формулы. Время в очереди, которое на общем кластере часто больше времени счёта. То, как ваша лицензия учитывает GPU, и это стоит выяснить у поставщика до того, как строить на этом планы. И разовая стоимость проверки GPU-постановки для каждого семейства задач, о которой пойдёт речь в двух следующих разделах.

Что GPU-решатель делает иначе?

Ansys с каждым выпуском публикует страницу ограничений GPU-решателя Fluent. Прочитать её для версий 2025 R2 и 2026 R1 весьма поучительно. Вот подборка с пояснением, чем каждый пункт грозит вам:

• Уровень давления в замкнутых несжимаемых областях. В замкнутой несжимаемой стационарной области GPU-решатель сохраняет начальное среднее по объёму давление, а CPU-решатель задаёт нулевое давление в опорной ячейке. Поля оказываются сдвинуты, и Ansys отмечает, что это может повлиять на интегралы сил для тел, поверхность которых не замкнута. Постоянный сдвиг подъёмной силы между двумя решателями в первую очередь указывает сюда.
• Знак массового расхода на неконформных интерфейсах. Мониторы расхода на таких интерфейсах могут выводить неверный знак. Баланс массы выглядит ужасно, хотя с течением всё в порядке.
• Отчёты о расходе через поверхности. Страница поддерживаемых функций для 2025 R2 сообщает, что GPU-решатель правильно выдаёт массовый расход только на внутренних зонах, а для остальных показывает ноль. Выход с расходом 0 кг/с это ограничение отчёта. С каналом всё в порядке.
• Динамическое давление на неподвижных стенках. Монитор правильно показывает ноль, а отчёты, используемые как выходные параметры, показывают неверное ненулевое значение.
• Ограничение отношения турбулентной вязкости. Отношение ограничивается тем же пределом, что и на CPU, но без сообщения в консоль. CPU-решатель сообщает, когда срабатывает ограничение. GPU-решатель держит это при себе.
• Инициализация. Гибридная инициализация с граничными условиями дальнего поля по давлению может не сойтись или дать нефизичный отток, и Ansys рекомендует стандартную инициализацию. Запуск нестационарного расчёта со стационарного решения работает неправильно, если решается уравнение энергии; обходной путь описан в документации.
• Перезапуск в другом решателе. GPU-решение со сжимаемым материалом и уравнением энергии не перезапустится корректно в CPU-решателе.
• Неподдерживаемые настройки в старых case-файлах. Модели, которые GPU-решатель не поддерживает, скрыты в интерфейсе или помечены как Unsupported. Если задать их через текстовый интерфейс, они отмечаются как проигнорированные, преобразованные или неподдерживаемые. CPU-файл, который на них опирался, всё равно запустится, и только журнал расчёта скажет вам, что с ними произошло.

Список к тому же меняется. На странице для 2025 R2 говорилось, что сверхзвуковое течение на входах по давлению, входах по скорости и выходах по давлению рассматривается как дозвуковое. На странице для 2026 R1 этого пункта уже нет, зато появились другие, например предел в 20 химических компонент и несовместимость модели flamelet generated manifold с пористыми средами и движущимися системами отсчёта.

Ничего скандального здесь нет. Каждый пункт записан, а это больше, чем можно сказать о некоторых особенностях CPU-решателей, с которыми мне доводилось сталкиваться. Беда в том, что большинство из нас читает примечания к выпуску так же, как условия договора с мобильным оператором. Читайте страницу для той версии, на которой считаете, каждый раз, когда она меняется.

Как я проверил бы результат на GPU

Одна вторая половина дня на семейство задач, с повтором при смене версии решателя или физики.

1. Возьмите уменьшенный случай из этого семейства. Та же физика, тот же тип сетки, те же типы граничных условий, и достаточно малый размер, чтобы за несколько часов посчитать его в обоих решателях.
2. Посчитайте его на CPU с двойной точностью до строгой сходимости. Следите за величинами, которые пойдут в отчёт, и проверьте балансы массы и энергии, как в любой работе.
3. Посчитайте его на GPU с теми настройками, которые будут в рабочих расчётах, включая точность. Проверять двойную точность, а считать потом с одинарной значит проверять не то.
4. Прочитайте журнал GPU-расчёта на предмет всего проигнорированного, преобразованного или неподдерживаемого.
5. Сравните целевые величины, балансы и один профиль вдоль линии через важную для вас область.
6. Оценивайте разницу относительно своей погрешности дискретизации. Два решателя никогда не совпадают точно, поэтому ноль здесь неправильная мерка.

Последний шаг обычно пропускают. Вопрос в том, расходятся ли решатели сильнее, чем вы уже допускаете из-за сетки.

Пример расчёта. Допустим, исследование сетки дало индекс сеточной сходимости 3% для перепада давления. Если результаты GPU и CPU различаются на 0,4%, разница теряется на фоне неопределённости, которую вы уже указываете, и GPU-постановка годится для этого семейства. Если они различаются на 2,5%, выбор решателя почти равен всей вашей сеточной неопределённости, и прежде чем пользоваться результатом, нужно понять причину: точность, схема для давления или проигнорированная настройка. Числа условные; важна логика.

Если вы ни разу не проводили исследование сетки для этого семейства, сравнению GPU не на что опереться, так что начните с него. Разобранный пример в статье о сеточной независимости в этом блоге занимает примерно такую же половину дня.

Типичные ошибки и как они выглядят на экране

• Ноль на выходе. GPU-расчёт показывает, что масса не покидает область. Это ограничение отчёта; проверьте по внутренней поверхности, прежде чем перестраивать сетку.
• Постоянный сдвиг силы или давления между расчётами GPU и CPU для замкнутой несжимаемой задачи. Это разница в уровне давления, и она важна для сил на незамкнутых поверхностях.
• «Сошлось вдвое быстрее», если считать по времени итерации, хотя число итераций удвоилось. Измеряйте время до сошедшейся целевой величины.
• База в 16 ядер в обосновании закупки. Если ваша реальная CPU-задача использует 128 ядер, сравнивайте с ними.
• Нехватка памяти при инициализации на полиэдральной сетке, размер которой оценивали по правилу для гексаэдров. Добавьте от 20 до 40%.
• Незаметная смена моделей из старого case-файла. Читайте журнал расчёта.

Что бы сделал я

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

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

И я арендовал бы, прежде чем покупать. Один GPU-узел на день, описанная выше послеобеденная проверка на хорошо знакомой задаче, и у меня была бы собственная цифра ускорения, измеренная на моём собственном маршруте.

Если вы уже считаете на GPU и хотите, чтобы кто-то со стороны проверил, совпадают ли результаты с тем, что давал ваш CPU-процесс, это экспертиза модели, одна из небольших работ, описанных на страницах услуг.