なぜ単一モデル運用が破綻したのか
- 年末から 2026 年初頭にかけて、私たちが見てきた現場では"すべてを 1 つのフラッグシップ LLM で賄う"という構成が急速に崩れた。最大モデルを常時叩き続けると、GPU 時間の 60〜70% が短文応答に浪費され、NIM コンテナが返す p95 レイテンシは SLO を容易に割る。代わりに、タスク特性に応じて Llama-3.3-70B・Mixtral-8x22B・Nemotron-4 340B を使い分けるマルチモデル構成が現実解になっている。NIM は各モデルを OpenAI 互換 API でラップしてくれるため、ルーティング層側は HTTP で軽く剥がすだけで済む。
3 モデルの役割分担
Llama-3.3-70B は汎用的なチャット応答・要約・軽い分類に最適で、H100×2 または H200×1 の NIM で p50=180ms 付近を安定して出せる。Mixtral-8x22B は MoE 構造ゆえにアクティブパラメータが 39B 程度で済み、コード生成と多言語応答で費用対効果が高い。Nemotron-4 340B は推論・複数ステップの計画・長文の厳密な構造化出力に回す最上位層で、H200×8 または B200×4 の NIM を専有させ、レイテンシよりも品質を優先するワークロードに絞る。この 3 層に振り分けるだけで、GPU 費用が前月比で 38% 削減できた事例もある。
ポリシールーティング層の構造
ルーティング層は 3 つの入力を見る：タスクカテゴリ（分類器の出力）、SLO ラベル（realtime / batch）、ユーザー階層（free / pro / enterprise）。出力は NIM エンドポイントの URL と model 名だ。擬似コードで書くとこうなる。
```python def route(req: ChatRequest) -> NIMTarget: if req.slo == "batch" and req.tokens_out > 2048: return NIM_NEMOTRON_340B if req.task in {"code", "multilingual"}: return NIM_MIXTRAL_8X22B if req.tier == "enterprise" and req.needs_reasoning: return NIM_NEMOTRON_340B return NIM_LLAMA_33_70B ```
重要なのは、フォールバック経路を必ず用意することだ。Nemotron NIM が 503 を返したら Llama に落とす、Mixtral が過負荷なら Llama に落とす、というカスケードを Envoy / Kong 側で宣言的に書いておくと、1 モデルが死んでも全体停止を避けられる。
計測：どのメトリクスを見るか
NIM は Triton ベースなので `nv_inference_request_duration_us`、`nv_gpu_utilization`、`nv_energy_consumption` が Prometheus に出る。ルーティング層側では per-route の成功率・平均入出力トークン数・$/1M tokens を別途ダッシュボード化する。Mixtral ルートだけ出力トークンが異常に長い場合は、分類器の誤判定か、プロンプトテンプレートの指示文が冗長化している疑いが強い。
コストモデル：$/1M tokens の目安
- 年 Q2 時点の自社 H200 クラスタ実測では、Llama-3.3-70B が約 $0.32／1M tokens（出力側）、Mixtral-8x22B が $0.48、Nemotron-4 340B が $4.10 前後で、最上位と最下位の差は約 13 倍ある。この差を正しく回収できるのは"Nemotron でないと品質が足りないタスク"だけなので、分類器の精度がそのまま収益性に直結する。
KGA が現場で採っている構成
私たちは NIM を Kubernetes 上の `inference` 名前空間に分離し、各モデルを独立 Deployment + PodDisruptionBudget で保護している。ルーティング層は Go 製の薄い HTTP サービスで、ポリシーは OPA（Open Policy Agent）で Rego にして外出しする。ポリシーを差し替えるたびにビルドし直す運用は避け、モデル追加・廃止を GitOps で回すのが運用負荷の観点で最も安い。NIM 化されたモデル群を"交換可能部品"として扱えるこの構造が、2026 年のマルチモデル時代の基本形になると見ている。