Inklingを使う前に作る、キャッシュ込みLLMルータの3層設計

LLMルータを「難しい仕事を強いモデルへ送る分類器」として作ると詰まる。足すたび、料金、待ち時間、権限、キャッシュが変わる。選ぶべきなのは、実行を最後まで戻せる運転条件だ。

7月15日にThinking Machinesが公開したInklingは、総パラメータ975B、推論時に有効になるのは41BのMoEモデルだ。最大100万トークンの文脈と推論の努力量を調整するつまみも持つ。選択肢が増えると、単一モデルのベンチだけで呼び先を決める設計は先に寿命が来る。

公式発表: https://thinkingmachines.ai/news/introducing-inkling/

値札で送ると、キャッシュを捨てる

IBM Researchが同日に出したルーティングの検証がかなり具体的だった。同じCodeActエージェントでAppWorld Test Challengeの417タスクを走らせると、Claude Sonnet 4.6は合計79ドル、GPT-4.1は155ドルだった。1タスクあたりでは0.19ドルと0.37ドル。後者のほうが入出力の単価は低いのに、ほぼ2倍になった。

理由は入力キャッシュだった。エージェントはシステムプロンプト、ツール定義、作業ログを何度も送る。料金表だけを見ると、この再利用分を「どのモデルに残すか」で失う。自分はルータのログに cache_read_tokens と同一セッションの切替回数を先に出す。見えないと、節約したつもりで会話を温め直してるんだよね。

検証の出典: https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt

これは417タスク、そのエージェント、そのキャッシュ条件での結果だ。ただ、ルータの評価に実効コストを入れないと比較にならない。

実装は選択器より先に、3層へ分ける

モデル名を返す関数だけでは足りない。自分なら3層に分ける。

1. 実行可能性層: データ所在地、ツール権限、入出力、文脈上限で候補を絞る
2. 運転層: キャッシュ命中率、待ち時間、キュー、残予算で並べ替える
3. 復帰層: タイムアウトやスキーマ不一致から、どこまで引き継ぐかを管理する

Inklingのように長い文脈と努力量のつまみを持つモデルは、2層目に効く。ただし100万トークンを受けられることと、毎回送ることは別だ。作業ログが長いエージェントでは、努力量を下げるより、同じモデルに文脈を残したほうが安く終わる。

type RunState = {
  taskId: string
  policy: "jp-only" | "standard"
  cacheKey: string
  checkpoint: { messages: Message[]; toolResults: ToolResult[] }
}

function candidates(s: RunState, live: LiveMetrics) {
  return registry
    .filter(m => m.policy.includes(s.policy))
    .filter(m => m.context >= tokenCount(s.checkpoint.messages))
    .map(m => ({
      model: m,
      score: live.cacheHit(m, s.cacheKey) * 40
        - live.p95Latency(m) * 0.02
        - live.effectiveCost(m, s) * 10,
    }))
    .sort((a, b) => b.score - a.score)
}

重要なのは係数じゃない。checkpoint を会話IDに閉じ込めず、メッセージとツール結果として持つ点だ。保存しておけば、APIが落ちても未確定の書き込みを繰り返さず別モデルへ渡せる。決済やデプロイには冪等キーも付ける。ここを後回しにすると、事故が広がる。

「難易度」は実行前には分からない

要約なら軽量、実装なら大型、と決めたくなる。でも契約の要約が検索や権限確認を呼び、修正が重なることもある。最初のプロンプトだけでは実際の難しさは見えない。

IBM Researchの比較でも、難易度ベースより、コスト・精度・レイテンシを同時に最適化した構成のほうが運転点を広く取れた。レイテンシ重視の構成はOpus単独比で精度84%、コストを21%減、待ち時間を9%減。ルータ自身は1タスク約6ms、メモリ約2KBだった。観測値を実行中に更新できるかが効く。

最初の版では切替回数に上限を置くのが効く。何度も乗り換えると、キャッシュも原因の切り分けも壊れる。自分は「ツール実行前だけ切替可」「実行後は次のチェックポイントまで固定」から始める。

新モデルの価値は、追加できることにある

Inklingはオープンウェイトで微調整でき、テキスト・画像・音声を扱える。順位だけを追うより、既存の実行面にどう安全に差し込めるかを先に見る。対象タスクを絞り、実効コストと復帰率を取る。そこで初めて比較が始まる。

モデルが増えるほど、ルータは振り分け器では済まない。キャッシュを残し、制約を守り、同じ副作用を繰り返さない実行制御になる。ログにキャッシュ読み取り、モデル切替、チェックポイントからの復帰回数を出す。この3つが取れていれば、新モデルを試すたびに運用が強くなる。