ローカル推論とハイブリッド推論

すべてのプロンプトが、他社のデータセンターにあるフロンティアモデルを必要とするわけではありません。Bromure Agentic Coding は、Apple の MLX フレームワークを使って、オープンウェイトのコーディングモデルを Mac の GPU 上で直接実行できます。クラウドへの往復も、トークン単位の課金も、コードがマシンの外へ出ることもありません。ワークスペースは完全にオンデバイスで動作させることも、オンデバイスのセーフティネットを備えつつクラウドを使い続けることも、エージェントごとに両者を組み合わせることもできます。

ローカル推論はワークスペース単位の選択であり、Fusion とは直交する概念です。Fusion は 1 つのプロンプトに何個のモデルが応答するかを決め、ルーティングはどのバックエンドが応答するかを決めます。本章では、推論がどこで実行されるか、モデルカタログとダウンロードの仕組み、3 つのルーティングモードとハイブリッドポリシーエンジン、個々のエージェントをローカルモデルへ向ける方法、そしてエンジンの挙動を観察する方法を説明します。このペインのフィールドごとの設定リファレンスは ローカルモデル設定 にあります。

メモ: ここで説明する処理はすべて Mac ホスト上で実行され、VM の内部では実行されません。Virtualization.framework は Linux ゲストに GPU、Metal、MLX へのアクセスを一切与えないため、オンデバイス推論は macOS 上で行い、ワイヤ境界 越しにゲストから到達する必要があります。Apple Silicon（M1 以降）が必須です。これはアプリ本体と同じ要件です。

推論が実行される場所

エンジンはアプリに組み込まれており、インストールするものも、Python 環境も、Ollama・LM Studio・セルフホストの vLLM インスタンスといった外部サーバーを指定する必要もありません。セッションがオンデバイス推論を必要とすると、アプリはプライベートな MLX エンジンを起動し、ゲストのエージェントをそれに接続します。

エンジンの子プロセス

MLX エンジンは、アプリ自身のバイナリの監視下にある子プロセス（bromure-cli model _mlx-engine）として実行され、アプリ本体の内部では動作しません。これは意図的な分離です。Mac のメモリに収まりきらない大きすぎるモデルを読み込んでも、停止するのはエンジンの子プロセスだけであり、アプリや実行中の VM が停止することはありません。親プロセスはクラッシュしたエンジンを自動で最大 3 回まで再起動します。それ以降はあきらめ、ログに engine child crashed repeatedly — giving up (a model likely OOMs this Mac) と出力します。子プロセスはアプリの終了時に停止され、ハードクラッシュで取り残された孤児プロセスは次回起動時に回収されます。

1 つのエンジンが、開いているすべてのワークスペースにサービスを提供します。エンジンは 127.0.0.1 上でカーネルが割り当てるループバックポートにバインドします。0.0.0.0 にバインドすることは決してなく、慣例的な 11434 を使うこともありません（このポートは、別途インストールされた Ollama や LM Studio が動作し続けられるよう空けてあります）。エンジンは、ホストのユニファイドメモリから 16 GB を差し引いたメモリ予算（下限は 8 GB）の範囲内で複数のモデルを並行してロードし、各モデルを初回使用時に遅延ロードして、予算が逼迫すると最も長く使われていないモデルを退避させます。ワークスペースを開いたり閉じたりすると、実行中のエンジンは管理エンドポイントを通じてライブで再構成されます。再起動は不要です。

エンジンがウォームアップしている間、セッションウィンドウには ローカルエンジンを起動中… と表示するステータスピルが出て、エンジンがレディネスプローブに応答すると消えます。

ゲストがエンジンに到達する仕組み

VM 内のエージェントがエンジンと直接やり取りすることはありません。エージェントは合成ホスト https://bromure.llm（実在の DNS を持たない名前）を宛先とし、ホスト側の MITM プロキシがこれを傍受して、クラウドトラフィックに適用するのと同じ プロンプトインジェクションスキャン と トレースキャプチャ を適用し、リクエストをホスト上のエンジンへ転送します。したがってローカル推論は決して死角にはなりません。Anthropic への呼び出しと同じワイヤ境界を越え、同じ監査証跡に記録されます。

