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

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

たとえ話：会社の出張規定

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

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

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

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

仕組み

3つの階層

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

信頼度スコアリング

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

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

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

CJK対応トークン推定

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

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

マルチバックエンド推論エンジン

ルーターの背後には、単一インターフェースで複数のバックエンドをサポートする統合推論エンジンがあります：

バックエンドオプション

llama.cpp — C++の主力エンジン。クロスプラットフォームのハードウェアアクセラレーション対応：

Apple Metal（macOS）
NVIDIA CUDA（Linux/Windows）
Vulkan（クロスプラットフォームGPU）
CPUフォールバック（任意のプラットフォーム）

mistral.rs — Rustネイティブエンジン。高度な機能：

ISQ（In-Situ Quantization）：前処理なしでモデルをオンザフライ量子化
PagedAttention：長いコンテキストの効率的なメモリ管理
Speculative Decoding：小型モデルでトークンをドラフトし、メインモデルで検証

OpenAI互換HTTP — OpenAI chat completions APIに対応する任意のサーバーに接続：

Exo分散クラスター
llamafile単一バイナリサーバー
vLLM、SGLangなどのサービングフレームワーク

MLX Bridge — Apple Siliconユーザー向けに、mlx_lm を呼び出すPythonサブプロセス：

API呼び出し不要のローカルリフレクション
エージェントのパーソナリティをファインチューニングするLoRAアダプター対応
リフレクションをローカルで実行することでAPIトークンを節約

InferenceManagerステートマシン

システムは一つのバックエンドを選んで固定するわけではありません。InferenceManagerが自動フェイルオーバー付きの優先チェーンを維持します：

優先1：Exo P2Pクラスター（複数マシンのGPUメモリをプール——235B+モデル実行可能）
     |
     v  （利用不可またはアンヘルシー？）
優先2：llamafile（単一バイナリ、ゼロインストール）
     |
     v  （利用不可？）
優先3：直接バックエンド（llama.cppまたはmistral.rsをインプロセスでロード）
     |
     v  （ローカルGPUなし / モデルが大きすぎ？）
優先4：OpenAI互換サーバー（外部vLLM、SGLangなど）
     |
     v  （外部サーバー利用不可？）
優先5：Cloud API（Claude——最終手段、常に利用可能）

各バックエンドは定期的にヘルスチェックされます。バックエンドがアンヘルシーになった場合（クラッシュ、メモリ不足、エラー返却）、マネージャーは自動的に次の階層にフォールダウンします。バックエンドが回復すると、昇格して戻ります。

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経由でのモデル管理

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

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

他システムとの連携

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

まとめ

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