Core ML 裝置端推論：真正能出貨的模式

Core ML 是隨每一台現代 Apple 裝置一起出貨的裝置端推論引擎。這套框架會在可用時把運算分派給 Neural Engine，不可用時交給 GPU，最後才退回 CPU，並依照模型與硬體自動挑選最快的路徑¹。結果是：在較新的 iPhone 上，絕大多數正式環境的模型規模都能在次毫秒到數十毫秒的延遲內完成推論，每次呼叫不花錢，沒有網路往返，也不會把資料交給第三方。

把這套框架看成「不起眼的水電管線」的印象早就過時了。近十年來，從「照片」App 的語意搜尋，到多數內建本機 ML 的第三方 App，裝置端功能一直靠 Core ML 撐著；在一路回溯到 iOS 11 的所有系統上，它仍是執行固定的、已轉換模型的正式環境層。不過它在技術堆疊中的位置，確實在 WWDC 2026 有了變動：Apple 推出 Core AI，將其定位為驅動裝置端 Apple Intelligence 的低階框架，並點明那是新的類神經網路工作該走的方向¹¹¹²。至於讓一次 Core ML 部署真正出得了門、而不是停在「在我的 Mac 上可以跑」的那些模式，並沒有改變，數量也依舊不多：模型轉換、分派提示、延遲預算與量化。本文會對照 Apple 的文件逐一走過，最後把 Core ML 放回 WWDC26 之後的技術堆疊裡定位。

TL;DR

• Core ML 會在 Apple Silicon 的 Neural Engine、GPU 與 CPU 上執行 .mlpackage 與 .mlmodel 檔案。分派是自動的，但可以透過 MLModelConfiguration.computeUnits 給出提示²。
• 模型轉換透過 coremltools 完成（PyTorch、TensorFlow、ONNX → Core ML）。轉換屬於工具鏈的工作，而非執行期的工作；模型一旦轉換好並打包進來，App 只要載入並執行即可。
• Apple Silicon 的統一記憶體架構意味著模型權重不會在 CPU、GPU 與 NE 之間來回複製，三者背後是同一塊記憶體³。正是這個架構細節，讓次毫秒的推論成為可能。
• 量化（近期 Core ML 版本中的 INT8、INT4）能縮小模型體積、加快 Neural Engine 上的推論，代價是可量測的精度損失，幅度取決於模型。coremltools 9.0（2025年11月）新增了 iOS 26 部署目標、模型狀態讀寫，以及 int8 的模型輸入與輸出¹³。
• 技術堆疊在 WWDC 2026 變了：Apple 把 Core AI 定位成裝置端 Apple Intelligence 背後的推論框架，也是新的類神經網路工作的落點；Core ML 則繼續擔任固定的已轉換模型與傳統 ML 的正式環境層¹¹¹²。

心智模型：三條運算路徑，一塊記憶體

Apple Silicon（M 系列 Mac 以及 A12 Bionic 之後的 A 系列 iPhone）提供三種推論目標。

Neural Engine。 專為低精度矩陣乘法打造的加速器。對現代 ML 模型仰賴的運算（卷積、注意力、嵌入）最快，功耗也最低。但它只支援特定的運算類型與張量形狀，不支援的運算會逐層回退到 GPU 或 CPU。

GPU。 透過 Metal 提供的通用平行運算。處理 ML 形態的工作比 Neural Engine 慢，但比 CPU 快，負責接手 Neural Engine 不支援的運算。

CPU。 保底路徑。做 ML 推論很慢，但永遠可用、支援所有運算，而且行為可以預期。

統一記憶體架構意味著三者背後是同一塊實體記憶體³。模型權重只載入一次，分派目標切換時並不會被複製。正是這個架構事實，把多目標分派從「逐層的複製成本」變成「逐層的排程決策」。

