Core ML vs MLX vs Foundation Models：如何選擇蘋果的裝置端 AI 技術堆疊

蘋果如今提供了四種在使用者硬體上執行模型的截然不同的方式，選錯一種就得付出重寫的代價。 在我寫下這篇文章的 M2 Max 上，MLX 能穩定跑出 11.2 TFLOPS 的 fp16 矩陣運算，並以實測 351 GB/s 的統一記憶體頻寬搬運資料¹。但對多數應用程式而言，這份算力是錯誤的選擇，因為系統內建的 Foundation Models 框架用六行 Swift 就能完成同樣的工作，而且下載大小一 MB 也不會增加。這四個框架並非彼此競爭，而是同一個問題的四種不同答案：模型是誰的，執行由誰維護？

TL;DR

• Foundation Models 是預設選項。如果蘋果裝置端那個約 30 億參數的 LLM 足以完成任務（摘要、擷取、分類、產生結構化輸出、呼叫您自己的工具），您就不必隨附任何模型權重，不必負擔推論成本，還能免費繼承每一次作業系統層級的模型升級。²
• Core ML 用於把 您自己 訓練好的模型裝進應用程式一起發布。它是唯一同時具備一流 Neural Engine 分派、契合 App Store 的封裝方式，以及以彈性換取續航力與可預測性的預先編譯契約的路徑。³
• MLX 適用於模型本身就是產品的情境：研究、微調、執行開放權重 LLM，或任何需要對張量進行即時掌控的工作負載。它是開發機與 Mac 應用程式的工具，而不是 iOS 的發布載具。⁴
• Core AI（iOS 27）是墊在這一切底下的新地基：一個低階的模型執行框架，具備 NDArray 張量與明確的運算單元指定，適合那些如今把 Core ML 當成張量執行環境來硬用的團隊。
• 這個決定通常只需要一個問題：內建模型就用 Foundation Models；自己的模型跑在 iOS 上就用 Core ML；自己的模型跑在自己的 Mac 上就用 MLX；在 iOS 上需要張量層級的掌控就用 Core AI。 本文其餘的篇幅，談的是這條經驗法則失效的那 20% 情況。

問題背後的問題

我看過的每一場「該用哪個框架」的爭論，最後都收斂到兩條軸上。（這四者我都寫過深入剖析：Foundation Models、Core ML、MLX、Core AI。）

第一條軸：權重是誰的？ 是蘋果的內建模型、您自己訓練或轉換的模型，還是您從模型庫拉下來的開放權重。Foundation Models 永遠只執行蘋果的模型（外加您的 LoRA 式轉接器）⁵。Core ML 與 MLX 永遠只執行您提供的權重。光是這一點，就在效能話題登場之前砍掉了一半的選項空間。

第二條軸：誰擁有執行過程？ Foundation Models 把一切都藏了起來：沒有張量，沒有運算單元，除了一個工作階段物件之外也沒有上下文視窗管理。Core ML 藏起大部分：您交給它一份編譯好的 .mlmodelc 並給出運算單元的提示，分派由框架決定。MLX 什麼都不藏：陣列運算由您自己寫，惰性求值與統一記憶體就是您手上的工具。Core AI 落在 Core ML 與 MLX 之間：張量與運算單元指定是明確的，但執行仍由蘋果代管。

把任何一項真實功能放到這兩條軸上，框架自己就選好了。

Foundation Models：零 MB 的預設解

多數團隊最該先試的框架，恰恰是那個完全不需要模型的框架。Foundation Models 透過 LanguageModelSession 揭露了 Apple Intelligence 背後的裝置端 LLM，而它的殺手鐧並不是模型本身，而是 引導式生成：替 Swift 結構體標註 @Generable，框架就會約束解碼過程，讓模型的輸出 就是 您的型別，而不是一串您得剖析後再祈禱格式正確的字串。²

@Generable
struct Itinerary {
    let destination: String
    let days: Int
    @Guide(description: "Budget in USD") let budget: Double
}

