Core AI：在 Apple silicon 上執行模型

Apple 的裝置端 AI 堆疊一直缺了一階。Foundation Models 提供封裝完成且免費的系統 LLM。Core ML 執行一個固定的轉換後模型，由轉換器替您做出硬體決策。MLX 則提供一個您自行嵌入的陣列框架，以及一個由您選定的模型。iOS 27 補上了這三者底下的那一階：Core AI，一個一句話摘要為「在您的 App 中於 Apple silicon 上執行 AI 模型」的框架。¹ 它是模型執行的介面層，當您想親自掌控特化、快取與推論排程，而非接受上層的預設行為時，就會接觸到它。

在 session 324 中，Apple 將 Core AI 定位為驅動裝置端 Apple Intelligence 的同一套推論框架，如今開放給您自己 App 的智慧功能使用。¹⁵

這樣的定位很重要，因為 Core AI 位於大多數 App 應該使用的抽象層之下。Apple 形容它從一開始就為 Apple silicon 而設計，讓您的 App 能跨 CPU、GPU 與 Neural Engine 運用最新的模型架構與推論技術，並透過一套 Swift API 讓常見任務變得簡單，同時在需要時給您對模型特化、快取與推論效能更多的掌控權。¹ 本文的論點是：當您手上有一個模型，想以明確的控制決定它在何處、以何種方式執行時，就該選用 Core AI；若沒有這樣的需求，則停留在 Core ML 或 Foundation Models。這個框架回報的是特定需求，而非預設偏好。

TL;DR / 重點摘要

• Core AI 將未特化的 AIModelAsset（以低成本檢視模型的結構與中繼資料）與已特化的 AIModel（在裝置上執行推論）區分開來，由 AIModelCache 保存裝置專屬的成品，並以 AssetError 表示 asset 操作的失敗。²³⁶⁴
• 推論資料流經 NDArray，一個由純量值構成的多維陣列，並由 NDArrayDescriptor 描述，後者固定了形狀、純量型別與記憶體佈局的預期。⁵⁷
• 您透過 SpecializationOptions 以 ComputeUnitKind（CPU、GPU 或 Neural Engine）來鎖定硬體，並將非同步工作排程到 ComputeStream 上。⁸⁹¹⁰
• InferenceFunction 持有權重與緩衝區並執行推論；InferenceFunctionDescriptor 則讓您先檢視它的輸入、輸出與狀態簽章。該函式是 Sendable 的，因此您可以並行執行它。¹⁴¹³
• 模型從磁碟上的 .aimodel bundle 載入，而 Core AI 在框架之外還附帶準備、轉換與除錯工具。當您需要對特化與排程的明確控制時，才選用 Core AI；否則就停留在 Core ML 或 Foundation Models。²¹

撐起整套設計的兩個詞：Asset 與 Model

Core AI 要您內化的第一件事，是磁碟上的模型與執行推論的模型是不同的物件，而把前者特化為後者所費不貲。框架為兩者各自賦予一個型別。

AIModelAsset 是「一個未特化的來源模型 asset」。² 您從磁碟上某個 .aimodel bundle 的 URL 建立它，並用它在不付出特化成本的情況下檢視模型。Apple 明白說明這個分割存在的理由：model asset 讓您能查詢模型資訊而不必執行特化這項昂貴的操作。從一個 asset 中，您可以讀取函式簽章、輸入與輸出描述、運算與儲存型別，以及作者提供的中繼資料。您無法做的事是執行推論；asset 只供檢視之用。²

// Call shape is illustrative; confirm the exact initializer against Apple's docs.
let asset = try AIModelAsset(url: bundleURL)   // an .aimodel bundle on disk
// Inspect signatures, input/output descriptions, compute and storage types,
// and author-provided metadata — without specializing.

AIModel 則是另一半：「一個用於在裝置上執行推論的特化模型」。³ 一個 AIModel 代表一個針對當前裝置硬體最佳化的特化 .aimodel asset，您透過從磁碟載入該 asset 來建立它。³ asset 回答的是這是什麼模型？；model 回答的是就在這裡、此刻執行它。兩者之間的成本不對稱，正是 API 強迫您指明想要哪一個的原因。如果您只建立 asset，檢視上百個候選模型來挑一個是便宜的；但若每次檢視都伴隨特化，那將是毀滅性的代價。

特化會產生裝置專屬的成品，而這些成品有個歸宿：AIModelCache，「一個儲存特化模型成品以供推論的快取」。⁶ 這個快取保存模型載入以執行其推論函式所需的、經過最佳化的裝置專屬成品，Apple 並指出每筆快取項目包含一個由特定 .aimodel 或 .aimodelc 與某個特化組合所形成的特化 asset。⁶ 實務上的解讀是：特化並非您想在每次啟動時重複的事。快取正是 Core AI 讓昂貴步驟只發生一次、而便宜步驟（載入已快取的成品）此後反覆發生的方式。

