oMLXとは？Apple Silicon向けローカルLLM推論サーバを解説
oMLXはApple Silicon Mac専用のオープンソースLLM推論サーバ。階層KVキャッシュ（RAM＋SSD）と連続バッチングで複数リクエストを効率処理し、メニューバー常駐のmacOSアプリから管理できる。2026年8月時点でGitHub Trending週間上位・スター約2万。機能・要件・使い方・Ollama等との違いを解説。
oMLX（GitHub: jundot/omlx）は、Apple Silicon Mac専用に設計されたオープンソース（Apache 2.0）のLLM推論サーバです。一言で言えば「連続バッチングとSSDキャッシュを備え、macOSのメニューバーから丸ごと管理できる推論サーバ」で、Mac miniやMacBook ProでローカルLLM・VLM・埋め込み・リランカーをまとめて動かしたい開発者や小規模チーム向けのツールです。mlx-lmをベースに、複数リクエストの同時処理と、GPUメモリが埋まった際にKVキャッシュをディスクへ退避して再利用する仕組みを組み合わせている点が新しく、2026年8月時点でGitHub Trendingの週間上位（スター約2万、週間+1,600前後）に入っています。
oMLXでできること
- 階層KVキャッシュ: ホット層（RAM）が埋まると自動でコールド層（SSD）へ退避し、次回同じprefixのリクエストで再計算せず復元
- 連続バッチング: mlx-lmのBatchGeneratorを利用し、複数リクエストを効率的に同時処理。prefillとcompletionのバッチサイズを個別に設定可能
- マルチモデル同時ロード: LLM・VLM・埋め込み・リランカーを同一サーバ上に同居させ、LRUによる自動退避と手動制御の両方に対応
- VLM/OCR対応: 複数画像を入力できるVLM・OCRモデルをサポート
- 管理ダッシュボード（Web UI）: サーバの監視、モデル管理、チャット、ワンクリックのベンチマーク（prefill/PPとtext generation/TGのtokens/sec計測）
- ネイティブmacOSアプリ: SwiftUI製のメニューバー常駐アプリで自動アップデートと統計の永続化に対応し、ターミナルを開かずにモデルのダウンロードやサービス管理ができる
- OpenAI互換API: /v1/chat/completions、/v1/completions、Anthropic互換の/v1/messages、/v1/embeddings、/v1/rerank、/v1/models
- ツール呼び出し（function calling）: JSON schemaによるバリデーション付き
動作要件と対応モデル
| 項目 | 内容 |
|---|---|
| OS | macOS 15.0（Sequoia）以降 |
| ハードウェア | Apple Silicon（M1/M2/M3/M4/M5）搭載Mac |
| Python | 3.11〜3.13 |
| LLM | mlx-lmがサポートするモデル全般 |
| VLM | Qwen3.5、GLM-4V、Pixtralなどmlx-vlm系 |
| OCR | DeepSeek-OCR、DOTS-OCR、GLM-OCR |
| 埋め込み | BERT、BGE-M3、ModernBERT |
| リランカー | ModernBERT、XLM-RoBERTa |
どのモデルがどれくらいのメモリで動くかを事前に把握したい場合は、VRAM計算ツールでモデルサイズと量子化から必要メモリの目安を確認できます。個別モデルの必要スペックはQwen3.8 27Bの必要スペック解説やOrnith-1.5の必要スペック解説も参考にしてください。
インストール
# 方法1: .dmgをダウンロード
# https://github.com/jundot/omlx/releases から最新の.dmgを取得してインストール
# 方法2: Homebrew
brew tap jundot/omlx https://github.com/jundot/omlx
brew install jundot/omlx/omlx
# 方法3: ソースからインストール
git clone https://github.com/jundot/omlx.git
cd omlx
pip install -e .使い方 — 最短手順
Homebrewやdmgでインストールした場合は、メニューバーアプリからサーバを起動し、ダッシュボードUIでモデルをダウンロードするだけで準備が整います。ターミナルを使う場合も流れは同じで、サーバ起動→モデルのダウンロード→OpenAI互換APIへのリクエスト、という3ステップです。起動後はダッシュボード（Web UI）でモデルの状態確認やベンチマーク実行も行えます。
# OpenAI互換エンドポイントにリクエスト
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "<ダウンロード済みモデル名>",
"messages": [
{"role": "user", "content": "こんにちは"}
]
}'
# ロード済みモデルの一覧を確認
curl http://localhost:8000/v1/models階層KVキャッシュと連続バッチングの仕組み
LLM推論では、直前までの入力・生成トークンに対応するKey/Valueテンソル（KVキャッシュ）をメモリ上に保持しておくことで、同じprefixを持つ後続リクエストの計算を省略できます。ただしKVキャッシュはメモリを大きく消費するため、リクエスト数やコンテキスト長が増えるとRAMが不足し、通常は古いキャッシュを破棄してprefillからやり直すことになります。oMLXの階層KVキャッシュは、この破棄の代わりにキャッシュブロックをSSDへ退避する「コールド層」を用意します。ホット層（RAM）が埋まると使用頻度の低いブロックからSSDへ移し、同じprefixのリクエストが再び来た際にはSSDから復元することで、計算をゼロからやり直すコストを避けます。これにより、同じシステムプロンプトや長い共通コンテキストを使い回すマルチユーザー環境・マルチセッション環境で、メモリの物理容量を超えたキャッシュ運用がしやすくなります。
連続バッチング（continuous batching）は、複数の推論リクエストを1つのバッチとしてまとめて処理しつつ、生成が終わったリクエストから順次バッチを抜けさせ、新しいリクエストを随時追加できる方式です。リクエストごとに逐次処理する場合と比べてGPU（Apple SiliconではGPU/ANE）の稼働率を高めやすく、同時アクセスが発生する環境でのスループット改善に寄与します。oMLXはmlx-lmのBatchGeneratorを利用してこれを実装しており、prefill（入力トークンの処理）とcompletion（生成トークンの処理）でバッチサイズを別々に設定できるため、リクエストの特性（長い入力が多いか、長い生成が多いか）に応じたチューニングが可能です。なお、公式READMEには具体的なスループットの数値は記載されておらず、ダッシュボードのベンチマーク機能（PP/TGのtokens/sec計測）を使って自分の環境で確認する形になります。
既存ツールとの違い（Ollama・LM Studio・mlx-lm・llama.cppとの比較）
ローカルLLM実行ツールにはすでにOllama、LM Studio、mlx-lm（素の状態）、llama.cppなど複数の選択肢があります。それぞれの立ち位置を整理した上で、oMLXがどこで差別化しているかを見てみます。ツール全体の比較はローカルLLM推論エンジンの比較記事でも扱っているので、選定の際はあわせて参照してください。以下は各ツールの一般的な特徴を整理したもので、細かい挙動はバージョンや設定によって変わり得る点に留意してください。
| 観点 | oMLX | Ollama | LM Studio | mlx-lm（素） | llama.cpp |
|---|---|---|---|---|---|
| 対応プラットフォーム | Apple Siliconのみ | macOS/Linux/Windows | macOS/Linux/Windows | Apple Siliconのみ | macOS/Linux/Windows（CPU/各種GPU） |
| バックエンド | MLX | llama.cppベースが中心 | llama.cpp/MLXなど選択可 | MLX | 独自実装（GGUF） |
| 連続バッチング | 対応（prefill/completionを個別設定） | 限定的・バージョン依存 | 基本的に非対応が中心 | 標準機能としては非搭載 | サーバモード（llama-server）で対応 |
| KVキャッシュのSSD退避 | 階層KVキャッシュとして標準搭載 | 一般的には非搭載 | 一般的には非搭載 | 非搭載 | 非搭載（プロンプトキャッシュのファイル保存は可） |
| 埋め込み/リランカーの同居 | 同一サーバでLLM・VLM・埋め込み・リランカーを同時ロード | モデルごとに個別運用が中心 | モデルごとに個別運用が中心 | 用途特化（推論のみ） | 用途特化（推論のみ） |
| GUI | ネイティブmacOSアプリ＋Webダッシュボード | CLI中心（別途GUIあり） | ネイティブGUIアプリ | CLIのみ | CLI中心（Webサーバのシンプル画面） |
| API互換性 | OpenAI互換＋Anthropic互換（/v1/messages） | OpenAI互換API | OpenAI互換API | 独自CLI/簡易サーバ | OpenAI互換サーバモードあり |
| ライセンス | Apache 2.0 | MIT | 独自ライセンス（無料利用可） | Apache 2.0系（MLX） | MIT |
向いているケース・向いていないケース
- 向いている: Apple Silicon MacやMac miniをローカル推論サーバとして常時稼働させたい
- 向いている: 複数人・複数セッションから同時にアクセスがあり、連続バッチングやKVキャッシュの使い回しでスループットを底上げしたい
- 向いている: LLMに加えて埋め込みやリランカーも同居させ、1台のMacでRAG的な構成をまとめて運用したい
- 向いている: ターミナル操作に不慣れなメンバーがいて、GUI（メニューバーアプリ・ダッシュボード）でモデル管理をしたい
- 向いていない: Linux/WindowsサーバやクラウドGPUで運用したい（Apple Silicon専用のため対象外）
- 向いていない: 大規模なマルチGPUクラスタでの分散推論が必要（oMLXは単一Mac向けの設計）
- 向いていない: とにかく手早く1モデルだけをローカルで試したいだけで、キャッシュ階層化や連続バッチングの恩恵が薄いライトな用途
よくある質問
oMLXはIntel MacやWindowsでも使えますか？
使えません。oMLXはApple Silicon（M1〜M5）搭載Macかつ macOS 15.0（Sequoia）以降を前提に設計されており、Intel MacやLinux、Windowsはサポート対象外です。
OllamaやLM Studioと比べて速いですか？
公式READMEには具体的なスループット数値の記載がなく、単純な速度比較はできません。oMLXはダッシュボードのベンチマーク機能でprefill（PP）とtext generation（TG）のtokens/secを自分の環境で計測できるので、実際の用途に近い条件で比較することをおすすめします。
既存のGGUFモデルはそのまま使えますか？
oMLXはMLXフォーマットのモデルを前提としており、mlx-lmがサポートするモデル、およびmlx-vlm系のVLM、対応するOCR・埋め込み・リランカーモデルを利用します。GGUF専用モデルをそのまま読み込む用途にはllama.cpp系のツールの方が適しています。
商用利用は可能ですか？
oMLX自体はApache 2.0ライセンスで公開されており、ライセンス条件の範囲内で商用利用も可能です。ただし利用するモデル側のライセンス条件は個別に確認してください。
階層KVキャッシュを使うとSSDの寿命に影響しますか？
KVキャッシュのSSD退避は書き込み・読み込みを伴うため、頻繁に大量のキャッシュ入れ替えが発生する環境ではSSDへの書き込み量が増える点は考慮が必要です。公式に定量的な影響値は公開されていないため、長期運用する場合は自分の利用パターンで書き込み量を確認することをおすすめします。
まとめ
oMLXは、Apple Silicon Mac専用という制約と引き換えに、階層KVキャッシュによるSSD退避と連続バッチング、マルチモデル同時ロード、メニューバー常駐アプリによる管理という組み合わせを1つのオープンソースツールにまとめたLLM推論サーバです。Ollama・LM Studio・mlx-lm・llama.cppといった既存の選択肢がそれぞれ得意とする領域を持つ中で、oMLXは「1台のMacで複数モデル・複数リクエストを効率よくさばきたい」というニーズに寄せた設計になっています。導入を検討する際は、まず要件と対応モデルを確認し、ダッシュボードのベンチマーク機能で自分の用途における実際のスループットを計測した上で採用を判断するとよいでしょう。
この記事に関連する無料ツール（登録不要・その場で結果）
お気軽にご相談ください
お問い合わせ