MLX 在 Apple Silicon 上：當您需要的是自己的模型，而非 Apple 的模型

Apple 的 Foundation Models 框架只交給您一個模型：系統自己的那一個。封裝完整、免費，更新節奏由 Apple 決定。多數裝置端語言任務用它就對了，硬要越過它反而是個錯誤。但有些工作需要一個由您親自挑選的模型：某個特定的開放權重 LLM、一個由您鎖定的版本、一份以自有資料訓練出來的微調模型，或是系統模型根本不具備的能力。當您需要讓自己的模型在裝置上運行時，Foundation Models 底下那一層就是 MLX¹。

MLX 是 Apple 為 Apple Silicon 打造的機器學習陣列框架，並提供可直接嵌入 App 的 Swift API（MLX Swift）²。它不是您去呼叫的系統框架，而是您連同模型權重一起隨 App 發佈的函式庫。這個差別就是整筆交易的核心，也是您判斷該不該往下掉一層、還是待在 Apple 安排好的位置的依據。

TL;DR

• MLX 是為 Apple Silicon 而生、類似 NumPy 的陣列框架，具備惰性求值、可組合的函式轉換，以及 Metal 後端²。
• 統一記憶體模型是它能在手機上運作的原因。 陣列存放在 CPU 與 GPU 共用的同一塊記憶體池中，因此 MLX 可以在兩者上共用同一組緩衝區運算，不必付出主機到裝置的複製成本³。
• 用 LLMModelFactory 在裝置上執行開放權重 LLM，指向 mlx-community/Llama-3.2-3B-Instruct-4bit 這類量化模型，再透過 ChatSession 生成內容⁴。
• 以 LoRA adapter 微調：訓練一個小型 adapter，隨 App 附上 adapters.safetensors，load(into:) 會在執行期把基底模型的 Linear 層換成 LoRALinear⁵。
• 擁有自己的模型要付的代價：App 體積（權重很大）、記憶體壓力、缺乏系統整合，而且每一次更新都得自己扛。Foundation Models 完全沒有這些成本，因為帳單是 Apple 在付。

MLX 是什麼，以及 Apple Silicon 為何讓它成為可能

MLX 給您看起來像 NumPy 的陣列與運算，再加上機器學習所需的各種轉換：自動微分、向量化，以及先建構運算圖、直到讀取結果才真正執行的惰性求值²。這個專案的推進速度也帶著研究型框架的節奏：MLX 在 2026 年 7 月來到 0.32.0，MLX Swift 同一週發佈 0.31.6，發布節奏大約每隔幾週一次⁷。請鎖定版本，並預期 API 介面會持續擴張。光看這些描述，符合條件的框架不下十來個。真正讓 MLX 能在您口袋裡的裝置上跑動輒數十億參數模型的，是它的記憶體模型。

在桌機的 GPU 上，資料放在系統 RAM，運算時得跨匯流排複製到 GPU 自己的記憶體，算完再複製回來。這道複製就是稅金，對大型模型而言更是苛刻。Apple Silicon 採用統一記憶體：CPU、GPU 與 Neural Engine 共同定址同一塊記憶體池。MLX 正是圍繞這個事實設計的³。一個陣列不存在「在 CPU 上」或「在 GPU 上」之分；它就在記憶體裡，任何處理器都能就地操作。沒有複製，也沒有匯流排稅。一個量化到 4 bit 的 30 億參數模型只佔幾 GB，而且不需要那些來回搬運——在記憶體規格相近的獨立 GPU 機器上，正是這些搬運讓同樣的工作變得不切實際。Apple 多年前做下的硬體決定，才是裝置端跑真實模型得以成立的根本原因，而以 tile 為基礎、統一記憶體的架構正是 MLX 立足的地基。

在裝置上運行 LLM

從「我想要某個特定模型」到文字出現在畫面上，路徑很短。MLX Swift 的 LLM 層會從 Hugging Face Hub 載入量化模型並執行⁴：

let container = try await LLMModelFactory.shared.loadContainer(
    from: HubClient.default,
    using: TokenizersLoader(),
    configuration: .init(id: "mlx-community/Llama-3.2-3B-Instruct-4bit")
)

let session = ChatSession(container)
let response = try await session.respond(to: "Summarize this in one line: \(text)")

