コンテンツにスキップ

信頼度ルーターとローカル推論エンジン

スマートなモデル選択でAPI費用80%以上削減。


どの会社にも出張のランク制度があります:

  • エコノミー:国内便、ビジネスホテル。日常業務向け。
  • ビジネス:良い席、良いホテル。重要な顧客ミーティング向け。
  • ファーストクラス:CEOがFortune 500のパートナーと会う時だけ。

社内スタンドアップミーティングにファーストクラスで行く人はいません。出張デスクがその出張の重要度を見て、適切なランクを割り当てます。

DuDuClawの信頼度ルーターはLLMクエリのための出張デスクです——各クエリの複雑さを評価し、うまく処理できる最も安価なモデルにルーティングします。


階層 処理するもの 使用タイミング コスト
LocalFast 小型ローカルモデル(例:7Bパラメータ) 簡単なクエリ、挨拶、事実の検索 無料(ローカル計算)
LocalStrong 大型ローカルモデル(例:13B+パラメータ) 中程度の複雑さ、要約、翻訳 無料(ローカル計算)
CloudAPI Claude API 複雑な推論、創造的タスク、多段階分析 トークン従量制

クエリが到着すると、ルーターは軽量なヒューリスティックスで信頼度スコアを計算します:

クエリ到着
|
v
+-----------------------+
| トークン数をカウント | <-- 短いクエリは通常シンプル
| 複雑度キーワードを | <-- 「分析」「比較」「設計」
| 検出 | のようなキーワードは
| | 高複雑度を示唆
| CJK比率を推定 | <-- 中国語/日本語テキストは
| | 異なるトークン密度
| | (約1.5文字/トークン vs
| | 英語約4文字/トークン)
+-----------------------+
|
v
信頼度スコア(0.0 - 1.0)
|
+---> > 高閾値 --> LocalFast
|
+---> > 低閾値 --> LocalStrong
|
+---> <= 低閾値 --> CloudAPI

スコアリングは完全にルールベースです——どのLLMを使うか決めるためにLLM呼び出しは不要です。閾値とキーワードリストは設定可能です。

CJK(中国語・日本語・韓国語)ユーザーにとって微妙ですが重要な詳細です。英語テキストは平均約4文字/トークンですが、CJKテキストは平均約1.5文字/トークンです。100文字の日本語メッセージは約67トークンを消費しますが、100文字の英語メッセージは約25トークンです。

ルーターはクエリの複雑さを推定する際にこの違いを考慮します。CJK対応がなければ、日本語クエリの複雑さを体系的に過小評価し、能力が不十分なモデルにルーティングしてしまいます。


ルーターの背後にある推論エンジン

Section titled “ルーターの背後にある推論エンジン”

どんなモデルがあり、どう選び、どう入れるかは 53-local-models.md が担当します。ここではルーターが知っておくべきことだけを扱います。

出荷されているバックエンドは1つ

Section titled “出荷されているバックエンドは1つ”

OpenAI互換HTTP が、実際に出荷されている唯一の InferenceBackend 実装です。OpenAI chat-completions API を話すものなら何にでも接続できます:llama-server、Ollama、llamafile 単一バイナリサーバー、vLLM、SGLang。設定は inference.toml [openai_compat] です。

このページがかつて列挙していたインプロセスのバックエンドは、2026-09-29 に削除されました(wiki/reports/feature-audit-2026-09-29.md T1-D2/D3、T3-S4/S5):

  • llama.cpp(llama-cpp-2)— リリースビルドは metal/cuda/vulkan feature を一度もコンパイルしておらず、generate() は “not yet fully implemented” を返すスタブでした。
  • mistral.rs(mistralrs-core、ISQ/PagedAttention/Speculative Decoding)— 同様に、出荷バイナリに組み込まれたことがありません。
  • MLX bridge(mlx_lm Python サブプロセス)— 呼び出し元ゼロ。ここで説明されていた「API 呼び出し不要のローカルリフレクション」経路はコード上に存在しませんでした。
  • Exo 分散クラスター — リポジトリのどこにも設定例がなく、ユーザーからは到達不能でした。[openai_compat] base_url を Exo のエンドポイントに向ければ同じクラスターに届きます。

BackendType::LlamaCpp と MistralRs は既存の inference.toml が読めるようパース可能な値として残していますが、選択すると openai_compat を案内する BackendUnavailable が返ります。

v1.67.1 から書き込み時に検査します。

  • inference.update(ダッシュボードの推論ページ)は backend = "openai_compat" または空の値だけを受け付けます。空の値はキーを削除し、エンジンが自分で openai_compat を選びます。それ以外の値は何も書き込む前に拒否され、openai_compat を案内するメッセージが返ります。古いファイルを保存できるよう例外が1つあります。すでに保存されている削除済みの値をそのまま送り返した場合は受け付けるので、変更するまでの間もこのページで他の設定を保存できます。ページではその値をサポート終了と表示します。
  • agents.update は openai_compat 以外の [model.local] backend を拒否します(この検査は v1.67.1 以前からあります)。v1.68.0 からは社員の編集ページが [model.local] backend/context_length/gpu_layers を送らなくなりました。
  • [model.local] backend のデフォルト値、duduclaw onboard、duduclaw wizard、同梱のエージェントテンプレートは openai_compat を書くようになりました(以前は llama_cpp)。
  • 何も読まないフィールドをダッシュボードから外しました。推論ページの「記憶體上限」(max_memory_mb)、生成設定の「GPU Layers」「Context 大小」([generation] gpu_layers / context_size)、AI 従業員編集ページの「Context 長度」「GPU Layers」([model.local] context_length / gpu_layers)です。メモリ、GPU オフロード、コンテキスト長は外部サーバーが管理します。保存済みの値はファイルにそのまま残ります。

