ニュース

GMO GPUクラウドで最新推論OSS『NVIDIA Dynamo』を動かしてみた
～Dynamo が推論パフォーマンスを向上させる仕組みとは？（Vol.3)～

皆さんこんにちは:-)
GMOインターネットでGPUクラウドの開発・普及活動をしている大川です。

ここまで二回にわたって NVIDIA Dynamo を GMO GPUクラウド上で動作させ、前回は Dynamo Serve の最小構成を試しました。ここまで来るとマルチノード環境を構築してみたいところですが、一旦足を止めて、Dynamo がなぜ推論性能を向上すると謳われているのか、このソフトウェアが目指すところはどこなのか、改めて振り返りたいと思います。

アテンション機構におけるトークン処理

Tramsformer モデルを採用した LLM の推論において、その処理は大まかに「Prefill」と「Decode」と呼ばれる二つのフェーズに分けることができます。

^{出典：Introducing NVIDIA Dynamo, A Low-Latency Distributed Inference Framework for Scaling Reasoning AI Models}

まず「Prefill」フェーズでは入力トークン（=プロンプト）に対して「アテンション」呼ばれる“文章中のどの部分が重要なのか”の重みづけを行います。ここでは入力トークン全体に対する Key と Value の行列計算が並列で行われ、一度計算した結果を（冗長な再計算を避けるため）KV キャッシュとして貯めていきます。
これによっていわば「入力された文章の全容把握」を行うわけですが、このプロセスには大量の行列計算が伴い、GPU の演算性能に負荷がかかります。
即ち「どれくらい並列で重い計算ができるか」がとても重要です。

続く「Decode」フェーズでは「Prefill」フェーズで得た KV キャッシュをもとに出力トークン（=回答）を逐次生成していきます。ここではそれまでの累積 KV キャッシュを活用してトークンの生成処理を繰り返し行うため、特性上並列での処理が難しく、どちらかといえば高速に情報を読み出してトークンをすばやく生成できる GPU メモリ性能（帯域）が重要になります。

既存のアーキテクチャにおける課題

前述のように実は推論中の各フェーズにおいて求められる性能特性は全く異なっているため、ひとつのノード上で双方の処理を行うと、どうしてもアサインされたリソースに最適ではない部分が生じてしまいます。

例えば（GPU メモリ帯域を生かし）Decode によって出力トークンを一定間隔で生成しているところ、他方から新たなクエリを受け付けて Prefill が実行されると（一時的に演算性能が高騰するので）応じて Decode 側のトークン出力レイテンシが不安定になり、ユーザの使用感に悪影響を及ぼしてしまうケースが挙げられます。

Dynamo のアーキテクチャ

こういった課題を解決するため、それぞれの処理を行う実行ノード、即ち以前の記事で言うところの「ワーカー」を役割ごとに分けることでリソースの効率をより高め、結果的にトークン出力のスループット（Token Revenueと呼ばれる）を向上させることが Dynamo の狙いです。

^{出典：Introducing NVIDIA Dynamo, A Low-Latency Distributed Inference Framework for Scaling Reasoning AI Models}

この図にある通り、Dynamo ではフロントエンドからの入力に対して、まず Prefill ワーカーが処理を行い、後続トークンの生成は Decode ワーカーが KV キャッシュを引き継いで処理します。それぞれ自身の担当する作業に集中すればよいので、リソースの割り当て最適化が狙えるというわけです。これは Disaggerecated Serving と呼ばれています。

ワーカーはそれぞれ台数を設定できますので、実際に実行される推論タスクの特性に合わせて増設を行うことも「従来のアーキテクチャ」に比べて容易であると考えられます。