vllm-mlx レビュー: Apple Silicon で OpenAI と Anthropic の両方を受ける推論サーバー

既存クライアントを書き換えずにローカル推論へ向ける

vllm-mlx が埋めるのは、Mac 上で動く推論サーバーと、CUDA 前提で組まれたクライアント側ツールの間の隙間である。OpenAI SDK を使うコードは base_url を http://localhost:8000/v1 に変えるだけで動く。Anthropic 側も ANTHROPIC_BASE_URL と ANTHROPIC_API_KEY を環境変数で差し替えれば、Claude Code がそのままこのサーバーに接続する。API キーは not-needed で通る。

対象読者は、ローカル LLM を試したいが Ollama のような単純なサーバーでは同時リクエストの処理効率に不満がある人、あるいは Claude Code のバックエンドを自前のモデルに置き換えたい人だ。README は Ollama や mlx-lm を直接使う場合と対比し、連続バッチ処理、ページド KV キャッシュ、プレフィックスキャッシュ、SSD 階層キャッシュを差分として挙げている。つまり単発のチャットではなく、エージェントのように何度もコンテキストを共有しながら呼び出す使い方を想定した作りになっている。

連続バッチ処理と KV キャッシュの階層構造

推論の中心は MLX の Metal カーネルで、モデルの変換工程を挟まず unified memory 上で動く。リクエスト処理は連続バッチ処理で束ねられ、KV キャッシュはページ単位で管理される。ページド KV キャッシュはメモリ効率を上げるだけでなく、プレフィックスの共有を可能にする。プレフィックスキャッシュ自体は trie ベースで、リクエストをまたいで再利用される。

長いコンテキストを扱うエージェント向けに、--ssd-cache-dir でプレフィックスキャッシュをディスクへ退避できる。起動時に --warm-prompts を与えると、よく使うプレフィックスを事前に読み込む。README はこの効果を TTFT の 1.3 倍から 2.25 倍と記載している。数値の出所はリポジトリ内の docs/benchmarks/ で、条件はそちらに委ねられている。

API 層は 1 プロセスで 2 系統を提供する。OpenAI 互換が /v1/chat/completions、/v1/completions、/v1/embeddings、/v1/rerank、/v1/responses。Anthropic 互換が /v1/messages で、ストリーミング、ツール使用、システムプロンプトに対応する。ツール呼び出しのパーサは 19 種類あり、OpenAI、Anthropic、Gemini、Qwen、DeepSeek、Gemma などが含まれる。構造化出力は response_format 経由の JSON Schema で、lm-format-enforcer を使うと説明されている。

導入手順と起動オプション

インストールは pip install vllm-mlx。起動は次の形になる。

vllm-mlx serve mlx-community/Llama-3.2-3B-Instruct-4bit --port 8000 --continuous-batching

音声を扱う場合は pip install vllm-mlx[audio] とし、非英語の TTS には macOS 側で brew install espeak-ng が要る。埋め込みを併用するなら --embedding-model mlx-community/all-MiniLM-L6-v2-4bit のように指定する。推論モデルの推論過程を取り出すには --reasoning-parser qwen3 のようなパーサ指定を加える。

観測面では --metrics を付けると /metrics が Prometheus 形式で公開される。性能測定用に vllm-mlx bench-serve が同梱されており、--url、--concurrency、--prompts、--output を組み合わせて CSV や JSON に結果を書き出せる。--workload と --repetitions を使えば品質チェック付きのワークロードを繰り返し実行できる。

構成の自由度が高い一方で、フラグの数は多い。--moe-top-k や --mtp、--spec-prefill といった項目はモデル固有の最適化であり、対象モデル以外に付ける意味はない。README は Qwen3-30B-A3B に対する --moe-top-k の効果を +7 から 16% と書いているが、これは特定モデルでの話である。

Apple Silicon 専用という制約が意味するもの

最大の制約は対応ハードウェアだ。README は M1、M2、M3、M4、M5 の Apple Silicon のみを挙げ、Metal カーネル経由で動くと明記している。Linux サーバーや NVIDIA GPU 上で同じ構成を再現する道は用意されていない。既存の推論基盤が CUDA で組まれているチームにとって、これは評価対象外になることを意味する。

二つ目はメモリの上限がマシン構成に縛られる点だ。unified memory は利点である反面、モデルを載せられるかどうかが購入時のメモリ量で決まる。README の表でも Qwen3-30B-A3B-4bit は約 18 GB を使用するとされており、同時接続数を増やせば KV キャッシュ分がさらに上乗せされる。連続バッチ処理はスループットを上げるが、メモリを無限にするわけではない。

三つ目は音声やマルチモーダルの依存関係だ。TTS の一部は espeak-ng という外部バイナリに依存し、pip の世界だけで完結しない。コンテナ化されたデプロイを前提にする場合、この種のホスト側依存は無視できない。

最後に、README に載る性能値の読み方にも注意が要る。LLM の decode 数値は greedy かつ単一ストリームの条件で示されている。同時実行時の挙動は別の資料に分かれている。

Ollama や mlx-lm と何が違うのか

比較対象として最も分かりやすいのは mlx-lm を直接使う構成だ。mlx-lm は MLX 上でモデルを動かすためのライブラリであり、サーバーとしての機能は付随的である。vllm-mlx はそこに連続バッチ処理、ページド KV キャッシュ、プレフィックスキャッシュ、SSD 階層キャッシュを載せ、API サーバーとしての体裁を整えている。単発の推論を Python から呼ぶだけなら mlx-lm で足りる。複数クライアントを同時に捌き、共通のプレフィックスを再利用したいなら vllm-mlx の層が効いてくる。

