TornadoVM 7.3 发布：通过 FFM API 与 CUDA 混合接入实现 Java 原生 GPU 工作负载加速

一句话结论

TornadoVM 7.3 通过移除 JNI 并引入 FFM API 及 CUDA 库混合调用，使 Java 应用能直接调用 cuBLAS 等原生 GPU 库以加速现代机器学习工作负载。

关键要点

• TornadoVM 7.3 版本全面采用 Foreign Function & Memory (FFM) API 取代 Java Native Interface (JNI)，并移除了实验性的 JVMCI 依赖。
• 该版本支持在所有受支持的 JDK（21、25、26 和 27）上通过“反射 + ASM + Unsafe”层统一获取编译器元数据。
• 新增对 cuTile 编程模型的支持（通过 TileContext），允许直接从 TornadoVM 任务图中调用 cuBLAS 和 CUTLASS 等 CUDA 库。
• 为苹果生态提供混合 API 支持，可访问 MXL 库，并新增对多 GPU 并行执行的支持。
• 配套发布 jitLLM v2.0，这是一个基于 TornadoVM 的 Java AI 推理引擎，以单个 JAR 文件形式发布，旨在性能上竞争 llama.cpp 和 Ollama。

背景与事实

TornadoVM 是一个面向 Java 的开源异构 GPU 编程框架，其最新 7.3 版本于近期正式发布。该框架的核心定位并非取代现有的 Java 虚拟机（JVM），而是与 OpenJDK、GraalVM、Temurin 或 Zulu 等主流 JDK 发行版协同工作。它通过自动加速机制，将 Java 源代码编译为 OpenCL 和 Apple Metal 后端代码，并将计算任务卸载至硬件后端，同时管理 Java 堆内存与加速器之间的数据交互。这种“编写一次，到处运行”的设计理念允许开发者在笔记本电脑上利用本地资源开发，随后部署到配备 Nvidia GPU 的服务器上以获得显著性能提升。

在 7.3 版本的架构变更中，开发团队对底层调用机制进行了重大调整。此前依赖的 Java Native Interface（JNI）已被 Foreign Function & Memory（FFM）API 取代，同时移除了实验性的 JVM 编译器接口（JVMCI）依赖。据开发团队介绍，新版 TornadoVM 现在通过反射、ASM 库和 Unsafe 层获取所有编译器元数据。这一处理路径在所有受支持的 JDK 版本（包括 JDK 21、25、26 和 27）上得到统一实施。这一变更旨在消除跨版本兼容性差异，为后续的功能扩展提供更稳定的基础。

针对 Nvidia 生态系统的集成在该版本中得到了深化。除了传统的 OpenCL 后端外，TornadoVM 7.3 通过优化 CUDA 后端支持了更深层的库调用。具体而言，开发者现在可以使用新的 TileContext 支持 cuTile 编程模型，并直接从 TornadoVM 的任务图（TaskGraphs）中调用 cuBLAS 和 CUTLASS 等高性能 CUDA 库。开发者可以根据具体的性能指标和代码可移植性需求，灵活地将即时编译（JIT）生成的内核替换为 CUDA 库调用，或者将两者串联起来执行。与此同时，为了保持跨平台能力，TornadoVM 也为苹果公司的 MXL 库添加了类似的混合 API 支持。此外，该版本首次引入了多 GPU 执行支持，旨在解决单卡瓶颈并提升大规模并行计算效率。

影响分析

对于中文开发者与从业者而言，TornadoVM 7.3 的发布降低了在 Java 生态中构建高性能 GPU 应用的门槛。过去，Java 开发者若要利用 Nvidia 针对特定硬件平台优化的底层库（如线性代数、快速傅里叶变换或针对稀疏矩阵的手动优化矩阵乘法），通常需要编写复杂的本地代码或依赖第三方桥梁库。现在，通过 TornadoVM 的混合 API，Java 程序员可以在保持 Java 编程惯例的前提下，直接访问这些优化库。这对于需要处理现代云和机器学习工作负载的团队尤为重要，因为它简化了从 CPU 到 GPU 的代码迁移过程。

该框架的集成能力对微服务和高性能计算场景产生直接价值。以 Apache Flink 为例，TornadoVM 的集成允许开发者在使用 Table API 编写标准查询时，仅通过一个简单的配置标志来表明查询可能需要在 GPU 上加速。当计算任务到达任务管理器时，框架会自动检查节点中的 GPU 可用性，并通过库提供程序分析查询的中间表示（IR），判断是否适合在 GPU 上执行。这种“无侵入式”的加速方式，意味着现有的 Java 大数据和流处理系统无需大规模重构即可获得 GPU 红利。然而，这要求开发者理解数据并行工作负载的特征，因为只有那些迭代之间没有依赖关系的循环才最适合卸载到加速器上并行运行。

适用边界

TornadoVM 的加速优势并非适用于所有 Java 计算场景。其核心机制依赖于将计算卸载到 GPU，因此最适合数据并行工作负载，例如具有大量独立迭代且迭代间无数据依赖关系的循环。如果 Java 代码包含高度串行的逻辑、复杂的控制流或频繁的主存随机访问，GPU 卸载可能不仅无法带来性能提升，反而因数据传输开销导致性能下降。此外，虽然 TornadoVM 支持“编写一次，到处运行”，但为了达到最优性能，开发者在部署到 Nvidia GPU 服务器时仍需利用 CUDA 后端特有的库调用优化，这意味着跨不同 GPU 架构（如从 Nvidia 到 AMD）的可移植性在深度优化场景下会受到限制。

孤本观察

TornadoVM 团队通过 Beestream.ai 这一衍生公司进行商业化推广，并同步推出以单个 JAR 文件形式发布的 jitLLM v2.0，显示其正试图从纯粹的底层框架向直接面向 AI 推理应用的市场层面延伸。

来源

来源：InfoQ 中文 AI