mlx-serve レビュー: Zig で書かれた Apple Silicon 向けローカル推論サーバーを採用前に読む

mlx-serve が埋めるのは「ローカル推論の API 互換性」という隙間

Apple Silicon で LLM を動かす手段自体はもう珍しくない。問題は、動かしたモデルを既存のツールチェーンにどう繋ぐかである。README は mlx-serve を「OpenAI- and Anthropic-compatible local inference for Apple Silicon」と説明し、同じ http://localhost:11234 が Claude Code、OpenAI SDK、Continue、Cursor、Open WebUI から使えるとしている。加えて Ollama API（/api/chat、/api/generate、/api/tags、/api/embed、/api/pull）も実装しており、Raycast や Obsidian、ollama-python のような既存クライアントをそのまま向けられるという主張になっている。対象読者は、モデルそのものよりもクライアント側の接続先を差し替えたい開発者である。Python を実行時に要求しない点も README では繰り返し述べられており、mlx-lm からの移行を検討している層を明確に意識している。

Zig サーバー、MLX と llama.cpp の同梱、そして 3 系統の API

アーキテクチャの骨格は README の記述から読み取れる。中核は Zig で書かれたネイティブサーバーで、MLX 形式のモデルと HuggingFace 上の GGUF の両方を扱う。GGUF 側は llama.cpp を「embedded」として取り込む形になっており、外部に別ランタイムを立てる構成ではない。ビルドスクリプトが Zig、mlx、llama.cpp のバージョンを固定して取得またはビルドするため、依存の解決は利用者側の仕事から外れている。HTTP 面では OpenAI 互換、Anthropic Messages API、Ollama API の 3 系統を同じポートで受ける。リリースノートの v26.9.1 では 1M コンテキスト、v26.9.2 ではモデル単位の設定とチャットプロバイダが追加されており、サーバー単体ではなくクライアント側の設定粒度も更新対象になっている。テキスト以外に画像、動画、音楽、音声（ボイスクローン）、3D 生成も同じサーバーが担うと README は述べており、推論サーバーというよりマルチモーダルなローカル実行基盤として設計されている。

導入手順: アプリ経由か、Homebrew か、ソースビルドか

README が示す経路は 3 つある。最も推奨されているのは MLX Core アプリで、メニューバー常駐型、署名・公証済み、サーバーバイナリを同梱する。Homebrew では次のように入れる。brew tap ddalcu/mlx-serve https://github.com/ddalcu/mlx-serve、続けて brew install --cask mlx-core がアプリ、brew install mlx-serve が CLI とサーバーのみになる。ターミナル派向けには Ollama 風のコマンドが用意されている。mlx-serve run gemma4 は Gemma 4 E4B（4-bit）をダウンロードして起動しそのまま REPL に入る。mlx-serve pull qwen3.6:27b はダウンロードのみで再開可能、mlx-serve list はディスク上のモデル一覧、mlx-serve serve は取得済みモデルを名前解決でオンデマンドに読み込む。モデル指定は短縮名、org/repo 形式の HuggingFace ID、name:tag のいずれも受け付ける。ソースから組む場合は git clone --recurse-submodules、brew bundle install --file=Brewfile（cmake と webp）、./app/build.sh の 3 手順で、Xcode 26.2 以降と Metal Toolchain コンポーネントが前提となる。

macOS 26.2 という足切りと、LICENSE 表記の不一致

最初に引っかかる制約はプラットフォームである。README は macOS 26.2 以降の Apple Silicon を要求し、それ以外の環境については何も示していない。Linux サーバーや CI ランナーでヘッドレスに回したい用途は、この時点で選択肢から外れる。次にライセンス表記が素直ではない。リポジトリのメタデータは NOASSERTION を返しており、README のバッジは MIT、本文の比較表の最下行も License: MIT と書かれている。GitHub が自動判定できていない以上、採用判断の前に LICENSE ファイルの実文を自分で読む必要がある。ここは README を信用するかどうかの問題ではなく、記載と実体が一致しているかを確認する作業である。同梱物として llama.cpp と MLX が入るため、本体のライセンスだけでなく依存側の条件も確認対象になる。法的助言はここではできないが、社内配布や製品組み込みを想定するなら法務確認の前に事実を揃えておくべき箇所である。

性能比較表の読み方: 何が比較され、何が比較されていないか

