Core AI：在 Apple Silicon 上執行模型

蘋果的裝置端 AI 技術堆疊一直少了一階。Foundation Models 提供封裝完成的系統 LLM，免費可用。Core ML 執行一個已轉換的固定模型，硬體層面的取捨由轉換器替您決定。MLX 給的則是一套由您自行嵌入的陣列框架，以及一個由您自行挑選的模型。iOS 27 補上了位於這三者之下的那一階：Core AI，它的一句話摘要是「Run AI models in your app on Apple silicon」。¹ 它是模型執行層，是當您想親自掌控特化、快取與推論排程，而不願接受上層預設行為時所要觸及的地方。

在第 324 場議程中，蘋果將 Core AI 定位為驅動裝置端 Apple Intelligence 的同一套推論框架，如今開放出來，供您自己 App 中的智慧功能使用。¹⁵

這個定位之所以重要，是因為 Core AI 位於大多數 App 理應使用的抽象之下。蘋果的說法是：Core AI 在設計上充分考量了 Apple silicon，讓 App 能在 CPU、GPU 與 Neural Engine 上使用最新的模型架構與推論技術；其 Swift API 讓常見工作保持簡單，同時在必要時把模型特化、快取與推論效能的更多控制權交到您手上。¹ 本文的論點是：當您有一個模型，而且希望明確控制它在何處、以何種方式執行時，就選擇 Core AI；否則請留在 Core ML 或 Foundation Models 這一層。這個框架回報的是具體的需求，而不是預設的偏好。

TL;DR / 重點整理

• Core AI 把未特化的 AIModelAsset（以低成本檢視模型的結構與中繼資料）與已特化的 AIModel（在裝置上執行推論）區分開來；AIModelCache 保存裝置專屬的產物，AssetError 則代表資產操作的失敗。²³⁶⁴
• 推論資料透過 NDArray 流動，它是一個由純量值構成的多維陣列，其形狀、純量型別與記憶體配置的期望由 NDArrayDescriptor 訂定。⁵⁷
• 您透過 SpecializationOptions 以 ComputeUnitKind（CPU、GPU 或 Neural Engine）指定硬體，並把非同步工作排程到 ComputeStream 上。⁸⁹¹⁰
• InferenceFunction 持有權重與緩衝區並執行推論；InferenceFunctionDescriptor 讓您先行檢視它的輸入、輸出與狀態簽章。這個函式是 Sendable 的，因此可以並行執行。¹⁴¹³
• 模型從磁碟上的 .aimodel 套件載入。框架周邊的工具鏈如今也有完整文件：coreai-torch 這個 Python 套件負責轉換 PyTorch 模型，coreai-build CLI 將 .aimodel 預先編譯成各架構專屬的 .aimodelc 資產，而 Core AI Debugger App 加上 Xcode 除錯儀表與 Instruments 範本則涵蓋了檢視與效能分析。¹⁷ 當您需要明確控制特化與排程時就選擇 Core AI；否則請留在 Core ML 或 Foundation Models。²¹

貫穿整套設計的兩個詞：資產與模型

Core AI 要您先內化的一點是：磁碟上的模型和執行推論的模型是兩種不同的物件，而把前者特化成後者代價高昂。框架為兩者各給了一個型別。

AIModelAsset 是「an unspecialized source model asset」（未特化的來源模型資產）。² 您從磁碟上 .aimodel 套件的 URL 建立它，用它在不付出特化成本的前提下檢視模型。蘋果明確說明了這個區分存在的理由：模型資產讓您不必執行特化這項昂貴操作，就能查詢模型資訊。從資產中，您可以讀出函式簽章、輸入與輸出說明、運算型別與儲存型別，以及作者提供的中繼資料。做不到的是執行推論——資產只用於檢視。²

// 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：「a specialized model for running inference on a device」（用於在裝置上執行推論的已特化模型）。³ AIModel 代表一個針對目前裝置硬體最佳化過的已特化 .aimodel 資產，透過從磁碟載入資產來建立。³ 資產回答的是這是什麼模型？，模型回答的是就在這裡、現在執行它。兩者之間的成本落差，正是 API 要求您指明想要哪一個的原因。若只建立資產，檢視上百個候選模型再挑一個並不費力；若每次檢視都要特化，代價將不堪設想。

