Apple Silicon上のMLX——Appleのモデルではなく、自前のモデルが必要になったとき

AppleのFoundation Modelsフレームワークが手渡してくれるモデルは1つだけです。システムのモデルであり、封をされていて、無料で、更新はAppleのスケジュールに従います。オンデバイスの言語処理の大半にとってはそれが正解であり、その先へ手を伸ばすのはむしろ誤りです。とはいえ、自分で選んだモデルでなければ務まらない仕事もあります。特定のオープンウェイトLLM、固定しておきたいバージョン、自前のデータで学習させたファインチューン、あるいはシステムモデルが持っていない能力——そうしたときです。自前のモデルをオンデバイスで動かす必要が出てきたとき、Foundation Modelsの一段下に控えているのがMLXです¹。

MLXは、Apple Siliconでの機械学習のためにAppleが用意した配列フレームワークで、アプリに直接組み込めるSwift API（MLX Swift）を備えています²。呼び出す先のシステムフレームワークではなく、モデルの重みごと自分で同梱して配布するライブラリです。この違いこそがトレードオフのすべてであり、ここを理解して初めて、一段下りるべきか、Appleが用意した場所に留まるべきかを判断できます。

要点

• MLXはApple Silicon向けに作られたNumPy風の配列フレームワークで、遅延評価、合成可能な関数変換、Metalバックエンドを備えます²。
• スマートフォン上で成立する理由は、ユニファイドメモリのモデルにあります。 配列はCPUとGPUが共有する単一のメモリプールに置かれるため、MLXは同じバッファ上で両者をまたいで動作し、ホスト・デバイス間のコピーという税を払わずに済みます³。
• オープンウェイトLLMをオンデバイスで動かすには、LLMModelFactoryでmlx-community/Llama-3.2-3B-Instruct-4bitのような量子化モデルを指定し、ChatSession経由で生成します⁴。
• ファインチューンはLoRAアダプターで行います。小さなアダプターを学習させ、adapters.safetensorsを同梱すれば、load(into:)が実行時にベースモデルのLinear層をLoRALinearに差し替えます⁵。
• 自前モデルの代償は、アプリサイズ（重みは巨大です）、メモリ圧迫、システム統合の欠如、そして更新をすべて自分で背負うこと。Foundation Modelsにこれらの代償がないのは、Appleが肩代わりしているからです。

MLXとは何か、そしてApple Siliconがそれを可能にする理由

MLXが提供するのは、NumPyのように見える配列と演算、加えて機械学習に必要な変換群です。自動微分、ベクトル化、そして計算グラフを構築して結果を読み出すときに初めて実行する遅延評価です²。プロジェクトの進み方も研究フレームワークのそれで、MLXは2026年7月に0.32.0、MLX Swiftは同じ週に0.31.6に到達しており、リリース間隔はおおむね数週間ごとです⁷。バージョンは固定し、APIの表面積が広がり続けることを前提にしてください。ここまでなら、当てはまるフレームワークは十指に余ります。数十億パラメータのモデルをポケットの中のデバイスで動かせるようにしているのは、メモリモデルのほうです。

デスクトップのGPUでは、データはシステムRAMに置かれ、計算のためにバス越しにGPU専用メモリへコピーし、結果をまた戻します。このコピーが税であり、大きなモデルではその負担は容赦がありません。Apple Siliconはユニファイドメモリを採用しています。CPU、GPU、Neural Engineのすべてが直接アドレスできる単一のプールです。MLXはその事実を軸に設計されています³。配列は「CPU上」でも「GPU上」でもなく、ただメモリにあるだけで、どのプロセッサもその場で操作します。コピーもバス税もありません。4ビットに量子化された30億パラメータのモデルなら数ギガバイトに収まり、同程度のメモリを積んだ独立GPU機ではとうてい実用にならないような往復を伴わずに動きます。端末上で本物のモデルを推論させることが成り立つのは、Appleが何年も前に下したハードウェアの決断があってこそであり、タイルベースかつユニファイドメモリのアーキテクチャが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に反映したい場合は、ストリームを生成して届いた断片から描画します⁴。

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 */ }
}

