Rapid-MLX を M シリーズ Mac のローカル推論基盤として検討する

Rapid-MLX が埋めようとしている穴は何か

ローカル LLM を Mac で動かすこと自体は、Ollama や LM Studio で既に容易になっている。問題はその先にある。コーディングエージェントや自作アプリは OpenAI か Anthropic の API 形式を前提に書かれており、ローカルの推論サーバーがその形式を喋れないと、クライアントごとにアダプタを書く羽目になる。Rapid-MLX はこの境界を引き受ける。README は「If a client accepts an OpenAI- or Anthropic-compatible endpoint, it can usually use Rapid-MLX without an adapter.」と述べており、Claude Code、Codex CLI、OpenCode、Aider、LangChain、PydanticAI などが互換先として列挙されている。対象読者は、M シリーズ Mac 上でエージェントを回したいが、API の差異を自前で吸収したくない開発者である。

MLX の上に FastAPI を被せる構成

リポジトリのトピックには mlx、fastapi、openai-api、tool-calling が並ぶ。つまり推論そのものは Apple の MLX に委ね、その上に HTTP サーバーを立てて OpenAI / Anthropic 互換のエンドポイントとして見せる構造だと読める。README が前面に出している機能は 3 つある。プロンプトキャッシュ、推論過程の分離（reasoning separation）、そしてツール呼び出しのパーサーである。キャッシュは README の見出しで 0.08s cached TTFT と表現され、同一プレフィックスの再計算を避けることでエージェントのループを軽くする狙いが見える。ツールパーサーは 17 種類とされ、モデルごとに異なるツール呼び出しの出力形式を吸収する層にあたる。エージェント用途では、この層の対応漏れがそのまま動作不能につながるため、速度の数字より実務上の重みが大きい。なお README にはクラウドルーティングへの言及もあるが、その判定条件や設定方法は与えられた資料からは確認できない。

導入経路は Homebrew、インストーラー、uv / pip の三つ

README が示すコマンドは明快である。Homebrew なら brew install rapid-mlx、スクリプトなら curl -fsSL https://rapidmlx.com/install.sh | bash。どちらも同じ rapid-mlx CLI を入れると説明されている。uv や pip を使いたい場合、あるいはインストーラーの中身を確認してから実行したい場合は alternative install methods と SECURITY.md を参照するよう案内されている。起動後の最初の一歩として rap という短いコマンドが例示されている。モデル選択は自動で、ガイド付きインストーラーは RAM 階層に応じて既にキャッシュ済みのモデルを優先し、無ければ 16 GB 未満で lfm2.5-1b-4bit、16 GB 以上で qwen3.5-4b-4bit を最初のチャット用にダウンロードする。より大きいモデルは rapid-mlx recipe とモデルピッカーから選ぶ流れになっている。

プラットフォーム制約とライセンス表記のねじれ

最大の制約は対応 OS である。README はデスクトップ版について Requires an M-series Mac; Windows and Linux desktop builds are not available yet と明記している。CLI とサーバーも見出しが macOS (Apple Silicon) となっており、Intel Mac や他 OS は想定外と読める。次にライセンス。README のバッジは Apache 2.0 を掲げているが、リポジトリのライセンス識別子は NOASSERTION であり、GitHub 側は Apache 2.0 として認識していない。これは表記の不一致なのか、追加条項のあるライセンスなのかが外部から判別できない状態を意味する。企業で利用する場合、LICENSE ファイルの原文を確認する作業を飛ばせない。ここは推測で埋めず、README の主張とリポジトリのメタデータが食い違っているという事実だけを記しておく。

Ollama との違いは速度の数字ではなく抽象化の位置

比較対象として自然なのは Ollama である。Rapid-MLX 自身が ollama-alternative をトピックに掲げ、README も Ollama とのスループット比較にリンクしている。ただし両者の差はベンチマークの倍率よりも、どこで抽象化しているかに表れる。Ollama はモデルの取得と実行をまとめて扱うツール寄りの設計で、独自の API を中心に据えている。Rapid-MLX は OpenAI / Anthropic 互換のサーバーとして振る舞うことを前面に出す。既存のエージェントや SDK をそのまま向けたい場合、後者のほうが配線は短い。一方で、モデルの管理や量子化の選択肢を細かく自分で決めたい場合、Ollama のほうが素直な場面は残る。どちらが優れているかではなく、クライアント側の書き換えを許容できるかで選ぶべき差である。

向かないケースと、リリース速度が生む追従コスト

ローカル推論は、モデルが手元のメモリに収まる範囲でしか品質を出せない。16 GB 未満の Mac に lfm2.5-1b-4bit が割り当てられる設計は、その現実を素直に反映している。長いコンテキストを要するコーディング作業や、複雑な推論を期待する用途では、そもそもローカルという選択自体が噛み合わない。Rapid-MLX の責務はそこではなく、収まるモデルをエージェントから使いやすくすることにある。もう一点、保守の観点で目に留まるのはリリースの刻みである。与えられた情報では v0.13.3 が 2026-09-01、v0.13.4 が 2026-09-03 と、2 日でパッチ版が進んでいる。活発さの裏返しとして、0.x 系の間に API や設定が動く可能性を前提に置く必要がある。バージョンを固定して検証し、上げるタイミングを自分で決める運用のほうが安全だろう。

採用を決める前に自分の手元で確かめること

最初に確認すべきは、自分の使うモデルが 17 種類のツールパーサーのどれで処理されるかである。README はテスト済み互換マトリクスへのリンクを置き、リリース前に 5 つの Tier-1 エージェントを実ウェイトで通すと述べているが、それは公開側の検証であって自分のワークフローの検証ではない。rapid-mlx recipe でモデルを選び、実際にツール呼び出しを含むプロンプトを投げて、期待どおりの JSON が返るかを最初に見る。次にプロンプトキャッシュが効く形になっているか、つまりシステムプロンプトやツール定義のプレフィックスが毎回同一に保たれているかを確認する。ここが揺れると cached TTFT の利点は消える。最後に LICENSE ファイルの原文と、Anthropic 互換エンドポイントを使う場合のカバレッジを互換マトリクスで突き合わせる。この 3 点が通れば、M シリーズ Mac 上のエージェント実行基盤として有力な候補になる。

編集部の結論

M シリーズ Mac を持ち、Claude Code や Aider などのクライアントを OpenAI 互換エンドポイント経由でローカルモデルに向けたい人には検討の価値がある。逆に Windows / Linux で動かす予定の人、クラウドの大規模モデル並みの品質を期待する人には向かない。導入前に確認すべきは、README が Apache 2.0 バッジを掲げる一方でリポジトリのライセンス識別子が NOASSERTION になっている点、同梱されるツールパーサーが自分の使うモデルの出力形式に対応しているか、そして 0.13.x 系が短期間に連続リリースされていることによる追従コストである。

公式情報源

1. Issues
2. Project website
3. raullenchai/Rapid-MLX on GitHub
4. README
5. Releases