分派由 MLModelConfiguration.computeUnits 控制。

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all 是預設值，對幾乎每一個 App 來說也是正確選擇。框架會為每個運算挑出最快的路徑，而這種逐運算的判斷，比開發者自己寫的任何啟發式規則都要快。需要覆寫它的情況很少：一種是為了測試結果一致而強制 .cpuOnly（模型在不同路徑上的行為會有差異，而測試需要確定性的路徑），另一種是強制 .cpuAndGPU，把 Neural Engine 讓給另一個併行的工作。

模型轉換：工具鏈的工作

多數 ML 模型是在 PyTorch、TensorFlow 中訓練，或直接用 Apple 的 Create ML 訓練出來的。Core ML 接受 .mlpackage 檔案，這是 Xcode 13 引入、取代舊有 .mlmodel 的現代格式⁴。轉換透過 Apple 的開源 Python 套件 coremltools 進行⁵。

一次典型的 PyTorch 轉 Core ML 分成三個步驟。

1. 載入訓練好的 PyTorch 模型，並切到推論模式。
2. 用與正式環境輸入形狀相符的範例輸入張量對模型做 trace。
3. 針對目標 iOS 部署版本，用 coremltools 轉換 trace 之後的模型。

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

轉換只在開發環境中，針對目標 iOS 部署版本（minimum_deployment_target）執行一次。產出的 .mlpackage 才是丟進 Xcode 專案的東西，執行期的 App 並不會跑 coremltools。目前的版本 coremltools 9.0 新增了直到 iOS 26 的部署目標、讀寫模型狀態的能力（用於帶 KV 快取的 Transformer 解碼器這類有狀態模型）、int8 的模型輸入與輸出，以及 Python 3.13 與 PyTorch 2.7 的支援¹³。

轉換有兩個實務上的陷阱。第一，動態形狀的輸入必須用 ct.RangeDim 明確處理，因為 Core ML 預設是靜態形狀，當正式環境的 App 餵進尺寸不一的輸入時，錯誤訊息幫不上什麼忙。第二，PyTorch 中沒有 Core ML 對應實作的自訂運算，得寫一個 Core ML 自訂層（用 Swift 程式碼實作缺少的運算），或在轉換前修改模型架構把該運算移除。兩條路的文件都相當完整⁵。

真正派得上用場的延遲預算

對要出貨的 App 來說，有三種延遲預算值得放在心上。

16 ms（60 fps 的即時 UI）。 即時相機濾鏡、逐格更新的 AR 場景、即時音訊分析。這個預算涵蓋全部環節：影像前處理、模型推論、後處理、UI 更新。塞得進來的模型通常都很小（MobileNetV3 等級，參數量不到 1 億），而且跑在 Neural Engine 上。

100 ms（互動式 UI）。 使用者做了某個動作，然後等待結果：點一下辨識、畫一筆認字、講一句轉寫。這個預算寬鬆得多，也撐得起更大的模型。10 億參數以下的語言模型、小型視覺 Transformer，以及多數正式品質的分類器，都能從容放進來。

1 秒以上（背景或批次）。 照片圖庫建立索引、文件分析、App 啟動時的模型預熱。更大的模型也行得通，但必須用進度指示器把使用者的預期拉齊。Foundation Models 的裝置端 LLM 在脈絡窗較大的操作上，就落在這一檔。

這些預算是準則，不是硬性上限。正確的做法不是相信另一台機器上跑出來的理論數字，而是用 os_signpost 或 Instruments 的 Core ML 範本，在目標裝置上實際量測⁶。

量化：更小何時也會更快

Core ML 支援多種量化等級⁷:

• Float32（全精度）。 訓練時的預設值。體積最大、最準確，也最慢。
• Float16。 半精度。在 GPU 與 NE 上更小也更快；對條件良好的模型，精度損失通常可以忽略。
• INT8。 帶校準的 8 位元整數量化。體積大致是 Float32 的四分之一，在 NE 上常有 2 到 4 倍的加速。精度損失視情況而定；以視覺模型而言，搭配量化感知訓練可以把 top-1 精度損失壓在 1% 以內。
• INT4 以下。 近期 Core ML 版本針對特定模型架構（LLM、大型視覺模型）支援的積極量化。代價是明顯的精度損失；這項技巧與貼合模型特性的量化感知訓練搭配時，效果最好。

