エッジ NIM を取り巻く 3 つの制約
工場ライン・小売店舗・車載ユニット・建機など、常時クラウド接続が保証されない現場に LLM を置こうとした瞬間、設計条件は一変する。最優先で考えるべき制約は、(1) 連続消費電力、(2) 熱設計（ファンレス／受動冷却）、(3) 通信断時の継続動作、の 3 つだ。Jetson Orin AGX 64GB はこの 3 条件を同時に満たせる最上位エッジ GPU 計算機で、NIM for Jetson が 2026 年時点で正式に提供対象になっている。
電力モードの設計
Orin AGX は 15W・30W・50W・MAXN（約 60W）モードを持つ。産業用受動冷却筐体では実質 30W〜40W 運用が上限で、60W モードは専用冷却を設計しないと継続運用できない。30W で 7B〜8B 量子化モデルが実効 18〜28 tokens/s、50W で 35〜50 tokens/s が観測される。ここで重要なのは、"ベンチマークの最大 tps"ではなく"許容された電力枠でのスループット"が設計値だという点だ。30W 運用ならモデル選定は 7B〜8B 量子化が上限、13B 超はクラウドへフォールバックする前提で組む。
量子化戦略：FP8 と INT4 の使い分け
Ada／Blackwell 世代以降の NVIDIA GPU は FP8 が一級対応で、Orin AGX でも TensorRT-LLM 経由で FP8 重みを扱える。精度劣化がほぼ無視できるため、帯域・メモリ・レイテンシに効く改善が欲しい場合の第一選択は FP8 になる。一方 INT4（AWQ／GPTQ）はメモリを約 4 倍圧縮でき、7B モデルなら 4〜5GB に収まるため、VRAM 占有を他タスク（ビジョン・ASR）と分け合うエッジ機に有効だ。実務では"FP8 を基準、メモリが足りないときのみ INT4"という順序で選定するのが安全で、INT4 を安易に選ぶと日本語の長文応答で破綻しやすい。
NIM for Jetson のコンテナ構成
Orin AGX では NIM イメージが aarch64 向けに別系統でビルドされており、Triton + TensorRT-LLM バックエンドで起動する。Docker Compose で Riva ASR NIM、LLM NIM、TTS NIM を同一ホストに並べ、マイク入力 → ASR → LLM → TTS を完結させる構成が取れる。すべてが OpenAI 互換 API で統一されているため、クラウド側との切替コストが最小化される点が大きい。
オフラインフォールバックの 3 パターン
通信断時の挙動は、"縮退応答モード"・"バッチ遅延モード"・"オフライン完全自立モード"の 3 つに分類できる。縮退応答モードは、クラウドの大規模モデルが本来答えるべきクエリについて、エッジ側の小型モデルが"通信復旧まで後ほどお答えします"とテンプレート返答する方式で、最も実装が軽い。バッチ遅延モードは、ユーザー要求をローカルに保存して復旧後にクラウド処理して通知する方式で、非同期 UX が許容される場面（保守レポート生成など）で使う。オフライン完全自立モードは、エッジモデルで全処理を完結させる方式で、軍需・地下設備・洋上設備など通信前提が置けない環境で採る。
運用で死にやすい 3 点
第一に、Orin AGX の温度上限付近ではクロックが下がり、tps が連続稼働中に突然半減する。現場モニタリングで GPU 温度と tps を同時に記録しないと原因究明が遅れる。第二に、ファームウェア（JetPack）と NIM イメージのバージョン整合性が厳格で、JetPack 更新時は NIM 再検証が必要になる。第三に、INT4 量子化モデルは日本語の敬語・固有名詞で目に見えて劣化することがあり、量産前に必ず業務ドメインの実データで評価する必要がある。
まとめ
エッジ NIM は"クラウド NIM の縮小版"ではなく、電力・熱・通信断という固有の制約に対して設計された別物として扱うべきだ。2026 年時点で Jetson Orin AGX ＋ NIM ＋ FP8 量子化 ＋ クラウドフォールバックは、現場配置可能な LLM の現実的な最小構成として確立しつつある。