Ollama との違いは API の表面積とキャッシュ設計にある。Ollama は独自 API を中心に据えており、OpenAI 互換は提供するものの、Anthropic の /v1/messages を同一プロセスで受ける構成は一般的ではない。vllm-mlx は OpenAI と Anthropic の両方を 1 プロセスから出し、Claude Code をそのまま向けられる点を前面に出す。加えてページド KV キャッシュとプレフィックス共有を明示的な設計として持つ。

ただしこれは、Ollama が劣るという話ではない。モデル管理や配布の体験は Ollama の方が成熟しており、vllm-mlx はモデルを mlx-community のリポジトリ名で直接指定する方式を取る。モデルの取得と更新を誰が担うかという運用面では、両者の前提が異なる。

マルチモーダルと音声を 1 プロセスに集約する

テキスト、画像、動画、音声を同一サーバーで扱う点は、構成要素を減らしたい場合に効く。視覚モデルとして Gemma 3、Gemma 4、Qwen3-VL、Pixtral、Llama vision が挙がっている。チャット内の音声入力は audio_url コンテンツブロックで受ける。

TTS は Kokoro、Chatterbox、VibeVoice、VoxCPM を使い、11 の声と 15 以上の言語に対応するとされる。STT は Whisper 系で、M4 Max における RTF は whisper-tiny が 197 倍、whisper-large-v3-turbo が 55 倍、whisper-large-v3 が 24 倍と記載されている。RTF は実時間に対する倍率であり、数値が大きいほど短時間で処理できる。ただしこれも単一のマシンでの測定値であり、自分の環境で同じ値が出る保証はない。

リランキングは /v1/rerank で提供される。README は MLX のリランカーが BERT 系および XLM-RoBERTa 系の系列分類重みに対応し、hidden_act として gelu、gelu_new、gelu_fast、relu、silu、swish を受け付けると説明する。それ以外の活性化関数は明示的に失敗する。これは設計判断として興味深い。黙って誤った活性化を使うより、カスタムアーキテクチャ側に専用アダプタを書かせる方が安全だという立場である。

ライセンスと更新の追い方

ライセンスは Apache-2.0。商用利用を含む幅広い用途を許容する条項だが、同梱物や依存パッケージのライセンスは別途確認が必要で、ここで法的な判断を下すことはできない。モデルの重みは mlx-community 側の配布物であり、それぞれのライセンスに従う。

更新の頻度は比較的高い。v0.4.0rc1 が 2026 年 5 月、v0.4.0 が 6 月、v0.4.1 が 8 月に公開され、リポジトリへの最終 push は 2026 年 9 月である。プレリリースを挟む開発スタイルなので、本番導入では rc を避けて安定版のタグを指定する方が無難だ。

アップグレード時の確認点は、API の互換性よりもフラグの挙動である。--moe-top-k や --mtp、--spec-prefill のような最適化フラグはモデル依存であり、対応モデルが変われば意味も変わる。バージョンを上げる前に、自分の起動コマンドに含まれるフラグが新しいリリースでも同じ効果を持つかをリリースノートで確認したい。README は英語以外にスペイン語、フランス語、中国語の版を用意しており、差分の把握はそちらでもできる。

導入を決める前に自分のワークロードで測る

README の性能表は魅力的に見えるが、条件が明示されている。LLM の decode は M4 Max、128 GB、greedy、単一ストリーム。Qwen3-0.6B-8bit で 417.9 tok/s、Llama-3.2-3B-Instruct-4bit で 205.6 tok/s、Qwen3-30B-A3B-4bit で 127.7 tok/s という数字は、この条件下での値である。

自分の用途が同時接続を捌くことにあるなら、この表は判断材料として不十分だ。連続バッチ処理の結果は docs/benchmarks/ に分けて置かれている。同梱の vllm-mlx bench-serve を使えば、--concurrency を変えながら同じ条件を自分のマシンで再現できる。--continuous-batching を付けた起動と付けない起動で結果を並べれば、この機能が自分のリクエスト形状でどれだけ効くかが見える。

導入の判断は、この測定を先にやるかどうかで変わってくる。数値が良ければそのまま採用すればよいし、差が出なければ Ollama や mlx-lm で足りる可能性が高い。サーバーを増やす理由は、キャッシュの階層と API の二重対応が自分の構成で実際に効いている場合に限られる。

編集部の結論

M シリーズの Mac をローカル推論の実行基盤として持て余しているなら、vllm-mlx は検討に値する。とくに Claude Code や OpenAI SDK を使う既存クライアントを書き換えずに、接続先だけをローカルに向けたい場面では効果が分かりやすい。逆に NVIDIA GPU を既に運用しているチーム、複数ノードに分散してスループットを稼ぐ構成、Linux 上での本番運用が前提の案件には向かない。Apple Silicon 専用であり、Metal 以外のバックエンドは提供されていない。導入前に確認すべきは、自分の用途が単一ストリームの対話なのか同時接続なのかという点だ。README が示す M4 Max の数値は greedy かつ単一ストリームの条件であり、連続バッチ処理の効果は docs/benchmarks/ 側に置かれている。まず vllm-mlx bench-serve を自分のワークロードで回し、--continuous-batching の有無で結果を比べるのが最初の一歩になる。

公式情報源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. waybarrios/vllm-mlx on GitHub