エージェントはセンチネルのモデル名 bromure-local に固定され、ホストはこれをワークスペースで現在アクティブなモデルに再マッピングします。アクティブモデルの切り替えは、エージェントを再起動しないホスト側の再マッピングです。エージェントは bromure-local を要求し続けるだけで、その背後に別のモデルが割り当てられます。

メモ: MLX エンジンがまだサポートしていないアーキテクチャのモデルは、明確で恒久的なエラー（「そのアーキテクチャ … はまだオンデバイスエンジンでサポートされていません — 別のモデルを選んでください」）で失敗します。これはクライアントエラーとして返されるため、エージェントがループで再試行することはありません。

モデルカタログ

カタログは、事前に変換済みの MLX モデルを厳選したリストであり、各モデルはエージェント型コーディングで最も重要な 1 点について検証されています。量子化モデルはツール呼び出しを頻繁に壊すため、カタログの各エントリにはツール呼び出し検証のバッジが付いています。エントリにはダウンロードサイズと最小ユニファイドメモリ要件も記録されており、ペインはこれを RAM フィットゲート に変換します。

ベースラインのカタログはアプリ内に同梱されているため、初日からオフラインでペインが機能します。起動時、アプリは https://dl.bromure.io/mlx/catalog.json から更新済みカタログを取得します。より新しいマニフェストはベースラインを完全に置き換えます（マージされません）。公開カタログから削除されたモデルはリストから消えます。ただし、すでにインストール済みの場合は例外で、インストール済みの追加項目として残ります。

ベースラインに同梱されるモデル

同梱カタログは、メモリ帯域ごとにそろえた Qwen3 コーディングモデルのセットです。4 つすべてがツール呼び出し検証済みです。

80 億パラメータのモデルはサポート対象のどの Mac でも動作します。4,800 億パラメータの mixture-of-experts モデルは 512 GB のマシン（M3 Ultra）を必要とし、そのため推奨としてはマークされていません。更新済みカタログは、アプリのアップデートなしに、より新しいビルドやより大きいビルドを追加することがあります。

バッジと RAM フィットゲート

ペインの各行（および bromure-cli model catalog の各行）には 2 つのバッジが付きます。

• サイズ帯 — 16 GB 以下を必要とするモデルは S、32 GB までは M、64 GB までは L、それを超えるものは XL。
• あなたの Mac のユニファイドメモリに対するフィット判定 — Fits、Tight、Won't fit。「Fits」は、モデルの最小要件に加えて OS やその他すべてのための 16 GB の余裕を必要とします。「Tight」はほとんど余裕なくロードされることを意味します。「Won't fit」はモデルの最小要件があなたのメモリを超えることを意味します。Won't-fit の行はグレーアウトされ、選択もダウンロードもできません。

たとえば Qwen3 8B モデル（最小 16 GB）は、16 GB の Mac では Tight、32 GB 以上では Fits と表示されます。Qwen3-Coder 30B-A3B（最小 32 GB）は 48 GB 以上で Fits と表示されます。

カタログ外のモデルを使う

カタログは厳選されたメニューであって、囲いではありません。すでに MLX 形式になっている Hugging Face リポジトリは、その org/repo 名でコマンドラインから取得できます（コマンドラインリファレンス を参照）。このようなモデルは未検証として扱われ、ツール呼び出しの保証も RAM フィットの保証もありません。GGUF 形式のリポジトリは、GGUF が Ollama と llama.cpp の経路であって MLX のものではないため、直ちに拒否されます。

That's a GGUF (Ollama/llama.cpp) model — Bromure serves MLX weights only.

モデルのダウンロードと保存

ウェイトは、組み込みの純 Swift 製ダウンローダーによって huggingface.co から直接取得されます。Python も、mlx_lm.convert も、いかなる変換処理もありません。ダウンローダーは Hugging Face API からリポジトリのファイル一覧を読み取り、各ウェイトファイルを .partial の一時ファイルにストリームし、アトミックに正しい場所へリネームします。リポジトリ内のドキュメント、画像、GGUF ファイルはスキップされます。開始前に、ディスク容量のプリフライトが実行され、ディスクを埋め尽くす代わりに早期に失敗します。