透過 coremltools.optimize.coreml.linear_quantize_weights 進行線性量化時，會接受一份全域 op 設定，用來選擇量化模式（linear_symmetric 或 linear），並指定一個權重大小門檻，低於門檻的權重維持全精度。轉換是對既有的 .mlpackage 執行，產生一個新的量化套件；兩者可以一起放進 bundle，由 App 依裝置等級決定要載入哪一個。

要不要量化是逐一模型的決定：小型分類器可能沒什麼好處，因為它的運算本來就很便宜；大型語言模型的好處則極大，因為它的運算主要由量化權重上的矩陣乘法主導。正確的做法是先量化，在保留下來的測試集上量測精度，若精度損失對該用途可以接受就出貨。

可以直接拿來用的 Apple 內建模型

Apple 透過 Core ML Models 頁面提供了數個預先訓練好的 Core ML 模型⁸。值得認識的幾個類別如下。

• 影像分類： MobileNetV2、ResNet50、SqueezeNet 各種變體，全都已打包好，可直接放進 Vision 框架的 VNCoreMLRequest。
• 物件偵測： YOLOv3、MNIST、CenterNet 各種變體。
• 姿態估計： 用於人體姿態的 PoseNet（可當作 Vision 中 VNDetectHumanBodyPoseRequest 的基準替代方案）。
• 語意分割： 用於影像分割的 DeepLabV3。
• 文字辨識： 以 ML 為基礎的 OCR，作為 Vision 內建功能之外的選擇。

對多數 App 來說，Apple 的預訓練模型已經涵蓋了感知類的基本能力（分類、偵測、分割），不必自行訓練。至於語言任務，系統的裝置端 LLM 完全位在這一層之上：Foundation Models 框架以高階 Swift API 的形式把它開放出來，離線且免費，沒有任何模型檔案需要您自行打包或轉換。

模型加密與 App Store 的考量

App bundle 裡的 .mlpackage，任何人解開 IPA 都讀得到。對於確實構成智慧財產的模型，Apple 透過 Encrypt your Core ML model 工作流程支援模型加密⁹: 用 Xcode 產生加密金鑰並交由 CloudKit 管理，bundle 中的模型以加密形式存放，Core ML 會在載入時解密。

不過對多數 App 而言，加密是殺雞用牛刀。用常見的 ImageNet 資料訓練出來的模型稱不上競爭優勢，加密它只會墊高維運複雜度，卻沒有保護到任何有價值的東西。請把加密留給那些真正體現訓練資料投入或競爭優勢的模型。

裝置端隱私：架構層面的勝利

隱私這件事很直接。Core ML 的推論完全在裝置上發生。輸入資料（影像、音訊、文字）不會離開裝置。模型檔案在本機，推論在本機，結果也在本機。

對受管制產業（醫療、金融、教育）的 App 來說，這個架構事實直接消掉了一整類法規遵循工作。沒有需要寫進隱私權政策的第三方資料處理者，沒有需要做安全審查的模型 API 端點，也不會有資料存放地的問題，因為資料根本沒有移動過。

隱私聲明（Privacy Manifest）格式¹⁰把這套隱私敘事固定進 App Store 送審流程：一個只用 Core ML 做裝置端推論、其他什麼都不做的 App，可以就推論路徑宣告零第三方資料分享。送審流程更快，隱私審查更短，面向使用者的隱私「營養標示」也更乾淨。

與代理工作流程的連結

Core ML 會和這個系列已經談過的三種模式相互搭配。

Vision 框架的 VNCoreMLRequest。 自訂的 Core ML 模型可以走 Vision 管線執行，前處理會自動完成。這個模式（在 Vision Framework 中有詳述）是在 iOS App 裡出貨自訂影像分類器或偵測器的正途。

