TornadoVM достиг версии 7.3, превращая обычные Java-программы в нагрузки, которые выполняются на многоядерных CPU и GPU. Открытый фреймворк работает вместе с OpenJDK, GraalVM, Temurin или Zulu, перенося код на аппаратные бэкенды и управляя памятью между кучей Java и ускорителями. Для компаний с облачными нагрузками и машинным обучением на Java это важно, поскольку существующий код получает производительность GPU без выхода из экосистемы JVM.
Как TornadoVM 7.3 переносит Java на GPU
Фреймворк компилирует исходный код Java при разработке под бэкенды OpenCL и Apple Metal, а затем переносит тот же код на серверы с GPU Nvidia для более высокой производительности. Разработчики могут собирать проект на ноутбуке с локальным оборудованием и позже переходить на серверы с GPU, что команда подает как Write Once, Run Anywhere для современных ML-нагрузок. В версии 7 интерфейс Java Native Interface заменен на Foreign Function and Memory API, а зависимость от экспериментального JVM Compiler Interface удалена.
Метаданные компилятора теперь поступают через единый слой reflection плюс ASM плюс Unsafe, одинаковый для поддерживаемых версий JDK 21, 25, 26 и 27. Выпуск добавляет оптимизированный бэкенд CUDA с поддержкой модели программирования cuTile через новый TileContext. Разработчики могут вызывать библиотеки CUDA, такие как cuBLAS и CUTLASS, прямо из TaskGraphs в TornadoVM, заменяя JIT-ядра вызовами библиотек или объединяя оба подхода. Тот же гибридный API поддерживает Apple MXL, а также добавлено выполнение на multi-GPU.
Не каждое вычисление на Java подходит для переноса, а лучшими кандидатами названы data-parallel циклы без зависимостей между итерациями. Последние версии нацелены на то, чтобы дать JVM-разработчикам привычный доступ к настроенным библиотекам Nvidia для линейной алгебры, быстрых преобразований Фурье для анализа сигналов, глубоких нейросетей и умножения разреженных матриц. TornadoVM интегрируется с Quarkus, LangChain4j, Flink и Spring AI и распространяется через SDKMAN. Интеграция с Flink показывает модель: флаг конфигурации помечает запрос Table API для возможного ускорения.
Что это дает Java-проектам с ИИ
Для бизнеса с Java-системами практический эффект — более низкий порог использования GPU в аналитике и инференсе ИИ без переписывания сервисов на Python или C++. Запрос Flink Table API проверяется в task manager на наличие GPU, затем анализируется через промежуточное представление, чтобы решить, подходит ли ускорение. Небольшие команды сохраняют привычные фреймворки и дистрибутивы JDK, а крупные организации могут направлять подходящие запросы на узлы с GPU и оставлять остальные на CPU.
Выбор модели программирования влияет на результат и переносимость, поэтому командам стоит проверить, какой путь подходит их нагрузке. TornadoVM предлагает четыре способа программировать GPU Nvidia, начиная с аннотации parallel API, которая подсказывает, что цикл можно выполнять параллельно. Этот подход оказался недостаточным для промышленной производительности, поэтому появились kernel context API и TileContext для более точного управления. Прямые вызовы библиотек CUDA обменивают переносимость на настроенную скорость, а пригодность по-прежнему зависит от data-parallel структуры.
Маркером для наблюдения станет внедрение jitLLM v2.0, движка ИИ-инференса на Java, построенного на TornadoVM и поставляемого как один JAR-файл. Команда сравнивает его по производительности с llama. cpp и Ollama, а коммерциализация идет через спин-офф Beestream. ai. Если проекты на Flink, Quarkus или Spring AI сообщат о промышленном ускорении на GPU, а jitLLM наберет пользователей, выполнение Java-кода на GPU перейдет из опции фреймворка в операционную практику.
