画像・文書・動画も扱うモデルを、EKSやSageMaker HyperPod EKSで動かす構成です。重みの精度やGPUに応じた最低構成と、同時実行数を変える計測を示します。 トークンごとの計算量と、全重みを保持するメモリーは別の条件です。遅延と処理量を自社の入力で測り、必要な設備を判断することが焦点になります。 マルチモーダルモデルを自分の基盤で動かす AWSは10月29日、NVIDIA Nemotron 3.5 Super VLをAmazon EKSなどへ配備する方法を公開しました。総パラメーター数1200億、各トークンで120億を活性化するMoEモデルです。テキスト、画像、文書、動画を入力し、テキストを出力します。記事では既存のNemotron群にこのモデルが加わることを紹介し、通常のEKS、EKS Auto Mode、SageMaker HyperPod EKSを対象にしています。モデルの説明だけでなく、配備、通信の検証、性能測定までを扱う技術情報です。公開重みを取得できることと、小さな設備で自由に動くことは同じではありません。必要なGPUの数は、重みの形式とハードウェアによって異なります。 疎な計算でも全体の重みを保持する モデルはMamba-2、注意機構、専門家層と画像エンコーダーを組み合わせます。毎回使うパラメーターを絞っても、GPUメモリーには全体の重みを保持する必要があると説明しています。記事はBF16とNVFP4の構成を区別し、GPUごとの最低台数を示しました。配備基盤では共有ストレージに重みを置き、EFAでGPUノード間を接続します。NVIDIA Dynamoによって一体で処理する方式と、入力側と生成側を分離する方式を比較します。主な対象は、画像や資料を扱う業務エージェントを自分たちの環境で運営したい開発者です。入力の形式が増えると、文章だけの試験で見えない待ち時間も生じる可能性があります。原文は通信の確認とモデルの計測を分け、基盤の不具合をモデル自体の限界と取り違えない方法を示しています。最大の入力長と実際の処理効率も別の確認点です。 同時利用時の応答時間から容量を決める 記事ではNCCLの通信試験でGPUとEFAを確認し、aiperfで最初のトークンまでの時間、生成中の間隔、処理量を測ります。同時実行数を変えることで、遅延の目標を満たす範囲が見えるとしています。導入側では、この手順を自社の文書や画像の大きさに合わせることが論点になります。小さな入力の結果から、本番の長い資料を処理する費用は決まりません。量子化や配備方式を変えた場合には、速度だけでなく出力の品質も確認する必要があると見られます。計算資源を確保する費用に、重みの保管、ネットワーク、運営の負担を加えて比較する方法が考えられます。利用頻度が低い用途では、設備を維持する時間が総費用へ大きく影響する可能性もあります。原文の測定例を固定の性能保証とせず、必要な同時利用数と応答時間を定めて再計測することが判断材料になります。