let session = LanguageModelSession()
let itinerary = try await session.respond(
    to: "Weekend in Kyoto under $800",
    generating: Itinerary.self
).content

整個整合就這麼多。沒有下載步驟，沒有量化決策，也不必費心推敲發熱問題；作業系統負責排程模型，把它分享給裝置上的每一個應用程式，並在每次發行時升級它。工具呼叫讓模型能夠執行您定義的函式，這已足以在完全不依賴伺服器的情況下，做出真正具備代理特質的功能。²

限制同樣是對稱的：這是一個約 30 億參數的通才模型。它擅長摘要、擷取、分類，也能有模有樣地產出結構化輸出；但它不處理開放領域的世界知識、長上下文的文件分析，也做不到前沿模型能做的那些事。當內建模型不夠用時，蘋果給出的答案是轉接器（用蘋果的工具組針對基礎模型訓練的 LoRA 式微調），但轉接器意味著一份長期承諾：蘋果每改版一次基礎模型，您就得重新訓練一次⁵。包含工作階段管理與審查者常踩到的失敗模式在內的完整拆解，都在Foundation Models 深入剖析裡。

何時選它：任務呈現語言的形態、內建模型能達到您的品質標準，而且「不隨附任何權重」這件事很重要。符合條件的功能比多數團隊以為的多得多；在伸手拿下面任何一項之前，不妨先試試它。

Core ML：您的模型，蘋果的執行

Core ML 回答的是另一個問題。您已經有一個模型（視覺分類器、嵌入模型、語音管線、蒸餾過的 LLM），而它必須在 iOS 應用程式內部執行、靠電池供電、控制在 App Store 的大小限制之內，而且今年就要上線。

它的契約是預先編譯。您用 coremltools 轉換權重，模型編譯成 .mlmodelc，執行時由框架在 Neural Engine、GPU 與 CPU 之間分派；而 ANE 正是這份清單上其他選項在今天的 iOS 上給不了您的東西。真正的工程含量集中在轉換這一步：運算子涵蓋率、量化（調色盤化、線性 8/4 位元、稀疏化，coremltools 的最佳化堆疊真的很深⁶），以及決定您的模型跑在 2 瓦還是 8 瓦的運算單元提示。那些真正能在正式環境存活下來的做法（分派提示、延遲預算、量化階梯），正是Core ML 支柱文章的主題。

Core ML 不做什麼同樣關鍵：它不訓練、不微調，也不讓您在計算圖中途碰到張量。它是一台推論專用設備。那些既要「執行我的圖」又要「戳一戳中間結果」的團隊，向來只能把 Core ML 硬掰成張量執行環境；而 Core AI 的存在，正是為了吸收這種扭曲。

何時選它：權重是您自己的、目標平台是 iOS/iPadOS（或跨蘋果平台），而且續航力、大小、ANE 都很重要。換句話說，幾乎涵蓋了這個平台上所有已發布的自訂模型功能。

MLX：裝在 Mac 裡的研究機器

MLX 是這裡的異類：它是蘋果機器學習研究團隊推出的開源陣列框架，而不是作業系統框架⁴。它長得像 NumPy，採用惰性求值，並把 Apple silicon 的統一記憶體當成一項實實在在的特性來用：沒有主機到裝置的複製，因為根本不存在獨立的裝置記憶體。

這台機器上的數字讓論點變得具體。在完全不調校的情況下，M2 Max 在 MLX 之下穩定跑出 4096×4096 的 fp16 矩陣乘法 11.2 TFLOPS，以及實測 351 GB/s 的串流頻寬¹：足以互動式地執行量化後的 300 億參數開放權重模型、用 LoRA 一夜之間微調 70 億參數模型，並反覆迭代那些原本得去租雲端 GPU 才跑得動的訓練工作。有了 mlx-lm 生態系，多數開放模型不過是一次 pip install 加一次下載的距離。