実務上の重みは、この2つの細部がほとんど背負っています。第一に、モデルIDの4bitは飾りではありません。量子化があってこそ、モデルはメモリに収まり、デバイス上で使いものになる速度で動きます。配布するのは4ビット（あるいはそれ以下）の重みであって、フル精度ではありません。第二に、量子化しても重みは大きいままなので、アプリに同梱する（すぐ使えるが、ダウンロードは肥大する）か、初回起動時に取得する（バイナリは軽いが、待ち時間と失敗時の経路を抱える）かを、意識して選ぶことになります。Foundation Modelsがこの問いを突きつけてこないのは、モデルがすでに端末にあるからです。MLXでは、重みは自分で抱える問題になります。

ファインチューン——新しいモデルではなく、LoRAアダプターで

自前のモデルを持ち込む理由は、ベースモデルそのものであることはまずありません。自分のドメインを教え込むことです。数十億パラメータのモデルをオンデバイスでフル・ファインチューンするのは筋の悪い手です。筋がいいのはLoRA（低ランク適応）のほうです。ベースモデルには手を触れず、その振る舞いを調整する小さなアダプター重みだけを学習させます。アダプターはギガバイトではなくメガバイト単位です⁵。

MLX Swiftは、adapter_config.jsonとadapters.safetensorsを収めたディレクトリから学習済みアダプターを読み込み、コンテナにロード済みのモデルへ適用します⁵。

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層に置き換えます。これで推論にファインチューンの結果が反映されるわけです。モデルはコンテナの内側にあるため、アダプターの適用はcontainer.updateを通して行い、実行時のホットスワップも可能です（一方をunload(from:)し、もう一方をload(into:)する）。同じベースモデルに、機能ごとに異なる振る舞いをさせられます。この構図は、Appleがシステムモデル向けに用意したFoundation Modelsのカスタムアダプターと重なります。違いは、こちらではベースモデルも学習パイプラインも成果物も自分のものであり、中身の見えないモデルに適応させるのではない、という点です。

判断——Foundation Models、MLX、それともクラウドか

層は3つあります。選び違えれば、能力を失うか、避けられたはずの作業の山を抱えるかのどちらかです。

• Foundation Models——システムモデルでその仕事がこなせるなら。無料で、プライベートで、同梱すべき重みはゼロ、管理すべきメモリもゼロ、システム統合はタダで付いてきます。既定はここです。Appleがこのために作ったオンデバイスの言語タスク（要約、分類、抽出、書き換え、構造化出力）は、議論の余地なくここに属します。
• MLX——システムが与えてくれないモデルが必要なとき。特定のオープンウェイトLLM、OSアップデートで足元が動かない固定バージョン、ドメイン特化のファインチューン、あるいはFoundation Modelsの守備範囲外のアーキテクチャ（視覚言語モデル、非テキストモデル）。アプリサイズとメモリと保守責任で支払い、制御を買うわけです。
• クラウド——モデルが本当に大きくなければならないとき。フロンティア級の推論、長文脈の分析、数十億パラメータのオンデバイスモデルには手の届かない、最大級のモデルだけができること。オンデバイスはフロンティアモデルの代替ではなく、曲線上の別の点にすぎません。

正直に読めばこうなります。MLXは、はっきりした理由があって意図的に一段下りる選択であって、より良い既定ではありません。自分の機能にとってFoundation Modelsに欠けている能力を名指しできないなら、MLXは必要ありません。それでも配布するということは、ギガバイト級の重みと、抱える必要のなかったメモリ予算を背負うということです。

iOS 27は、この地図に4つめの層を加えます。Core AIは、自分で用意したモデルを実行するためのAppleのシステムフレームワークで、特化（specialization）、キャッシュ、演算ユニットのスケジューリングを明示的に制御できます。「自分のモデルをオンデバイスで」という階層でMLXと重なりますが、向きは正反対です。Core AIは、用意済みの.aimodelをシステム管理のもとで実行するための場を提供します。一方のMLXは、学習ループも量子化も反復も自分の手元に抱えたまま組み込むライブラリです。変換済みモデルをシステム管理のもとで高速に動かすのが目的なら、Core AIが仕事を取りに来ます。実験したい、ファインチューンしたい、パイプライン全体を自分のものにしたいのなら、道具はやはりMLXです⁶。

MLXに手を伸ばすべきでないとき

