React Native AI：把推論放回裝置端的三個 provider 與它們的真實邊界
On-device LLM execution in React Native with Vercel AI SDK compatibility
秒懂
- 它是什麼？
- callstackincubator/ai 用 Vercel AI SDK 的介面包住 Apple Foundation Models、llama.rn 與 MLC LLM，讓 React Native 應用在裝置上跑文字生成、向量、轉錄與語音合成；但每個 provider 的可用性門檻差異極大。
- 適合誰用？
- 如果你已經在用 Vercel AI SDK，且目標是 iOS 26 以上的 Apple Intelligence 裝置，Apple provider 是唯一不需要下載模型、安裝後即可呼叫的選項，值得先驗證；需要跨 iOS 與 Android 一致行為、或要指定特定 GGUF 權重，就得接受 llama.rn 或 MLC 的下載與記憶體成本。反過來說，如果你的使用者大量停留在舊版 iOS，或產品必須支援 Android，Apple provider 的可用性表已經直接排除這條路，不要把它當成跨平台方案。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 71 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是推論位置，不是模型能力
多數 React Native 應用接 LLM 的方式，是把 prompt 送到自家後端或供應商 API，再把回應串回前端。這條路徑的代價是伺服器成本、網路延遲，以及使用者資料離開裝置。callstackincubator/ai 把推論搬回裝置端，README 對這件事的說法是「Run AI models directly on users' devices for privacy-preserving, low-latency inference without server costs」。
目標讀者是已經在用 Vercel AI SDK 的 React Native 開發者。專案沒有自創一套 API，而是提供相容的 model 物件，讓 generateText、streamText、embed 這些既有呼叫直接換掉 model 參數。README 的相容性表寫得很明確：0.11 及以下對應 AI SDK v5，0.12 及以上對應 AI SDK v6。這是升級時第一個會撞到的分歧點，因為它決定你能否沿用現有的 SDK 依賴版本。
它不負責替你選模型，也不負責托管模型。除了 Apple provider 用的是系統內建模型，其餘兩個 provider 都要你自己指定權重並承擔下載與記憶體。把它想成「把 AI SDK 的呼叫端接到裝置端 runtime」的黏著層，比想成一個完整的推論平台更準確。
三個 provider 的機制完全不同，不能用同一套假設
Apple provider 走的是 Foundation Models 與系統框架。README 列出四項能力：文字生成用 Apple Foundation Models，向量用 NLContextualEmbedding 產生 512 維語意向量，轉錄用 SpeechAnalyzer，語音合成用 AVSpeechSynthesizer。這些都是系統模型，安裝後不需要下載任何權重，README 標注為 built-in。
Llama provider 的機制是把 GGUF 權重交給 llama.rn 載入。模型 ID 的格式是 owner/repo/filename.gguf，例如 ggml-org/SmolLM3-3B-GGUF/SmolLM3-Q4_K_M.gguf。README 給的流程是三步：先呼叫 model.download 並傳入進度回呼，再呼叫 model.prepare 把模型載入記憶體，用完呼叫 model.unload 釋放。這三步的存在本身就說明了它的成本結構，下載、載入、卸載都是開發者要自己編排的生命週期。
MLC provider 走 MLC LLM 的 runtime，同樣需要先下載模型。README 在這裡多了一個容易漏掉的條件：Xcode 需要開啟 Increased Memory Limit capability。這不是可選的效能調整，而是能否載入模型的門檻。把三個 provider 並排看，Apple 是零下載但綁定系統版本，Llama 與 MLC 是可控權重但綁定記憶體與下載流程，選擇其實是在「版本相容性」與「模型可控性」之間取捨。
安裝與最小可跑路徑
Apple provider 的安裝只有一行，README 說明不需要額外 linking，在 iOS 裝置上會 autolink：
npm install @react-native-ai/apple
呼叫端沿用 AI SDK 的函式，只是把 model 換成 apple() 系列。文字生成用 apple()，向量用 apple.textEmbeddingModel()，轉錄用 apple.transcriptionModel()，語音用 apple.speechModel()。README 的範例從 'ai' 匯入 generateText、embed、experimental_transcribe 與 experimental_generateSpeech，後兩者帶 experimental_ 前綴，代表 API 尚未穩定，升級時要預期簽名可能變動。
Llama provider 要裝三個套件，因為它依賴原生模組與檔案存取：
npm install @react-native-ai/llama llama.rn react-native-blob-util
模型 ID 用 llama.languageModel('owner/repo/filename.gguf') 建立，下載進度從回呼的 progress.percentage 取得。README 舉了三個可用的權重，包括 SmolLM3-3B、Llama-3.2-3B-Instruct 與 Qwen2.5-1.5B-Instruct 的 GGUF 版本。
MLC provider 的安裝是 npm install @react-native-ai/mlc，但 README 在這一節被截斷，只留下「Requires the 'Increased Memory Limit' capability in Xcode」這句。完整的 Xcode 設定步驟需要回到官網的 getting started 頁面確認，本文無法從現有材料補齊。
Apple provider 的可用性表是最硬的限制
README 的可用性表把每個功能的 iOS 版本門檻分開列：文字生成要 iOS 26 以上且裝置支援 Apple Intelligence，向量要 iOS 17 以上且無額外條件，轉錄要 iOS 26 以上，語音合成 iOS 13 以上即可，Personal Voice 則要 iOS 17 以上。
這張表的意思是，同一個 provider 底下的四個功能，覆蓋的裝置範圍並不一致。向量與基本語音合成可以在較舊的系統上跑，但文字生成與轉錄直接卡在 iOS 26 加 Apple Intelligence 硬體。如果你的應用要對全體使用者提供聊天功能，這條路在舊裝置上會直接斷掉，而且不是靠降級模型能解決的問題。
另一個容易誤判的地方是平台。Apple provider 只支援 iOS。Llama 與 MLC 才同時支援 iOS 與 Android。想在兩個平台上維持一致行為的團隊，從一開始就不該把 Apple provider 當成主力，除非你願意為 Android 另寫一套路徑。
還有一個實務上的失敗模式寫在 DevTools 那節：AI SDK Profiler 面板看得到卻一直是空的，README 的說法是關掉目前的 React Native DevTools 視窗再開一個新的，因為舊的 debugger session 會讓 Rozenite 面板掛著卻收不到當前 app 的 telemetry。這是工具鏈層級的問題，不影響推論本身，但會讓除錯時誤以為請求沒有送出。
與直接使用 llama.rn 或遠端 API 的差異
Llama provider 底下就是 llama.rn，所以真正的替代方案不是別的框架，而是直接呼叫 llama.rn。差別在介面層：直接用 llama.rn 要自己處理 prompt 模板、訊息格式、串流輸出的解析，而這個專案把這些包成 AI SDK 的 model 物件，讓 generateText 與 streamText 可以直接吃。代價是你被綁在 AI SDK 的版本節奏上，README 的相容性表已經顯示 0.12 跳到了 v6，這種綁定會在 SDK 大版號更新時變成升級工作。
另一個替代方向是維持遠端推論。遠端 API 的優勢是模型能力不受裝置限制，也不需要處理下載與記憶體，換來的是伺服器成本、網路延遲與資料離開裝置。這個專案在 README 裡明白把「without server costs」與「data stays local」列為賣點，所以判斷點很單純：如果你的場景對延遲或資料落地有硬要求，裝置端才划算；如果只是想要更好的模型品質，裝置端反而會讓你被 3B 級別的權重綁住。
MLC 與 Llama 之間的差異則在 runtime。兩者都需要下載模型，但 MLC 走的是 MLC LLM 的編譯與最佳化路徑，README 對它的描述集中在 runtime 本身，而 Llama 走 llama.rn 並直接吃 HuggingFace 上的 GGUF。選哪個取決於你手上已有的權重格式與團隊對原生建置的熟悉度，而不是 API 形狀。
版本相容性與升級成本
這個專案的版本節奏不快。最近的釋出是 v0.12.0（2026-01-28）、v0.11.0（2025-10-14）、v0.10.0（2025-09-27），三個版本橫跨約四個月，而 0.12 是一次帶有破壞性的對應關係變更，把 AI SDK 從 v5 拉到 v6。這表示升級不是換個版本號就好，而是要同步調整 AI SDK 依賴與相關呼叫。
授權是 MIT，用在商業產品上不需要額外授權談判。需要留意的是間接依賴：llama.rn、react-native-blob-util 與 MLC LLM 各自有自己的授權與維護節奏，這些不在這個專案的 MIT 範圍內，實際採用前應逐一確認。本文不對授權條款提供法律意見。
維護面的另一個成本是模型本身。README 給的 GGUF 範例指向 HuggingFace 上的特定 repo 與檔名，模型 ID 是字串，一旦上游改名或刪檔，執行期才會失敗。這不是套件能替你擋掉的問題，需要在設定層自己固定版本或自建鏡像。
DevTools 的部分要另外安裝 @react-native-ai/dev-tools，且 README 明確要求 Rozenite 必須已安裝並在 app 中啟用，否則外掛不會有作用。這是一條獨立的依賴線，與推論功能無關，但會影響你能否觀察到 OpenTelemetry span。
編輯結論
如果你已經在用 Vercel AI SDK，且目標是 iOS 26 以上的 Apple Intelligence 裝置，Apple provider 是唯一不需要下載模型、安裝後即可呼叫的選項，值得先驗證；需要跨 iOS 與 Android 一致行為、或要指定特定 GGUF 權重，就得接受 llama.rn 或 MLC 的下載與記憶體成本。反過來說，如果你的使用者大量停留在舊版 iOS，或產品必須支援 Android，Apple provider 的可用性表已經直接排除這條路，不要把它當成跨平台方案。動手前先確認三件事：AI SDK 版本與 0.12 的對應關係、目標裝置的 iOS 版本與 Apple Intelligence 硬體條件、以及 llama 模型 ID 指向的 HuggingFace 檔案是否仍存在。
社群筆記