v1.68.0 から:

  • inference.update が成功すると gateway のキャッシュされた推論エンジンがリセットされ、次のチャネル返信とディスパッチから新しい設定が使われます(以前は約20の推論設定が再起動まで無視されていました)。ページにはエンジンを再読み込みしたと表示されます。
  • 推論ページでは [llamafile] を型付きの項目(enabled、dir、default_file、host、port、gpu_layers、context_size、extra_args)で編集でき、信頼度ルーター → 詳細で [router] local_tools と UCCI 関連のキー(ucci_fast_router、ucci_strong_router、ucci_observations、ucci_shadow_strong、ucci_shadow_max_inflight 1〜16、ucci_drop_stop_token)、[generation] capture_logprobs/capture_top_logprobs も編集できます。ページで llamafile の項目を空にしても保存済みの値は消えません。設定ファイルの詳細編集を使ってください。
  • max_memory_mb、[generation] gpu_layers/context_size、[embedding] は設定構造から削除され、inference.update は受け取っても無視します。

マネージャーは自動フェイルオーバー付きの優先チェーンを維持します:

優先1:llamafile(単一バイナリ、ゼロインストール)
|
v (利用不可?)
優先2:直接バックエンド(インプロセスの `InferenceBackend`。今日出荷されているものは無し)
|
v (ローカルGPUなし / モデルが大きすぎ?)
優先3:OpenAI互換サーバー(llama-server、Ollama、vLLM、SGLang …)
|
v (外部サーバー利用不可?)
優先4:Cloud API(Claude——最終手段、常に利用可能)

各階層は定期的にヘルスチェックされます。アンヘルシーになった場合(クラッシュ、メモリ不足、エラー返却)、マネージャーは自動的に次の階層へ落ち、回復すれば昇格して戻ります。


llamafile:ゼロインストール推論

Section titled “llamafile:ゼロインストール推論”

llamafileは特筆に値します。MozillaのプロジェクトでLLMモデルと推論エンジンを単一の実行ファイルにパッケージしたものです。DuDuClawはllamafileをサブプロセスとして管理します:

ユーザーがローカル推論をリクエスト
|
v
llamafileは実行中か?
|
+--+--+
| |
はい いいえ
| |
| v
| llamafileサブプロセスを起動
| ヘルスチェック待ち(レディウェイトポーリング)
| |
v v
クエリをlocalhost:{port}にルーティング
|
v
レスポンスを返却

マネージャーがフルライフサイクルを管理:起動、ヘルスモニタリング、停止。llamafileサーバーはlocalhost上にOpenAI互換APIを公開するため、ルーターは他のバックエンドと同様に扱います。

結果:macOS、Linux、Windows、FreeBSDなどで動作するポータブルなゼロインストールローカル推論。


最も直接的なメリット:Claudeのフル推論能力が不要なクエリはClaudeに送りません。「東京の今の時間は?」というクエリはローカル処理でコストゼロです。毎日数千のクエリで、80%以上の節約になります。

ローカルモデルはミリ秒で応答します(秒ではなく)。簡単なクエリでは、クラウドへのラウンドトリップを待たずに、ほぼ瞬時にレスポンスを得られます。

ローカルで処理されたクエリはマシンの外に出ません。機密データやコンプライアンス制限のある環境では、これが決定的な利点です。

クラウドAPIがダウン、レート制限、または低速の場合でも、ローカルモデルがシステムを稼働し続けます。多層フェイルオーバーにより、クエリを処理できるモデルが常に利用可能です。


推論エンジンはMCPツールで完全に管理できます:

ツール 用途
model_list ~/.duduclaw/models/ 内のGGUFファイルを一覧表示
model_load / model_unload モデルのロード/アンロードのライフサイクル管理
inference_status ロード中のモデル、ハードウェア、メモリ使用量、バックエンド種別
hardware_info GPU自動検出、VRAM、RAM、推奨設定
route_query 実際に生成せずルーティング判断をプレビュー
inference_mode 現在のモード(llamafile / direct / openai-compat / cloud-only)
model_search RAM条件でフィルタしてHuggingFace+厳選リポジトリを検索
model_download ~/.duduclaw/models/ へダウンロード(レジューム+ミラーフォールバック対応)
model_recommend ハードウェアに応じたモデル提案

  • アカウントローテーション:ローカル推論がクエリを処理すると、APIアカウントは消費されません。クォータの寿命が延びます。
  • CostTelemetry:各クエリがどの階層で処理されたかを追跡し、運用者が最適なコスト/品質バランスのための閾値調整を可能にします。キャッシュ効率が30%を下回ると、アダプティブルーティングが自動的にローカルを優先します。
  • 進化エンジン:ルーターの判断が予測エンジンの精度メトリクスにフィードバックされます。
  • Multi-Runtime:信頼度ルーターはランタイム層の下位に位置します——モデルを決定するのはルーター、CLIバックエンドを決定するのはランタイムです。

すべての質問が最も高価な回答に値するわけではありません。信頼度ルーターは、各クエリがうまく処理できる最も安価なモデルを確実に割り当てます——そしてマルチバックエンドエンジンが、ラップトップGPUから分散クラスターからクラウドまで、常にモデルが利用可能であることを保証します。