Foundation Models 的裝置端 LLM。 Apple Intelligence 的系統級 LLM 位在 Foundation Models 框架之後，而截至 WWDC 2026，Apple 指出驅動它的推論框架就是 Core AI¹¹。本文的概念依然可以直接移轉：運算單元分派、量化權重與延遲預算，約束系統級 LLM 的方式，和約束您自己轉換的模型完全一樣。那篇談框架的文章涵蓋 LLM 的 API，本文則涵蓋底下的推論模式。

使用本機 ML 的 App Intents 工具。 一個執行本機影像分類器或文字分類器的 AppIntent，可以在沒有網路往返的情況下，把結構化結果回傳給 Apple Intelligence。正是這個組合，讓「代理化的 Apple」真正保有隱私；代理的工具之所以能在本機執行，是因為框架撐得住。

什麼時候該選雲端推論

Core ML 的天花板就是裝置的運算能力。有三種情況雲端才是對的答案。

大到無法隨 bundle 出貨的模型。 700 億參數的 LLM 放不進 App bundle。這種規模的工作負載，雲端推論（或者以串流權重的方式在裝置端執行，那是另一種模式）才是合適的工具。

推論過程中需要跨裝置共用狀態。 推論時必須讀寫共用資料庫的模型（例如對數十億筆記錄做協同過濾的推薦系統）。Core ML 純本機的模式並不合用。

模型迭代非常快。 每天都在推出模型更新的團隊，會因為伺服器端推論而受惠，因為推出不必等 App Store 的審查週期。Core ML 把模型打包進 App 的做法，替模型改版節奏帶來摩擦，這個取捨是真實存在的。

模式很清楚：規模與迭代速度是雲端勝出，延遲、成本與隱私則是 Core ML 勝出。

WWDC 2026 之後 Core ML 的位置

WWDC 2026 重畫了本文腳下的地圖，卻沒有讓它失效。Apple 推出了 Core AI，這是一個 iOS 27 的框架，摘要寫著「Run AI models in your app on Apple silicon」；並在第 324 場 session 中表示，Core AI 就是驅動裝置端 Apple Intelligence 的推論框架，如今也向第三方 App 開放¹¹。如果說 Core ML 的轉換器替您做掉了硬體與最佳化的決定，那麼 Core AI 是把操縱桿交到您手上：明確的模型特化、受管理的產物快取、運算單元指定，以及非同步運算串流。完整的拆解請見 Core AI：在 Apple silicon 上執行模型。

關於走向的訊號，比單看文件所透露的更強烈。在 WWDC 2026 的機器學習 group lab 上，一位 Core AI 工程師表示，Apple 正在請所有做類神經網路的人日後轉向 Core AI，Core ML 會留著，但重心放在決策樹這類傳統機器學習¹²。這句話是 lab 現場的轉述，而不是公開政策，但它與這次發布的整體樣貌相符：新的工具鏈、新的格式，以及 Apple Intelligence 的工作負載，都給了 Core AI。

對今天就要出貨的 App，務實的讀法如下。

• 既有的 Core ML 部署會繼續運作。 iOS 27 沒有任何一處把 .mlpackage 這條路列為棄用，而 coremltools 9.0 才在 2025年11月這樣不久之前交付了新能力（iOS 26 目標、有狀態模型、int8 輸入輸出）¹³。
• 在 iOS 27 以下，Core ML 仍是唯一選項；對於一個固定的、已轉換的模型，若轉換器的預設行為正合您意，它也是務實的選擇。
• 鎖定 iOS 27 以上的新類神經網路工作，應先評估 Core AI，尤其是當您說得出自己需要哪一種特化、快取或排程控制時。
• 其他各層沒有移動。 系統級 LLM 仍在 Foundation Models之後，而 MLX 仍是面向自有開放權重模型與微調模型的可嵌入陣列框架。Core ML 對上 Core AI，談的是您模型的執行層，而不是這些。

這個模式對 iOS 26 以上的 App 意味著什麼

三點結論。

1. 只要模型放得進 bundle，而且每次呼叫都能給出使用者可以據以行動的結果，就預設選 Core ML。 影像分類、物件偵測、音訊分類、手勢辨識、嵌入生成，以及中小規模的語言任務都屬於此類。框架的自動分派加上 Apple Silicon 的 NPU，免費帶來次毫秒到數十毫秒的推論。