當 asset 操作出錯時（bundle 不存在、.aimodel 格式損毀、檔案無法讀取），Core AI 會丟出 AssetError，「一個在 model asset 操作期間發生的錯誤」。⁴ 請以對待任何 I/O 邊界的方式來看待它：asset 存在於磁碟上，磁碟操作會失敗，而型別系統會明確告訴您該把 catch 放在哪裡。

張量：NDArray 與它的 Descriptor

推論把數字送進去、再把數字送出來，而 Core AI 用來裝這些數字的容器是 NDArray，「一個用於模型推論、由純量值構成的多維陣列」。⁵ 如果您用過 NumPy 的 ndarray、MLX 陣列或 MLMultiArray，這個概念的樣貌想必不陌生：一個具有明確佈局的 n 維純量區塊。NDArray 以其形狀及其餘描述性屬性所定義的佈局來儲存資料。⁵

搭配的型別是 NDArrayDescriptor，「一個對陣列形狀、純量型別與記憶體佈局預期的描述」。⁷ descriptor 就是契約。Apple 的說法很直接：descriptor 包含您提供給推論函式的陣列值所需符合的預期，而多數預期是嚴格的。如果 descriptor 指定純量型別為 .float32，您提供的陣列就必須使用 .float32。⁷ 您不去猜測某個函式想要的形狀與型別；而是向該函式的 descriptor 詢問，並依其要求建構。

// Call shape is illustrative; confirm exact property/method names against Apple's docs.
let inputDescriptor = function.descriptor.inputs.first!   // an NDArrayDescriptor
// The descriptor fixes shape, scalar type, and layout; the array you build
// must satisfy those expectations (e.g. .float32 means .float32).

這裡的設計教訓與 asset/model 的分割如出一轍。Core AI 一貫地在昂貴的值物件之前，擺上一個便宜的描述物件。您讀取 descriptor 來得知契約，接著配置滿足它的 NDArray，而非先配置、再到推論時才發現不符。針對影像輸入，Core AI 還特別定義了 ImageDescriptor，「一個對影像尺寸與像素格式的描述」，讓視覺模型的像素輸入也享有同樣的「descriptor 優先」待遇。¹¹

選擇推論在何處執行

Apple silicon 有三個可供運算的地方：CPU、GPU 與 Neural Engine。Core AI 之所以存在、而不只是 Core ML，原因就在於 Core AI 讓您能指明框架要鎖定其中哪一個，而不是由它自行推斷。

ComputeUnitKind 是「一種可供模型推論使用的硬體運算單元類型」。⁸ 您將運算單元類型與 specialization options 搭配使用，以控制框架在特化模型時鎖定哪個硬體；在預設情況下，特化會使用裝置上所有可用的運算單元。⁸ 對多數工作而言，預設就是正確答案，這正是重點所在：您只在有理由時才覆寫它（一條對延遲敏感、想固定在 Neural Engine 上的路徑；一趟想強制跑在 CPU 上的除錯流程；一條與其他 GPU 工作協同、GPU 負載沉重的管線）。

您透過 SpecializationOptions 傳達這個意圖，它是承載特化時所做選擇的結構。⁹ 特化就是前面提過的那個昂貴步驟，而運算單元的鎖定與其他特化決策就存放在 SpecializationOptions 中。由於一筆快取項目是以特定 asset 與特化組合為鍵，改變您的選項就會改變您取回的是哪個已快取成品，這便把鎖定與快取兩端串成了閉環。⁶

排程是「如何執行」的另一個面向，Core AI 用 ComputeStream 來塑造它，即「一串非同步執行的工作」。¹⁰ compute stream 是您用來將工作編碼到串流上的東西，Apple 並指出，編碼到同一條串流上的多個推論，會依其讀寫的值在必要時被序列化。¹⁰ 由此推出兩個意涵。第一，串流是您的排序基本單元：把彼此相依的推論編碼到同一條串流上，Core AI 就會依資料相依性將它們排序。第二，工作預設為非同步，因此串流也是您在 Neural Engine 或 GPU 工作期間保持呼叫端執行緒空閒的方式。

推論函式：真正執行的那個東西

一個載入的 .aimodel 並非單一可呼叫物。模型會公開具名的函式（一個編碼器、一個解碼器、一座視覺塔、一個 prefill 步驟對上一個 decode 步驟），而 Core AI 的執行單位是 InferenceFunction：「一個對輸入值執行推論並產生輸出值的函式」。¹⁴

