LM StudioがMLXエンジンを統一した理由──フォークされていた2つの実装を1つにするとフォロー応答が25倍速くなった

Mac上でローカルLLMを手軽に動かせるアプリ「LM Studio」は、Apple製チップ向けの推論エンジンとしてAppleのMLXフレームワークを採用している。この記事で扱う変更自体は2025年5月30日に公式ブログで発表されたものだが、テキストモデルと画像対応モデルを1つのアーキテクチャで扱う「統一型MLXエンジン」という設計は、日本語での解説がほとんど見当たらない。LM Studio公式ブログの技術記事と、GitHub上のmlx-engineリポジトリの現状を読み解く。

3行まとめ

1. LM Studioは2025年5月30日、テキスト用mlx-lmと画像対応用mlx-vlmという別々の実装を使い分けていた「フォーク型」アーキテクチャを、mlx-lmを核としてmlx-vlmの機能をアドオンとして組み込む「統一型」に置き換えたと発表。Gemma 3 12B QATでフォロー応答のTTFTが約25倍速くなった
2. GitHub上のlmstudio-ai/mlx-engineリポジトリ（2026年8月24日時点で★1,172、MIT license）を確認すると、2026年8月28日直前まで開発が継続しており、2026年3月にQwen 3.5、4月にGemma 4がそれぞれ「Unified」アーキテクチャに対応済みになっている
3. LM Studio公式ブログは2026年6月5日、mlx-engine v1.8.5でエージェント的な長文脈ワークフロー向けにKVキャッシュのディスク保存機能を追加したと発表。ベンチマークでは追加RAM使用量が最大80%減、スループットが最大2倍、画像リクエストの処理が最大3.5倍速くなったとしている

何が変わったか：2つのライブラリを1つに束ねる

LM StudioのMLXエンジンは、Apple Silicon上でLLMを効率的に動かすために、2つのPythonパッケージを利用している。

• mlx-lm：テキスト生成用（Apple社のAwni Hannun氏、Angelos Katharopoulos氏らが開発）
• mlx-vlm：画像対応の言語モデル（VLM）用（Prince Canuma氏が開発）

公式ブログによれば、mlx-engineのコミットf98317e以降（アプリ内エンジンv0.17.0以降）で、LM Studioはこの2つのパッケージの基盤コンポーネントを織り込んだ「統一型」アーキテクチャに移行した。テキストモデルの実装は常にmlx-lmのものを使い、mlx-vlmのビジョンモデル実装は、テキストモデルが理解できる画像埋め込みを生成するための「アドオン」としてモジュール的に使われる形になった。

旧アーキテクチャの問題

ブログは、旧来の「フォーク型」アーキテクチャの問題を次のように説明している。モデルが画像対応（Vision-capable）ならmlx-vlmの実装（テキスト＋ビジョン）を排他的に使い、テキスト専用ならmlx-lmの実装（テキストのみ）を排他的に使う、という単純な分岐構造だった。

この設計には次のような問題があったという。

• mlx-lmとmlx-vlmの機能が完全にパリティしていない、または挙動に微妙な違いがある場合、どちらを使うべきか判断が難しい
• マルチモーダルモデルとテキスト専用モデルの体験のズレを、どう抑えるか
• 片方の実装がもう片方より性能が良い、あるいはもう片方にはないバグを持つ場合、どちらを使うか一貫して選ぶにはどうすればいいか。リクエストに応じてホットスワップするのは複雑
• 2つの実装を切り替えたり、マルチモーダルモデルのテキスト専用版（例：テキスト専用版のGemma 3）を使う場合、モデルごとのバグ・保守の対象面積が2倍になる。同じ基盤モデルを推論するために2つの実装が並存し、条件によって使い分けられているため、両方をバグフリーに保つ必要が生じる

統一アーキテクチャの実現方法

LM Studioは、Awni Hannun氏、Prince Canuma氏との議論を経て、mlx-lmとmlx-vlm双方への貢献を通じてこの統一を実現した。主な変更点は次の通り。

• mlx-lm側：generate_stepへのinput_embeddings入力の追加、Pixtralのテキストサポート追加
• mlx-vlm側：Gemma3・Qwen2.5VLのテキスト・画像入力マージ関数の公開、Pixtralのmerge_input_ids関数の公開

この統一アーキテクチャでは、マルチモーダルLLMのコアとなるテキストモデルは常にmlx-lmから読み込まれ（もはやmlx-vlmからわずかに異なるテキストモデルが読み込まれることはない）、条件付きでmlx-vlmの機能を使う「VisionAddOn」を読み込んで、mlx-lmのテキストモデルが理解できる画像埋め込みを生成する。

効果：フォロー応答のTTFTが約25倍速くなった