2. 只要精度損失可以接受，就大膽量化。 INT8 通常是安全的；INT4 適合體積節省真的重要的大型模型。請在保留集上量測精度，而不是想當然地認為量化到哪裡都安全。

3. 搭配 Vision 與 Foundation Models，組成完整的本機管線。 Core ML 是引擎，Vision 是它之上的感知 API，Foundation Models 則是它之上的 LLM。本系列的 Vision 一文與 Foundation Models 一文談的是更高層的介面。

完整的 Apple Ecosystem 系列包括：有型別的 App Intents；MCP 伺服器；路由的抉擇；Foundation Models；執行期與工具鏈 LLM 之別；三種介面；單一事實來源模式；兩個 MCP 伺服器；給 Apple 開發用的 hooks；Live Activities；watchOS 執行期；SwiftUI 的內部構造；RealityKit 的空間心智模型；SwiftData 的 schema 紀律；Liquid Glass 模式；多平台出貨；平台矩陣；Vision 框架；Symbol Effects；我拒絕書寫的主題。系列首頁在 Apple Ecosystem 系列。若想了解 iOS 與 AI 代理結合的更廣脈絡，請參閱 iOS Agent Development 指南。

常見問題

Core ML 如何在 Neural Engine、GPU 與 CPU 之間做決定？

Core ML 會逐一檢視模型圖中的運算，並把它派給支援該運算的最快目標。Neural Engine 以最低的延遲與功耗，處理它支援的運算（多數矩陣乘法、卷積、注意力）。NE 不支援的運算交給 GPU，其餘由 CPU 處理。這個決定是逐運算、自動進行的，而且比手寫的啟發式規則更快。

是不是應該永遠使用 .computeUnits = .all？

幾乎永遠如此。框架的自動分派調校得很好。要覆寫它的情況有兩種：測試輸出一致性時改成 .cpuOnly（由於浮點捨入，同一個模型在 NE 與 CPU 上的結果會略有差異），或者為了替併行工作騰出 Neural Engine 而改成 .cpuAndGPU。

.mlpackage 與 .mlmodel 在實務上有什麼差別？

.mlpackage 是 Xcode 13 引入的現代格式，支援儲存中繼資料、為 ML Program（mlprogram）編譯準備的多種模型變體，以及 iOS 13 之後的工具鏈。.mlmodel 是舊有格式。兩者都能透過 MLModel 載入，但新的開發應該採用 .mlpackage。

App bundle 中的 Core ML 模型可以多大？

沒有固定上限，但 App Store 對下載的 bundle 大小上限是 4 GB，而透過行動網路安裝也有實務上的限制。系統的裝置端 LLM 完全繞開了這個問題：由作業系統負責散布，App 透過 Foundation Models取用，不必打包任何東西。至於隨 App 打包的模型，100 MB 以內相當寬裕；100 到 500 MB 搭配啟動時的載入策略也可行；超過 500 MB 最好用 BGProcessingTask 背景下載或隨選資源來處理。

新模型該用 Core ML 還是 Core AI？

在 iOS 27 以下，Core ML 是唯一選項。在 iOS 27 以上，Apple 表明的方向是類神經網路走 Core AI，傳統機器學習與既有部署則繼續用 Core ML¹¹¹²。如果您手上是一個固定的、已轉換的模型，而轉換器的預設行為就夠用，Core ML 依然可以順利出貨；如果需要對特化、快取或排程做明確控制，Core AI 存在的意義正是提供這種控制。

我怎麼知道量化有沒有傷到模型精度？

保留一份測試集，分別在原始的 Float32 模型與量化後的模型上跑推論，比較各項指標（分類器看 top-1 精度、偵測器看 F1、語言模型看 perplexity、翻譯看 BLEU 等），再依應用對精度的要求做決定。量化感知訓練（在損失函數中模擬量化來訓練模型）通常能挽回大部分的精度損失。

參考資料