AI省エネ・モデルルーティング編

原案台帳は、分類・軽量モデル・上位推論・ローカル処理・キャッシュ等を組み合わせた費用最適化をEA-018の対象とする。公開後アップデートでは「最安モデルへ送る」だけではなく、品質・金銭コスト・遅延・可用性・policy・計算/電力効率を同時に扱うrouting/control planeとして整理する必要がある。特に、モデル単価の低下を省エネと同一視せず、model selection、cache、local/offline処理、fallback/retry、energy measurementを別々の制御面として扱う。

Enterprise AI Core / provider mapping / interoperability / implementation / benchmark / cost engineering / sustainability / non-LLM control plane

• workloadごとに強いモデル固定ではなく、軽量モデル・上位モデル・local処理等を選択するroutingは、受入品質を保ったまま費用/計算量を削減できるか。
• managed router、learned router、rule/cascade router、gateway/load-balancerは何を同じものとして扱え、何を分離すべきか。
• monetary cost、latency、energyは相関し得るが同一指標ではない。法人運用で「省エネ」をどう測定可能にするか。
• cache/fallback/retry/model refreshによってroutingの品質・費用・energy効果が変動する場合、どの観測値を保持すべきか。

• Routingはモデル選択ではなくcontrol planeである。 法人向けには少なくとも eligibility filter → cache/local shortcut → router decision → selected model/runtime → fallback/retry → result/trace → eval feedback の連鎖で記述する方が実態に合う。
• 強いモデル固定は常にPareto最適ではない。 RouteLLM/FrugalGPTは、workloadを難易度・confidence等で分け、弱/安価modelを使える問い合わせへ割り当てることでcost-quality frontierを改善し得ることを示す。
• managed routerと自作routerを分離する。 managed routerはmodel pool、region、deployment、tool/context capability等のavailability gateを持つ。自作/OSS routerは制御自由度が高いが、モデル能力metadata、pricing、health、fallback、security policy、driftを運用者が管理する必要がある。
• cost、latency、energyは別目的関数。 安価なAPIが必ずしも低energyではなく、短いlatencyも低energyを保証しない。energy claimは、可能なら同一task/hardware/software条件の実測値を使う。
• cacheはrouting効果を変える。 prompt cacheは同一model/prefixの再利用に依存するため、per-turn routingでmodelが揺れるとhit benefitを失う場合がある。router評価にはmodel-selection distributionとcache-hit/writeを同時記録する。
• local処理もcandidate routeの一種として扱えるが、前提が異なる。 EA-009/010のself-host/edge manifestを参照し、data locality、offline、hardware capacity、quantization品質を通過したtaskだけをlocal route候補にする。cloud modelと単価だけで比較しない。
• router自身もdriftする。 candidate model、version、price、region、tool support、rate limit、traffic mixが変化すれば最適routingは変わる。固定導入ではなく再評価loopが必要。

• Router misclassification: 難しいtaskを弱modelへ送りaccepted qualityを落とす、または容易taskを上位modelへ送り節約を失う。
• Domain shift: router学習/benchmarkと実workloadが異なり、specialized categoryだけ劣化する。
• Capability mismatch: context window、structured output、tool calling、vision等の必要能力を満たさないmodelを選択する。
• Policy mismatch: region/data-zone/provider/model allowlistに違反する候補をpoolへ入れる。
• Cache fragmentation: selected modelの変動でprompt cache hitが落ち、想定したcost/latency削減が失われる。
• Retry/fallback amplification: 一度のrouting失敗が複数model attemptへ増幅し、tail cost/latency/energyを悪化させる。
• Price drift / model refresh: provider価格やrouting pool更新で過去の最適点が無効になる。
• Energy opacity: managed APIではrequest単位のphysical energyを公開しない場合が多く、token costからjouleを推測で確定しない。
• Benchmark transport risk: RouteLLM/FrugalGPT等の公開benchmark上の節約率を自組織taskへ保証値として転記しない。
• Rebound effect: 1件あたりを安くしても総呼出量が増えれば総費用/総energyが減らない。省エネはper-requestだけでなくperiod totalも見る。

• provider / region / deployment type / account entitlement
• candidate model availability and lifecycle
• model subset / same-family restriction where applicable
• context window / modality / tool / structured-output compatibility
• data residency / policy allowlist
• quota / rate limit / capacity
• local hardware/runtime/quantization availability
• prompt-cache support, prefix requirements, TTL, cache-write/read pricing
• routing mode and router version

