【oMLX】MacでローカルLLMのサーバーを動かし、OpenCodeなどから使う方法

Mac（Apple Silicon）で動作するLLMの推論サーバーはいくつかありますが、今回はoMLXを試してみました。oMLXでは、サーバーの状態をメニューバーとアプリやWeb管理画面で確認できたりと、サーバーとしての機能が充実しています。今回は、oMLXをインストールしてOpenCodeで利用するところまでやってみましたので紹介します。

はじめに

Mac でローカルLLMを動かす手段は、ここ数年でかなり増えました。私も、LM Studio、mlx-lm や Unslothといくつか試してきましたが、それぞれ利点と欠点があり「これは」というものはなくどれも一長一短です。

今回は、oMLXを試してみました。oMLXは起動するとメニューバーに常駐し、GUIで状況を確認できるなど「サーバー向け」としてはかなり使いやすいです。

この記事では、実際にインストールし、opencode からローカルモデルを使えるところまでの設定手順と使ってみた感想をまとめます。

oMLXとは

oMLX は、Apple の機械学習フレームワーク MLX をベースにした、Apple Silicon 向けのローカルLLM推論サーバーです（Apache 2.0 のオープンソース）。

主な特徴は以下の通りです。

動作要件は macOS 15.0 以降、Apple Silicon（M1〜M5）、Python 3.11〜3.13 です。

OpenCodeなどでローカルLLMを使うメリットは、「データが外にでない」ことです。たまに、「外に出せないデータ」で処理することがあるので、その場合だけローカルLLMを使っています。

ぶっちゃけ、クラウド側のLLM（OpenCode Goなど）を使った方が快適なのですが、出せない場合は性能や速度が多少劣化してもローカルを使うしかありません。

最近のローカルLLMは、性能は劣るといってもソースコードの解析や資料整理には十分な性能です。気になるのは速度ですね。

インストール

インストール方法は大きく3つありますが、モデルの管理などもやりやすいので、macOS アプリ版をおすすめします。

私の環境（M4 Max 128GB）では macOS アプリ版を使っています（0.7.0）。アプリ版は ~/.omlx/bin/omlx に CLI の shim も入るため、メニューバーからの操作と omlx コマンドの両方を使えます。

アプリ版はネイティブカーネルが同梱され、アプリ内の自動アップデートにも対応しています。Xcode の準備やカーネルのビルドをせずに済むので、まずはアプリ版で試すのが手軽だと思います。

ネイティブカスタムカーネルが入っていないと、対応モデルで気づかないうちに遅い汎用パスへフォールバックすることがあります。速度が出ないと感じたら、まずここを確認するとよさそうです。

サーバーの起動とモデルの準備

サーバーの起動は、アプリを起動してメニューバーから行う方法をおすすめします。 ターミナルを開かずに起動・停止ができ、状態もそのままメニューバーで確認できます。

アプリを起動するとメニューバーにアイコンが常駐し、そこからサーバーを操作できます。ターミナルを開かずに始められるのが楽でした。

コマンドラインから起動する場合

コマンドラインから起動したい場合は、次のコマンドでも同じサーバーを立てられます。

omlx serve はフォアグラウンドで起動します。バックグラウンドのサービスとして常駐させたい場合は omlx start を使います（停止は omlx stop、再起動は omlx restart）。既定のモデルディレクトリは ~/.omlx/models、待受は 127.0.0.1:8000 です（omlx serve --help より）。

サーバーは http://localhost:8000/v1 で待ち受けます。付属の管理画面は http://localhost:8000/admin、内蔵チャットは http://localhost:8000/admin/chat です。

モデルはサブディレクトリとして配置します。

対応しているツール（Claude Code・Codexなど）

oMLX には、起動中のサーバーに接続した状態で外部のコーディングツールを立ち上げる omlx launch コマンドがあります。omlx launch --help で確認したところ、対応しているツールは次のとおりでした（oMLX 0.7.0）。

どのツールが自分の環境に入っているかは、omlx launch list で確認できます。

私の環境での出力は次のとおりで、OpenCode だけがインストール済みとして表示されました。

Available integrations:
  claude       Claude Code (not installed)
  codex        Codex (not installed)
  codex_app    Codex App (not installed)
  opencode     OpenCode (installed)
  openclaw     OpenClaw (not installed)
  hermes       Hermes Agent (not installed)
  pi           Pi (not installed)
  copilot      Copilot CLI (not installed)
  dsh          DeepSeek Harness (not installed)