邊界同樣具體。沒有 Neural Engine：MLX 編寫的對象是 GPU（與 CPU），不是 ANE。沒有 iOS 發布路線：技術上您確實可以嵌入它，但權重散布、發熱與審查指南都說明這是錯誤的工具；MLX 屬於您的 Mac、您使用者的 Mac，以及您的研究迴圈。而且沒有人替您管理執行：記憶體壓力、量化選擇、求值排程全歸您自己。什麼時候「用自己的模型而不是蘋果的模型」值得承擔這份所有權，MLX 支柱文章有詳細討論。

何時選它：您正在訓練或微調、正在本機執行開放權重 LLM，或者正在打造那種「對模型的掌控本身就是產品」的 Mac 原生工具。如果您的主力機是一台記憶體充裕的 Apple silicon Mac，MLX 能把它變成一台名副其實的機器學習工作站。

Core AI：新的地基

iOS 27 補上了蘋果一直缺席的那一層：Core AI，一個低階的模型執行框架，具備 NDArray 張量、資產與模型的區分、明確的運算單元指定，以及可呼叫的推論函式⁷。當 Core ML「把編譯好的模型交給我，你拿走預測結果」的契約過於僵硬時，就該用它：把張量運算與模型呼叫交織在一起的管線、本來就該跑在 ANE 上的自訂前處理與後處理，以及共用緩衝區的多模型計算圖。

兩點澄清能讓多數讀者少走一段冤枉路。Core AI 不是 Foundation Models 的替代品（這一層依然沒有內建 LLM，編譯好的資產得您自己帶）。它也 不是 iOS 版的 MLX：沒有訓練，沒有自動微分，沒有即時執行的研究迴圈。它是打開了艙蓋的 Core ML 機艙。如果您從未與 Core ML 的抽象搏鬥過，那您並不需要 Core AI；可一旦您發布過 MLMultiArray 的雜技表演，或為了串接模型而塞進不必要的轉換，您其實已經需要了。張量模型與指定用的 API 詳見Core AI 支柱文章。

真正會被拿出來爭論的情況

「我們需要一個 LLM，但要用自己的／更大的。」 Foundation Models 無法載入外部權重，沒有例外。走 Core ML 的蒸餾小型 LLM 可行，還能拿到 ANE；走 MLX 的量化開放模型在 Mac 上可行。也請誠實面對那個裝置端圈子裡沒人願意說出口的替代方案：如果任務需要前沿級的品質，答案就是一次伺服器呼叫，而裝置端那幾層負責承接後備路徑與隱私敏感的子集合。

「我們想在 iPhone 與 Mac 上用同一套堆疊。」 Foundation Models 與 Core ML 在蘋果生態系內部都是跨平台的；MLX 實際上只屬於 Mac。同時推出 Mac 專業版應用程式與 iOS 隨行應用程式的團隊，往往最後落腳在 Mac 上用 MLX（大模型、使用者自備權重），iOS 上用 Core ML 或 Foundation Models：同一項功能、兩套引擎，以及一次對「裝置本來就不同」的誠實承認。

「我們已經有一條 Core ML 管線了，Core AI 是遷移目標嗎？」 只在管線真正讓人難受的地方才是。Core AI 吸收的是那些張量形態的邊緣；今天運作良好的編譯模型核心，會繼續照常運作。把一套健康的 Core ML 部署整批搬過去，什麼也換不來。

「SwiftData 或 App Intents 會改變這些結論嗎？」 相鄰，但不重疊：您的模型層為那些由 App Intents 向系統揭露的功能提供養分，而您所保存的一切都遵循SwiftData 的結構描述紀律。這裡討論的框架決定的是 推論如何執行，而不是圍繞它的應用程式該怎麼蓋。

一棵決策樹

Is the task language-shaped and within a ~3B generalist's reach?
├── YES → Foundation Models. Ship zero weights. Done.
└── NO → Whose weights?
    ├── Apple's, but specialized → Foundation Models + trained adapter
    │     (accept: retrain per base-model rev)
    └── Yours →  Where does it run?
        ├── iOS/iPadOS app → Core ML
        │     └── unless you need tensor-level control → Core AI (iOS 27+)
        ├── Mac, models-as-product / training / open weights → MLX
        └── Frontier-quality required → server, with on-device fallback