特化會產生裝置專屬的產物，而這些產物有自己的歸屬：AIModelCache，「a cache that stores the specialized model artifacts for inference」（儲存供推論使用的特化模型產物的快取）。⁶ 這個快取保存模型執行其推論函式時所載入的、經過最佳化的裝置專屬產物；蘋果指出，每個快取項目都包含一個由特定 .aimodel 或 .aimodelc 與某種特化組合所形成的特化資產。⁶ 就實務而言，這樣讀最貼切：特化不是您希望每次啟動都重來一次的事。快取正是 Core AI 讓昂貴的一步只發生一次、之後只發生便宜的一步（載入已快取產物）的方式。

當資產操作出錯時（套件遺失、.aimodel 格式損毀、檔案無法讀取），Core AI 會拋出 AssetError，「an error that occurs during model asset operations」（模型資產操作期間發生的錯誤）。⁴ 請像看待任何 I/O 邊界一樣看待它：資產位於磁碟上，磁碟操作會失敗，而型別系統會準確告訴您 catch 該寫在哪裡。

張量：NDArray 及其描述元

推論就是把數字送進去、再把數字取出來，而 Core AI 承載這些數字的容器是 NDArray，「a multidimensional array of scalar values used for model inference」（用於模型推論的純量值多維陣列）。⁵ 若您用過 NumPy 的 ndarray、MLX 陣列或 MLMultiArray，這個概念的輪廓會很熟悉：一塊帶有明確配置的 n 維純量資料。NDArray 會依其形狀與其餘描述性屬性所定義的配置來儲存資料。⁵

與之搭配的型別是 NDArrayDescriptor，「a description of an array’s shape, scalar type, and memory layout expectations」（對陣列形狀、純量型別與記憶體配置期望的描述）。⁷ 描述元就是契約。蘋果的說法很直接：描述元包含了對您提供給推論函式的陣列值的期望，而且大多數期望都很嚴格。若描述元指定純量型別為 .float32，那麼您提供的陣列就必須使用 .float32。⁷ 您不必猜測函式想要什麼形狀與型別；去問函式的描述元，然後照著做就好。

// 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).

這裡的設計啟示與資產／模型的區分如出一轍。Core AI 始終在昂貴的值物件之前擺一個便宜的描述物件。您先讀描述元弄清契約，再配置滿足它的 NDArray，而不是先配置、到推論時才發現對不上。針對影像輸入，Core AI 還定義了 ImageDescriptor，「a description of an image’s dimensions and pixel format」（對影像尺寸與像素格式的描述），於是視覺模型的像素輸入也享有同樣的「描述元優先」待遇。¹¹

選擇推論在哪裡執行

Apple silicon 上有三處可以運算：CPU、GPU 與 Neural Engine。Core AI 之所以存在、而不是只有 Core ML，正是因為 Core AI 讓您能指明框架要以其中哪一個為目標，而不是由它自行推斷。

ComputeUnitKind 是「a type of hardware compute unit available for model inference」（可用於模型推論的一種硬體運算單元）。⁸ 您把運算單元種類與特化選項搭配使用，藉此控制框架在特化模型時以哪種硬體為目標；預設情況下，特化會使用裝置上所有可用的運算單元。⁸ 對絕大多數工作而言，預設值就是正確答案——這正是重點：只有在您有理由時才去覆寫它，例如想把一條對延遲敏感的路徑釘在 Neural Engine 上、想把某次除錯強制放到 CPU 上，或是有一條需要與其他 GPU 工作協調的重度 GPU 流程。

這個意圖透過 SpecializationOptions 傳達，它是承載特化時所做選擇的結構。⁹ 特化正是前面提過的昂貴步驟，而運算單元指定以及其他特化決策都集中在 SpecializationOptions 裡。由於快取項目以特定資產與特化組合作為鍵值，改變選項就會改變您取回的快取產物，如此便把硬體指定與快取串成一個閉環。⁶

「如何執行」的另一個面向是排程，Core AI 把它建模為 ComputeStream，「a stream of work to be run asynchronously」（一條將被非同步執行的工作串流）。¹⁰ 運算串流是您用來把工作編碼進去的對象；蘋果指出，編碼到同一條串流上的多次推論，會依所讀寫的值視需要序列化。¹⁰ 由此可得兩個推論。其一，串流是您的排序基本元素：把彼此相依的推論編碼到同一條串流上，Core AI 就會依資料相依性替它們排序。其二，工作預設是非同步的，因此當 Neural Engine 或 GPU 正在忙時，串流也正是您讓呼叫端執行緒保持空閒的手段。

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

