RunAnywhere SDK：用一個 C++ 核心把八種平台的推論路徑收斂成一組 API

它解決的不是推論速度，而是八套 SDK 的維護成本

在裝置上跑模型本身不難，難的是同一套功能要在 Swift、Kotlin、Flutter、React Native、Web 與桌面之間各寫一次，而每個平台的底層引擎還不一樣：Apple 端偏好 MLX 與 Core ML，Android 的 Snapdragon 機種有 Hexagon NPU，瀏覽器只有 WebGPU，伺服器端則是 CUDA 或純 CPU。RunAnywhere 的作法是把這些差異收進一個 C++ 核心，上層八個 SDK 只暴露同一組語意化 API。README 的架構圖把這件事寫得很直白：八個 SDK 疊在一個 C++ 核心上，核心之下是能力註冊表，再往下才是 QHexRT、MLX、llama.cpp、sherpa + ONNX、Core ML 或雲端。目標讀者是那些已經決定模型要跑在使用者裝置上、但不打算為每個平台重寫一次推論層的團隊。它的賣點是覆蓋面，不是單點效能。

能力註冊表如何決定你的程式最後跑在哪顆晶片上

README 對路由機制的描述是：引擎先註冊自己能在什麼硬體上執行，接著由優先序最高且符合當前裝置的引擎勝出。優先序大致是 QHexRT 對應 Snapdragon Hexagon NPU，MLX 對應 Apple silicon，llama.cpp 作為通用後備（Apple 上用 Metal，NVIDIA 上是需自行開啟的 CUDA 建置，瀏覽器裡是 WebGPU），語音與嵌入交給 sherpa + ONNX，擴散模型交給 Core ML。這裡有個容易被忽略的細節：README 明確指出 LiteRT 與 ExecuTorch 只是保留的 framework 列舉值，並非已整合的執行環境。也就是說，型別系統裡看得到不等於裝置跑得動。文件因此要求呼叫 RunAnywhere.capabilities()（v4）來探測當前套件與裝置真正能執行的能力，並強調「列舉值存在不代表引擎已安裝」。這個設計把硬體選擇從開發者手上拿走，換來跨平台一致，代價是當你想要指定某個特定引擎時，得先確認它在你的裝置上是否真的被註冊。

從 pip 到 Swift Package Manager 的三種起步路徑

最快的驗證路徑是 Python。README 給的指令是 pip install runanywhere，接著 import runanywhere as ra，呼叫 ra.initialize()，再以 ra.llm.generate 搭配 LlmOptions(model="qwen2.5-0.5b") 產生文字，註解說明模型會在首次使用時下載。偏好終端機的人可以改用另一條路：CLI 位於 RunanywhereAI/RCLI，它消費的是本倉庫發布的 C++ 桌面套件，安裝方式是 brew install runanywhereai/tap/rcli，或 curl -fsSL https://raw.githubusercontent.com/RunanywhereAI/RCLI/main/install.sh | sh，之後執行 rcli run qwen3 "..."。行動與桌面端則走原生套件：Swift 範例顯示要先 import RunAnywhere 與 LlamaCPPRuntime，呼叫 LlamaCPP.register() 與 try RunAnywhere.initialize()，再填 RAModelLoadRequest（modelID、category、framework）並 await RunAnywhere.loadModel，最後用 RALLMGenerateRequest 取得結果。想在 Apple silicon 上改用原生路徑，則是 import RunAnywhereMLX 後呼叫 MLX.register()。這三段程式碼的形狀一致，差異只在註冊哪個 runtime。

語音代理、CUA 與結構化輸出：哪些是完整功能，哪些只是解析器

README 在列舉能力時附帶了不少界線說明，這些界線比功能清單本身更有參考價值。語音代理是 VAD、STT、LLM、TTS 串成一條管線，播放範圍由 SpeechHandle 界定，但喚醒詞偵測並未實作。電腦操作部分提供的是一個 CUA 動作解析器，把 Fara1.5 風格的字串解析成依視窗縮放的座標，README 直接寫明它不是完整的自主代理框架。結構化輸出依賴 generateStructured 加上 enforcement mode，且受限解碼只在引擎支援時才生效。工具呼叫支援穩定的呼叫 ID 與代理迴圈，平行呼叫則取決於引擎與能力回報。這些括號裡的限制，決定了你能否把它當成產品的唯一推論層。若你的語音流程需要喚醒詞，或你的代理需要自行規劃多步操作，這兩塊得自己補上。