README の比較表は情報量が多いが、そのぶん読み落としやすい但し書きが脚注に置かれている。mlx-serve のデコード速度は「geomean vs LM Studio, identical weights」で +26%（MLX、出荷時デフォルト）と記載される。つまり同一の MLX ウェイトを使った条件での比較であり、GGUF 同士の比較ではない。脚注 1 は、Ollama が MLX をほぼ扱えず NVFP4 変換が少数ある程度だと説明したうえで、Ollama との比較は GGUF 対 GGUF の推定値 ~−15% であると明記している。推定値であることも明記されている。mlx-lm との比較は +11%（MLX）である。これらは README が提示する数値であり、本記事で追試したものではない。採用検討の実務としては、自分のモデルと量子化で自分のマシン上で測り直す以外に確かめる方法がない。ベンチマークの生データは README の末尾で Performance セクションに置かれていると案内されている。

LM Studio との違いは Electron か否か、Ollama との違いは MLX の扱い

代替として最も現実的なのは LM Studio と Ollama である。LM Studio との差は実行形態にある。mlx-serve は Zig のネイティブサーバーとネイティブのメニューバーアプリで、README は「No Electron」を繰り返し掲げる。LM Studio は Electron ベースとされており、比較表でもその点が区別されている。API 面では LM Studio も MLX と GGUF の両方を扱い、最近のビルドでは Anthropic の /v1/messages と OpenAI の /v1/responses 互換エンドポイントを部分対応で備えると README は説明する。mlx-serve はそこに Responses の WebSocket トランスポートや /v1/responses/compact を上乗せしているという書き方になっている。Ollama との差はより根本的で、Ollama は MLX をほぼ実行できず、比較は GGUF 対 GGUF に落ちる。OpenAI 互換も README の表では partial と評価されている。逆に Ollama はネイティブの Ollama API を持ち、mlx-serve はそれを模倣する側である。既存の Ollama クライアントを動かし続けたいなら、どちらが本家かという順序は意識しておく価値がある。

エージェント機能とサンドボックス: 何が同梱され、何が未確認か

README は組み込みのエージェントループと MCP クライアントを 10 ツール構成で備え、エージェントのシェルを分離された Linux VM で動かすと述べている。加えて Claude Code、OpenCode、Pi 向けのワンクリックランチャー、別の Mac のモデルを借りる LAN モデル共有も機能として挙げられている。これらは README の記述であって、本記事で動作を確認したものではない。分離 Linux VM という設計は、エージェントにシェルを握らせる構成としては妥当な方向だが、VM の実装方式、起動コスト、ネットワーク境界がどこで切られているかは README からは読み取れない。v26.9.1 の「Terminals in the sidebar」と v26.9.2 の「Per-model settings, chat providers」を見る限り、この領域は活発に変わっている。エージェント機能を採用理由の中心に置くなら、まずこの部分のドキュメントとソースを自分で読むべきで、README のチェックマークだけを根拠にすべきではない。

向くチーム、向かないチーム、最初に確かめる 3 点

向くのは、Apple Silicon の Mac を開発機として使い、Claude Code や OpenAI SDK 互換のクライアントの接続先をローカルに切り替えたい個人および小規模チームである。モデルの取得からサーバー起動までを mlx-serve run と mlx-serve serve で完結させたい場合、CLI とアプリのどちらでも同じバイナリと同じポートに着地する点は運用を単純にする。向かないのは、Linux 上で推論を回す構成、macOS 26.2 未満しか用意できない環境、そして Python 依存を許容できる代わりに既存の mlx-lm パイプラインをそのまま使い続けたい場合である。最初に確かめるのは LICENSE ファイルの実文、Metal Toolchain の有無（xcrun -sdk macosx metal --version）、そして自分のモデルでの実測速度の 3 点になる。README の +26% は同一 MLX ウェイト条件の geomean であり、自分の量子化とコンテキスト長にそのまま当てはまる数字ではない。

編集部の結論

macOS 26.2 以降の Apple Silicon 機をすでに持っていて、Claude Code や OpenAI SDK 互換のクライアントをローカルに向けたいなら、MLX Core アプリを brew install --cask mlx-core で入れて localhost:11234 に接続する経路が最も摩擦が少ない。逆に Intel Mac、macOS 26.2 未満、Linux や CI 上のヘッドレス推論が要件なら対象外である。導入前に確認すべきは 3 点で、第一に LICENSE ファイルの実際の文面（GitHub のメタデータは NOASSERTION で README のバッジは MIT と食い違う）、第二に README が示す性能比較が同一 MLX ウェイト条件の geomean +26% という限定された主張であること、第三に Xcode 26.2 と Metal Toolchain が揃わない環境では ./app/build.sh が通らないこと。ソースから追うなら xcrun -sdk macosx metal --version が通るかを最初に確かめ、通らなければ xcodebuild -downloadComponent MetalToolchain を先に実行する。

公式情報源

1. ddalcu/mlx-serve on GitHub
2. Issues
3. Project website
4. README
5. Releases