若 UI 需要逐 token 呈現，改成生成串流，收到片段就即時渲染⁴：

let input = try await container.prepare(input: UserInput(prompt: prompt))
let stream = try await container.generate(input: input, parameters: GenerateParameters())
for await event in stream {
    if case let .chunk(text) = event { /* append to UI */ }
}

實務上的份量幾乎都壓在兩個細節上。第一，模型 ID 裡的 4bit 不是可有可無的裝飾：正是量化讓模型塞得進記憶體、並以堪用的速度在裝置上運行。您交付的是 4 bit（或更低）的權重，不是完整精度。第二，即使量化過，權重依然龐大，所以您得刻意決定要把它們打包進 App（開箱即用，但下載檔案肥大），還是首次啟動時再下載（二進位檔輕巧，但使用者得等，而且失敗路徑要處理）。Foundation Models 從不會拋出這道題，因為模型早已在裝置上。換成 MLX，權重就是您的問題。

微調：一個 LoRA adapter，而不是一個新模型

自帶模型的理由，很少是基底模型本身，而是把您的領域知識教給它。在裝置上對數十億參數模型做完整微調並不是明智之舉，LoRA（低秩調適）才是解法：訓練一小組 adapter 權重來調整基底模型的行為，基底本身完全不動。adapter 的體積以 MB 計，不是 GB⁵。

MLX Swift 會從一個放有 adapter_config.json 與 adapters.safetensors 的資料夾載入訓練好的 adapter，再套用到已載入 container 的模型上⁵：

let adapter = try LoRAContainer.from(directory: adapterURL)
await container.update { context in
    try? adapter.load(into: context.model)   // swaps Linear layers for LoRALinear
}

load(into:) 會把模型標準的 Linear 層替換成 LoRALinear 層，將 adapter 的低秩差值折疊進去，於是推論結果便反映出您的微調。由於模型活在 container 內部，套用 adapter 要透過 container.update；而且您可以在執行期熱抽換 adapter（unload(from:) 卸下一個，load(into:) 換上另一個），讓同一個基底模型在不同功能下展現不同行為。這個模式與 Apple 透過 Foundation Models 自訂 adapter 為系統模型提供的做法相互呼應：差別在於這裡的基底模型、訓練流程與最終成果都歸您所有，而不是去調適一個您看不見的模型。

抉擇：Foundation Models、MLX，還是雲端

三個層級，選錯的代價不是損失能力，就是白白多做一堆本可避免的工。

• Foundation Models：當系統模型做得到這件事時就用它。免費、私密、不必隨 App 附上權重、不必自行管理記憶體，系統整合更是免費奉送。這裡就是預設值。Apple 為它設計的那些裝置端語言任務（摘要、分類、抽取、改寫、結構化輸出）就該留在這一層，沒有例外。
• MLX：當您需要系統不會給您的模型時才用：某個特定的開放權重 LLM、一個不會因 OS 更新而悄悄變動的鎖定版本、一份領域微調模型，或是 Foundation Models 範圍之外的架構（視覺語言模型、非文字模型）。您付出的是 App 體積、記憶體與維護責任，換回來的是控制權。
• 雲端：當模型真的非大不可時才用：前沿推理、長脈絡分析，以及那些最大的模型辦得到、而幾十億參數的裝置端模型辦不到的事。裝置端不是前沿模型的替代品，它只是同一條曲線上的另一個點。

誠實的解讀是：MLX 是為了特定理由而刻意往下掉的一層，不是更好的預設值。如果您說不出 Foundation Models 究竟缺了哪一項能力來支撐您的功能，那就不需要 MLX；硬要交付它，代價是扛著幾 GB 的權重和一份您本來不必背的記憶體預算。

iOS 27 在這張地圖上加了第四層。Core AI 是 Apple 用來執行您所提供模型的系統框架，對特化、快取與運算單元排程都有明確控制權。它與 MLX 在「您的模型、跑在裝置上」這一層重疊，但方向恰好相反：Core AI 是為已備妥的 .aimodel 提供由系統託管的執行介面，MLX 則是由您自行嵌入的函式庫，訓練迴圈、量化與反覆迭代都在裡面由您掌控。如果您的需求是在系統管理下快速執行一個轉換好的模型，Core AI 會來搶這份工作；如果您的需求是實驗、微調，或是握有整條流程，MLX 依然是那把工具。⁶

