AIの導入が加速する中、推論は、 多くの大規模言語モデル（LLM）の導入を支える主要なワークロードになりつつあります。チャットボットの応答、 検索結果、コード提案、翻訳リクエストはいずれも、 AIモデルのリアルタイム実行に依存しています。こうした ワークロードが拡大するにつれて、それを支えるインフラストラクチャーの重要性も、 モデルそのものと同程度の高まりを見せています。このブログでは、 LLMクエリの種類によって、GPUのメモリ帯域幅、消費電力、スループット、 エネルギー効率にどのような違いが生じるのかを見ていきます。
AI推論を理解する
大規模なデータセットを処理してモデルに学習させるトレーニングとは異なり、
推論は、実世界のAIアプリケーションを動かす
運用ワークロードです。あらゆる推論リクエストでは、タイムリーに結果を返すために、
コンピューティング、メモリ、ストレージの各リソース間で膨大な量のデータを移動させる
必要があります。AIの導入が拡大し続ける中、推論はインフラ需要を押し上げる
主な要因の1つとなっています。そのため、大規模なAIワークロードを実現するには、
メモリ容量、帯域幅、パフォーマンス、電力効率が
極めて重要です。
大規模言語モデルの推論とは、学習済みのAIモデルを使用して、
新しい入力から出力を生成するプロセスです。ユーザーがプロンプトを送信すると、
モデルはそのリクエストを分析し、応答を作成するために最も可能性の高い
トークンの並びを予測します。チャットボットとの会話、テキスト要約、
翻訳、おすすめ、コンテンツ生成はいずれも、LLM推論によって
実現します。
LLM推論に潜む複雑さ
LLMクエリ1回あたりのエネルギーコストは、プロンプトの種類によって 最大7倍異なる場合があります（下の表1を参照）。こうしたばらつきは、 インフラ計画に実質的な影響を及ぼします。そして、その鍵となるのが メモリです。
多くの人は、LLM推論を単純なプロセスだと考えています。つまり、 プロンプトを入力すると、トークンが返ってくるというものです。しかし、その裏側では、 複雑で大きく変動する計算処理が行われています。LLMに送信される クエリの種類によって、リソース要件はまったく変わってきます。 消費されるメモリ帯域幅、GPUにかかる負荷、消費電力、そして その電力が時間の経過とともにどれだけ効率的に 有用な出力に変換されるかも変化します。
これは、インフラ計画において大きな意味を持ちます。マイクロンCEOのサンジェイ・ メロートラが「データなくしてAIなし」と述べているように、 適切なメモリとストレージインフラストラクチャーがなければ、 効率的な推論も実現しません。クエリの種類によってどのように異なる需要が生じるのかを 理解することが、キャパシティプランニング、電力予算管理、コスト最適化を 機能させるうえで重要です。
テスト方法
こうした違いを定量化するため、GPT-OSS-120Bを使用し、 ヘルスケア、テクノロジー、科学、プログラミング、翻訳、ロールプレイという 6つの異なるクエリカテゴリーで推論テストを実施しました。また、 GPU使用率、メモリ帯域幅、消費電力、スループット、エネルギー効率に関する リアルタイム指標を収集しました。
- 使用したモデルはGPT-OSS-120Bで、NIMコンテナを通じて デプロイしました。
- 指標は、カスタムのPython Gradioインターフェースを使用し、 NVIDIA® nvidia-smiによるリアルタイムのGPUテレメトリーと併せて収集しました。
- ストレージには、モデルやデータセットを高速に読み込むため、15TBのMicron® 9550 NVMe™ SSDを1台 使用しました。 Micron 9550 SSDの高いシーケンシャル読み取りスループットは、モデルの重みを高速に読み込み、 デプロイ時のコールドスタートレイテンシーを低減するうえで不可欠でした。
- 使用したサーバープラットフォームは、HPE ProLiant® DL384 Gen12です。
6つのクエリカテゴリー
一般的な実世界のLLMユースケースを代表するものとして、6つのカテゴリーを選定しました。各カテゴリーには、それぞれ異なる計算特性があります。
ヘルスケア：構造化された事実の想起を必要とする簡潔でエビデンスに基づく医療関連クエリ。
プロンプト例：「心血管リスクに影響を与えるエビデンスに基づく因子を列挙し、簡潔にまとめてください」
テクノロジー：ドメイン知識と構造化された出力を必要とする技術的な要約。
プロンプト例：「HBM3EとHBM4の主な違いを箇条書きで要約してください」
科学：簡略化せず、正確な専門用語を用いた説明を求めるクエリ。
プロンプト例：「CRISPRの中核的なメカニズムを、比喩を使わずに説明してください」
プログラミング：分析、推論、コード生成を必要とするコード最適化タスク。
プロンプト例：「この関数を速度面で最適化し、ボトルネックのみを説明してください」
翻訳：大きなコンテキストウィンドウと長めの生成を必要とする多言語翻訳。
プロンプト例：「この段落を、コメントを付けずに日本語に翻訳してください」
ロールプレイ：ペルソナの制約と文体上の要件を伴うクリエイティブな生成。
プロンプト例：「過積載の宇宙船のAIとして振る舞い、内部の状態について簡潔なログを作成してください」
主な結果：リソース要件が大きく異なる
カテゴリー別のパフォーマンス概要
クエリカテゴリー別に見るLLM推論のリソース要件
図1：6つすべてのクエリカテゴリーにおける主要な推論指標の比較
| カテゴリー | プロンプトトークン | 生成トークン | TTFT （秒） | デコードTPS | 平均消費電力 （W） | デコード時 エネルギー（J） | 効率 （トークン/J） |
|---|---|---|---|---|---|---|---|
| ヘルスケア | 64 | 257 | 2.286 | 55.35 | 170.5 | 792 | 0.3246 |
| テクノロジー | 68 | 436 | 7.188 | 62.48 | 172.3 | 1203 | 0.3625 |
| 科学 | 65 | 259 | 1.513 | 69.76 | 179.5 | 666 | 0.3886 |
| プログラミング | 244 | 1082 | 2.004 | 57.12 | 170.6 | 3232 | 0.3348 |
| 翻訳 | 1150 | 1588 | 3.373 | 58.81 | 171.6 | 4634 | 0.3427 |
| ロールプレイ | 93 | 255 | 1.294 | 64.88 | 182.5 | 717 | 0.3555 |
表1：6つのクエリカテゴリー別に見たデコードフェーズのパフォーマンス 概要（プリフィルを除く）
図2：メモリ帯域幅の使用量の推移（プリフィル時に急上昇）
メモリ帯域幅：推論を支える基盤
メモリ帯域幅は、多くの場合、LLM推論における主な制約要因となります。測定の結果、カテゴリー別のピークメモリ帯域幅要件は、348GB/秒（ヘルスケア）から475GB/秒（ロールプレイ）の範囲となりました。このような変動があるため、インフラストラクチャーは平均的なワークロードではなく、全体の中で最も要求の厳しいワークロードに合わせてプロビジョニングする必要があります。
図2の時系列データは、プリフィルフェーズにおいてメモリ帯域幅の使用量が非常にバースト的であることを示しています。メモリ帯域幅の使用量の観測データから、プリフィル（プロンプト処理）フェーズではスパイクが見られ、デコードフェーズではより安定したパターンを示すことが分かります。このようなバースト的な挙動により、平均帯域幅使用量だけを見ていると、実際のピーク要件を大幅に過小評価してしまいます。
このことは、メモリテクノロジーの重要性を示しています。Micron HBM3Eのような広帯域幅メモリソリューションは、AI推論ワークロードが要求する持続的な帯域幅を提供するように設計されています。GH200のようなプラットフォームでは、HBMがCPU側メモリとして機能するMicron LPDDR5Xと連携し、ユニファイドメモリアーキテクチャーを通じてデータを流し続けます。1つのロールプレイクエリはピーク時に475GB/秒に達します。これはHBM3eを搭載したGH200の帯域幅である4.9TB/秒の約10%に相当するため、およそ10個のクエリを同時に実行すると、メモリバスが飽和する可能性があります。これは、モデルが大規模化するにつれて、メモリ帯域幅が推論パフォーマンスの主な制約要因となり得る理由を示しています。
重要な知見：最も要求の厳しいワークロードを処理するには、最大475GB/秒のメモリ帯域幅が必要です。ヘルスケアQ&Aのような「単純な」クエリでさえ、ピーク時には348GB/秒を必要とします。メモリ帯域幅は多くの場合、推論スループットの制限要因となります。
注：メモリ帯域幅の使用量の推移を示すには、単一の時系列グラフで十分です。今回のようにメモリ帯域幅に制約される推論ワークロードでは、メモリ帯域幅、GPU使用率、消費電力が密接に相関しているためです。これらは連動して変化します。プリフィル中にメモリ帯域幅が急増すると、GPUのストリーミングマルチプロセッサー（SM）のアクティビティと消費電力もそれに応じて急増します。デコード中に帯域幅が安定すると、他の2つも同様に安定します。時間的なパターンが実質的に同じであるため、メモリ帯域幅だけを追跡しても、GPU使用率と消費電力を把握するための信頼できる代替指標となります。これらには共通の根本要因があります。それは、推論中の各時点でGPUがどれほど高い負荷で動作しているかということです。
図3：GPU使用率の分布。箱が縦に長いほど、ワークロードの変動が大きく、バースト的であることを示している
GPU使用率：性質上、バースト的
以下の箱ひげ図は、クエリカテゴリーによってGPU使用率がどのように異なるかを示しています。分布が広いほど、ワークロードはよりバースト的で、予測しにくいことを示しています。
重要な知見：GPUリソースの需要はバースト的であり、定常的ではありません。平均使用率に基づいてプロビジョニングを計画すると、ピーク需要時にシステムのリソースが不足する可能性があります。この点は、箱ひげ図を見ると明らかです。単一の推論リクエスト内でも使用率は大きく変動するため、キャパシティプランニングにおいては、従来の「平均使用率」という指標が誤解を招く可能性があります。
消費電力とエネルギー効率
消費電力は、クエリの種類によって大きく異なります。GPUの平均消費電力はカテゴリー間で170Wから183Wと比較的安定していますが、図2に示すように、クエリ1件あたりの総エネルギー消費量は666J（科学）から4634J（翻訳）まで、最大7.0倍の差があります。この差は、主に各クエリの処理時間と生成されるトークン数によって生じます。
図4：トークン量と処理時間の内訳。翻訳とプログラミングがリソース消費の大部分を占める
トークン量と処理時間：実際のコスト要因
カテゴリー間で最も大きな違いが現れるのは、トークン量と総処理時間です。翻訳では、生成トークン数がロールプレイの6.2倍となり、デコード時間は6.9倍、デコード時のエネルギー消費量は6.5倍になりました（表1）。プログラミングでは、生成トークン数が科学の4.2倍になりました。
図5：エネルギー効率の推移（値が高いほど良好）
エネルギー効率：ジュールあたりのトークン数
図6に示すように、クエリ実行中の効率は一定ではありません。プリフィル中は、GPUが電力を消費している一方で、まだトークンを生成していないため、効率は低い状態から始まります。その後、出力が生成されるにつれて効率は向上します。プログラミングや翻訳のような長いクエリは、初期のプリフィルで消費されるエネルギーがより多くのトークンに分散されるため、最終的に最も効率的になります（約0.33トークン/J）。短いクエリやプリフィルの比重が高いクエリでは、効率は低くなります。電力予算とサステナビリティ目標を管理するチームにとって、この指標の重要性はますます高まっています。
エネルギー効率は、1ジュールあたりに生成されるトークン数で測定され、0.3246トークン/J（ヘルスケア）から0.3886トークン/J（科学）まで幅があります。科学カテゴリーでは、比較的低い電力オーバーヘッドで高いデコードスループットを維持できるため、最も効率が高くなっています。この指標は、電力予算やサステナビリティ目標を管理するデータセンター運用者にとって、より一層重要になっています。
結論
この分析から明らかなことが1つあります。LLM推論は、決して均一なワークロードでは ありません。クエリの種類によって、メモリ帯域幅、GPU使用率、 消費電力、エネルギー効率など、必要となるリソースの特性は まったく変わってきます。
データからは、ワークロードが複雑であり、GPUリソースの需要がバースト的であることが分かります。 平均使用率を基準に計画を立てると、ピーク需要時にパフォーマンスの低下を 招くことになります。そのため、チームは以下の点に注力する必要があります。
- デプロイ構成で想定される、最も要求の厳しいワークロードの リソース要件を考慮する
- バースト時のGPU使用率と平均使用率の両方を考慮する
- 想定される構成の中でワーストケースとなるクエリカテゴリーを踏まえて 電力予算を検討する
- カテゴリー別の指標を監視し、最適化の機会を 特定する
- ワーストケースの電力要件を考慮し、電力予算を適切に 設定する
クエリの種類ごとのリソース特性を理解することで、 組織はより効率的で、費用対効果が高く、応答性に優れたAIインフラを 構築できます。推論ワークロードが拡大するにつれて、広帯域幅HBM3E、大容量LPDDR5X、 高スループットNVMe SSDなど、適切なメモリおよびストレージ基盤の上に AIインフラを構築することが重要になります。
AIインフラを最適化する準備はできていますか？ AIワークロード向けに 設計された、マイクロンのデータ センターメモリおよびストレージソリューションの ポートフォリオについては、 マイクロンのAIソリューションをご覧ください。
技術脚注
1 すべての推論テストは、ユニファイドメモリアーキテクチャー（480GB LPDDR5X + 144GB HBM3E）を備え、72コアのGrace Arm CPUとHopper H200 GPUを統合したNVIDIA GH200プラットフォーム上で実施されました。パフォーマンスの結果は社内テストに基づくものであり、システム構成、ワークロード特性、ソフトウェアバージョンによって異なる場合があります。
2 ストレージパフォーマンスは、Micron 9550 NVMe SSDによって実現されています。詳細については、Micron 9550 NVMe SSDをご覧ください