一個載入完成的 .aimodel 並不是單一個可呼叫的東西。模型會公開一組具名函式（編碼器、解碼器、視覺塔，或 prefill 與 decode 兩個步驟），而 Core AI 的執行單位是 InferenceFunction：「a function that performs inference on input values and produces output values」（對輸入值執行推論並產生輸出值的函式）。¹⁴

在呼叫之前，先檢視它。InferenceFunctionDescriptor 是「a description of an inference function’s signature」（對推論函式簽章的描述），您用描述元在執行推論前檢視該函式輸入、輸出與狀態的名稱與型別。¹³ 值得停下來多看一眼的是狀態：帶狀態的函式，正是有狀態的模型（例如 Transformer 解碼迴圈中的 KV 快取）在多次呼叫之間保留資訊的方式，而描述元會在您試著驅動它之前，就先告訴您這個函式有沒有狀態。

InferenceFunction 本身持有推論所需的資源，包括模型權重與中間緩衝區。您從模型中載入函式，並呼叫 run(inputs:states:outputViews:) 來執行推論。¹⁴ run 的簽章在蘋果自己的說明中被明白點出，因此一次呼叫需要的三樣東西一目了然：輸入值、狀態值，以及您希望被寫入的輸出檢視。

// 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 的，因此可以從多個工作並行執行；蘋果也指出，為了支撐這種並行，它會視需要自動配置額外的中間緩衝區。¹⁴ 您不必為了保護共用的暫存空間而用鎖把呼叫排成一列——函式會替每個並行呼叫端管理各自的緩衝區。相較於那些單一推論控制代碼實際上只能單執行緒使用的 API，這是實實在在的差別。

流經 run 的值是 InferenceValue 實例，「a value that an inference function accepts as input or produces as output」（推論函式作為輸入接受、或作為輸出產生的值）。¹² InferenceValue 包裝的不是 NDArray 就是像素緩衝區；推論結束後，您透過它的 value 屬性取回結果。¹² 正是這層包裝，讓同一個 run 簽章不必拆成多個多載，就能同時承載張量輸入與影像輸入：文字模型傳入由 NDArray 支撐的值，視覺模型傳入由像素緩衝區支撐的值，而函式則透過讀取描述元來得知自己期望的是哪一種。

何時該動用 Core AI

Core AI 最難的部分不是 API，而是判斷您究竟該待在這一層，還是待在上面一層。誠實的決策樹如下：

• Foundation Models：當蘋果的系統模型能完成這項工作時。摘要、分類、擷取、改寫、結構化輸出——這些屬於 Foundation Models 框架，它不佔用您的權重、記憶體預算，也不需要特化步驟。若您的功能裝得進去，就到此為止。為了重做系統模型早已完成的事而下沉到 Core AI，純屬白費工夫。
• Core ML：當您有一個固定的、已轉換的模型，並希望由轉換器替您做硬體與最佳化決策時。Core ML 以 Neural Engine 為目標，為鎖定下來的正式模型提供嚴格的功耗與延遲表現，而且完全不要求您思考特化或排程。若您不想去想運算單元指定或運算串流，這就是留在 Core ML 的訊號。
• MLX：當您想要一套可自行嵌入並反覆迭代的研究級陣列框架時——自己的訓練迴圈、量化的開放權重模型、LoRA 微調、快速實驗。MLX 是您隨權重一起出貨的函式庫，而不是系統層級的模型執行層。它勝在彈性與迭代速度。
• Core AI：當您有一個要執行的模型，並且想要框架給出的那些明確把手時：可在投入前檢視的 AIModelAsset、能釘住運算單元的 SpecializationOptions、由您管理的 AIModelCache、可供排程的 ComputeStream，以及可以並行呼叫的 InferenceFunction。當上層的預設行為恰恰成了擋路的東西，而您又能說清楚自己需要覆寫哪一個預設時，就該來這裡了。

貫穿整套堆疊的主軸是：每往下一層，就用一個預設換來一個把手。Foundation Models 把一切都給您，什麼也不問。Core AI 把操縱桿交給您，並要求您知道該拉哪一根。若您說不清楚自己需要哪一項特化、快取或排程的控制，那就代表您還不需要 Core AI。

