MLXを利用したMac上でのローカルのエージェントAIの実行

こんにちは Angelosです MLXチームのエンジニアです。

今日はエージェンティックAIワークフローを Mac上でMLXを使って 構築・実行する方法を紹介します。 クラウドもAPIキーも不要で ハードウェアが処理します。 この1年でAIエージェントは 研究プロトタイプから 日常の生産性ツールへと進化しました。 エージェントの話の前に 以前の状況を振り返りましょう。

おなじみのチャット体験です。 言語モデルにプロンプトを送ります。 モデルが返答を返します。 その返答に基づいて行動が必要なら コマンドを実行したり、 ファイルを確認したり エラーを修正するのはあなた自身です。 今はエージェントと対話しています。 エージェントはモデルと連携して 次の行動を決定します。 そして実際にツールを呼び出して タスクを実行します。 コマンドの実行 ファイルの読み取り、APIの呼び出し 結果を観察し次のステップを 決めるためにモデルに戻ります。 ユーザーからエージェントへ。 エージェントからモデルへ。 エージェントからツールへ。 これがエージェンティックループです。 タスクが完了するまで このサイクルが繰り返されます。 Appleシリコンで特に 魅力的なのは このループ全体が ローカルで実行できる点です。

データはデバイス上に留まり AIはいつでもどこでも利用可能で 使用コストもかかりません。 実際にどのような動きをするか お見せしましょう。

Mac上でローカル実行している エージェントをご覧ください。 画面にはセットアップが表示されています 左側にモデルを実行するMLX、 右側には操作中の OpenCodeエージェントがあります。

MLXリポジトリの最近の プルリクエストを取得するよう 変更点を要約して注意点を 特定するよう指示しました。 モデルはリクエストを分析して GitHub CLIでPRデータを取得し、 差分を確認して 簡潔な要約を作成します。 これはすべてローカルで実行されており、 モデルはハードウェア上で動き gitコマンドだけがネットワークに接続します。 このビデオを終えた後 やることがたくさんありそうです。 可能性をご確認いただいたところで、 今日どのように進めるかを 説明します。 まずローカルエージェンティックAIスタックを 紹介します。 これをすべて動作させる 4つのレイヤーです。 基盤となるMLXから エージェントまでの全レイヤーです。 次に独自のローカルエージェントを 段階的に設定する方法を説明します。 その後MLXがハードウェアを 最大限に活用する方法を ご覧いただきます。

最後にさらにライブデモを 行います。 SwiftUIアプリをゼロから構築して Xcodeでバグを修正するデモです。 スタックから始めましょう。

MacでのローカルエージェンティックAIを 支えるスタックには4つのレイヤーがあります。 各レイヤーを下から順に 説明していきます。 最下層にはMLXがあります。 Appleシリコン向けに設計された オープンソースのアレイフレームワークです。 低レベルの計算処理、Metalアクセレレーション メモリ管理を担います。 これがすべての基盤です。 その一つ上には 言語モデルレイヤーがあります。 MLX-LMはロード・実行・量子化・ 大規模言語モデルの ファインチューニングを提供します。 HuggingFaceの何千もの モデルをサポートしており、 CLIツールとPython APIの 両方を提供します。 昨年のセッションをご覧の方は これを詳しくご説明しました。 しかしエージェントに対応するには さらに必要なものがあります。 標準APIを持つ 永続的なサーバーです。 そこでMLX-LM Serverの 出番です。 これはOpenAI互換のHTTPサーバーで、 標準APIを通じてローカルモデルを 公開します。 構造化ツール呼び出しをサポートし モデルが確実に関数を呼び出せます。 また複雑な問題を分析できる リーズニングモデルも 応答前にステップごとに処理できます。 クラウドLLM APIの ドロップイン置き換えとして使えます。 スタックの最上位に エージェント本体があります。 これは任意のフレームワークや OpenAIのchat completion プロトコルに対応したツールです。 Xcode、OpenCode、Pi agent、 カスタムスクリプトなど何でも使えます。 MLX-LM Serverが 標準インターフェースを提供するため、 どのエージェントフレームワークも すぐに動作します。 このスタックを使っているのは 私たちだけではありません。 多くの人気アプリやツールが MLXとMLX-LMで構築されています。 Ollama、LM Studio、vLLMは 最も人気のあるものの一部です。 エコシステムは広く成長しており、 これらのツールを使っているなら すでにMLX上で動いている可能性があります。