Not enough disk space: 40 GB free, but about 270 GB is needed.

モデルの保存場所

ダウンロードしたウェイトは、Application Support ディレクトリ配下の、リポジトリごとにフラットなレイアウトで配置されます。

~/Library/Application Support/BromureAC/models/<org>--<name>/

各ディレクトリには、モデルの config.json、その .safetensors シャード、およびトークナイザーが格納されます。ダウンロードはグローバルな副作用であり、すべてのワークスペースで共有されます。モデルを一度取得すれば、すべてのワークスペースで利用可能になります。他のツールによって ~/.cache/huggingface/hub にすでにキャッシュされたモデルは、ハードリンク経由でこのディレクトリに一度だけ移行されるため、二重にダウンロードされることはありません。

ペイン内のダウンロード状態

各モデル行のアクションコントロールは、その状態を反映します。

ダウンローダーはファイル単位で再開可能なため、中断された取得を最初からやり直す必要は決してなく、部分的なダウンロードが動作するインストールと取り違えられることもありません。最後のバイトが着地するまで、処理中を示すセンチネルファイルがそれを示します。

ヒント: 最初にダウンロードしたモデルは、自動的にワークスペースのアクティブモデルに設定されます。そのため、新しいワークスペースは「ローカルモデルなし」から「サービス提供可能」までワンクリックで到達します。

ワークスペースでローカルモデルを有効にする

ワークスペースブラウザでワークスペースを開き、ワークスペースを編集 をクリックして、ローカルモデル ペイン（ミント色の CPU アイコン）を選択します。ペインは最初は 1 つのスイッチだけで、ローカル推論をオンにすると初めてモードピッカーとモデルリストが表示されます。

1. ローカルモデルを有効化（「クラウドの代わりにこの Mac 上でコーディングモデルを実行します。」）をオンにします。これによりワークスペースのルーティングがクラウドから切り替わります。オフに戻すとクラウドが復元されます。
2. モード を選択します。
   • ローカル — 常にオンデバイス は、すべてのリクエストをこの Mac 上に留めます。ペインが述べているとおり、応答はプライベートですが低速で、メモリに収められるモデルによって制約されます。
   • ハイブリッド — クラウド、必要時にローカルへフォールバック は、通常どおりリクエストをクラウドへ送り、クラウドに到達できない場合にのみオンデバイスのモデルへフォールバックします。クラウドの速度と品質を得ながら、ローカルのセーフティネットを備えます。
3. モデルリスト（モデル · N GB ユニファイドメモリ という見出しで、N はあなたの Mac のメモリ）で、モデルを Download し、その左のラジオドットでアクティブとして選択します。グレーアウトされた行は、あなたの Mac が持つよりも多くのメモリを必要とします。
4. 保存 をクリックします。

ルーティングモードとアクティブモデルの選択は保存時に永続化されます。ダウンロードはグローバルであるため、保存の有無にかかわらず直ちに実行されます。選択したモデルを合わせると、あなたの Mac のメモリに近いかそれ以上のメモリが必要になる場合（エンジンはそれらを並行してサービス提供するため、メモリは加算されます）、ペインは警告を表示し、1 つを外すか、より小さいモデルを選ぶよう求めます。

フィールドの全リストとデフォルトは ローカルモデル設定 にあります。

ルーティング: クラウド、ローカル、ハイブリッド

ルーティングは、エージェントの LLM トラフィックをどのバックエンドが処理するかについての、最上位のワークスペース単位の選択です。3 つの値があります。

ローカル または ハイブリッド を選択すると、MITM 傍受経路が自動的に有効になります。そのために別のスイッチを切り替える必要は決してありません。応答された各ターンは、どのバックエンドが応答したかを記録する served-by マーカー（cloud または local-<model>）とともに トレース にタグ付けされます。これをトレースインスペクタで読み取ることで、ハイブリッドセッションが実際にどこへ行ったのかをターンごとに確認できます。

ルーティングはペインで設定されるワークスペース単位のデフォルトですが、実行中の VM に対してコマンドラインの bromure-cli vm routing からも変更できます（コマンドラインリファレンス を参照）。

