oMLX 0.3.9.dev2はMacローカルLLMをCodexやCopilotに寄せてきた
目次
oMLX 0.3.9.dev2を、MacローカルLLMをClaude CodeやCodex、Copilotの裏側に置く前提で読むと、追加機能の重心が見える。
Gemma 4 VLM側のMTP、DFlash engineでGemma 4を動かせるようになった件、omlx launch copilotの追加、SSD KVキャッシュまわりの調整、管理UIの再起動ボタン。
GitHub Releases の v0.3.9.dev2はpre-release扱いで、0.3.9正式版へ向かう2本目の開発ビルドにあたる。
oMLX自体は、Apple Silicon向けのMLXベース推論サーバー。
OpenAI互換APIとAnthropic Messages APIを出し、メニューバーアプリ、管理UI、モデル管理、continuous batching、SSDへ逃がせるKVキャッシュを一体で持つ。
README上の要件はmacOS 15.0以降、Python 3.10以降、Apple Silicon。
Intel Macや古いmacOSは対象外。
長い共通プロンプトを再計算しない設計
ローカルLLMをコーディングエージェントに使うと、最初につらいのはモデルの生成速度だけではない。
システムプロンプト、ツール定義、リポジトリの説明、直前の会話履歴が毎回ぶら下がるので、生成前のprefillが重くなる。
oMLXが強く押しているのは、このprefillをKVキャッシュとして再利用する設計だ。
READMEでは、ホット層をRAM、コールド層をSSDに置き、キャッシュブロックをsafetensors形式で永続化すると説明している。
同じprefixに再び当たったとき、最初から全トークンを計算し直すのではなく、SSDから復元する。
この方向は、以前見たHypuraのNVMeストリーミングとTurboQuantのKVキャッシュ量子化とも問題意識が近い。
ただしHypuraが大きいモデル本体やFFN層をどう流すかに寄っていたのに対し、oMLXはエージェント会話の実行時状態、つまりKVキャッシュをどう残すかに寄っている。
モデル本体がメモリに載るかどうかと、長い文脈を毎ターン再計算するかどうかは別の詰まり方をする。
oMLX公式サイトでは、コーディングエージェントではKVキャッシュがセッション中に何度も無効化される、と説明している。
小さいモデルを速く回すだけならOllamaやLM Studioでも済むが、ツール定義を抱えた長い会話を何度も往復するなら、生成速度より先にprefillの待ち時間が体感を支配する。Claude CodeやCodexをローカルバックエンドへ向けたい場合、ここを残せるかどうかで運用が変わる。
0.3.9.dev2の主役はGemma 4 VLM側のMTP
0.3.9.dev2のリリースノートで先頭に出ているのは、Gemma 4 image + text requests のMTP対応だ。
MTPはMulti-Token Predictionの略で、次の1トークンだけでなく複数トークンを先読みし、本体モデル側で検証して受け入れる仕組み。
speculative decoding系の高速化に分類される。
このブログでは、Gemma 4 MTPについて先に公式情報の確認とM1 Max 64GBでの実測をやった。
実測では、26B A4Bだけ速くなり、31B DenseとE4Bは遅くなった。
MTPは「オンにしたら常に速い」ではなく、モデル構造、batch、prompt、量子化、実行環境でかなり変わる。
今回のoMLX側の差分は、テキストだけでなくvision path、つまり画像+テキストのデコードにMTPが入ったこと。
リリースノートでは、管理UIでトグルを有効にすると、vision pathでもテキスト側と同じように複数トークン予測を使う、と説明している。
既存環境の挙動を壊さないため、デフォルトではオフ。
VLMは画像エンコード、視覚トークン、言語デコードが絡むので、体感速度のボトルネックがテキストLLMより見えづらい。
Gemma 4で画像を読ませる用途があるなら、oMLXの管理UIでMTPを切り替えて、短文質問、長い説明生成、OCR寄りの読み取りで別々に測るのが良い。
テキスト側のGemma 4 MTPと同じで、1つのベンチだけでは判断しにくい。
DFlashとParoQuantはモデル選択肢を広げる差分
dev2ではDFlash engineでGemma 4を動かせるようになった。
DFlashはMLX周辺の高速推論経路で、oMLX側ではエンジンプールの選択肢として扱われる。
リリースノートでは、Gemma 4がDFlash選択時にフォールバックせず、他のモデルと同じプールに乗るようになった、と書かれている。
あわせて、DFlash向けの量子化選択肢、FP16 draft model boost、prefix cache sizeの設定も入っている。
長いセッションでキャッシュエントリがchurnしにくくなる方向の調整で、「初回だけ速い」より「数十分触っても待ち時間が崩れない」を優先する作りに寄っている。
量子化ではParoQuant対応と、custom quantization loaderの差し込み口が入った。
omlx serve、omlx chat、管理UIのLoad modelが同じdispatcherを通るようになり、今後の量子化方式をloader分岐で増やせる。
さらにoQ sensitivity measurementでは、元モデルがRAMに収まらない場合にproxy modelを自動構築するようになった。
Apple Siliconはユニファイドメモリで扱いやすい一方、大きいモデルを量子化前に全部載せる段階で詰まりやすい。
proxy modelを自動で作ってoQの感度測定を進める仕組みが入ったことで、64GBや48GBクラスのMacでも、これまで「載らないから諦め」だった量子化作業に手が出る幅が広がる。
omlx launch がCopilotまで面倒を見る
dev1で omlx launch claude、codex、opencode、openclaw、pi が入り、dev2で copilot が追加された。
omlx launch copilot を実行すると、curses TUIでモデルを選び、oMLXが環境変数を組み、CLIへexecする流れになる。
これは地味だけど、ローカルLLMをエージェントに繋ぐときの面倒な部分をかなり削る。
モデル名、base URL、APIキー、Anthropic互換かOpenAI互換か、コンテキスト長の扱いを毎回shell設定に書くのは壊れやすい。
管理UIのApplications dashboardにもCopilot行が出る。
OllamaとローカルLLMでMCPサーバーを使うならブリッジが要るで書いたように、ローカルLLMをtool callingやMCPへ繋ぐ時は、モデルの賢さ以前にAPI互換、ツール定義、実行プロセスの接続でつまずく。
oMLXはそこを「モデルを選んでCLIを起動する」1操作に畳んでいて、launch対応CLIが6種類に増えた。
管理UIから再起動ボタンで設定反映を完結させる
dev2には管理UIのRestart Serverボタンも入った。
Settingsからサーバーを再起動でき、restart endpointはadmin authで守られる。
メニューバーやshellへ戻らずに設定変更後の再起動まで済む。
長時間エージェントを動かすときは、モデルディレクトリ、キャッシュ設定、量子化、エンジン切り替えを管理UIで触ることが増える。
再起動だけshellに戻ると、いまの状態がUIに出ているものと一致しているか追いにくい。Restart Serverが同じ画面に来たことで、設定変更から反映確認まで1画面で閉じる。
新機能ではSTTのmax_tokens対応、非英語transcriptionの言語指定、フランス語管理UI、Hugging Face namespaceに合わせたダウンロード保存、チャット履歴のリネーム、ストリーミング完了ログも入っている。
ただ、MacローカルLLMをCodexやCopilotの裏側に置く観点では、Gemma 4 VLM MTP、DFlash、oQとParoQuant、omlx launch copilot、Restart Serverのほうが触ったときの差が出やすい。
dev2を測るなら指標を分ける
v0.3.9.dev2はpre-release扱いで、メイン環境を置き換えるより別モデルディレクトリか短い検証セッションで触るのが前提になる。
リリースノートにも、バグがあればissueを開いてほしいと明記されている。
oMLXで速度を見るなら、TTFT、prefill tokens/sec、generation tokens/sec、同一プロンプト2回目以降のキャッシュヒット時、メモリ使用量を分けて測る必要がある。
SSD KVキャッシュでprefillが消えたのか、MTPでdecodeが速くなったのか、DFlashでengine差が出たのかは、まとめて測ると混ざる。
Gemma 4のテキストMTPでも、Apple Siliconの単発実行では公式ベンチと逆の結果になるケースがあった。MTP、DFlash、量子化loaderは、モデル・バッチ・プロンプト長で挙動が変わる。
参考