以上がスタックです。 自分でセットアップする方法を ご説明します。

ゼロから完全なローカルエージェンティック ワークフローへの移行は3ステップです。 ステップ1: MLX-LMをインストールします。 pip installひとつで 必要なものがすべて揃います。 ステップ2: サーバーを起動します。 ツール呼び出し対応のモデルで mlx_lm.serverを実行します。 小さなモデルから始めて セットアップをテストするのが良いでしょう。 サーバーが起動してモデルをロードし、 ローカルホストで リクエストを受け付ける準備ができます。 ステップ3: エージェントを ローカルサーバーに向けます。 ほとんどのエージェントフレームワークでは、 base URLをローカルサーバーの アドレスに設定するだけで 完了です。 エージェントは知ることも 気にすることもありません。 モデルがクラウドではなく Macで動いていることを。

具体的な例をご覧ください。 これはOpenCodeの設定です。 ローカルプロバイダーを定義します。 特にURLをローカルホストに 設定して サーバーが期待するモデル名を 設定します。 このローカルモデルをすべてに使うよう OpenCodeに指示します。 以上です。 これですべての操作が ローカルモデル経由で動きます。

エージェントがMLXと通信できたので、 MLXがハードウェアを 最大限に活用する方法と ローカルでエージェントを実行する際の 主要な課題への対応を見ましょう。

最初の課題はプロンプト処理です。 エージェンティックワークフローでは モデルがツール出力を受け取るたびに、 新しいコンテキストをすべて処理してから 次のステップについて推論します。

これはエージェンティックループ全体で 繰り返されすぐに積み重なります。 エージェンティックセッションは通常 数十万トークンで構成されており、 そのほとんどは生成されたものではありません。

M5チップには専用の Neural Acceleratorが搭載されており、 MLXはこの種の処理に それを活用できます。 具体的にはNeural Acceleratorが 行列乗算を M4比でM5において 4倍高速化します。 MLXの特化した乗算と アテンションカーネルにより、 これがプロンプト処理の 高速化にほぼそのまま反映されます。

プロンプト処理時間の短縮により エージェントはコードベースを読み込んだり ツール結果を処理したりするのが ほぼ4倍速くなります。 一番うれしいのは、 Neural Acceleratorを活用するのに 特別な引数は不要で コードの変更も必要ないことです。 MLXが利用可能なハードウェアに 最適なカーネルを自動選択してくれます。

次に2番目の課題 並行処理についてです。 実際にはエージェントが単独で 動くことはほとんどありません。 よくあるパターンは エージェントが複数のサブエージェントを生成し、 それぞれが問題の異なる部分を 並行して処理します。 1つはドキュメントを読み 別の1つはコードを検索し、 3つ目はテストを書く といった具合に同時進行します。 複数のリクエストが ローカルモデルに同時に届きます。 MLX-LM Serverはこれを 継続的バッチ処理で対応します。

リクエストを1件ずつ 処理する代わりに、 受信したリクエストを 動的にバッチにグループ化して GPU上でまとめて処理します。 新しいリクエストは 処理中のバッチに加わることができ、 現在の処理が終わるのを 待つ必要がありません。 その結果、サブエージェントは キューで待機して止まることがありません。 すべてが並行してサービスを受けられ、 エージェンティックワークフロー全体が スムーズに進みます。 最後に3番目の課題は モデルサイズです。 場合によっては512GBのRAMを 搭載した1台のマシンでも モデルがメモリに収まらないほど 大きすぎることがあります。 例えば最新のDeepSeekモデルは 1兆6,000億ものパラメータを持ち、 重みだけで800GB以上の メモリが必要です。 MLXの分散サポートにより ThunderboltやEthernet経由で 接続した複数のMacに モデルを分散できます。 エージェントにとってこれは 2つの点で有効です。 1つ目は、1台のマシンでは 動かせないほど大きく 高性能なモデルを実行できること。 2つ目は、デバイスをまたいで プロンプト処理を並列化できること。 これによりエージェンティックループが 直接高速化されます。 モデルがツール結果を より速く処理できるためです。