起動は omlx launch <ツール名> です。--model を省略すると、モデルを対話的に選択できます。

omlx launch --help で確認できた主なオプションは次のとおりです。

対応ツールは増えていく可能性があるので、最新の一覧は omlx launch list で確認するのが確実です。管理画面の「統合（Integrations）」からも同じように各ツールを設定できます。

モデル名を指定せずにlanchするとインストールされているモデル一覧が表示されますのでそこで設定することもできます。

opencodeから接続する

OpenCode に接続する方法は2つあります。omlx launch opencode で起動する方法と、opencode.json にプロバイダを自分で追加する方法です。私は後者を使っています。

公式のワンクリック統合は使わず、手動で設定する

oMLX の管理画面には、OpenCode をはじめとするエージェントツールをワンクリックで設定する統合機能があります（公式 README に記載）。ただし私は、この機能で opencode.json が書き換わってしまう問題に遭遇しました。

設定ファイルは自分で管理したいので、統合機能は使わず、プロバイダのエントリを手動で追加する方法をおすすめします。私が追加した設定の例です。

{
    "$schema": "https://opencode.ai/config.json",
    "provider": {
        "omlx": {
            "name": "oMLX (local)",
            "npm": "@ai-sdk/openai-compatible",
            "options": {
                "baseURL": "http://127.0.0.1:8000/v1",
                "apiKey": "oMLXで設定したAPIキー（未設定なら空文字）"
            },
            "models": {
                "mlx-community/Qwen3.6-35B-A3B-4bit": {
                    "name": "Qwen3.6 35B A3B",
                    "limit": {
                        "context": 200000,
                        "output": 200000
                    }
                }
            }
        }
    }
}

models に書く名前は、その環境で実際に配信されているモデル名と一致させてください。確認するには次のコマンドが使えます。

ここでのモデル名はあくまで一例です。/v1/models の出力に合わせて書き換えてください。API キーは omlx serve --api-key で設定できますが、localhost 専用なら検証をスキップする設定もあります。

注意点：opencode.json が書き換わる

公式に書かれているコマンドラインでの起動を行うとOpenCodeの設定ファイルが書き換わっていました。気になる場合は、手動追加をするべきです。

サーバーの状態をGUIで確認する

oMLX の分かりやすいところは、サーバーの状態を GUI で確認できる点です。私が実際に便利だと感じたのは次の2つです。

• メニューバーアプリ
  サーバーの起動・停止・監視をメニューバーから行えます。配信統計が再起動後も残り、クラッシュ時には自動再起動してくれます。ターミナルを開かずに状態が分かるのが楽です
• Web 管理画面
  リアルタイムの監視、モデルのロード状態、モデル別の設定、ベンチマーク、モデルのダウンロードを1か所で扱えます。どのモデルがメモリに載っているか（ピン留め・アンロード）を見られるので、重い処理の前後で確認しやすいです

内蔵チャットで動作確認する

管理画面には簡易的なチャット（/admin/chat）が備わっています。モデルの読み込みが済んでいるかを確かめたり、opencode に渡す前に応答を確認したりするのに使えます。会話履歴やモデルの切り替えができ、VLM/OCR モデルでは画像アップロードにも対応しています（公式 README の記述ベース）。

サーバーを立てた直後に「そもそもこのモデルはちゃんと応答するのか」を確かめられるのは地味に助かります。

KVキャッシュの挙動（ホット／コールド）

oMLX の特徴である階層型 KV キャッシュは、私の環境では期待どおり動作している印象です。仕組みは公式 README で次のように説明されています。

• ホットキャッシュ（RAM）
  よく使う KV ブロックをメモリに保持し、高速に再利用します
• コールドキャッシュ（SSD）
  ホットがあふれると、ブロックを safetensors 形式で SSD に退避します。次のリクエストで一致するプレフィックスがあれば、最初から計算し直さずディスクから復元します。これはサーバー再起動後も維持されます
• プレフィックス共有と Copy-on-Write
  共通するプレフィックスを共有しつつ、書き換え時はコピーして安全に扱います

