0.はじめに

こんにちは！HPC事業部 技術グループのhinokiharaです。

今年はAIの発展が目覚ましいですね！私もAnthropicのClaude Codeを毎日のように使用しており、働き方が劇的に変わりました。ただ非常に便利な一方で、会社の機密データや大事な研究データを読み込ませられない(読み込ませてしまった)という話もよく聞きます。機密性の高いデータを扱う場合はやはりローカルにLLMをホストしたい。でもローカルLLMはまだ性能が足りない。。。そんな悩みを持つ方は多いのではないでしょうか？

今日はそんな悩みを持つ方々に、「ローカルLLMはここまで来たぞ」という話をしたいと思います。つい先日リリースされたばかりの、NVIDIAのNemotron 3 Ultraをご存知でしょうか? 総パラメータ数550B(アクティブ55BのMoE)という、非常に大きなオープンウェイトモデルです。とはいえ、Nemotron 3 Ultraの本質は「賢く答えるAI」ではありません。複雑なタスクに対して適切なツールを呼び、失敗から回復しながら、何時間でもタスクを進め続ける——そんなエージェント用途のために、一貫して作り込まれたモデルなのです。このモデルの性能・能力については、ウェブ上ですでにいくつかのサイトでAPI(期間限定の無償版や有償版含む)が提供されておりますので、容易に確認することができます。ぜひ一度触ってみてはいかがでしょうか？

Nemotron 3 Ultraのユニークなところは、「モデルがオープンウェイトで公開されている」ことです。つまり、動かせる環境さえあれば社内・研究室内のサーバーでも動かすことができます。公開厳禁の機密情報を取り扱うようなタスクもAIに仕事を任せることができるようになるかもしれません。そこで早速、社内のGPUサーバーを使ってこのモデルをデプロイしてみましたので報告します。個人的な印象としては、1台のGPUサーバーで複数人の実運用も可能な非常に期待できるモデルだと感じています。

1.基本情報

今回の検証では、HPC5000-ETN GPU8R4Sを利用しました。

モデルはHugging Faceで公開されているNVFP4量子化版(NVIDIA-Nemotron-3-Ultra-550B-A55B-NVFP4)を、SGLangを使ってデプロイしました。Nemotron 3 UltraはMamba-2(状態空間モデル)とTransformerのハイブリッド構成を採用しています。Transformerが過去の全トークンを参照するのに対し、Mamba-2層は固定サイズの「状態」を更新しながら読み進めるため、計算コストがコンテキスト長に対してほぼ線形に抑えられます。特に、長いコンテキストを抱えたままの生成でも1トークンあたりのコストがほとんど増えないのが利点です。

また、MTPによる投機デコードは公式推奨値が5トークンと、一般的な設定値(1〜3)に比べて大きく取られています。これはモデルの学習段階でMTPを前提としたチューニング(予測ヘッドの重み共有や専用の後段学習)が行われているためで、実際にコーディングなどの分野で5トークン分のドラフトが機能していることを確認できました。

このように、単に精度の高いモデルというだけでなく、実際にGPUサーバー上で動作させるための推論最適化まで作り込まれたモデルであることが窺えました。

2. 測定

LLMの推論は、prefillとdecodeという性質の異なる2つのフェーズに分かれます。prefillは入力プロンプト全体を一度に処理してKVキャッシュを構築する段階で、大量のトークンをまとめて計算するためGPUの演算器を使い切るコンピュートバウンドな処理です。一方decodeは1ステップにつき1トークンずつ生成する段階で、生成量に対して読み込む重みが大きく、演算よりメモリ帯域がボトルネックになるメモリバウンドな処理です。このためdecodeは複数リクエストをバッチングして重みの読み込みコストを分散させることでスループットを稼ぎますが、性質が逆のprefillと同じバッチで混在させると互いの効率を損ないやすい、という非対称性があります。

prefillとdecodeは性質が正反対の処理であるため、推論性能をベンチマークする際は、両者を合算した単一の指標ではなく、それぞれ分けて測定する必要があります。具体的には、prefillの速さは最初のトークンが返るまでの時間(TTFT)、decodeの速さは1トークンあたりの生成時間(TPOT)や出力トークン毎秒として、別々に評価します。

なお、prefillはprefix cacheにヒットした場合スキップされることがあるため、TTFTを測る際はキャッシュの状態(コールドかウォームか)を揃えないと値が大きくブレる点に注意が必要です。

2.1 prefill 処理

