手元の Mac を「チーム共有の LLM 推論サーバー」にする、という発想は、一年前ならちょっとした冗談に聞こえたかもしれません。
でも今は、Apple Silicon の性能とオープンソースの推論エンジンが揃ってきたことで、現実的な選択肢になっています。
omlx（jundot/omlx）を使って Mac をそのままローカル LLM サーバーとして動かす方法を、セットアップから社内 API としての実運用イメージまで一気通貫で語ります。
読み終えたあとに「自分のユースケースに合うか・合わないか」を自分で判断できる、そこをゴールにします。
Mac をそのまま LLM サーバーにする、という選択肢
ローカル LLM のツールは今や乱立気味です。
Ollama はセットアップが一番楽で、llama.cpp はクロスプラットフォームで動く汎用エンジン。
どちらも Apple Silicon で動きますが、どちらも「Mac 専用」ではありません。
omlx はそこが違います。
Apple が開発した機械学習フレームワーク MLX をベースにしていて、Apple Silicon のユニファイドメモリアーキテクチャに最初から最適化されています。
ユニファイドメモリというのは、CPU と GPU が同じメモリ空間を共有する仕組みです。
従来の PC では「CPU メモリ → GPU VRAM」へのコピーが推論のたびに発生していましたが、MLX ではそのコピーがゼロです。
llama.cpp も Metal 加速に対応していますが、設計の根っこがクロスプラットフォーム前提なので、ユニファイドメモリの恩恵を構造的に活かしきれていません。
同じモデルを動かしたとき、MLX のトークン生成速度が llama.cpp の 1.5〜2 倍になるケースがある、というのはこの構造的な差から来ています。
omlx はその MLX の上に、SSD キャッシュ・連続バッチ処理・マルチモデル管理・OpenAI/Anthropic 互換 API を乗せたサーバーです。
メニューバーアプリとして常駐させておけば、チームの誰もが同じエンドポイントを叩ける小さな推論サーバーが出来上がります。
「でも Mac が 1 台しかない」という場合でも、開発中のツールのバックエンドをクラウド LLM から手元の omlx に切り替えて試す、という使い方は十分に現実的です。
モデルの応答をローカルで完結させたい場面、コスト感覚を掴みたい場面、プロトタイプをオフラインで動かしたい場面——そういうときに「Mac をそのまま使う」という選択肢が手の届くところにある、というのが omlx の面白さだと思っています。
インストールから起動まで、実際の操作感
omlx のインストールには 3 つの経路があります。
公式サイト（omlx.ai）から .dmg をダウンロードする方法、Homebrew を使う方法、ソースからビルドする方法です。
日常的に Homebrew を使っているなら、以下が一番手軽です。
brew install --cask omlx
インストールが終わったらアプリを起動すると、メニューバーにアイコンが現れます。
署名・公証済みのネイティブ macOS アプリなので、Gatekeeper に引っかかることなくそのまま動きます（Electron ではなく Swift 製です）。
前提条件として、macOS 15 以上と Apple Silicon（M1〜M4）が必要です。
Intel Mac では動きません。
メニューバーのアイコンをクリックするとサーバーの起動・停止、ポートの確認、Web ダッシュボードへのリンクが表示されます。
モデルの追加・ロード・切り替えはこのダッシュボードから行います。
Hugging Face 上の MLX 形式モデルを指定してダウンロードできるほか、ローカルのモデルファイルを直接読み込むことも可能です。
サーバーが起動したら疎通確認をしておきましょう。
デフォルトのポートは 10240 です。
curl http://localhost:10240/v1/models
ロード済みのモデル一覧が JSON で返ってくれば OK です。
続いてモデルへのリクエストを試します。
curl http://localhost:10240/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "mlx-community/Qwen2.5-7B-Instruct-4bit",
"messages": [{"role": "user", "content": "こんにちは"}]
}'
ここまで動けば、OpenAI 互換 API を叩けるクライアントなら何でも繋がります。
モデルのロード中はダッシュボードにプログレスが表示されるので、「なぜか応答が返ってこない」という状況も把握しやすいです。
「なぜ 16GB でも動くのか」——SSD キャッシュと連続バッチ処理の仕組み
ユニファイドメモリが 16GB の Mac で 35B クラスのモデルを動かす、というのは一見無理に聞こえます。
4bit 量子化でも Qwen 3 35B は 20GB 前後のメモリを要求するので、OS やアプリが使う分を考えると確かにギリギリです。
omlx がこれを可能にしているのが 二層 KV キャッシュ の仕組みです。
KV キャッシュとは、Transformer が過去のトークンを参照するときに使う計算結果のキャッシュです。
コンテキストが長くなるほどこのキャッシュは大きくなり、メモリを圧迫します。
omlx はこのキャッシュを「ホット（ユニファイドメモリ）」と「コールド（SSD）」の二層に分けて管理します。
最近使ったブロックはメモリに残し、しばらく参照されていないブロックは LRU ポリシーで SSD に退避させます。
キャッシュは safetensors 形式でディスクに永続化されるので、サーバーを再起動しても以前見たプレフィックスを再計算せずに復元できます。
この仕組みが特に効くのは、モデルの切り替えが頻繁な場面 と メモリ容量を超えるモデルを扱う場面 です。
複数のモデルを LRU で管理しながら、使われていないモデルのキャッシュを SSD に逃がすことで、物理メモリを超えたモデルセットを実用的に扱えます。
M2 MacBook Pro で Qwen 3 35B（4bit）を動かしたとき、89% のキャッシュ効率と 47 トークン/秒の生成速度を記録した、という数値が公式に示されています。
一方、レイテンシを最優先にしたい単一モデル常駐の用途 では、SSD キャッシュのメリットはほぼ出ません。
SSD へのアクセスはメモリより遅いので、キャッシュのスワップが発生するとレイテンシが跳ね上がります。
「1 つのモデルだけを常時ロードして、できるだけ速く応答を返したい」という場合は、モデルをピン留めしてメモリから追い出されないようにする設定が重要です。
連続バッチ処理（continuous batching）については、複数のリクエストが同時に来たときの話です。
従来のシンプルな実装では、先のリクエストが長い応答を生成している間、後続のリクエストはただ待つだけです。
omlx は mlx-lm の BatchGenerator を使って複数リクエストを並列処理します。
8 並列リクエストで最大 4.14 倍のスループット向上が確認されています。
これは社内 API として複数人が同時に叩く用途と相性がいいです。
ただし、1 リクエストあたりのレイテンシは並列数が増えると若干伸びます。
「速さ」より「さばける量」を優先する場面で真価を発揮する仕組みだと理解しておくといいでしょう。
Claude Code や社内ツールのバックエンドとして繋ぐ
omlx は OpenAI 互換（/v1/chat/completions）と Anthropic 互換（/v1/messages）の両方のエンドポイントを提供しています。
これが Claude Code との接続をシンプルにしてくれます。
Claude Code は環境変数 ANTHROPIC_BASE_URL を指定することで、Anthropic の本番 API の代わりに任意のエンドポイントを向けられます。
omlx が Anthropic 互換の /v1/messages を持っているので、以下の設定だけで繋がります。
export ANTHROPIC_BASE_URL=http://localhost:10240
export ANTHROPIC_API_KEY=dummy # ローカルなので認証不要だが、空だとエラーになるため適当な値を入れる
この状態で Claude Code を起動すると、Anthropic API の代わりに手元の omlx が応答を返します。
モデルの指定は Claude Code 側の設定に従いますが、omlx にロードされているモデル名と一致させる必要があります。
ひとつ正直に言っておくと、omlx にロードしているのはあくまでオープンソースの LLM であり、Claude そのものではありません。
Claude Code の複雑なエージェント動作は Claude の高い指示追従性を前提に設計されているので、7B〜14B クラスのモデルではツール呼び出しのフォーマットを守れなかったり、複数ステップの推論が途中で崩れたりすることがあります。
実用的に使うなら、32B 以上の量子化モデルを使うか、コード補完・説明生成など単発タスクに絞るのが現実的です。
OpenAI 互換エンドポイントしか持たないモデルや、既存の社内ツールが OpenAI 形式しか喋れない場合は、LiteLLM をゲートウェイとして挟む方法があります。
# litellm_config.yaml
model_list:
- model_name: local-qwen
litellm_params:
model: openai/mlx-community/Qwen2.5-14B-Instruct-4bit
api_base: http://localhost:10240/v1
api_key: dummy
litellm --config litellm_config.yaml --port 4000
これで LiteLLM が Anthropic Messages API 形式のリクエストを受け取り、omlx の OpenAI 互換エンドポイントに変換して転送します。
Claude Code からは ANTHROPIC_BASE_URL を http://localhost:4000 に向ければ OK です。
Slack Bot や簡易 RAG のバックエンドとして使う場合は、いくつか現実的な制約を把握しておく必要があります。
レイテンシは、モデルのロードが完了していない状態で最初のリクエストが来ると数十秒待たされることもあります。
同時接続については、連続バッチ処理のおかげで数人規模の同時利用は現実的にこなせますが、10 人以上が一斉に叩くような用途は厳しいです。
モデルサイズの上限感は、16GB 機なら 7B〜14B（4bit）が快適に動く現実的なラインで、32B 以上は SSD キャッシュを活用しながら動かす形になります。
運用して初めて気づく、いくつかの注意点
一番ハマりやすいのが Mac のスリープ問題 です。
Mac がスリープするとサーバープロセスが止まり、クライアントからのリクエストがタイムアウトします。
開発中の自分だけが使う分には気になりませんが、チームで共有するサーバーとして使う場合はスリープを防ぐ必要があります。
macOS のシステム設定でディスプレイオフとスリープを分離して、本体スリープを無効にするのが基本です。
ターミナルから制御したい場合は caffeinate コマンドが使えます。
caffeinate -i -s & # -i: アイドルスリープ防止、-s: システムスリープ防止
バックグラウンドで動かしておけば、omlx が起動している間はスリープしません。
LaunchAgent として登録して自動起動させるのも有効です。
運用上で押さえておきたいチェックポイントをまとめておきます。
- スリープ対策: システム設定でスリープを無効化するか、caffeinate を常駐させる。Mac を専用サーバー機として使う場合は「電源アダプタ接続時はスリープしない」設定が確実。
- ポート管理: デフォルトは 10240 番。他のサービスと競合しないか確認し、ファイアウォール設定と合わせて管理する。
- ネットワーク境界: omlx はデフォルトで localhost にバインドされます。チームに公開するには 0.0.0.0 バインドに変更しますが、同じネットワーク上の全員からアクセスできる状態になるので、IP 制限や VPN 経由のアクセスに絞るのが無難です。
- モデルのピン留め: 頻繁に使うモデルは LRU で追い出されないようにピン留め設定を使う。スワップが発生すると最初のリクエストのレイテンシが大きく跳ね上がります。
omlx が向いているのは、複数のモデルを切り替えながら試したい・メモリを超えるサイズのモデルを SSD キャッシュを使って動かしたい・チームの数人が同時に叩く社内 API が欲しい、という場面です。
逆に、1 つのモデルを常時ロードして 1 トークン目までのレイテンシを極限まで削りたい、という用途なら、Ollama や llama.cpp のほうがシンプルで扱いやすいかもしれません。
「Mac を持て余している」「クラウド API のコストを手元で検証したい」「チームのプロトタイプに自前エンドポイントを立てたい」——そういう動機があるなら、omlx は試す価値がある選択肢です。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援・DX 推進に取り組んでいます。
ローカル LLM の導入検討から社内ツールへの組み込みまで、実務に即した形でサポートしています。
興味があればお気軽にご相談ください。
お問い合わせはこちら