WWDC 2026 一場實驗室問答中的說法，讓 Core AI 與 Core ML 在新專案上的分界更清楚。根據對 WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab 的本機轉錄錄音所作的轉述，出席問答的一位 Core AI 工程師表示，蘋果正在請所有從事神經網路工作的人今後轉向 Core AI；Core ML 會繼續存在，但聚焦於決策樹之類的傳統機器學習，而所有新的東西都會走向 Core AI。¹⁶ 請把它當成打造這個框架的人所釋出的方向訊號，而不是白紙黑字的政策：若您要在新專案中動用神經網路，實驗室的說法是把 Core AI 當作構築的基礎。

一個模型如何抵達 Core AI

這個框架只是更大工作流程中屬於執行階段的那一半；自 6 月的測試版以來，蘋果已把工具那一半也完整公開。¹⁷ 整條流程是這樣運作的。

轉換。 您從一個 .aimodel 檔案開始，它要麼由來源模型經 coreai-torch 套件（蘋果的 Core AI PyTorch Extensions for Python）轉換而來，要麼本來就已備妥為該格式。¹⁷ .aimodel 會像任何資源一樣加入您的 Xcode target，出現在 Compile Sources 建置階段中，並在 Xcode 裡獲得一個模型檢視器，用來顯示參數、儲存大小、中繼資料與運算圖。有一項建置系統相依性要先知道：Core AI 的模型整合需要 Metal Toolchain，而 Xcode 預設並不安裝它；缺少它時，含有 .aimodel 檔案的建置會以「找不到 Metal 編譯器」的錯誤失敗。¹⁷

視需要預先編譯。 特化會在您建立 AIModel 時自動發生，而對大型模型來說，這筆首次載入的成本相當可觀。coreai-build 命令列工具把其中最昂貴的部分——模型編譯——移到您的建置機器上：它把 .aimodel 轉換成依裝置架構區分的 .aimodelc 資產，每種架構一個（編譯 MyModel.aimodel 會產生 MyModel.<arch>.aimodelc）；執行時 App 會挑選與目前裝置相符的資產，於是 Core AI 就略過了編譯步驟。¹⁷ 預先編譯所針對的是 Apple Intelligence 的硬體門檻：搭載 A17 Pro 或更新晶片的 iPhone 或 iPad、M1 或更新晶片的 Mac，以及搭載 M2 的 Apple Vision Pro。¹⁷

除錯與效能分析。 三樣工具撐起了可觀測性：Core AI Debugger，一款獨立的 macOS App，用來檢視模型的運算圖、在裝置上執行它，並把輸出與一次參考執行做比對；Xcode 中的 Core AI 除錯儀表，在除錯階段即時監看載入、特化與推論活動；以及 Core AI instrument，一個 Instruments 範本，用來分析跨 CPU、GPU 與 Neural Engine 的執行時間。¹⁷

前面描述的執行階段樣貌可以原封不動地嵌進這套流程：備妥的模型先作為 AIModelAsset 載入以供檢視，再特化成 AIModel，然後透過它的 InferenceFunction 執行；AIModelCache 則保存特化產物，讓昂貴的那一步只發生一次。¹²³⁶¹⁴

常見問題

蘋果的 Core AI 框架是什麼？

Core AI 是 iOS 27 中用來在 Apple silicon 上執行 AI 模型的底層框架，蘋果將它概括為「Run AI models in your app on Apple silicon」。¹ 它透過一套 Swift API 在 CPU、GPU 與 Neural Engine 上執行模型推論，讓常見工作保持簡單，同時在您需要時提供對模型特化、快取與推論效能的控制。¹ 作為模型執行層，它位於 Foundation Models 與 Core ML 之下。

AIModelAsset 與 AIModel 有什麼差別？

AIModelAsset 是您用磁碟上 .aimodel 套件的 URL 建立的未特化來源資產；由於特化代價高昂，您用它在不特化的情況下檢視模型的函式簽章、輸入與輸出說明、運算型別與儲存型別以及中繼資料，而資產本身無法執行推論。² AIModel 則是針對目前裝置硬體最佳化過、確實會執行推論的已特化模型；您透過從磁碟載入資產來建立它。³ 這樣的區分讓您以低成本檢視，只在真正投入時才特化。

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

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

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

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

我該用 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 談位於堆疊頂端、蘋果封裝完成的系統 LLM。系列入口在 Apple Ecosystem 系列。若想了解 iOS 與 AI 代理結合的更廣脈絡，請參閱 iOS Agent Development 指南。

參考資料