ブログが強調する実利用上のメリットは、これまでテキスト専用LLMだけの特権機能だった「プロンプトキャッシュ」が、マルチモーダルモデルとのテキストのみのチャットでも使えるようになった点だ。これにより、フォローアップ応答が劇的に速くなる。

ブログに掲載されたデモ動画のキャプションには次のように書かれている。

"Gemma 3 12B QAT, both MLX 4 bit on M3 MacBook Pro. ~25x faster follow-up TTFT with the unified architecture"

M3 MacBook Pro上でGemma 3 12B QAT（MLX 4bit量子化）を使った場合、統一アーキテクチャによってフォローアップのTTFT（Time To First Token、最初のトークンが出力されるまでの時間）が約25倍速くなったという。これは、テキストのみのやり取りでVLMをテキスト専用モデルと同じように扱えるようになり、画像がない場合はプロンプトキャッシュが効くようになったためだ。

現時点で対応しているモデル

ブログ執筆時点（2025年5月30日）で、統一アーキテクチャに移行済みなのはGemma 3（Gemma3VisionAddOn）とPixtral（PixtralVisionAddOn）の2モデルのみだった。ブログは、このVisionAddOnパターンを他のモデルに拡張するためのオープンソースへの貢献を歓迎するとし、Qwen2.5VLへの拡張が次の候補として挙げられている。音声入力への対応は「まだ扱っていないが、同じアプローチが音声にも通用するよう計画している」としている。

2026年8月時点の続報──Qwen 3.5・Gemma 4も統一アーキテクチャに対応、v1.8.5でさらに高速化

2025年5月の発表時点で統一アーキテクチャに対応していたのはGemma 3とPixtralの2モデルのみだったが、GitHub上のlmstudio-ai/mlx-engineリポジトリのコミット履歴を確認すると、その後も対応モデルの拡張が続いている。

さらにLM Studio公式ブログは2026年6月5日、「Improving LM Studio's MLX Engine for Agentic Workflows」という記事でmlx-engine v1.8.5を発表した。Qwen 3.5・3.6はハイブリッドアーキテクチャ、Gemma 4はスライディングウィンドウアーキテクチャをそれぞれ採用しており、これらはKVキャッシュを大幅に節約できる一方、「巻き戻し（rewind）」――エージェントが長い推論を行った後、その推論内容を破棄して次の応答を組み立て直す操作――に弱いという課題があったという。v1.8.5は256トークン境界でKVキャッシュをディスクに保存・復元する仕組みでこれに対処し、公式ブログは「追加RAM使用量が最大80%減、スループットが最大2倍、画像リクエストの処理が最大3.5倍速くなった」というベンチマーク結果を報告している。

この記事の核である「フォーク型から統一型へ」という2025年5月の変更点自体は、2026年8月時点でも維持・拡張され続けている設計思想だと確認できる。

GGUF/llama.cppとの違いという文脈で

MLXはApple独自の機械学習フレームワークで、Apple Siliconのユニファイドメモリアーキテクチャに最適化されている点が、GGUF形式・llama.cppエコシステムとの主な違いとして語られることが多い（詳しくはGGUFとMLX、Macで動かすならどっちを選ぶべきかを参照）。LM StudioはMLXエンジンとllama.cpp（GGUF）ベースのエンジンの両方をサポートしており、今回の統一化はそのうちMLXエンジン側の内部実装に関する変更だ。ローカルLLM全般の基礎、必要スペックについてはローカルLLMとは何か、具体的なモデル選びについてはローカルLLMおすすめモデル10選も参照してほしい。

「約25倍」は特定条件下の一測定値

• 「約25倍」という数値は、2025年5月の公式ブログのデモ動画キャプションに記載された特定の条件（Gemma 3 12B QAT、MLX 4bit、M3 MacBook Pro）での計測であり、他のモデル・ハードウェア構成でも同程度の高速化が得られるかは確認できていない
• 2026年6月のv1.8.5ブログが示す「最大80%減／最大2倍／最大3.5倍」という数値も、公式ブログに記載された測定条件（具体的なモデル・ハードウェアの組み合わせ）の詳細までは本記事では読み込んでおらず、"up to"（最大で）という表現が示す通り、上限値である点に注意が必要
• 音声入力への対応が2026年8月時点で実現しているかどうかは、GitHubリポジトリのファイル一覧・コミットメッセージを確認した範囲では判断できなかった。mlx_engineディレクトリに音声関連と明確に分かる名前のモジュールは見当たらなかったが、リポジトリ全体を網羅的に確認したわけではない
• lmstudio-ai/mlx-engineのコミット履歴とファイル構成はGitHub APIで確認したが、コード自体を実行して統一アーキテクチャの現在の挙動を検証したわけではない