Core ML 裝置端推論：真正能上線的模式

Core ML 是隨每一台現代 Apple 裝置出貨的裝置端推論引擎。此框架會根據模型與硬體自動選擇最快的路徑：在 Neural Engine 可用時調度至 Neural Engine，否則改用 GPU,最後才退回 CPU¹。在近期的 iPhone 上,大多數正式環境的模型尺寸可達到次毫秒到數十毫秒的推論延遲,每次呼叫零成本,沒有網路往返,也不會將資料暴露給第三方。

「冷僻管線」這種對 Core ML 的舊印象早已過時。如今 Core ML 為 Apple Intelligence 的裝置端 LLM、相片 App 的語意搜尋、相機 App 的場景辨識,以及大多數出貨本地 ML 的第三方 App 提供動力。讓 Core ML 部署真正能上線而不是「在我電腦上能跑」的模式其實只有一小組:模型轉換、調度提示、延遲預算與量化。本文將對照 Apple 官方文件逐一說明。

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 上的推論,代價是視模型而定的可量測精度損失。
與代理工作流的銜接:Foundation Models(Apple Intelligence 的裝置端 LLM)以高階 Swift API 包裝的 Core ML 模型形式出貨;同樣的調度與量化模式皆適用。

心智模型:三條運算路徑,一塊記憶體

Apple Silicon(M 系列 Mac 與 A12 Bionic 之後的 A 系列 iPhone)出貨三種推論目標:

Neural Engine。 一種針對低精度矩陣乘法設計的專用加速器。對現代 ML 模型仰賴的運算(卷積、注意力、嵌入)而言速度最快,功耗最低。僅支援特定運算類型與張量形狀;不支援的運算會逐層退回 GPU 或 CPU。

GPU。 透過 Metal 進行的通用平行運算。對 ML 形狀的工作而言比 Neural Engine 慢,但比 CPU 快。負責處理 Neural Engine 不支援的運算。

CPU。 後備方案。ML 推論很慢,但永遠可用、永遠支援所有運算,且結果可預測。

統一記憶體架構意謂著同一塊實體 RAM 支援上述三者³。模型權重一次載入後,在不同目標之間切換調度時不會被複製。這項架構事實將多目標調度從「逐層複製成本」轉變為「逐層排程決策」。

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⁴。轉換透過 coremltools 進行,這是 Apple 的開源 Python 套件⁵。

典型的 PyTorch 至 Core ML 轉換流程包含三個步驟:

載入訓練完成的 PyTorch 模型,並將其切換為推論模式。
使用符合正式環境輸入形狀的範例輸入張量對模型進行 trace。
用 coremltools 針對目標部署的 iOS 版本轉換 traced 模型。

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.iOS18,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

轉換只在開發環境執行一次,並針對目標部署的 iOS 版本(minimum_deployment_target)進行。產生的 .mlpackage 才是被加入 Xcode 專案的檔案。執行階段的 App 並不會執行 coremltools。

轉換時有兩個實務上的陷阱。第一,動態形狀輸入需要透過 ct.RangeDim 明確處理,因為 Core ML 的靜態形狀預設值在正式環境 App 餵入不同尺寸時會產生語意不明的錯誤。第二,在 PyTorch 中沒有 Core ML 對應運算的自訂 op 需要 Core ML 自訂 layer(以 Swift 程式碼執行缺少的 op),或是在轉換前修改模型架構以移除該 op。兩者都有完整的文件可參考⁵。

真正適用的延遲預算

對上線的 App 而言,有三種延遲預算最重要:

16 ms(60 fps 即時 UI)。 即時相機濾鏡、每幀更新的 AR 場景、即時音訊分析器。預算涵蓋全部:影像前處理、模型推論、後處理、UI 更新。能塞進這個預算的模型通常很小(MobileNetV3 等級,參數量低於 100M),並在 Neural Engine 上執行。

100 ms(互動式 UI)。 使用者執行動作後等待結果:點選辨識、繪製識別、口述轉錄。預算寬鬆得多,可支援更大的模型。10 億參數以下的語言模型、小型 vision transformer,以及大多數正式等級的分類器都能輕鬆容納。

