実行プログラムと拡張機能

oMLXでMacのモデルを使い続ける:キャッシュと高速化設定の選び方

文書を読ませていたモデルからコーディング用に切り替えると、また長い待ち時間。アプリをいくつか開けば、メモリも窮屈になります。oMLXは、こうした日々の利用を管理するMac用サーバーです。最高速度の数字より、自分の作業のどこで待っているかに合わせて設定してみます。

まず用意したモデルファイルを確認します

oMLXはApple Silicon搭載MacでMLXモデルを動かし、APIを通じてほかのアプリから使えるようにします。モデル名が同じでも、GGUFとMLXの変換版はそのまま置き換えられません。ダウンロード先の形式、量子化、必要な設定ファイルを先に確認します。

公式のmacOSアプリ、または別途インストールしたCLIを利用できます。ここでは、インストールとモデルの準備が済んでいることを前提にします。モデル用ディレクトリの下に各モデルのフォルダーを置くと、サーバーが見つけて一覧に表示します。

まず1モデル、1リクエストで接続します

最初はリクエストを1件ずつ処理し、メモリガードをsafeにします。最高速度を狙う設定ではなく、接続と回答を確かめるための出発点です。下のコマンドのモデルフォルダーを実際の場所に変更し、アプリでサーバーが動いている場合は先に停止してください。

別のターミナルで状態を確認します。healthyはサーバーの準備状態を示すもので、すべてのモデルの回答を検証した意味ではありません。loadingなら、固定したモデルの読み込み中かもしれません。準備ができたら127.0.0.1:8000/adminでモデルを選び、短い質問を送ってみます。

このMacからだけ接続できるサーバーを起動

omlx serve --model-dir "$HOME/.omlx/models" --host 127.0.0.1 --port 8000 --memory-guard safe --max-concurrent-requests 1

oMLXとMLXモデルを準備した後に実行します。モデルのダウンロードやインストールのコマンドは含みません。

サーバーの状態を確認

curl http://127.0.0.1:8000/health

サーバーを起動したターミナルはそのままにして、別のターミナルで確認します。

よく使うモデルだけを常駐させます

いつも使うモデルは固定し、たまに使うモデルには、未使用の時間が続くと解放するTTLを設定できます。メモリが足りなくなると、最近あまり使っていないモデルを解放する仕組みもあります。すべて固定すると、別のモデルへ切り替える余裕が減ってしまいます。

KVキャッシュは、すでに読んだ入力の計算記録です。よく使う部分はメモリに、保管する部分はSSDに置き、同じ入力の前半が現れたときに再利用します。新しい文書を初めて読む時間と、同じ文書について再び質問する時間は分けて測る必要があります。

Flash-Next の PLE SSD オフロードは、この KV キャッシュとは異なります。モデルの大きな埋め込みテーブルを SSD に配置する別のローダー経路で、Lightning MTP と併用設定が可能です。必要容量と速度は、実際のファイルサイズとページキャッシュの状態で変わります。

メモリ警告が出たら、まず文脈を短くします

Macのユニファイドメモリは、ほかのアプリとも共有しています。oMLXのメモリガードは、その時点の余裕と上限を見ながら新しい入力の処理を待たせたり、モデルを解放したりし、逼迫するとリクエストを中止することもあります。ガードを無効にしても、必要なメモリが減るわけではありません。

長い入力で止まったら、コンテキスト上限、同時リクエスト数、固定したモデルから減らしてみます。SSDキャッシュを増やすだけでは、モデルの重みや実行中の作業領域に必要なメモリまですべて賄うことはできません。

MTPとSpecPrefillは、待ち時間の別の部分を短縮します

Lightning MTPは、次のトークン候補を作って検証し、回答生成を速める仕組みです。対応するモデル構造、実際のMTP重み、モデル側の有効な設定がそろう必要があります。名前にMTPがあれば十分というわけではなく、候補を先読みする深さを増やせば必ず速くなるものでもありません。

SpecPrefillは、小さなドラフトモデルで長い入力の一部を選んで処理する実験的な機能です。同じトークナイザーを使う互換性のあるドラフトモデルが必要で、キャッシュなどを除いた処理対象が設定した長さを超えると動作します。短い質問や画像入力にも同じ効果があるとは考えないでください。

native MTP と、統合された Gemma assistant の Lightning 経路は、SpecPrefill と別々に設定できます。一方、外部 assistant を使用する VLM MTP は、現在 SpecPrefill と同時実行できません。モデル名だけでなく、どの実行経路かを先に確認してください。

両方の設定を有効にできても、すべてのリクエストで同じ効果が得られるとは限りません。それぞれ単独で変更した場合と併用した場合のログ、最初のトークンまでの待ち時間、生成速度、回答内容を比較します。入力の一部を選別するため、文書の細かな条件が抜けていないかも確認してください。

別のサーバーに移る前に残しておく記録

oMLXとMTPLXを比較するなら、まず変換版、コンテキスト、高速化の条件をそろえます。一方の繰り返し質問と、もう一方の初回の質問を比べると、キャッシュの差をエンジンの差と捉えてしまいがちです。モデルを切り替える使い勝手と、一つの回答の速さも分けて判断します。

自分の文書やコードで何度か試し、モデルファイル、ランタイムのバージョン、設定、時間を残します。一度の最高記録は、次の作業の性能を保証しません。接続を確認できたら、モデル別レシピで自分のMacに合う設定を続けて確認してください。

変更履歴

サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。

  1. oMLXのモデル管理・キャッシュ・高速化の案内を追加

    MLXモデルでサーバーを起動し、メモリガード・モデルの保持・キャッシュ再利用を確認する手順を追加しました。MTPとSpecPrefillの適用条件を分け、SSD上の入力キャッシュとモデル重みのオフロードを区別しました。