メモ: ローカルルーティングは、エージェントのトラフィックのうち Anthropic および OpenAI のホスト（および bromure.llm センチネル）向けのものをエンジンへ再ルーティングします。それ自体がすでに実在のクラウド認証情報に固定されているエージェントを乗っ取ることはありません。たとえば、同じワークスペースを共有するサブスクリプションの Claude エージェントは、その実在のクラウドトラフィックを維持します。特定の 1 つのエージェントをワークスペースのルーティングにかかわらず強制的にローカルにするには、後述のそのエージェント自身の ローカルモデル 認証モードを使用します。

ハイブリッドフォールバックポリシー

ハイブリッドは単一のスイッチではなく、コーディングの軌跡をモデルの途中入れ替えで壊さないように調整された、小さなポリシーエンジンです。すべての決定はセッションの境界で行われ、その後はスティッキーになります。会話が一度あるバックエンドにルーティングされると、そのセッションの残りの間はそこに留まります（コヒーレンスガード）。

ローカルへのフォールバックを引き起こす条件

新しいセッションについては、最初に一致したルールが勝ち、その順序は次のとおりです。すでに固定済みのスティッキーセッション、枯渇したクラウドトークン予算、不健全なクラウド（ヘルスゲート）、分割比率の割り当て、そしてそれ以外はクラウド。すでにクラウドへ処理中のリクエストの途中では、次の 2 つがローカルモデルでの即時リプレイを強制し、そのセッションを生存期間中ローカルに固定します。

• ハードエラー — 接続の拒否やタイムアウト、またはプロバイダーからの HTTP 429、529、5xx。
• ソフトデッドラインの超過 — TTFT 予算（デフォルトで 5 秒）以内に最初のトークンが返らない。

その下には、保守的なヘルスゲートがあります。クラウドは、直近のおよそ 10 リクエストで少なくとも 3 回失敗した場合、または TTFT の指数加重移動平均が 8 秒を超えた場合に不健全とマークされ、3 回のクリーンで高速なプローブが成功して初めて回復します。クラウドが不健全な間、新しいセッションは、各セッションが先にソフトタイムアウトのペナルティを払うことなく、直接ローカルへ向かいます。バックエンド同士が競争させられることは決してありません。投機的なヘッジも二重の支出もなく、フォールバックは実際のトリガーが発生した後にのみ発動します。

調整可能なつまみ

3 つのつまみが公開されており、いずれも実行中の VM に対するコマンドライン経由でのみ操作できます（コマンドラインリファレンス を参照）。これらはワークスペースごとに永続化されますが、ルーティングが ハイブリッド でない限り無視されます。

ヘルスゲートの内部処理（8 秒の EWMA しきい値、失敗ウィンドウ、回復プローブ数）は固定であり、ユーザーが調整することはできません。

エージェントのバックエンドとしてのローカルモデル

ルーティングはワークスペース全体の軸ですが、単一のエージェントをローカルエンジンへ向け、ワークスペースの残りをクラウドに残すこともできます。ワークスペースの エージェント タブでは、各エージェント（Claude Code、Codex、Grok）に認証モードピッカーがあり、その選択肢には ローカルモデル が含まれます。これを選んでインストール済みのモデルを選択すると、そのエージェントは、エンジンが無視するダミーのクラウドキーを使って完全にオンデバイスエンジンに対して動作します。MITM は、クラウドトラフィックに適用するのと同じ保護を適用します。

これにより混在ワークスペースが可能になります。たとえば、サブスクリプションで動く Claude Code と、ローカルモデルで動く Codex を並べることができます。ワークスペース全体のローカルルーティングがクラウドエージェントの実在のトラフィックを乗っ取ることは決してなく、エージェント単位のローカルモードが他のエージェントに漏れることもありません。ローカルモデル ペインでローカル推論をオン・オフに切り替えると、アプリは各エージェントの認証モードを自動的に同期します。

Fusion におけるローカルモデル

ローカルモデルは、マルチモデル合成機能である Fusion の正当な参加者でもあり、そこでは 2 つの役割のいずれかを担えます。