重點整理

給要交付功能的應用程式團隊： - 先拿 Foundation Models 做原型；六行 Swift 是想得到的最便宜的實驗，而「內建模型其實就夠了」是最常見的意外收穫。 - 把 Core ML 的轉換時間與推論時間分開編列預算；吞掉數週時間的地方是運算子涵蓋率與量化。

給機器學習工程師： - 一台 64GB 以上的 Apple silicon Mac，在 MLX 之下就是一台真正的微調機器；在去租雲端 GPU 之前先量一量。上面那組 11.2 TFLOPS／351 GB/s 的數字，出自一顆落後兩個世代的筆電晶片。¹ - ANE 依然是 Core ML（如今還有 Core AI）的護城河。如果每次推論的耗電很關鍵，沒有哪條 GPU 路徑競爭得過。

給架構師： - 把這四個框架當成層次而非對手：語言類功能用 Foundation Models，隨應用程式發布的自訂模型用 Core ML，張量形態的邊緣用 Core AI，Mac 與實驗室用 MLX。在正經的應用程式裡，混合部署是常態，不是壞味道。 - 模型的 所有權 才是長期的成本中心：Foundation Models 的權重由蘋果維護，其餘的一切都由您維護。請把這一點算進選擇的價格裡。

常見問題

要在裝置端執行模型，該用蘋果的哪個框架？

這個決定通常只需要一個問題。內建模型就用 Foundation Models；自己的模型跑在 iOS 上就用 Core ML；自己的模型跑在自己的 Mac 上就用 MLX；在 iOS 上需要張量層級的掌控就用 Core AI。把功能放到兩條軸上——它執行的是誰的權重，以及誰擁有執行過程——框架自己就選好了。把這四者當成層次而非對手；在正經的應用程式裡，混合部署是常態。

Foundation Models 能執行我自己的模型權重嗎？

不能。Foundation Models 永遠只執行蘋果內建的裝置端模型，也就是那個約 30 億參數的通才模型，外加您的 LoRA 式轉接器。它無法載入外部權重，沒有例外。如果您需要自己的 LLM，走 Core ML 的蒸餾小模型可行，還能拿到 Neural Engine；走 MLX 的量化開放模型在 Mac 上可行。如果任務需要前沿級的品質，答案就是一次伺服器呼叫。⁵

我能把 MLX 包進 iOS 應用程式發布嗎？

現實上不可行。MLX 是蘋果機器學習研究團隊推出的開源陣列框架，而非作業系統框架；它只編寫 GPU 與 CPU，沒有 Neural Engine 存取權；再加上權重散布、發熱與審查指南，它對 iOS 安裝套件而言是錯誤的工具。MLX 屬於您的 Mac、您使用者的 Mac，以及您的研究迴圈。⁴

Core ML 與 Core AI 有什麼差別？

Core ML 是預先編譯式的推論：您交給它一份編譯好的 .mlmodelc，給出運算單元的提示，分派由框架決定。iOS 27 新增的 Core AI，則是那間機艙打開了艙蓋：NDArray 張量、資產與模型的區分，以及明確的運算單元指定。它依然不做訓練，也不隨附任何內建 LLM。如果您從未與 Core ML 的抽象搏鬥過，就不需要它。⁷

M2 Max 跑本機機器學習有多快？

在我寫下這篇文章的 M2 Max 上，MLX 在完全不調校的情況下，穩定跑出 4096×4096 的 fp16 矩陣乘法 11.2 TFLOPS，以及實測 351 GB/s 的串流頻寬。這足以互動式地執行量化後的 300 億參數開放權重模型，並用 LoRA 一夜之間微調 70 億參數模型。在去租雲端 GPU 之前先量一量；這些數字出自一顆落後兩個世代的筆電晶片。¹

參考資料