什麼時候不該伸手拿 MLX

• 系統模型早就做得到。 回頭重讀 Foundation Models 的任務清單。如果您的需求在名單上，到此為止。
• 您負擔不起權重。 量化過的小模型依然是龐大的資產。若 App 體積或首次啟動下載對您的使用者是實質限制，光這一項就可能替您做完決定。
• 您需要固定模型走 Neural Engine 的最低功耗路徑。 對於一個已知、已上線且不會變動的模型，Core ML 與它的轉換器能以最緊實的功耗與延遲鎖定 Neural Engine；而在 iOS 27 上，Core AI 是 Apple 明言的新神經網路工作方向，並具備明確的特化控制。MLX 的長處在彈性與研究級的迭代速度；系統框架的長處在鎖定成型的正式模型。它們是不同的工具，「裝置端 ML」也從來不是單一個決定。
• 您不會維護它。 自帶模型意味著更新、安全性與漂移全都由您承擔。系統模型則由 Apple 替您更新。如果您沒有人力去養一個模型，就別領養。

MLX 真正回報的能力，是對「何時該用它」的克制。這個框架確實非凡：一個真正的語言模型，針對您的領域微調過，完全在裝置上運行，沒有伺服器，也沒有按 token 計費的成本，而承載它的硬體，其記憶體架構正是為此而生。當您能講清楚理由時，這份能力值得伸手去拿。講不出理由就伸手，等於拿 Apple 那個免費、有人維護、與系統整合的模型，換來一份更笨重、無人維護、如今歸您所有的副本。判斷力就是這份工作的全部。

常見問題

Apple 的 MLX 框架是什麼？

MLX 是在 Apple Silicon 上執行機器學習的陣列框架，具備類似 NumPy 的 API、可組合的函式轉換（自動微分、向量化）、惰性運算與 Metal 後端²。MLX Swift 則是把它嵌入 App 所用的 Swift API，讓您能在裝置上執行並微調自己的模型。

MLX 如何運用 Apple Silicon 的統一記憶體？

MLX 陣列存放在共享記憶體中，因此運算可以在 CPU 或 GPU 上執行，不必在各自獨立的記憶體池之間搬運資料³。這種零搬運的特性，正是 Apple Silicon 統一記憶體架構在裝置端模型執行上如此高效的原因。

我可以用 MLX 在裝置上執行開放權重 LLM 嗎？

可以。LLMModelFactory.shared.loadContainer(from:using:configuration:) 會從 Hugging Face Hub 載入像 mlx-community/Llama-3.2-3B-Instruct-4bit 這樣的量化模型；ChatSession 提供 respond(to:) 處理單次呼叫，而 container.generate(input:parameters:) 則會串流 .chunk(text) 事件，用於逐步輸出⁴。

我要如何用 MLX 微調模型？

用 LoRA adapter，而不是新模型。LoRAContainer.from(directory:) 會從放有 adapter_config.json 與 adapters.safetensors 的資料夾載入 adapter；透過 container.update 套用後，它會把模型的 Linear 層換成 LoRALinear 層，並支援在執行期熱抽換 adapter⁵。

MLX、Foundation Models 與 Core ML：我該用哪一個？

當 Apple 的系統模型能勝任時，一律預設 Foundation Models（免費、私密、不必附帶權重）¹。只有在您需要系統不提供的模型時，才伸手拿 MLX：某個特定的開放權重 LLM、一個鎖定的版本、一份領域微調模型，或是 Foundation Models 範圍之外的架構。若是已鎖定成型、需要 Neural Engine 最低功耗路徑的正式模型，選 Core ML；在 iOS 27 上想讓自己的模型由系統託管執行，並保有明確的特化與排程控制，選 Core AI；而當模型確實非得是前沿規模不可時，選 雲端。

什麼情況下不該伸手拿 MLX？

當系統模型早已做得到、當您負擔不起交付數 GB 權重、當一個固定模型交給 Core ML 的最低功耗 Neural Engine 路徑更划算，或是當您沒有人力承擔一個模型的更新、安全性與漂移時。MLX 是為了明確理由而刻意往下掉的一層，不是更好的預設值。