• レッグとして。 融合するモデル の下で ローカルモデル をチェックし、インストール済みのモデルを選ぶと、そのドラフト回答が Claude、Codex、Grok と並んでパネルに加わります。あなたの Mac 上で動作するため、限界コストゼロで有能な追加のレッグになります。
• ジャッジとして。 Fusion のジャッジプロバイダーとして ローカル を選ぶと、分析と合成の段階を完全にオンデバイスで実行し、判定ステップ全体をクラウドから切り離せます。

どちらの役割も、少なくとも 1 つのダウンロード済みローカルモデルを必要とします。それまでは、Fusion ペインの対応する行はグレーアウトされ、ここで先に 1 つダウンロードするようヒントが表示されます。パネルの完全なワークフローは Fusion を参照してください。

ツール呼び出しの修復

エージェント用途における量子化モデルの支配的な失敗モードは、エージェントが実行できる構造化された呼び出しの代わりに、ツール呼び出しをプレーンテキストとして出力してしまうことです。修復プロキシ がエンジンの前段に位置し（ゲストと MITM のローカル経路は、いずれも素のエンジンではなくこれを指しています）、これらのケースを透過的に救済します。

修復プロキシは各応答について出力をバッファリングし、モデルが呼び出しを漏らしうる多数のアドホックな形状を再パースします。次のようなものが含まれます。

<function name="write_file" arguments='{…}'>
<tool_call>{…}</tool_call>
[{"name": "…", "parameters": {…}}]

さらに Qwen3-Coder のネイティブ形式 <function=Name><parameter=k>v</parameter></function> や Gemma のチャネル形式も含みます。見つけたものから適切なツール利用ブロックを合成し、メッセージをエージェントのネイティブなワイヤ形状のプロトコル準拠 SSE として再出力します。また、行き詰まった前置き（モデルがアクションを説明し「では、ファイルを作成します:」と述べたのに、ツールを一度も呼び出さずにターンを終えてしまう状態）も検出し、欠落した呼び出しを回復するために最大 2 回まで再プロンプトします。ツールが宣言されているときは、常にシステムプロンプトにツール形式のリマインダーが付加されます。

修復はローカル推論では常に有効で、設定は不要です。エンジンの問題はワイヤネイティブなエラーボディに変換されるため、エージェントは汎用的な失敗ではなく本当の理由を表示します。たとえば次のようになります。

Local inference engine unreachable (starting up, reloading a model, or stopped) — retry in a moment.

エンジンの監視

Window メニューにある 2 つのウィンドウで、Console.app を開かずにオンデバイス推論を観察できます。

推論メトリクス

Window → Inference Metrics… は、ライブのテレメトリパネル（ウィンドウタイトル Inference Metrics）を開きます。ラベル Local inference とエンジンのループバックアドレスが見出しに表示されます。エンジンの Prometheus メトリクスをカード（Decode tok/s、Prefill tok/s、Running、Waiting、In flight、Avg latency、Cache hit、Metal mem、Gen tokens、Prompt tokens）にパースし、さらに Loaded models リストと、生のテーブルを表示する All metrics 開示要素を備えます。

このウィンドウは 5 秒ごとに、しかも開いている間だけポーリングします。デコード率とプレフィル率は設計上、生涯累積の比率であるため、秒単位でぶれる差分ではなく安定した平均として読めます。エンジンが停止しているとき、パネルは engine not reachable と表示し、長い生成の間は一時的に engine busy (timed out) と表示することがあります。

推論エンジンログ

Window → Inference Engine Log… は、エンジン子プロセスの出力と親プロセスのライフサイクルイベント（モデルのロード、「serving」、リクエストごとの統計、および OOM・クラッシュ・再起動・ロードエラーのいずれか）のライブテール（ウィンドウタイトル Inference Engine Log）を開きます。行は色分けされます（失敗は赤、健全なイベントは緑、警告はオレンジ、進行中の作業は青）。ツールバーには Filter… フィールド、Auto-scroll チェックボックス、Copy、Clear があります。まだ何も起きていないときは No inference-engine activity yet と表示されます。バッファは 5,000 行で上限が設けられたインメモリのリングであり、すべての行はアプリの stderr にもミラーされるため、ターミナルから bromure-cli を起動すれば永続的なコピーが得られます。

コマンドラインリファレンス