MLX-LM Serverでの 分散推論のセットアップは 比較的シンプルです。 mlx.launchを使ってサーバーを起動し、 ノードと接続の種類の情報を含む ホストファイルを指定します。 モデルは利用可能な全デバイスに 自動的にシャードされ、 あとはすべて自動的に動作します。 macOS 26.2からThunderbolt RDMA のサポートが追加されました。 Thunderbolt経由で低遅延・ 高帯域幅通信を実現します。 その結果、MLXを使った分散推論は 大幅な高速化を実現しました。 4ノードで最大3倍の速度向上です。 MLXを使った分散推論のために Macをセットアップする方法については、 セッション「Explore distributed inference and training with MLX」をご確認ください。 先ほどのPR要約デモを 覚えていますか？ あれはシンプルな 読み取り・報告タスクでした。

もう一歩進んで 何が起きるか見てみましょう エージェントにプロジェクト全体を ゼロから書くよう依頼したり 既存のバグを修正するよう お願いします。

このデモでは エージェントに依頼します 小さなSwiftUIアプリケーションを ゼロから構築するよう。

空のXcodeプロジェクトから 始めて iPadの描画アプリを構築するよう エージェントに依頼しています。

さっそく始まります。 エージェントはまず 現在のディレクトリを確認して 既存のプロジェクト構造を 把握します。 実装を導くための 計画を立て、 コードの作成に 取り掛かります。 エージェントを使えば何もコピーせず プロジェクトをビルドする必要もありません。 エージェントはファイルを書いてから アプリをビルドし、 途中で発生するエラーを 修正していきます。

さあ完成です モデルが終了しました アプリの最初のバージョンを作成するのに 数分しかかかりませんでした。 同時にXcodeでプロジェクトを 開いていました シミュレータでアプリを 起動しています。

エージェントが作成したものを 確認してみましょう。

完全に機能する描画アプリが 出来上がっています。 2分で構築されたにしては 素晴らしい仕上がりです。 エージェンティックコーディングでは 反復を続けられます 満足のいく結果になるまで。 例えば私は丸みを帯びたend capが好みです。 見た目がずっと良いと思います。 エージェントに追加するよう依頼しましょう。

エージェントはコードを編集して アプリを再コンパイルします エラーなくコンパイルできるまで。

新しいバージョンをテストしましょう。

丸みを帯びたend capができました。 これは素晴らしいですね。 これがすべてローカルで 行われたことがさらに印象的です。 このMac上のMLX-LM serverを通じて モデルが実行されました エージェントは標準的な 開発ツールを使用しました xcodebuildなどを使って 作業を確認・ビルドしました。

最後のデモです。 開発環境に直接統合された ものをご覧いただきましょう。

同じ描画アプリのプロジェクトを Xcodeで開いています。 Xcodeを起動中のMLX serverに 接続しましょう。 設定を開いて Intelligenceタブに移動します。 をクリックして プロバイダーを選択します。 PortをMLX serverの起動時に 指定した8080などのポートに設定し、 完了です。 これでXcodeがローカルモデルと 通信できます。

以前動作していたアプリに バグを仕込みました モデルに修正を依頼できます。

数秒以内にバグを特定して 周辺のコードを調べます。 最後に修正を書いて アプリをビルドして実行できます。

これはローカルで実行されている エージェントが Xcodeの既存の開発ワークフローに 統合できることを示しています プロジェクトファイルを読み込み ビルドエラーを理解して、 的を絞った修正を行います。 ローカルAIなら、コードが Macから出ることはありません。

今日はMac上でローカルに エージェンティックAIを動かすための MLXからエージェントまでの フルスタックをご紹介しました そしてNeural Accelerator、 継続的バッチ処理、 分散推論が高速化を実現する 方法も紹介しました。 始めるには、MLX-LMをインストールし サーバーを起動して お気に入りのエージェントを向けましょう。 今日ご紹介したすべてのものは オープンソースで今すぐ利用可能です。 ご視聴ありがとうございます MacのローカルエージェンティックAIで皆さんが 何を作るかを楽しみにしています。