背景：讓 Java 應用使用 GPU 的新途徑
根據 InfoQ於 2026 年 10 月 21 日刊載、Ben Evans 撰寫的報導，開源異質運算框架 TornadoVM 已推出 7.3 版。TornadoVM 的目標，是讓 Java 程式能在多核心 CPU 與 GPU 上自動加速，而不必先把既有系統改寫成另一套語言。它並不是要取代 Java 虛擬機器（JVM，負責管理程式執行與記憶體的 Java 執行環境），而是與現有 JVM 並行運作，可搭配 OpenJDK、GraalVM、Temurin 或 Zulu 等主流 JDK 版本。
實際運作時，TornadoVM 會把適當的 Java 程式碼卸載至硬體後端，在 Java 堆積記憶體與加速器之間管理資料，並執行產生的運算核心。這種能力特別適合現代雲端服務與機器學習工作負載，因為這些應用經常包含大量可並行的計算。框架也支援將同一套 Java 程式從使用 OpenCL 或 Apple Metal 的本機環境，部署到配備 NVIDIA GPU 的伺服器，形成針對現代機器學習工作負載的「寫作一次、到處執行」模式。
版本 7.3 的核心變更
新版後端改用 Foreign Function & Memory API，也就是 FFM，取代過去的 Java Native Interface（JNI，用於串接 Java 與原生程式碼的介面）。TornadoVM 同時移除實驗性的 JVM Compiler Interface 相依性。團隊表示，所有編譯器中繼資料現在都透過 reflection、ASM 與 Unsafe 構成的統一路徑取得，在支援的 JDK 21、25、26 與 27 上採用一致的處理方式。reflection 是 Java 的反射機制，ASM 則用於分析或產生 Java 位元組碼；這項變更的重點，是減少不同 JDK 與編譯路徑之間的差異。
NVIDIA 生態系整合是 7.3 版另一項重要进展。最佳化的 CUDA 後端加入 cuTile 程式模型與新的 TileContext，使 Java 程式可以使用以 tile 為運算單元的 CUDA 編程方式。開發者也能在 TornadoVM TaskGraph 內直接呼叫 cuBLAS 與 CUTLASS 等 CUDA 函式庫。前者是 NVIDIA 的基礎線性代数函式庫，後者則提供模板化的平行運算與矩陣乘法能力。依效能與可攜性需求，開發者可以選擇以即時編譯產生的核心執行工作、改用現成函式庫，或將兩者串接；Apple 的 MXL 函式庫也透過 hybrid API 獲得相同類型的整合能力。此外，7.3 版新增多 GPU 執行支援，讓工作負載得以利用同一節點內的多張 GPU。
從開發便利性到框架整合
TornadoVM 的方向，是提供符合 Java 開發習慣的環境，讓應用直接使用 NVIDIA 針對不同硬體調校的函式庫，涵蓋線性代數、快速傅立葉轉換、深度神經網路，以及稀疏矩陣的手工最佳化乘法。框架目前已與 Quarkus、Lang4j、Flink、Spring AI 等專案整合，也可透過 SDKMan 安裝。
Java 開發者接觸 NVIDIA GPU 的方式並非只有一種。parallel API 只需在迴圈上加上註解，向編譯器提示各次迭代可能可以平行執行；但團隊指出，這種簡單介面長期不足以滿足正式應用的效能需求，因此又加入 kernel context API、TileContext 與可串接原生函式庫的 hybrid API。這些入口涵蓋提示式自動優化、較明確的核心控制，以及直接使用 CUDA 生態系三種主要方向。
Apache Flink 的整合顯示，TornadoVM 並非一律把所有運算強制搬到 GPU。開發者仍以 Table API 撰寫一般查詢，再透過設定旗標標示該查詢可能適合 GPU 加速。當查詢抵達 Flink 的工作管理器後，框架會先檢查執行節點是否配有 GPU，再交由函式庫提供者分析查詢的中間表示（IR，即編譯過程使用的運算結構），判斷工作是否真的適合卸載。這種設計讓 GPU 加速依據實際工作內容與執行環境決定，而不是只依賴開發者的初始提示。
AI 推論與商業化方向
伴随 7.3 版發布，團隊還推出以 TornadoVM 為基礎的新一代 Java AI 推論引擎 jitLLM 2.0。jitLLM 以單一 JAR 檔形式提供，團隊將其定位為 llama.cpp 與 Ollama 的效能競爭者，顯示 TornadoVM 的應用範圍正從一般 GPU 加速延伸至 AI 推論。TornadoVM 與 jitLLM 也透過 TornadoVM 團隊成立的衍生公司 Beestream.ai 進行商業化，使開源專案之外再形成產品與服務路徑。
適用範圍與限制
GPU 卸載並非對所有 Java 運算都有利。最適合的工作是資料平行型計算，例如每次迭代之間沒有相依關係的迴圈，因為這些迭代可以同時在加速器上執行。若運算包含密集的順序相依、資料傳遞成本很高，或原本就在 CPU 上執行更有效率，搬移到 GPU 未必能帶來預期收益。TornadoVM 提供多種 API，正是為了讓開發者在自動提示、精細控制與函式庫最佳化之間取捨；其成效仍取決於工作負載、硬體、函式庫支援與部署環境。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。