NIMはコンテナ1本でLLM推論を提供するが、エンタープライズで「本番」と呼ぶには周辺K8sとガバナンスの設計が必要だ。本稿では公開されているNVIDIA K8sコンポーネントを前提に、実運用で効く5パターンを示す。
パターン1：GPU Operatorによるノード標準化
NVIDIA GPU OperatorはNVIDIA Driver・Container Toolkit・DCGM Exporter・Device Pluginをノードに一括展開する。Helm chartで導入し、`driver.enabled`、`toolkit.enabled`、`dcgmExporter.enabled`を環境に合わせて設定する。既存ノードにドライバ導入済みなら`driver.enabled=false`でOperator側はToolkit以上のみを管理させる構成が現実的だ。Node Feature Discoveryと組み合わせて、`nvidia.com/gpu.product=H100-SXM5-80GB`のようなラベルでNIMのPodをスケジューリングする。
パターン2：マルチテナント分離
同一クラスタで複数チーム・顧客を収容するなら、ネームスペース分離＋NetworkPolicy＋ResourceQuotaが最低ライン。GPU自体はMIG（H100なら最大7分割）でハード分離するか、Time-Slicingでオーバーサブスクリプションするかを選ぶ。推論レイテンシSLAが厳しい本番系にはMIG、開発検証にはTime-Slicingという使い分けが定石だ。NIMコンテナはMIGインスタンスに対してそのまま起動でき、engineプロファイルが一致していれば問題ない。
パターン3：DCGM連動HPA
標準のHPAはCPU/メモリしか見ないので、GPU推論には役立たない。Prometheus Adapterで`DCGM_FI_PROF_SM_ACTIVE`または`nv_inference_queue_duration_us`をカスタムメトリクス化し、HPAの`External`メトリクスとして参照する構成を組む。実務では「キュー滞留pでスケールアウト、直近N分のアイドルでスケールイン」のように、スケールアウト側は敏感に、スケールイン側は鈍感にチューニングする。KEDAを使うとPrometheusスケーラで簡潔に書ける。
パターン4：エアギャップインストール
規制業界や機密ワークロードではインターネット非接続が前提になる。NIMコンテナはNGCから事前pullし、社内レジストリ（Harbor等）にpushしておく。engine planも同梱済みなので追加ダウンロードは不要だが、LoRAアダプタとトークナイザをNFSまたはS3互換ストレージ（MinIO等）に配置し、`NIM_PEFT_SOURCE`でマウントさせる。エアギャップではライセンス検証やテレメトリが問題になりやすいので、オフラインライセンスモードを使う前提で契約時に確認する。
パターン5：モデル更新のBlue/Green
NIMはコンテナイメージのタグがそのままengineバージョンに紐づく。Deploymentを2系統（blue/green）用意し、Serviceのセレクタ切替でトラフィックを切る。Argo Rolloutsを使えばcanary比率を徐々に上げつつメトリクス（エラー率・TTFT・正答率）に基づく自動ロールバックが可能。モデル更新は量子化変更や語彙拡張で出力分布が変わるので、本番トラフィックのシャドー評価を挟むのが望ましい。
横断の設計原則
これら5パターンに共通するのは「GPUリソースを使い切る前提で設計し、SLA違反を先に検知する可観測性を付ける」ことだ。NIMは起動が軽く、engineが確定しているため、コンテナ化されたマイクロサービス文化にそのまま乗る。逆に言えば、K8s運用が未成熟な組織では、NIMよりも先にGitOps・監視・SREプラクティスの底上げが効く。