NIMのPoCが成功すると、次に出てくるのが「本番で何を見るか」「結局いくらかかるか」の2問だ。可観測性とTCO設計は不可分なので、あわせて整理する。
GPUメトリクスの基盤：DCGM
NVIDIA Data Center GPU Manager（DCGM）は、GPU単体の状態を取得する標準スタックだ。Kubernetesでは`dcgm-exporter`をDaemonSetで展開し、SMアクティビティ（`DCGM_FI_PROF_SM_ACTIVE`）、テンソルコア使用率（`DCGM_FI_PROF_PIPE_TENSOR_ACTIVE`）、HBM帯域（`DCGM_FI_PROF_DRAM_ACTIVE`）、電力（`DCGM_FI_DEV_POWER_USAGE`）をPrometheusにエクスポートする。NIMの性能劣化を切り分ける際は、SMアクティビティが想定通り上がっているか、テンソルコアが回っているか、HBM帯域が張り付いているかの3点を先に確認する。
アプリ層メトリクス：Triton + NIM
NIMコンテナは`:8002/metrics`でTriton由来メトリクスを出す。重要なのは`nv_inference_queue_duration_us`（キュー待ち）、`nv_inference_compute_infer_duration_us`（実計算）、`nv_inference_request_success`。加えてNIM独自のトークン計測（prompt_tokens/completion_tokens/TTFT/TPOT相当）が出るので、単位トークンあたりのコストをPrometheus recording ruleで算出しておくとFinOpsに直結する。
NeMo Guardrails
出力制御はNeMo Guardrails（OSS）をサイドカーまたは前段に配置する構成が一般的。Colang DSLで「禁止トピック」「PII検出」「ツール呼び出し制限」などのレールを書き、NIMの`/v1/chat/completions`への入出力を通す。レイテンシ増が1呼び出しあたり数百ms以上になるケースもあるので、Guardrails自体もメトリクス対象にする。
TCO構造：DGX Cloud vs 自社運用
DGX CloudはNVIDIA+クラウド各社が共同提供するGPUインスタンス（H100/H200系）で、時間課金。自社運用は設備（GPU・サーバ・ネットワーク・冷却）＋電力＋運用人件費＋データセンター区画の合計だ。公開情報ベースで言えるのは、短中期PoCとバースト需要はDGX Cloudが有利、年間稼働率70%超が読めるワークロードは自社運用の単位時間コストが下がりやすい、という定性的な傾向だけ。具体数値は契約条件・電力単価・GPU世代で大きく変わるので、自組織で積み上げるべきだ。
実測KPIの設計
TCO議論を意味のあるものにするには、単位が要る。推奨は「1Mトークンあたりコスト」「1リクエストあたりGPU秒」「TTFT p95／p99」「TPOT p95」の4点を、モデル×プロファイル×ハードウェア単位でダッシュボード化することだ。NIMの場合、engineが確定しているのでプロファイル単位の再現性が高く、モデル比較の土台を作りやすい。ここに電力・減価償却を載せれば、DGX Cloud見積もりと対等に議論できる。