• Learned two-model router: research + OSS implementation (RouteLLM).
• Cascade/router optimization: research evidence (FrugalGPT).
• Managed production routing surface: implemented in AWS Bedrock and Microsoft Foundry; exact pool/regions/version are PRODUCT_VOLATILE.
• Gateway/load-balancing router: maintained OSS ecosystems (e.g. LiteLLM) implement latency/cost/usage/fallback strategies;これらは「task能力を予測するrouter」と「deployment load balancer」を同一視しない。
• Energy-aware routing: measurement initiatives and research direction exist, but provider横断でrequest単位energyを同じ方法で取得できる共通production standardは今回確立できず UNKNOWNを残す。

Router評価はfixed-model baselineと同一代表workloadで行い、少なくとも次を同時記録する。 - accepted task rate / critical-category failure rate - selected-model distribution by workload category - monetary cost per accepted task; p50/p95/p99 - latency p50/p90/p95/p99 - retry/fallback count and amplification - cache hit/write tokens where available - quota/rate-limit/error behavior - local route rate where applicable - measured energy per accepted task (J or Wh) only when測定境界・hardware・software・taskが固定される場合 - period total cost / total energy / total accepted tasks 単一の「省エネscore」へ圧縮せず、quality thresholdを先に置いてPareto frontierで比較する。

• Security/Privacy: router前にpolicy eligibility filterを置き、機密taskを未承認provider/modelへrouteしない。routing decision自体へprompt全文を不要に永続保存しない。
• Audit: request ID、router version/config、eligible pool、selected model/version、routing mode/score（取得可能範囲）、fallback attempts、cache usage、latency、cost、policy decisionを記録。hidden chain-of-thoughtは監査要件にしない。
• Cost: router overhead、underlying model charge、cache write/read、retry/fallback、gateway/runtimeを含めEA-017のCOST_PER_ACCEPTED_TASKへ統合。
• Operability: shadow/canaryで導入し、critical taskにはdirect fixed-model routeまたはhard floorを残す。model/provider更新時は同じfixtureでregressionを再実行する。
• Sustainability: monetary priceをenergy proxyとして確定しない。実測不可ならenergyはUNKNOWN/UNMEASUREDとし、compute tier/model size等は補助説明に留める。

「モデルルーティングは、すべての要求を最上位モデルへ送る代わりに、要求ごとの必要能力や組織ポリシーに応じて候補を選び、品質条件を満たす範囲で費用・遅延・計算資源を最適化する制御層として利用できる。ただし、公開benchmarkやベンダー公称の節約率は自組織workloadの保証値ではない。候補model、価格、tool/context対応、region、cache、fallbackが変われば効果も変わるため、固定baselineに対する継続評価が必要である。金銭コストの低下をそのまま省エネとみなさず、energyを主張する場合は測定境界を明示した実測値を用いる。」

将来Workでは次を優先する。 1. ROUTING_POLICY_RECORDを作成: policy_id / router product+version / allowed models+versions / region / routing mode / quality floor / direct-route exceptions / fallback chain / cache policy / local-route eligibility / cost budget / energy metric availability / owner / review date。 2. EA-016のEVAL_CASE_RECORDとEA-017のWORKLOAD_COST_PROFILEを結合し、router導入前後を同じfixtureで比較する。 3. Azure Foundry Model Router、Amazon Bedrock Intelligent Prompt Routing、custom RouteLLM/LiteLLM系を同じcomparison matrixへ置く。ただしmanaged ML routerとload-balancer/gatewayを別classにする。 4. 公開直前にcandidate pool、region、router version、pricing、tool/context support、cache仕様を再採集する。 5. energy比較が必要な章ではMLPerf Power/AI Energy Scoreのmethodologyを参照し、cloud proprietary APIについてrequest-level jouleが公開されない場合は推測で埋めない。

• provider横断でcomparableなrequest-level energy telemetryを法人ユーザーが取得できる標準surfaceは今回確立できない。
• managed router内部のquality predictor/training data/scoreの完全な透明性はproviderごとに異なり、公開仕様以上はUNKNOWN。
• router導入による実組織TCO・total-energy削減率はworkload mix、traffic volume、fallback、cache、pricingに依存し、外部研究値で閉じない。
• local/cloud hybrid routingにおけるdata residency・security approvalはorganization-specific。

• routingを一つの万能optimizerとせず、quality/cost/latency/policy/energyを分離した評価設計を確立した。
• learned/cascade/managed/gateway routerの実装状態と境界を一次資料・原著研究・OSSで裏付けた。
• monetary costとenergyを分離し、実測可能時のenergy評価方法と未測定時のUNKNOWN規則を定めた。
• cache、fallback、model refresh、policy、local routeを将来Workが実測できるTEST_PROFILEへ落とした。

BOUNDED_CLOSE: EA-018