• システムモデルですでに足りている。 Foundation Modelsのタスク一覧をもう一度読んでください。自分の用途がそこに載っているなら、話はここで終わりです。
• 重みのコストを払えない。 量子化された小型モデルでも、アセットとしては十分に大きいものです。アプリサイズや初回ダウンロードがユーザーにとって現実的な制約なら、それだけで結論が出てしまうこともあります。
• 固定モデルに対してNeural Engineの最省電力経路が要る。 変わることのない既知の出荷済みモデルであれば、Core MLとそのコンバーターが電力とレイテンシを最も切り詰めてNeural Engineを狙えますし、iOS 27ではCore AIが、明示的な特化制御を伴う新規ニューラルネットワーク開発についてAppleが示す方向です。MLXが光るのは柔軟性と研究水準の反復であり、システムフレームワークが光るのは作り込んで固めた本番モデルのほうです。別々の道具であって、「オンデバイスML」はひとつの判断ではありません。
• 保守する気がない。 自前のモデルを持つとは、その更新も、セキュリティも、ドリフトも自分で引き受けるということです。システムモデルはAppleが更新してくれます。モデルを抱える体制がないなら、抱えないことです。

MLXが報いてくれる技量は、いつ使うかについての自制です。このフレームワークは本当に見事です。本物の言語モデルを自分のドメインに合わせてファインチューンし、サーバーもトークン単価もなしに、まさにこのために作られたメモリアーキテクチャのハードウェア上で、完全に端末内で走らせられるのです。理由を名指しできているなら、その能力は手を伸ばす価値があります。理由なしに手を伸ばせば、Appleが無料で保守し統合してくれるモデルを、より重く、誰も保守しない、いま自分のものになった複製と引き換えたことになります。見極めることが、仕事のすべてです。

よくある質問

AppleのMLXフレームワークとは何ですか

MLXはApple Siliconでの機械学習のための配列フレームワークで、NumPy風のAPI、合成可能な関数変換（自動微分、ベクトル化）、遅延計算、Metalバックエンドを備えます²。MLX Swiftはこれをアプリに組み込むためのSwift APIで、自前のモデルをオンデバイスで実行・ファインチューンできます。

MLXはApple Siliconのユニファイドメモリをどう使いますか

MLXの配列は共有メモリに置かれるため、別々のメモリプール間でデータをコピーすることなく、CPUでもGPUでも演算が走ります³。この転送ゼロという性質こそ、Apple Siliconのユニファイドメモリ・アーキテクチャがオンデバイスのモデル実行で効率的である理由です。

MLXでオープンウェイトLLMをオンデバイスで動かせますか

動かせます。LLMModelFactory.shared.loadContainer(from:using:configuration:)がmlx-community/Llama-3.2-3B-Instruct-4bitのような量子化モデルをHugging Face Hubから読み込みます。単発の呼び出しにはChatSessionのrespond(to:)を、逐次出力にはcontainer.generate(input:parameters:)が流す.chunk(text)イベントを使ってください⁴。

MLXでモデルをファインチューンするには

新しいモデルを作るのではなく、LoRAアダプターを使います。LoRAContainer.from(directory:)がadapter_config.jsonとadapters.safetensorsを収めたディレクトリからアダプターを読み込み、container.updateを通して適用すると、モデルのLinear層がLoRALinear層に差し替わります。アダプターは実行時にホットスワップも可能です⁵。

MLX、Foundation Models、Core MLのどれを使うべきですか

Appleのシステムモデルでその仕事がこなせるなら、既定はFoundation Modelsです（無料、プライベート、同梱する重みはゼロ）¹。MLXに手を伸ばすのは、システムが与えてくれないモデルが必要なときだけ。特定のオープンウェイトLLM、固定バージョン、ドメイン特化のファインチューン、あるいはFoundation Modelsの守備範囲外のアーキテクチャです。Neural Engineの最省電力経路を要する作り込んだ本番モデルにはCore ML、自前モデルを明示的な特化・スケジューリング制御のもとシステム管理で実行したいならiOS 27のCore AI、モデルが本当にフロンティア級でなければならないならクラウドを選んでください。

MLXに手を伸ばすべきでないのはどんなときですか

システムモデルですでに足りているとき、ギガバイト級の重みを配布する余裕がないとき、固定モデルならCore MLの最省電力Neural Engine経路のほうが向いているとき、そしてモデルの更新・セキュリティ・ドリフトを引き受ける体制がないときです。MLXは、はっきりした理由があって意図的に一段下りる選択であり、より良い既定ではありません。