Если сервис тормозит из-за Postgres, сети, медленного внешнего API или кривого SQL - видеокарта тут вообще ни при чём. Сначала индекс, нормальный запрос, кэш или очередь. Не CUDA.

Но бывает другой сценарий. Внутри обычного JVM-продукта появляется тяжёлый вычислительный кусок: нужно прогнать пачку изображений, обработать видео, посчитать тысячи сценариев для модели, подготовить данные для локального inference или долго крутить матрицы.

И вот в этот момент необязательно сразу поднимать отдельный Python-сервис, разбираться с PyTorch и тащить ещё один стек в прод.

Для Java есть TornadoVM.

Это open-source фреймворк, который берёт подходящий Java-код и запускает его на GPU. Java-метод во время работы приложения компилируется под CUDA для NVIDIA, OpenCL или Metal на Apple Silicon. Основной сервис при этом остаётся обычным: Kotlin/Java, Spring Boot, Postgres, очереди, REST API. На GPU уезжает только то место, где реально много однотипной работы.

Например, сервис принимает изображения, складывает их в S3, создаёт задачу в очереди и хранит статус обработки в базе. Всё это CPU-задачи.

А потом нужно сделать resize для 200 тысяч картинок, наложить фильтры, подготовить данные для модели или посчитать набор числовых признаков. В этих местах один и тот же расчёт повторяется для огромного количества пикселей, кадров или объектов. Это уже похоже на работу для GPU.

Но есть подвох: GPU не бесплатный ускоритель.

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

Недавно вышел TornadoVM 6. В релизе интереснее не отдельные CUDA-оптимизации, а то, что сам стек стал менее хрупким.

Проект убрал JNI и перешёл на Foreign Function & Memory API из Panama. Это значит меньше обвязки на C/C++ вокруг Java и меньше боли при работе с native-библиотеками и драйверами. Ещё TornadoVM отказался от JVMCI: одна сборка теперь заявлена для JDK 21–27. Для команды это звучит скучно, но на практике означает меньше зоопарка в CI и проще обновления JDK.

Пока не тащу TornadoVM в свой проект, но держу в закладках для сценариев с медиа, локальным inference и массовыми расчётами.

Мне здесь нравится не идея «Java теперь умеет GPU». Java и раньше могла работать с GPU, просто часто это означало JNI, нативную обвязку и отдельную боль в поддержке.

TornadoVM выглядит как попытка оставить продукт на Kotlin/Java и вынести на GPU только один узкий кусок, который действительно упёрся в CPU.

А у вас в реальных проектах бывало, что упирались именно в CPU и приходилось смотреть в сторону GPU? Что это было: AI/inference, обработка изображений или видео, аналитика, финансы, симуляции? И чем в итоге решили задачу?