NVIDIA Nemotron 3.5 Super VL は、AWS で既に利用可能な NVIDIA Nemotron 3 Nano、Nano Omni、Super、Ultra、および Nemotron 3.5 Lightning モデルに加わりました。これは 120B パラメータの Mixture-of-Experts（MoE）モデルで、トークンあたり 12B パラメータをアクティブにします。推論とツール使用をテキスト、画像、ドキュメント、ビデオ理解と組み合わせるため、1 つのモデルでテキストと視覚タスクの両方を処理できます。この投稿では、そのアーキテクチャとユースケースを探り、Amazon Elastic Kubernetes Service（Amazon EKS）、Amazon EKS Auto Mode、および Amazon SageMaker HyperPod EKS にデプロイする方法を紹介します。
Nemotron 3.5 Super VL は、Nemotron 3 Ultra から蒸留されたオープンなマルチモーダルモデルです。NVIDIA は重み、トレーニングデータセット、ポストトレーニングレシピを公開しているため、ドメイン固有のワークロードに合わせてモデルをカスタマイズし、管理するインフラストラクチャ上で実行できます。モデルの詳細は次のとおりです。総パラメータ数 120B、トークンあたりアクティブ 12B。ハイブリッド Mamba-2、MoE、アテンション層と RADIO ビジョンエンコーダを採用。コンテキスト長は最大 100 万トークン。入力はテキスト、画像、ドキュメント、ビデオ。出力はテキスト。BF16 および NVFP4 チェックポイント。NVIDIA によると、Hermes Bench で 63.44%、LangChain エージェント評価で 87.05%、CharXiv チャート推論ベンチマークで 80.8% を記録しています。
アーキテクチャの面では、Nemotron 3.5 Super VL はハイブリッド Mamba-Transformer MoE アーキテクチャを採用し、Mamba-2、アテンション、エキスパート層を交互に配置しています。スパースルーティングにより、120B パラメータのうち 12B がトークンごとにアクティブになるため、トークンあたりの計算量ははるかに小さいモデルに匹敵しますが、GPU メモリには完全な重みを保持する必要があります。Mamba-2 層は生成中に一定サイズの状態を維持するため、そのメモリは KV キャッシュのようにシーケンス長に応じて増加せず、長いコンテキストを経済的に保ちます。再帰的に共有されるマルチトークン予測（MTP）ヘッドは、ネイティブな投機的デコーディングをサポートします。
このモデルは、推論と視覚理解を組み合わせたエージェントワークフローをサポートします。主なユースケースには、コーディング（コードのテストと検証、エラーの分析、修正の推奨）、ウェブリサーチ（検索ツールが返すソースの相互参照と検証）、ドキュメントインテリジェンス（表、チャート、ページレイアウトを読み取って要約を生成）、サイバーセキュリティ（脆弱性の特定と脅威のトリアージ）、ビデオ理解（検索、コンテンツ分析、レビュー、インシデント分析）が含まれます。Nemotron 3.5 Super VL は、NVIDIA リファレンス実装、クックブック、NVIDIA Agent Toolkit を通じて、主要なオープンエージェントフレームワークやオーケストレーションシステムと統合されています。
GPU 構成の面では、vLLM での BF16 および NVFP4 の最小 GPU 数は次のとおりです。B200/GB200 では 8 個（BF16）または 2 個（NVFP4）、B300/GB300 では 4 個または 1 個、H200 では 8 個または 4 個、H100 では 16 個または 8 個が必要です。
デプロイアーキテクチャに関しては、リファレンス実装は標準の Amazon EKS、EKS Auto Mode、および SageMaker HyperPod EKS で動作します。EKS Auto Mode を使用すると、AWS がクラスタ内のスケーリング、GPU、EFA サポートを管理します。各クラスタには Kubernetes API をホストするコントロールプレーンと、CPU ノードと GPU ノードで構成されるデータプレーンがあります。CPU ノードはシステムおよびテストポッドを実行し、GPU ノードはモデルを実行します。Amazon Elastic Container Registry（Amazon ECR）はコンテナイメージを保存し、共有の Amazon FSx for Lustre ボリュームはモデルの重みを保持し、Elastic Fabric Adapter（EFA）は GPU ノードを接続します。NVIDIA Dynamo は、単一ノードでモデルを集約して提供するか、プリフィルとデコードを別々のノードで分散して提供します。ビジョン言語モデルの場合、画像/ビデオエンコーディングステージを独自のノードで分散実行することもできます。
このアーキテクチャは、p6-b200.48xlarge（NVIDIA B200 GPU 8 基）と p5en.48xlarge（NVIDIA H200 GPU 8 基）の両方で検証されています。NVIDIA Collective Communications Library（NCCL）の all-reduce マイクロベンチマークでクラスタとネットワークを検証できます。NCCL テストの実行中にすべての GPU の使用率とすべての EFA アダプタのトラフィックが確認できれば、クラスタが期待どおりに動作していることがわかります。また、NVIDIA aiperf ツールを使用して、クラスタ上にデプロイされたモデルのパフォーマンスを測定できます。aiperf の出力には、最初のトークンまでの時間（TTFT）、トークン間レイテンシ（ITL）、毎秒トークン数（TPS）のスループットなどの主要業績指標（KPI）が表示されます。さまざまな並行性レベルでこれらの測定を行うことで、レイテンシとスループットが同時リクエスト数にどのように依存するかを調べることができます。この情報は、容量とモデルデプロイトポロジを慎重に計画するために不可欠です。
並行性スイープの図は、集約デプロイと分散デプロイを比較しており、Nemotron 3.5 Super VL の推論が分散デプロイでより低い TTFT を持ち、ITL はほぼ同じであることを示しています。このようなチャートはデプロイ決定に役立ちます。レイテンシバジェットを水平線として描きます（例：TTFT 600 ミリ秒未満、ITL トークンあたり 100 ミリ秒未満）。両方の線の下にある最も右のポイントが、このトポロジの 1 レプリカがサービスレベル目標（SLO）内で提供できるスループットです。容量を計画するには、目標の毎秒トークン数をレプリカあたりのスループットで割り、デプロイするプリフィル-デコードペアの数を見つけます。変更（精度、TP/PP 形状、集約対分散、新しい Dynamo または vLLM リリース）後に同じスイープを再実行すると、トレードオフがすぐに可視化されます。曲線が右に下がるのは改善です。TTFT と ITL が別々にプロットされているため、どちら側をスケールするかもわかります。ITL の上昇はデコード容量の追加を示し、TTFT の上昇はプリフィル容量の追加を示します。
まとめると、この投稿では Amazon EKS、EKS Auto Mode、および SageMaker HyperPod EKS 上で NVIDIA Dynamo と vLLM を使用して NVIDIA Nemotron モデルを提供するためのアーキテクチャとパフォーマンス評価パターンについて説明しました。開始するには、リファレンス実装を使用して、自分のアカウントに Nemotron 3.5 Super VL をデプロイしてください。AI on EKS プロジェクトには、さらに多くの推論ブループリントも用意されています。