1 秒以上(背景或批次)。 相片庫索引、文件分析、App 啟動時的模型暖機。較大的模型在這裡可行,但必須以進度指示器設定使用者預期。Foundation Models 的裝置端 LLM 在較大上下文視窗的操作上即落於此範圍。

這些預算只是參考,而非硬性限制。正確做法是在目標裝置上以 os_signpost 或 Instruments 的 Core ML 模板實際量測⁶,而非相信來自其他機器的理論數字。

量化:更小有時更快

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

Float32(全精度)。 訓練時的預設值。最大、最準、最慢。
Float16。 半精度。在 GPU 與 NE 上更小且更快;對條件良好的模型而言,精度損失通常微不足道。
INT8。 帶校準的 8 位元整數量化。約比 Float32 小 4 倍,在 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 的預訓練模型即涵蓋感知原語(分類、偵測、分割),不需自行訓練。Foundation Models 的裝置端 LLM(於 Foundation Models on-device LLM 詳述)是最大的範例:一個數十億參數的 LLM,以高階 Swift API 包裝的 Core ML 模型形式出貨,於 Neural Engine 上調度,離線可用。

模型加密與 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 是以高階 Swift API 包裝的 Core ML 模型。同樣的調度模式(優先 Neural Engine)、量化模式(LLM 權重採 INT4)與延遲預算模式(短生成低於一秒)皆適用。Foundation Models 一文涵蓋 API;本文則涵蓋底層引擎。

使用本地 ML 的 App Intents 工具。 一個執行本地影像分類器或文字分類器的 AppIntent,能將結構化結果回傳給 Apple Intelligence,完全不需要網路往返。這個組合正是讓「代理化的 Apple」真正能保有隱私的關鍵;代理的工具在本地執行,因為框架支援這件事。

何時雲端推論才是正解

Core ML 的天花板就是裝置本身的算力。三種雲端較合適的情境:

模型過大無法放進 bundle。 一個 700 億參數的 LLM 不可能塞進 App bundle。對於這個規模的工作負載,雲端推論(或裝置端串流權重——一種不同的模式)才是正確工具。

推論期間需跨裝置共享狀態。 推論過程需要讀寫共享資料庫的模型(對億級紀錄做協同過濾的推薦系統)。Core ML 純本地的模型並不適配。

快速模型迭代。 每天出貨模型更新的團隊會受益於伺服器端推論,因為發布不需要 App Store 審查週期。Core ML 將模型打包進 App 的模式為模型迭代節奏增加了摩擦;這個取捨是真實存在的。

模式為:雲端在規模與迭代速度上勝出;Core ML 在延遲、成本與隱私上勝出。

這個模式對 iOS 26+ App 的意義

三項要點。

對於任何能塞進 bundle 並產生使用者可以行動的逐次呼叫結果的模型,預設使用 Core ML。 影像分類、物件偵測、音訊分類、手勢辨識、嵌入產生、中小型語言任務皆然。框架的自動調度搭配 Apple Silicon 的 NPU,免費提供次毫秒到數十毫秒的推論。
在精度損失可接受時積極量化。 INT8 通常安全;INT4 適合大型模型——大小節省的價值最為顯著。請在保留的測試集上實際量測精度,而非假設量化普遍安全。
與 Vision 和 Foundation Models 搭配,組成完整的本地流程。 Core ML 是引擎;Vision 是其上的感知 API;Foundation Models 是其上的 LLM。本系列的 Vision 文章與 Foundation Models 文章涵蓋更高階的介面層。

完整的 Apple Ecosystem 系列:具型別的 App Intents;MCP 伺服器;路由問題;Foundation Models;執行階段 vs 工具鏈 LLM 的區別;三個介面層;單一真實來源模式;兩個 MCP 伺服器;適用於 Apple 開發的 hooks;Live Activities;watchOS 執行階段;SwiftUI 內部構造;RealityKit 的空間心智模型;SwiftData schema 紀律;Liquid Glass 模式;多平台出貨;平台矩陣;Vision 框架;Symbol Effects;我拒絕書寫的主題。系列入口在 Apple Ecosystem Series。若需更廣的「iOS 與 AI 代理」脈絡,請參閱 iOS Agent Development guide。

