Rapid-MLX：コーディングエージェントのためのApple Silicon向けLLM推論サーバー

ローカルでLLMを動かす場面で、Apple Siliconは長く微妙な立場に置かれてきた。ユニファイドメモリのおかげでMac mini一台に数十億パラメータの量子化モデルを載せられる一方、それを支える推論サーバー層の成熟度はCUDA環境に遠く及ばなかった。Rapid-MLXはまさにこの空白を狙うプロジェクトである。Apache 2.0ライセンスで公開されたオープンソースの推論サーバーで、AppleのMLXフレームワーク上に構築されている。OpenAI互換とAnthropic互換の二つのAPI、すなわち/v1/chat/completions、/v1/responses、/v1/messagesを備える。掲げる狙いは明快で、コーディングエージェントのための信頼できるツール呼び出しだ。単に速さだけを目標にせず、エージェントがツールを壊れずに呼べるかどうかを同じ重みで扱っている点が興味深い。導入も平易で、PyPIとHomebrew coreから入手でき、brew install rapid-mlxの一行でサーバーが立ち上がる。デスクトップアプリとモデルのミラーも用意されている。

最も目を引くのは速度の主張である。プロジェクトによれば、同じモデルと同じ重みで、デコード速度はApple公式のmlx-lmの最大4倍、典型的なタスクでは約1.5倍に達する。測定はMac mini M4 ProでQwen3.5-9Bの4ビット版を使い、貪欲デコードで、両サーバーとも既定設定のまま行われた。ここで二点、冷静に見るべきことがある。一つ目は、「最大4倍」と「典型1.5倍」の差が示すとおり、効果が負荷の形に強く左右されることだ。キャッシュに当たる場面や複数リクエストが並行する場面ほど差が開く。二つ目は、検証が一つのモデル、一台のマシン、一つのデコード方式に限られ、数値の発表者がプロジェクト自身である点だ。方向性を示す証拠として受け止め、自分のモデルとタスクで再測定してから判断すべきである。タスクごとの結果、方法、生データが公開されていることは評価できる。宣伝用の数字一つで済ませず、第三者が検証できる形にしているからだ。 この数字を支えるのは、互いに噛み合ういくつかの仕組みである。第一は連続バッチ処理で、複数のリクエストを一つのデコードループ内で交互に進め、長いリクエストが他を待たせ続けることを防ぐ。第二はプレフィックスキャッシュである。Rapid-MLXはメモリ上に基数木形式のプレフィックスキャッシュを保持し、ハイブリッド構造のモデル向けには状態のスナップショットも持つ。終了時にディスクへ書き出し、起動時に復元する。これはコーディングエージェントにとって特に重要だ。エージェントは毎ターン、長いシステムプロンプトとツール定義、そこまでの会話全体を送り直す。その大半は前のターンと同一なので、キャッシュを再利用すればプリフィルの大部分を省ける。第三は量子化KVキャッシュで、精度をいくらか手放す代わりにメモリを節約し、限られたユニファイドメモリでより長い文脈や多くの同時セッションを扱えるようにする。三つを合わせると、単発の質問のピーク性能ではなく、長い接頭辞、多数のターン、繰り返しの呼び出しというエージェント特有の負荷に狙いを定めた構成になる。

ツール呼び出しの解析は、このプロジェクトを多くの同種製品から分けるもう一本の柱である。モデルの系統ごとにツール呼び出しのテキスト形式は異なり、XML風のタグを使うもの、JSON断片を使うもの、思考テキストの中に混ぜるものがある。サーバーの解析が不安定だと、エージェントは壊れた引数を受け取って途中で止まってしまう。Rapid-MLXは27のパーサーモジュールを備え、自動検出のフォールバックも持つ。モデルを替えても手作業で合わせ込まずに済ませる狙いだ。プロジェクト自身の比較表では、mlx-lmのサーバーはトークナイザーがツール呼び出し対応を宣言したモデルに限って対応し、OllamaとLM Studioはそれぞれ独自のツール呼び出し文書と実装を持つとされている。ただし、パーサーの数がそのまま信頼性を意味するわけではない。長い会話、入れ子の引数、ストリームが途中で切れた場合でも有効な呼び出しを復元できるかが本当の試金石であり、これは各自のエージェント基盤で確かめる必要がある。 より広い市場で見ると、競合は少なくない。oMLXも同じくMLXを基盤とし、メモリ上のホット層とSSD上のコールド層からなる階層型KVキャッシュを採用する。Ollamaは既定でモデルごとに並列一リクエストで、safetensorsモデル向けにMLXエンジンを加えた。LM Studioはllama.cppとMLXの二つのエンジンを持つ。mlx-lm付属のサーバーは量子化KVキャッシュを使うと一度に一つのリクエストしか処理できない。プロジェクトが2026年9月26日時点でまとめたこの比較表は、この分野が似通った機能群へ急速に収束していることを物語る。差を生むのは実装の細部と実測の振る舞いになる。Macでローカルのコーディングエージェントを動かす読者は、同じモデルと同じタスクでRapid-MLXと現行環境を比べるのが現実的だ。見るべきは、最初のトークンまでの時間、長いセッションでのキャッシュヒット、ツール呼び出しの失敗率の三点である。倍率の宣伝よりも、この三つのほうが適合度をよく教えてくれる。