當能力註冊表挑錯引擎，你沒有太多補救空間

把引擎選擇交給優先序規則，好處是行為可預期，壞處是它不認識你的場景。同一個模型在不同引擎上的量化格式、記憶體佔用與輸出品質並不一樣，而註冊表的判斷依據是裝置與能力，不是你的延遲預算或輸出穩定度需求。影像生成更明顯：README 說明 Stable Diffusion 走 Core ML，inpainting 走 Hexagon NPU，並註明是平台與後端 gated，意味著多數裝置拿不到這個功能。另一個現實問題是模型取得。Python 路徑會在首次使用時下載，但原生路徑要求你自己指定 modelID，而模型來源是 Hugging Face 上的 runanywhere/models，並非任意 GGUF 都能直接餵進去。如果你的團隊已經有一套自建的量化流程與 sampler 調校，硬塞進這層抽象只會多一層除錯。這種情況下，直接用 llama.cpp 或 MLX 會更省事。

與 llama.cpp 的差別：抽象層換掉了什麼

最直接的替代方案是 llama.cpp 本身，而 RunAnywhere 的 llama.cpp 後端正是建立在它之上。差別在於控制權的位置。直接用 llama.cpp，你決定 context 大小、執行緒數、KV cache 型別、sampler 鏈與量化檔案，換來的是每個平台各自一份整合程式碼，Apple 要處理 Metal，Android 要處理 NDK 與 ABI，瀏覽器要處理 WebGPU 與 WASM 的記憶體限制。RunAnywhere 把這些收進 C++ 核心，讓八個 SDK 共用同一組語意 API，代價是上述參數多半由框架與引擎註冊表代管。這不是誰比較好的問題，而是你的團隊有沒有能力維護多平台的推論層。另一個對照是雲端 API：本專案的定位是本地與離線，README 在架構圖裡把 Cloud 列為其中一個路由目標，但預設敘事是資料不離開裝置。若你的產品必須連網才能運作，這層抽象帶來的複雜度就不划算。

授權標示為 NOASSERTION，這是採用前必須先讀完 LICENSE 的理由

倉庫的授權欄位顯示 NOASSERTION，README 的徽章則寫著 RunAnywhere License，兩者都不是 OSI 認可的標準識別碼。這代表自動化的授權掃描工具無法直接判定條款內容，企業內部的合規流程通常會因此卡關。這裡不提供法律意見，但要指出的是一個具體事實：在把這個 SDK 放進產品之前，必須有人實際讀過 LICENSE 檔案，確認商用、再散布與修改的條件。維護成本方面，從版本節奏可以看出端倪。近期發布包含 cpp-desktop-v0.20.37、v0.20.36 與 v0.20.35，其中兩個版本在同一天發布，顯示專案仍在快速迭代的階段。快速迭代對採用者意味著兩件事：API 可能變動，而底層引擎（llama.cpp、MLX、ONNX）各自的更新也需要這個專案跟上。把這層抽象放進產品，等於多了一個需要持續追蹤的上游依賴。

編輯結論

如果你要的是同一份推論程式碼同時覆蓋 iOS、Android、Web 與桌面，RunAnywhere 的八個 SDK 共用一個 C++ 核心確實省下大量重複工作，值得先以 pip install runanywhere 或 Swift Package Manager 做一次端到端驗證。反之，若你需要精細控制量化格式、自訂 sampler，或必須採用 OSI 認可的授權，這個專案並不適合，因為引擎選擇由能力註冊表決定，而授權標示為 NOASSERTION。動手前請先確認三件事：RunAnywhere.capabilities() 在你的目標裝置上實際回報了哪些引擎、你要用的模型是否已在 Hugging Face 的 runanywhere/models 下備妥，以及 LICENSE 檔案的具體條文。

官方來源

1. Issues
2. Project website
3. README
4. Releases
5. RunanywhereAI/runanywhere-sdks on GitHub