Invalid input. Special characters are not supported.
最近、「メモリ」とコンテキスト長に関するAIの発表が相次いでいます。
- MetaはLlama 4モデルを発表しました。Maverickモデルでは最大100万トークンのコンテキストウィンドウをサポートし、Scoutモデルでは1000万トークンという驚異的なコンテキストウィンドウをサポートします。
- OpenAIは、ChatGPTが過去のチャットの内容を記憶し、アプリケーションがより便利になることを発表しました。
- GTCで、NVIDIAは推論ルーティングとKVキャッシュ管理のためのDynamoライブラリを発表しました。
このブログでは、これらの発表が何を意味し、AIファクトリーを設計するシステムアーキテクトにとって何を意味するのかをレビューします。
長いコンテキストは「良いところ」を表している
私たちの多くが大規模言語モデル（LLM）と対話するとき、私たちはクエリを書き、応答を得ます。入力と出力の合計サイズが、クエリの「コンテキスト・ウィンドウ」です。チャットのユースケースでは、入力と出力は通常100から1,000トークンの範囲です。
ハードウェアの性能が向上し、より大きなコンテキスト・ウィンドウをサポートするモデルが開発されるにつれて、このコンテキスト・ウィンドウが重要になるユースケースが見出されています。
私が毎日使っているのは、コーディング・アシスタントです。コード生成が必要なとき、モデルは既存のコードベースを理解する必要があります。このニーズは、生成リクエストのコンテキストに既存のコードを追加することで達成することができます。コンテキストとしてより多くのコードを使用することで、コーディングアシスタントはより高いレベルで作業し、コードベースにより大きなアーキテクチャ上の変更を加えることができます。
コンテキスト・ウィンドウは、本質的により賢いAIコーディング・アシスタントにつながります。
その他のユースケースには、メール、SharePointサイト、医療記録、法的手続きなどへのアクセスがあります。より多くのデータを入手することが、より良いアウトプットにつながることは一目瞭然です。
プリフィルとKVキャッシュとは？
なぜより大きなコンテキスト・ウィンドウが求められているかがわかったところで、最新のLLMの基礎となる概念、キー・バリュー（KV）キャッシュについて説明する必要があります。
現在使われている主なLLMはすべてTransformerアーキテクチャーを採用しており、推論クエリは以下の同じステップを踏みます。
埋め込み -> プリフィル -> デコード -> 後処理
埋め込みフェーズでは、テキストクエリをAIモデルが操作できるベクトル表現に変換します。
プリフィル段階では、モデルを通してクエリ（およびサポートテキストやコード行のような提供されたコンテキスト）を実行し、すべてのサブワードを評価することでクエリを消化し、内部表現を生成します。これらの表現の一部は、キー(K)およびバリュー(V)と呼ばれる一連のベクトルです。
楽しいことが起こるのは、デコーディングの段階です。プリフィル段階からデータを受け取り、クエリに応答して新しいトークン（単語）の生成が開始します。プリフィル段階で得られたKとVのベクトルは、新しく生成されるトークンごとに再計算されるか、キャッシュされて再利用されます。デコーディング時には、新しいKVベクトルを作成し、前のベクトルを使って新しいトークンを計算します。
最後に、後処理フェーズでは、デコード中に生成されたトークンを人間が読めるテキストに変換します。
この分解から得られる重要なインサイトは、プリフィル段階が完了するまでLLMは新しいトークンの生成を開始できないということです。この制約が意味するのは、プリフィルに多大な時間がかかると、ユーザーエクスペリエンスに直接影響を及ぼすということです。
プリフィルにはメモリと時間が必要です。
応用数学の博士号を持つ同僚のカティア・ジアニオスは、推論のためのシステムアーキテクチャーをモデリングしていることから、一部シナリオのプリフィル時間を見積もることができます。
免責事項：これらは推定値であり、システムをよりよく理解するために、ラボでテストを続けています。
次の表は、以下の推論パフォーマンスを示しています：
- Meta's Llama 4 Maverickモデル
- 4000億パラメータ
- FP8の重み
- 最大100万トークンのコンテキスト・ウィンドウ
- NVIDIA DGX B200サーバー上での実行
- 8x NVIDIA B200 GPU
- 1.4TBのHBM3E
- シングルユーザー
- 1,000トークンの出力
物事を簡潔に保つためにシングルユーザーを使用していますが、複数の同時ユーザーを使用すると、ロードとKVキャッシュのサイズが大幅に増加します。
短いコンテキストの場合、10,000トークン（およびそれ以上）までは1秒未満のプリフィル時間で簡単に処理できることがわかります。しかし、コンテキストの長さが最大になると、LLMが出力を開始するまでのプリフィル時間（最初のトークンまでの時間）は2分以上になります。
それぞれ25万のコンテキストを持つ10人のユーザーを掛け合わせると、プリフィル時間は30秒を超え、KVキャッシュの合計サイズは39GBになります。
これが長いコンテキストの「醜い」側面です。長いコンテキストのKV値の計算は、ユーザーエクスペリエンスに多大な影響を与えます。プリフィル時間が改善できなければ、長いコンテキストはインタラクティブなユースケースには適さないでしょう。
KVキャッシュを再利用する必要がある理由
長いコンテキストやAIコーディング・アシスタントを使用するという元の例に戻ると、連続したクエリのためのコンテキストが多大に再利用されることが予想されます。コーディング・アシスタントがクラスのメソッドを生成するとき、ベースクラスはクエリごとにアクセスされます。
クエリごとにKVキャッシュを生成するのではなく、一度生成してから、連続するクエリのために再利用する必要があります。しかし、このアプローチには、KVキャッシュのサイズの問題があります。最新のLLMで最適化されたとしても、KVキャッシュはAIシステムのメモリをすべて消費します。
オフロードによる救済
NVIDIA Dynamoライブラリには、KVキャッシュをGPUメモリから他の利用可能なデバイスに移行するKVキャッシュマネージャーがあります。また、KVキャッシュを複数のセッションやユーザー間で共有されるKVプールに変えるKV再利用テクノロジーも導入しています。HBMから移動する100万トークンのKVキャッシュ（～15GB）は、はるかに大きなKVプールのほんの一部に過ぎません。
まずはシステムメモリです。DGXの例では、GPUへの総帯域幅が1TB/秒の4TBのシステムメモリをサポートしています。これだけの帯域幅があれば、100万トークンのKVキャッシュをCPUメモリからGPUメモリにロードするのに、再計算に2分以上かかるのに比べて、（理想的なケースでは）わずか 15ミリ秒しかかかりません。
この時間短縮はユーザーにとって素晴らしいことです。コンテキストの初期計算後、CPUメモリからの再ロードは非常に速く、インタラクティブなユーザー体験を可能にします。
CPUシステムメモリは依然としてGPUメモリと同じ問題に直面しています。つまり、限定的なメモリ容量です。
次は、DGXサーバーのローカルNVMeドライブです。8台のPCIe Gen5 NVMeドライブ（Micron 9550の高性能Gen5ドライブなど）を使用すると、次の階層のKVキャッシュオフロード容量は30TBから245TBの範囲で、総帯域幅は112GB/秒になります。
ストレージ層はシステムメモリよりも大幅に低速である一方で、100万トークンのKVキャッシュのロードにかかる時間はわずか140ミリ秒です。
このようなオフロードと移行用のテクニックを使うことで、最初のトークン生成にかかる時間は短縮され、ユーザーエクスペリエンスが改善されます。GPUが以前行った作業をやり直す代わりに出力を生成することに多くの時間を費やすことになるため、これは総所有コスト（TCO）にとっても素晴らしいことです。
高性能ストレージが長いコンテキストの推論を可能に
生成AIの環境は、ここ数年で大きく変化しました。以前はストレージは二次的要素でしたが、インテリジェントなAIをポジティブなユーザーエクスペリエンスで実現するために、AIファクトリーに高性能ストレージを提供することは不可欠であると言えます。
昨年のFMSと今春のGTCで、マイクロンは次期PCIe Gen6 NVMeドライブのパフォーマンスを紹介しました。長いコンテキストとKVキャッシュ管理に関するこれらの開発は、最新のGPUに最速のNVMeフラッシュを接続することが、AIの導入を成功させる上で重要であることを示しています。