在呼叫它之前，您要先檢視它。InferenceFunctionDescriptor 是「一個對推論函式簽章的描述」，您用一個 descriptor 在執行推論前檢視某函式的輸入、輸出與狀態的名稱與型別。¹³ 狀態是值得停下來細想的細節：帶有狀態的函式，正是一個有狀態的模型（例如 transformer decode 迴圈中的 KV cache）在多次呼叫之間保留資訊的方式，而 descriptor 會在您嘗試驅動它之前，先告訴您某個函式帶有狀態。

InferenceFunction 本身持有推論所需的資源，包含模型權重與中間緩衝區。您從一個 model 載入一個函式，並呼叫 run(inputs:states:outputViews:) 來執行推論。¹⁴ run 的簽章在 Apple 自己的說明中被點名，因此一次呼叫所需的三樣東西是明確的：輸入值、狀態值，以及您想寫入的輸出視圖。

// run(inputs:states:outputViews:) is named in Apple's docs; surrounding
// loading/value-construction shapes are illustrative — confirm against Apple's docs.
let function: InferenceFunction = /* load from an AIModel */
let outputs = try function.run(
    inputs: inputValues,        // InferenceValue per input
    states: stateValues,        // any stateful values the function declares
    outputViews: outputViews
)

兩個屬性讓這個函式在負載下用起來很愉快。它是 Sendable 的，所以您可以從多個 task 並行執行它，Apple 並指出它會視需要自動配置額外的中間緩衝區以支援這種並行。¹⁴ 您不必為了保護共用的暫存空間而把呼叫排在一把鎖後面序列化；函式會為每個並行的呼叫端管理自己的緩衝區。這與那些單一推論控制代碼實質上單執行緒的 API 相比，是個有意義的差異。

流經 run 的值是 InferenceValue 實例，「一個推論函式接受作為輸入或產生作為輸出的值」。¹² 一個 InferenceValue 包裝的是 NDArray 或像素緩衝區其中之一，而您在推論後透過它的 value 屬性取得結果。¹² 正是這層包裝，讓單一的 run 簽章能同時承載張量輸入與影像輸入而毋須各自的多載：文字模型傳入以 NDArray 為底的值，視覺模型傳入以像素緩衝區為底的值，而函式則讀取 descriptor 來得知它預期的是哪一種。

何時該選用 Core AI

Core AI 最難的部分不在 API。而在於認清您究竟該不該待在這一層，而非往上一層。誠實的決策樹如下：

• Foundation Models，當 Apple 的系統模型能勝任這項任務時。摘要、分類、抽取、改寫、結構化輸出：這些都屬於 Foundation Models 的範疇，它不耗您的權重、不佔您的記憶體預算，也沒有特化步驟。如果您的功能適用，就到此為止。為了重新實作系統模型已經做到的事而降到 Core AI，是白費工夫。
• Core ML，當您手上有一個固定的、轉換後的模型，並想讓轉換器替您做出硬體與最佳化決策時。Core ML 為一個鎖定的正式環境模型鎖定 Neural Engine，並以緊湊的功耗與延遲執行，而且它對特化或排程一無所求。如果您不想去煩惱運算單元的鎖定或 compute stream，那就是該停留在 Core ML 的訊號。
• MLX，當您想要一個研究等級、由您嵌入並反覆迭代的陣列框架時：您自己的訓練迴圈、量化的開源權重模型、LoRA 微調、快速實驗。MLX 是一個您隨權重一同出貨的函式庫，而非一個系統級的模型執行介面。它的勝場在於彈性與迭代速度。
• Core AI，當您有一個模型要執行，並想要框架那些明確的把手時：一個您在投入前先行檢視的 AIModelAsset、一組固定運算單元的 SpecializationOptions、一個由您管理的 AIModelCache、一條由您排程的 ComputeStream，以及一些您並行呼叫的 InferenceFunction。當上層的預設正是擋在您面前的那道牆，而您能說出自己需要覆寫哪一個預設時，就會接觸到這一層。

貫穿整套堆疊的主軸是：每往下一層，就用一個預設換得一個把手。Foundation Models 把一切交給您，卻一無所求。Core AI 把操縱桿交給您，並要求您知道該拉哪一根。如果您說不出自己需要哪一項特化、快取或排程的控制，那您目前還不需要 Core AI。