これが効くのは、エージェントツールのようにコンテキストが長く、毎回同じ前置きを送りがちな使い方です。実際、私の使い方では KV キャッシュがうまく働いており、コンテキストを広げても以前のように極端に重くなる場面は減ったと感じています。ただしこれは体感であり、条件を揃えた計測をしたわけではありません。

LM Studioをサーバーとして使っていた時は、エージェントツール（OpenCode）でKVキャッシュがうまく働かず読み直しが発生することがありましたが、oMLX ではそのあたりがうまく動作するように見えます。

モデル選定の目安

私の環境（M4 Max 128GB）で使ってみた範囲の目安です。あくまで私の使い方での印象で、絶対的な基準ではありません。

• Qwen3.6 35B-A3B
  エージェントで対話しながら使う用途で、速度と品質のバランスがよく、個人的に一番おすすめです。プレフィル（数百tok/s）も生成（100tok/s前後）も高速です。
• Qwen3.8 27B
  動きますが、エージェントで対話ベースに使うと少し遅く感じます。じっくり考えさせる用途なら許容範囲です。対話でなく、AIにやらせて放置ならいいかと思います。

モデルはメモリに載るかどうかが前提になります。128GB あれば大きめのモデルも試せますが、コンテキスト長や同時リクエスト数によっては消費が増えるため、管理画面で状態を見ながら調整すると安心です。

他の推論エンジンとの比較（体感）

同じ Mac で使える推論エンジンと比べた、私の印象です。条件を揃えた厳密なベンチマークではなく、日々の使用感である点に注意してください。

• Splash Engine との比較
  速度では Splash Engine のほうが速いと感じます。一方で、私の使い方では oMLX のほうが安定している気がします。長時間の対話やエージェント用途では、速度より安定性が効いてくる場面が多いです
• mlx-lm との比較
  mlx-lm はコマンドラインで手軽に使える一方、モデル管理や監視は自分で面倒を見る必要があります。oMLX はサーバーとしての運用機能（GUI・マルチモデル・キャッシュ）が揃っている分、常用しやすいです
• LM Studio との比較
  LM Studio は GUI の完成度が高く手軽です。oMLX は KV キャッシュや OpenAI/Anthropic 互換の配信など、サーバーとしての性格が強い印象です

速度は用途とモデルに大きく左右されます。

実際に自分が使うモデル・プロンプト長で試してから判断するのが確実だと思います。

サブエージェントをあまり使わず、入出力が多い場合は、私も高速なSplash Engineを使うこともあります。

まとめ

結局のところ、oMLX は「Mac のローカルLLMを、エージェント用途で常用するためのサーバー」だと感じました。インストールはアプリを入れるだけ、サーバーの起動もメニューバーから、OpenCode との接続はプロバイダを1つ追加するだけで、特別に難しい設定はありません。ただし公式のワンクリック統合は opencode.json を書き換えてしまうので、私は自分で設定を書く方法を選んでいます。

接続先として使えるツールが OpenCode だけではないのも心強いところです。omlx launch には Claude Code、Codex、Copilot CLI、OpenClaw などが用意されていて、同じサーバーを複数のツールから使い回せます。どのツールが使えるかは omlx launch list で確認できます。

使ってみて効いていると感じたのは、GUI での運用のしやすさと KV キャッシュの階層化です。特に、以前はコンテキストを広げると重くなりがちだったところが緩和され、長時間の対話でも扱いやすくなりました。速度だけを見れば Splash Engine のほうが速い印象ですが、安定性を取るなら oMLX、というのが今の私の使い分けです。

まずは Qwen3.6 35B-A3B あたりで一度動かし、管理画面で状態を見ながら MTP やコンテキスト長を調整していくのが、無理のない導入のしかただと思います。

あわせて読みたい

【実行高速化！】MacのOpenCode環境でmlx-lmを動かす方法

あわせて読みたい

【ローカルLLM】Unsloth Desktopのインストールからopencode連携まで

ある/Aru

IT＆機械学習エンジニア/ファイナンシャルプランナー（CFP®)

XContact

専門分野は並列処理・画像処理・機械学習・ディープラーニング。プログラミング言語はC, C++, Go, Pythonを中心として色々利用。現在は、Kaggle, 競プロなどをしながら悠々自適に活動中 保有資格：CFP, マンション管理士、管理業務主任、宅建士など