モデルとルーティングのコマンドは、実行中のアプリのコントロール API と通信するため、アプリ（またはそのエージェント）が実行されている必要があります。特定の VM に作用するコマンドは、末尾に <vm> 引数（VM の id またはワークスペース名）を取ります。ワークスペースごとの永続的なデフォルトは、上記の GUI ペインで編集します。これらのコマンドはライブセッションに作用します。周辺のコマンドセットについては 自動化と CLI を参照してください。

モデル管理:

bromure-cli model catalog [--all] [--offline]
bromure-cli model pull <catalog-id | org/repo>
bromure-cli model ls
bromure-cli model use <catalog-id | org/repo> <vm>
bromure-cli model rm <catalog-id | org/repo>

実行中の VM のルーティングとハイブリッドポリシー:

bromure-cli vm routing cloud|local|hybrid <vm>
bromure-cli vm hybrid budget <tokens> <vm>
bromure-cli vm hybrid ttft <seconds> <vm>
bromure-cli vm hybrid split <0-100> <vm>
bromure-cli vm fusion enable|disable <vm>

vm routing はバックエンドモードを設定します。3 つの vm hybrid つまみはフォールバックポリシーを調整します（そしてルーティングがハイブリッドのときにのみ効きます）。vm fusion は直交するマルチモデルパネルを有効にし、Fusion で解説しています。

内部診断コマンド

これらの隠しサブコマンドは開発とトラブルシューティングのために存在し、日常のワークフローの一部ではありません。エンジンの子プロセス自体は、アプリによって bromure-cli model _mlx-engine --config <path> として生成されます。

コマンド	目的
bromure-cli model _mlx-serve <repo>	1 つのモデルのインプロセス MLX サーバーを起動してブロックし、curl テスト用にそのポートとキーを出力します。
bromure-cli model _mlx-selftest <repo>	モデルをロードし、1 回生成して、TTFT とデコード tok/s を出力します。
bromure-cli model _repair-serve --engine-port <port>	実行中のエンジンに対してツール呼び出し修復プロキシを単独で実行します。
bromure-cli model _tc-test <path>	保存されたテキストファイルに対してツール呼び出し救済を実行し、漏れた呼び出しの抽出を確認します。
bromure-cli model _spec-bench <main-repo> --draft <draft-repo>	モデルペアについて投機的デコーディングのオフとオンをベンチマークします。

パフォーマンスの見込み

オンデバイス推論は速度をプライバシーとコストと引き換えにしており、そのトレードオフは現実的です。それに応じて期待値を設定してください。

• スループットはモデルとチップに比例します。 Qwen3 8B のような小さいモデルは、サポート対象のどの Mac でも軽快です。大きな mixture-of-experts ビルドはより低速で、はるかに多くのメモリを必要とします。Inference Metrics ウィンドウは、あなたの ハードウェアでの実際のデコード率とプレフィル率を表示します。計画の基準にすべき正直な数字です。
• 最初のリクエストはモデルロードのコストを払います。 コールドなエンジンはウォームアップ中に ローカルエンジンを起動中… と表示します。大きなウェイトは、最初のトークンが現れる前にメモリへロードするのに実際の時間がかかります。以降のリクエストはこれをスキップします。
• マルチターンのエージェントループは最初のターン以降、安くなります。 エンジンは会話ごとのプレフィックス KV キャッシュ（モデルあたり最大 4 つのセッションスロット）を保持するため、各エージェントターンは書き起こし全体ではなく新しいトークンだけをプレフィルします。サイドチェーンがメインの会話のキャッシュを退避させることはありません。
• 生成は直列化されます。 エンジンは一度に 1 つの生成を実行するため、複数のビジーなセッションは、真に並行して実行されるのではなく GPU を共有します。
• 推論モデルは静かに考えます。 <think> ブロックを出力するモデルについては、そのブロックは常に、回答がエージェントに届く前に除去されます。書き起こしの肥大化なしに品質だけが得られます。

ヒント: ローカルモデルが遅く感じられたり停止したりする場合は、まず Inference Engine Log ウィンドウを開いてください。モデルのロード、退避、OOM 再起動、非サポートアーキテクチャのエラーはすべて、そこにプレーンテキストで現れます。エージェント側から推測するよりも速いです。