NVIDIA 最高的生態護城河 CUDA 可能不再是完全不可撼動的了，OpenFPM 開發者 Abhinav Singh 在 X 公布 OpenFPM 5.2.0，首次讓 Apple Metal GPU 成為這個開源高效能運算框架的一級後端。實測在 M3 Pro 上跑三維 SPH 壩潰模擬，GPU 6 秒對比循序 CPU 60 秒，加速比約 10 倍，GPU 利用率逼近 100%，物理結果也與原本 CUDA 版本高度一致。
We got CUDA kernels running on @Apple Metal GPUs! 🍎⚡️
Thanks to GPT 5.6 Sol, our existing CUDA/HIP-style simulation kernels in OpenFPM now directly execute on Apple Silicon GPUs.
Here is how we got there, and what the first real Dam break benchmark says. 🧵 pic.twitter.com/28S8X2aXwK
— Abhinav (@Abhinavsns) July 22, 2026
這次的重大突破主要在兩個層面：第一，Apple 生態轉譯 CUDA 的工程進展，已經從過去的個人零星嘗試，走到能用真實科學計算任務驗收的階段；第二，把這條多層 IR 翻譯鏈在六小時內打通，靠的不是某位 GPU 驅動工程師，而是 OpenAI 的 GPT-5.6 Sol 協助定位 MoltenVK、SPIR-V 的相容性問題並設計變通方案。對一般人而言，這件事的訊號意義在於：當 NVIDIA 憑藉 CUDA 生態的 4 百萬開發者與 512 億美金季度資料中心營收，構築出被稱為「5 兆美元護城河」的版圖時，開源社群已經悄悄的可能要越過這座護城河的一角了。
這份 PR 解決了什麼？
OpenFPM 是歐洲 mosaic-group 維護的開源 C++ 框架，專門用於開發可擴展的粒子與粒子-網格混合模擬程式碼，支援分散式記憶體與共享記憶體異構系統。長期以來，OpenFPM 的 GPU 後端只對接 CUDA 與 HIP，意味著只能在 NVIDIA 與 AMD 平台上跑高效運算。
這版的設計思路並不是為 Apple Metal 重新打造一份 GPU 核心，而是搭建一條多層轉換管線：
- 第一層：CUDA/HIP 內核源碼，應用層維持原本的 kernel 呼叫風格，不碰任何 Metal 專用 API。
- 第二層：Clang/HIP 編譯器，保留 kernel 語意，先把 HIP 轉成 LLVM IR。
- 第三層：SPIR-V 中介表示，這是 Khronos 制定的 GPU 通用中介碼，讓一份核心能跑到 Vulkan 相容硬體上。
- 第四層：Vulkan API 呼叫，透過 clspv、chipstar 等工具將 OpenCL C 編譯成 SPIR-V，再走 Vulkan 進入 GPU。
- 第五層：MoltenVK 翻譯層，把 Vulkan 指令翻譯成 Apple Metal API。
- 最底層：Apple Metal GPU（M3 Pro 等 Apple Silicon），最終執行。
這條路徑的關鍵價值在於硬體透明度。開發者只要不改 kernel 寫法，理論上就能讓同一份 OpenFPM 程式碼在 NVIDIA、AMD、Apple 三種 GPU 上跑。Abhinav 在原文也表示：「hard part done. Apple Silicon GPU is now a first-class OpenFPM backend.」
Apple 生態轉譯 CUDA：從零星嘗試到可驗收
Apple Metal GPU 跑 CUDA/HIP 風格程式的嘗試，這幾年並不少見，但大多停留在 demo 階段。過去開發者通常需要為 Apple 平台重寫整套 kernel，或者接受只能跑向量加法等級的示範。這次 OpenFPM 之所以值得拿出來談，是因為它選了真實的科學計算任務當驗收。三維 SPH 壩潰模擬需要同時處理掃描、排序與重排、cell 與鄰居列表構建、ghost 粒子交換、歸約操作、原子操作等模組，任何一環出錯都會讓性能或物理結果出問題。
- M3 Pro Metal GPU 執行時間：約 6 秒。
- 同程式循序 CPU 執行時間：約 60 秒。
- 加速比：約 10 倍。
- GPU 利用率：接近 100%，代表轉換效率極高。
- 物理結果一致性：關鍵參數與粒子軌跡與原始 CUDA 版本高度吻合，無精度損失。
粒子儲存隨粒子數 N 線性成長，鄰居搜尋等工作量約為 O(N·k)（k 為固定密度下的鄰居數）。這次 10 倍加速是單機後端對比，未來還能透過 Apple Thunderbolt 支援的 RDMA 技術，達成多機動態負載平衡，讓模擬規模進一步延伸。
社群上對「Mac 跑科學計算」並非沒有質疑。Hacker News 上就有人直言，與其花時間處理翻譯層，不如直接用更合適的系統；AMD 與社群對這類翻譯層的態度也一向分歧，AMD 官方更傾向於直接在上游專案（PyTorch、llama.cpp）實作 HIP 支援，因為追求 bug-for-bug 相容性被認為是徒勞之舉。OpenFPM 這次證明的是另一條路徑：先做好應用層抽象，讓同一份核心程式碼可以透過中間層透明地運行在 NVIDIA、AMD、Apple 三種 GPU 上。
AI 參與改進：GPT-5.6 Sol 在這條鏈裡做了什麼？
這次 OpenFPM 之所以能在六小時內把這條翻譯鏈打通，GPT-5.6 Sol 的角色值得展開看。 Abhinav 公開指出 AI 實際參與的環節：
- 設備端記憶體佈局：Apple Metal 的記憶體模型與 CUDA 有本質差異，GPT-5.6 Sol 協助完成了設備端記憶體佈局建構。
- 單精度限制處理：Metal 不支援 64 位元雙精度浮點，AI 透過
-cl-single-precision-constant編譯旗標，讓所有 kernel 統一使用單精度常量，移除了原本靠 hack 程式碼維持的相容邏輯。 - Volatile 裝飾器問題：MoltenVK 不尊重 SPIR-V 中的 Volatile 裝飾器，導致 load/store 指令重排序，進而影響原子操作的正確性。GPT-5.6 Sol 發現這個問題後，在 SPIR-V 層設計了對應的 workaround，並建議將復現用例上報給 MoltenVK 專案以推動上游修補。
- ABI 適配程式碼：PR 中 cmake/MoltenVKKernelABI.cpp 檔案包含 AI 自動生成的 ABI 適配程式碼。
對比過去 SPIR-V、MoltenVK 這類底層環境的除錯經驗，工作量通常以週或月計算。aoyii 在詳解文章中評論，這對應到過去需要數週的手工除錯工作，如今壓縮到數小時。AI 在這條鏈裡參與的，不再是應用層的程式碼生成，而是 SPIR-V 中介表示設計、跨平台記憶體模型調整、GPU 驅動相容性排查這一類工作。
這份進展對 NVIDIA 的護城河意味著什麼？
OpenFPM PR #18 規模很小，但它示範了一種繞過 CUDA 護城河的開源工作流。NVIDIA 在 2026 年的 5 兆美元市值靠的是軟體堆疊：4 百萬開發者、橫跨 PyTorch、TensorFlow、JAX、cuDNN、TensorRT 的生態系，加上 90% 營收集中於資料中心業務的商業模式。
這條轉譯鏈之所以有看頭，在於它採用多層 IR 翻譯而非重寫核心。類似的開源計畫例如 cuda4mac（GitHub haj/cuda4mac）也走 SPIR-V + LLVM 翻譯路線，但 OpenFPM 是第一個用真實科學計算任務做驗收的版本。對 Mac 使用者來說，這意味著過去只能在伺服器上跑的粒子模擬，現在能在筆電本地完成；對 NVIDIA 來說，Apple GPU 雖然短期內仍受制於雙精度浮點不足、無法直接取代高效運算叢集，但長期看會讓更多開發者把工作流留在 Mac 平台上，等於在護城河外圍長出一圈可用的灘頭。
開發者的坦白：實用價值與現實限制
Abhinav 對這次突破的自我定位相當坦誠：
- 本地除錯需求：團隊的大型模擬還是跑在叢集上，但跑大模擬前總要先用小模擬除錯。依賴 CPU 的本地除錯實在太慢，而模擬結果往往是好幾 GB，無法透過 SSH 傳回，遠端桌面又繁瑣難用，直接在本地跑最省事。
- 程式碼可移植性：在筆電上除錯通過的程式碼，原封不動丟到 GPU 叢集上就能自動擴展規模。
- 硬體抽象層驗證：能在 Apple 架構上跑起來，證明了設備抽象層的設計有效。
Abhinav 進一步指出，目前 Apple Metal GPU 最大的限制在於對高精度浮點運算的支援不足，許多專業科學計算領域依賴雙精度運算，因此 NVIDIA 的專業 GPU 在天氣預報、航空太空模擬等高效運算場景仍保有優勢。這次 OpenFPM PR #18 的意義，是把轉譯鏈打通到本地開發能用的程度，至於取代專業叢集，那是另一條路。