一段 WWDC 2026 lab 的說法，讓 Core AI 與 Core ML 之間對新專案而言的界線更為清晰。以下轉述自一份在本機轉錄的 WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab 錄音，會場上一位 Core AI 工程師表示，Apple 正請所有從事神經網路工作的人未來改用 Core AI，Core ML 則保留下來但聚焦於傳統機器學習（例如決策樹），而一切新的東西都導向 Core AI。¹⁶ 請把它讀作來自打造這個框架的人所釋出的「行進方向」訊號，而非一條有文件記載的政策：如果您在一個新專案中要動用神經網路，那場 lab 把 Core AI 定位為應據以建構的介面。

模型如何抵達 Core AI

這個框架是一個更大工作流程的執行階段那一半。Apple 指出 Core AI 在框架之外還包含用於模型準備、整合與除錯的額外工具：您為 Apple silicon 準備模型，將它們轉換為 .aimodel 格式，並使用一個支援視覺化與數值除錯的搭配 App。¹ 那份資料表對這些工具名稱的描述被截斷了，因此請對照 Apple 的 Core AI 文件來確認確切的工具名稱及其呼叫方式，而非信賴任何重建出來的版本。¹ 經過驗證的是這條管線的形狀：一個來源模型先被準備、轉換為 .aimodel、作為 AIModelAsset 載入以供檢視、特化為一個 AIModel，再經由它的 InferenceFunction 執行，而 AIModelCache 保存著特化成品，好讓昂貴的步驟只發生一次。¹²³⁶¹⁴

FAQ

什麼是 Apple 的 Core AI 框架？

Core AI 是 iOS 27 用於在 Apple silicon 上執行 AI 模型的底層框架，Apple 將它摘要為「在您的 App 中於 Apple silicon 上執行 AI 模型」。¹ 它透過一套 Swift API 跨 CPU、GPU 與 Neural Engine 執行模型推論，讓常見任務變得簡單，同時在您需要時給您對模型特化、快取與推論效能的控制。¹ 作為一個模型執行介面，它位於 Foundation Models 與 Core ML 之下。

AIModelAsset 與 AIModel 有什麼差別？

AIModelAsset 是您從磁碟上某個 .aimodel bundle 的 URL 建立的未特化來源 asset;您用它在不特化的情況下檢視模型的函式簽章、輸入與輸出描述、運算與儲存型別，以及中繼資料，因為特化所費不貲，而 asset 無法執行推論。² AIModel 則是針對當前裝置硬體最佳化、確實會執行推論的特化模型；您透過從磁碟載入 asset 來建立它。³ 這個分割讓您能低成本地檢視，並只在投入時才特化。

Core AI 如何在 CPU、GPU 與 Neural Engine 之間做選擇？

您透過 SpecializationOptions 以 ComputeUnitKind 控制硬體鎖定。一個運算單元類型指明一種可供推論使用的硬體運算單元，您用它來控制框架在特化模型時鎖定哪個硬體；在預設情況下，特化會使用裝置上所有可用的運算單元。⁸⁹ 您只在有特定理由時才覆寫預設，例如把一條對延遲敏感的路徑固定在某個運算單元上。

什麼是 InferenceFunction，我該如何執行它？

InferenceFunction 對輸入值執行推論並產生輸出值，持有模型權重與中間緩衝區。¹⁴ 您先透過 InferenceFunctionDescriptor 檢視它的簽章，後者描述該函式輸入、輸出與狀態的名稱與型別，接著從一個 AIModel 載入函式，並呼叫 run(inputs:states:outputViews:)。¹³¹⁴ 該函式是 Sendable 的，並會自動配置中間緩衝區以支援並行，因此多個 task 可以同時執行它。¹⁴

我該用 Core AI 取代 Core ML 或 Foundation Models 嗎？

當系統模型能勝任任務時，用 Foundation Models;當您手上有一個固定的轉換後模型、並想讓轉換器替您做出硬體與最佳化決策時，用 Core ML。當您想對上層替您處理的特化（SpecializationOptions、ComputeUnitKind）、快取（AIModelCache）與排程（ComputeStream）取得明確控制時，才選用 Core AI。⁸⁹⁶¹⁰ 如果您說不出自己需要哪一項控制，就停留在上一層。

完整的 Apple Ecosystem 系列：MLX on Apple Silicon，當您想要自己的模型與訓練迴圈時所嵌入的陣列框架；Apple Silicon 的 TBDR 與統一記憶體，讓 CPU/GPU/Neural Engine 共享得以運作的硬體基底；Core ML 裝置端推論，位於 Core AI 之上的固定模型層；以及 Foundation Models，堆疊頂端 Apple 封裝完成的系統 LLM。系列樞紐位於 Apple Ecosystem 系列。若需要更廣的 iOS 結合 AI 代理人脈絡，請參閱 iOS Agent Development 指南。

References