エージェント ナレッジ smart-routing

スマートルーティング——「先にルーティング、次に計算」（2026年8月）

単一バッチのうち3つの独立したプロジェクトに現れた、分野横断的なパターン：各作業単位を検査し、
それをこなせる最も安価なエンジンへ送る分類/ルーティング層——すべてを最も高価なエンジンに
通す代わりに。

パターン

まず分類し、次に振り分ける。各リクエスト/ページ/推論は、安価な「どのエンジンか？」の判定を
受けたのち、対応可能な最小のモデル/パーサーへ向かう。節約は重い経路へ送らないことから生まれる：
大半のユニットは安価なエンジンが処理し、本当に難しい裾野だけが高価なエンジンへ到達する。

3つのインスタンス（同じ形、異なる領域）

  1. モデルルーティング——NeMo Switchyard（NVIDIA-NeMo/Switchyard、Apache 2.0、Rust）。 OpenAI Chat / Anthropic Messages / OpenAI Responses の間を翻訳し、各リクエストをモデルのプール （vLLM、NIM、Ollama、任意のOpenAI互換エンドポイント）へルーティングする。組み込みルーター （リポジトリのルーティング表で確認済み）：llm_classifier（内容が弱/強ティアを決める）、 stage_router（会話シグナルで追加のモデル呼び出しなしに大半のターンをルーティング）、 エスカレーション（llm_classifier mode="escalation"——弱ティアを先に、判定役が昇格するかを 決める）、random（固定A/B分割）、さらに passthrough（単一ターゲット、ルーティング判断なし）。 LangChainはフロンティアモデルへ送るのを7%に絞ってコストを74%削減——6%の精度トレードオフを 伴う（145件のマルチターン Deep Agents タスク）。内部ベンチマークはClaude Opus 4.8単独の約1/3の コストでフロンティア級の精度を主張。（リポジトリが機構を裏付け——Apache 2.0、約755スター、 pre-alpha。74%/7%とOpusの数値はNVIDIAブログ由来で、30B-MoEのNemotron 3.5 Lightningと同時に 発表された。）
  1. ドキュメントルーティング——Firecrawl pdf-inspector（firecrawl/pdf-inspector、MIT、Rust）。 レンダリングせずにPDFの内部構造（フォントエンコーディング、テキスト演算子、画像カバレッジ） を読み、各ページを約10–50msでTextBased/Scanned/ImageBased/Mixedに分類する。テキストページは ネイティブ抽出、それ以外だけがOCRへ。約54%のテキストベースPDFのOCRをスキップすることが、 Firecrawlがホスト型パーサーを3.5–5倍速くした方法。Python（PyO3）/ Node（napi-rs）/ WASMバイン ディングと pdf2md / detect-pdf CLIを提供。opendataloader-benchで0.875。
  1. 推論エスカレーション——Needle 2（cactus-compute/needle、MIT）。4500万パラメータ / 14MB のモデルで、問題を関数呼び出しとして解き、較正済みの信頼度スコア付きの構造化JSONを返す。 低信頼度の結果はより大きなモデルへエスカレーション。セッション全体をローカル（約28MB RAM）で 実行するため、高価な経路は裾野だけでしか使われない。

なぜ重要か

LLM配信、ドキュメント解析、オンデバイスエージェント——3つの異なる領域だが同じ最適化：
高価なエンジン（フロンティアLLM / GPU OCR / クラウド推論）が見るべきは分布の裾野だけである。
マルチモデル・マルチパーサーのワークロードが増えるにつれ、「どのエンジンがどのユニットを処理
するか」はそれ自体が一つのレイヤーになる——ルーター所有者が握る新たな制御点だ。

ルーターロックイン地図（2026-08-13 検証済み）

「ロックインはどこで起きるか？」——4つのルーティング手法を、ルーターが握る3つのもの（ポリシー、
シグナル、カタログ）と照らして比較する：

  1. ホステッドアグリゲーター——OpenRouter（SaaS、約$100億評価、約1.5クアドリリオントークン/年）。 デフォルトは逆二乗の価格加重ルーティング（30秒の障害ウィンドウ付き）に、ツール呼び出し品質で プロバイダーを階層化する「Auto Exacto」ステップを加える。リクエストごとの provider オブジェクト で上書き可能（order、sort、only、max_price、allow_fallbacks）。トークンは転送価格 （「マークアップなし」）で、マージンは約5.5%のクレジット手数料 + 約5%のBYOK手数料。ロックイン = 1つのキー、1つの請求、そして自分が所有できないモデルカタログ + ルーティングポリシー。「Fusion」 マルチモデル扇出し（最大8モデル + 判定役）はプロプライエタリな付加価値で、独立テストでは単独の フロンティア呼び出しの約4倍のコストと計測された。
  2. ベンダールーター——NeMo Switchyard（NVIDIA、Apache 2.0）。推論スタック（NIM、vLLM）の上で ルーティング。NVIDIAは「チップの上のオーケストレーションソフトウェア」と位置づける。ロックイン = ルーティングがNVIDIAのアクセラレータ/NIMスタックに結合する。
  3. セルフホストOSSゲートウェイ——LiteLLM（MIT、約4万スター）。ルーター = model_group デプロイ メント間の負荷分散、フォールバック連鎖、リトライ、予算、レート制限、仮想キー。ベンダーロック インなし——「ロック」は自分自身の設定が制御点になることへ移る（Postgres + Redis 状態）。
  4. 信頼度ゲート付きエスカレーション——Needle 2（MIT）。エスカレーションする/しないの判断は、 モデル出力に埋め込まれた較正済み信頼度スコア。ロックイン = エスカレーションポリシーが信頼度 モデルに所有されること。プロプライエタリなら「いつフロンティアに課金するか」の判断は監査不能。

ロックインはどこで形成されるか——3つのベクトル、すべてルーティング判断そのもの：
(a) ポリシーの所有（LiteLLMではあなた、OpenRouter/Switchyardではベンダー）、
(b) シグナルの所有（Switchyardの分類器、OpenRouterのAuto Exacto階層、Needleの信頼度）、
(c) カタログ + 請求の所有（OpenRouterの70以上のプロバイダー + 1つの請求、NVIDIAのNIMカタログ）。
共有のルーティング設定標準はまだ存在しない——それぞれ独自のDSLを持つ（LiteLLM YAML、OpenRouter
provider オブジェクト、Switchyardのルーター型）。その断片化こそがロックイン面：ルーティングの
「MCP」がこれをコモディティ化するだろうが、まだ誰も出荷していない。

注視点