prefill処理は基本的にコンピュートバウンドな処理のため、入力コンテキスト長を変えながらスループットを測定しました。本サーバーでの結果は下記のとおりです。

短いコンテキストではprefillの並列度が不足してGPUの演算器を埋めきれず、スループットは低めに出ます。コンテキスト長が伸びるにつれて演算器が飽和し、16K前後で約5100 token/sのピークに達します。以降の処理時間はコンテキスト長に比例してほぼ線形にのびていくことが確認できました。

この結果は、キャッシュが効かない状態で128K程度の入力が来ると、prefill処理だけで約26秒かかることを意味します。LLMと複数回やり取りを繰り返すマルチターン会話では、過去のやり取りが保存・再利用できるため大きな影響はありませんが、コンテキストの圧縮や長大な調査結果の一括読み込みといった、キャッシュの効かない大量入力を処理する場面で、このコストが顕在化します。

2.2 decode 処理

decode処理は実運用を見越し、MTPによる投機デコードを有効にして計測しました。MTPを無効にした場合は約40 token/sでしたが、有効化により低並列時で最大約150 token/sまで改善しました。ドラフト長5トークンというMTPの設定が、実際に機能していることが窺えます。

ただし、実際に受理されるドラフトの平均長は、対象とする分野や内容によって2〜5トークンの幅で変動することも確認できました。コードのように次のトークンが予測しやすい内容では受理率が高く長く伸びる一方、非定型な文章では短くなる傾向です。なお、受理長の正確な定量データは現時点で取得が難しいため、ここでは定性的な傾向のみを示します。

今回の結果は、BlackBox AI(推論プロバイダ)のエンドポイントで測定された値の約420token/secと大きく乖離していますが、この差異は下記のようなことが原因であると考えています。

・Blackwell Pro 6000での運用はNVIDIA社が正式にサポートしておらず、ソフトウェア周りの最適化余地がまだある
・純粋なハードウェア構成の差(NVLinkの有無とGPUのスペック差)

加えて、弊社で検証を開始してまだ3日目というところもあり、まだ検証が不十分である、という点も付け加えておきます。本来はしっかり調査したうえで報告すべきですが、MTP有効時に最大で150token/sという記録は、現時点でも十分インパクトがあると考えています。

3.最後に

Nemotron 3 Ultraを社内のGPUサーバーにデプロイし、基本的な性能値を測定しました。単純なdecode処理の能力だけで言えば、十数人規模の同時処理も視野に入る性能を持っています。とはいえ、この構成でストレスなく運用できるのは何人程度かを見積もるには、引き続き検証が必要です。

ユーザーが快適に利用できるかを左右する指標の一つとして、不定期に投入されるprefillタスクをどう捌くか、という点があります。今回実測した128Kコンテキストの26秒から外挿すると、200K級のprefillには40秒程度を要し、その間は計算資源が奪われて他ユーザーの応答速度が一時的に低下します(チャンク分割により完全に停止はしないものの、レイテンシは悪化します)。

こうしたprefillとdecodeの相互干渉を避けるため、最近では両者を別のサーバーに分離して実行するPrefill-Decode Disaggregation(PD分離)という構成も採られるようになっています。性質の異なる2つの処理をそれぞれ専用のハードウェアに割り当てることで、システム全体のスループットと応答性を両立させる狙いです。

ただし、この構成にはGPUサーバーがもう一台必要となるため、費用対効果の見極めが要ります。1台構成のままでも、混雑状況に応じて、decode処理が走っている間はprefillの開始を一定時間遅らせる(SGLangの--enable-prefill-delayerなど)といった制御で対応することも、現実的な選択肢の一つとなりえます。

一方で、エージェントにタスクを丸投げするような、リアルタイムの応答性を必ずしも必要としないユースケースも今後増えていくと予想されます。そうした用途であれば、prefillの差し込みによるレイテンシ悪化は許容でき、むしろスループット最大化に振った設定が最適となります。

このあたりは、共有計算資源の上で性質の異なるワークロードをどうスケジューリングし、全体スループットと個々の応答性(そして利用者間の公平性)をいかに両立させるか、という課題に行き着きます。これはHPCクラスターのジョブスケジューリングが長年向き合ってきた問題と、構造的に同じものです。スケジューラの層も粒度も異なりますが、根底にあるトレードオフの設計思想は共通しており、弊社がHPC運用で培ってきた知見を活かせる領域だと考えています。引き続き検証を進めていきます。