FAQ

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

Core ML 會檢視模型圖中的每一個運算,並將其調度至支援該運算且速度最快的目標。Neural Engine 以最低延遲與功耗處理其支援的運算(大多數矩陣乘法、卷積、注意力)。GPU 處理 NE 不支援的運算。CPU 處理其餘部分。決策是逐運算、自動的,且比手寫的啟發式更快。

我是否應該總是使用 `.computeUnits = .all`?

幾乎總是。框架的自動調度已調校得很好。請僅在以下情況覆寫:測試輸出一致性時改為 .cpuOnly(同一模型在 NE vs 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,且空中安裝(OTA)有實務上的限制。Foundation Models 的裝置端 LLM 約 3 GB,並由作業系統而非 App bundle 進行分發。對於打包進 App 的模型,低於 100 MB 很舒適;100-500 MB 在採用啟動時載入策略下可行;500 MB 以上最好透過 BGProcessingTask 背景下載或 on-demand resources 處理。

我如何知道量化是否傷害了模型的精度?

保留一個測試集,對原始 Float32 模型與量化後模型分別執行推論,比對指標(分類器看 top-1 精度、偵測器看 F1、語言模型看 perplexity、翻譯看 BLEU 等等),再依該應用對精度的需求決定。量化感知訓練(在訓練時於損失函數中模擬量化)通常能挽回大部分的精度損失。

References

Apple Developer Documentation: Core ML. Framework reference covering automatic dispatch behavior across compute units. ↩
Apple Developer Documentation: MLModelConfiguration.computeUnits. Enum cases controlling which compute units the model may use. ↩
Apple Developer: Apple silicon performance (WWDC 2020 introduction to Apple Silicon’s unified memory architecture). ↩↩
Apple Developer Documentation: Core ML Model. .mlpackage and .mlmodel format reference. ↩
coremltools documentation. Apple’s open-source Python package for converting trained models from PyTorch, TensorFlow, and ONNX to Core ML. ↩↩
Apple Developer Documentation: Profiling Core ML models with Instruments. The Core ML Instruments template for per-layer latency and dispatch analysis. ↩
coremltools Optimization. Quantization techniques and accuracy-preservation patterns supported by Core ML. ↩
Apple Developer: Core ML Models. Apple’s gallery of pre-trained models ready to drop into iOS apps. ↩
Apple Developer Documentation: Encrypting a Model in Your App. The CloudKit-backed encryption workflow for Core ML models. ↩
Apple Developer Documentation: Privacy manifest files. The format for declaring an app’s data-collection and tracking behaviors. ↩

Core ML 裝置端推論：真正能上線的模式

心智模型:三條運算路徑,一塊記憶體

模型轉換:工具鏈的工作

真正適用的延遲預算

量化:更小有時更快

可直接套用的 Apple 內建模型

模型加密與 App Store 考量

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

與代理工作流的連結

何時雲端推論才是正解

這個模式對 iOS 26+ App 的意義

FAQ

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

我是否應該總是使用 `.computeUnits = .all`?

`.mlpackage` 與 `.mlmodel` 的實務差異是什麼?

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

我如何知道量化是否傷害了模型的精度?

References

相關文章

Apple's Vision Framework: What's Built In That Most Devs Reach for Cloud APIs For

What SwiftUI Is Made Of

Building AI Systems: From RAG to Agents

心智模型:三條運算路徑,一塊記憶體

模型轉換:工具鏈的工作

真正適用的延遲預算

量化:更小有時更快

可直接套用的 Apple 內建模型

模型加密與 App Store 考量

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

與代理工作流的連結

何時雲端推論才是正解

這個模式對 iOS 26+ App 的意義

FAQ

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

我是否應該總是使用 .computeUnits = .all?

.mlpackage 與 .mlmodel 的實務差異是什麼?

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

我如何知道量化是否傷害了模型的精度?

References

相關文章

Apple's Vision Framework: What's Built In That Most Devs Reach for Cloud APIs For

What SwiftUI Is Made Of

Building AI Systems: From RAG to Agents

我是否應該總是使用 `.computeUnits = .all`?

`.mlpackage` 與 `.mlmodel` 的實務差異是什麼?