ハードウェア前提でLLMを選ぶ時代：モデル選定をSRE運用に変える

「最強モデル」より「最適適合モデル」

最近のコミュニティ動向で明確になったのは、モデル選定がハードウェア制約から切り離せなくなったことです。実運用では、ノートPC、エッジ端末、共有GPU、クラウドAPIが同時に動きます。この状況で「一番賢いモデルはどれか」だけを基準にすると、遅延・コスト・可用性のどれかが必ず破綻します。

問うべきは次です。

このタスクを、この遅延予算・メモリ制約・データ制約で処理する最適モデルはどれか。

これはMLの趣味ではなく、SREの設計課題です。

なぜ手動選定は破綻するのか

現場では「このモデルが速かった」「このベンチが強かった」という断片情報で選ばれがちです。しかし本番負荷はタスクごとに特性が違います。

入力トークン長（短文分類と長文要約で別物）
エンドポイントごとのSLO
データ外部送信可否
同時実行数と突発バースト
フォールバック許容度

この差をポリシー化しない限り、品質の揺れ・p95遅延悪化・予算超過が繰り返されます。

まず作るべき「モデルルーティング契約」

モデルを選ぶ前に、選択の条件を契約化します。最低限の軸は以下です。

タスク種別（要約/分類/コード生成/抽出など）
遅延予算（p50/p95）
必要コンテキスト長
データ滞留ポリシー
1リクエストあたりコスト上限
フォールバック順序と劣化時挙動

この契約があると、インフラ状態が変わっても選択ロジックを再現できます。

混在推論時代の容量設計

ローカル推論と外部APIを併用すると、スケジューリング難度が急上昇します。実務では3レーン化が有効です。

Lane A（ローカル/端末）: 高機密・短タスク・超低遅延
Lane B（社内GPU）: 中規模処理・安定スループット
Lane C（外部API）: 大規模文脈・突発高負荷

重要なのは、全レーンの遅延・失敗率・単価を同じ可観測基盤へ集約することです。分断監視だと、ルーティング改善が現実と乖離します。

サイレント劣化を防ぐ4つのガードレール

1. タスク別の品質下限を定義

安価なフォールバックへ切り替える際、最低品質を下回ったら自動で段階降格を止める必要があります。

2. p95起点のオートスケール

平均遅延が良くても、長文入力が増えた瞬間にp95が崩壊することは珍しくありません。判断軸は常にテイル遅延です。

3. メモリ余裕率チェック

端末/エッジ側はOOMが顕在化しやすく、可用性事故だけでなくユーザー信頼を失います。常時ヘッドルーム監視を必須化してください。

4. 劣化時の明示

フォールバック・要約短縮・出力切り詰めが起きた場合、クライアントへ明示する設計にします。黙って返すと業務判断リスクが増えます。

実例：サポートCopilot

問い合わせ対応支援では、短い意図分類・中程度のナレッジ統合・長いケース要約が混在します。

意図分類は小型ローカルモデル
ナレッジ統合は社内GPU
長文要約は外部API（予算上限つき）
外部失敗時は「簡易要約モード」に明示的降格

この構成ならSLAとコストを同時管理できます。

組織運用への落とし込み

モデルルーティングはAPI Gatewayポリシーと同じ扱いにすべきです。

バージョン管理する
テストする
変更レビューする
例外を監査する

基盤チームがテンプレートを提供し、プロダクトチームがタスク閾値を調整する分業が安定します。財務・セキュリティ部門には定期的に、コスト配分とデータ経路順守の報告を返すべきです。

90日導入ステップ

1〜2週: ワークロード棚卸しとリスク分類
3〜5週: ルーティング契約とテレメトリ実装
6〜8週: 品質下限と予算アラートを強制化
9〜12週: 実障害データでフォールバック最適化

まとめ

2026年のモデル選定は「推論品質の比較」ではなく「インフラ挙動の設計」です。ハードウェア前提のルーティングをSREとして運用できる組織が、安定性と経済性の両方で先行します。