AWSが高性能並列ファイルシステムFSx for LustreとNVIDIAのGPUDirect Storageを組み合わせ、CPUを経由せずストレージからGPUメモリへモデルの重みを直接並列転送し、大規模LLMの読み込み時間を大幅に短縮する手法を公開した。あわせてメモリ圧縮技術TurboQuantによる文脈窓の拡大も紹介した。
AWSがAmazon FSx for LustreとNVIDIAのGPUDirect Storageを組み合わせ、CPUを経由せずストレージから各GPUのメモリ（HBM）へモデルの重みを直接並列転送する手法を公開した。従来方式ではLlama 3.1 405Bの読み込みに10〜20分かかり、この間に高価なGPUが起動待ちで遊んでいた。
P5en（NVIDIA H200×8基）は16本のネットワーク接続で合計400GB/秒の帯域を持ち、うち8本以上を直接転送に使える。テスト構成のファイルシステムは約94GiB/秒のスループットを出し、容量に応じて線形に拡張できる。読み込み短縮は新規インスタンスの即応性、オートスケールの反応速度、障害復旧の速さ、GPU稼働効率に直結する。
あわせて、文脈データを圧縮して扱える文章量を拡大するTurboQuantも紹介された。読み込み速度と長文脈の両面で、巨大モデル運用の応答遅延とコストに効く実務的な改善である。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
LLMが数千億パラメータ規模に巨大化するにつれ、モデルの重みをGPUの高速メモリ（HBM）へ読み込む時間が無視できなくなっている。従来方式では、保存先からCPUのメモリを経由し、各GPUへ順番にデータをコピーするため処理が一本道になり、例として4050億パラメータのLlama 3.1 405Bでは読み込みに10〜20分を要していた。この間、最も高価なGPU資源が遊んでしまい、最初の応答が返るまでの時間（コールドスタート）を悪化させていた。AWSは最近、NVIDIAのBlackwell世代を搭載したEC2 P6e/P6シリーズも投入しており、推論基盤の規模はさらに拡大している。
GPUDirect Storageを使うとCPUを経由せず、ネットワーク経由でストレージから各GPUのメモリへ直接データを並列転送できるため、読み込みの目詰まりがなくなる。読み込み時間の短縮は、新規インスタンスの即応性、自動拡張（オートスケール）の反応速度、障害復旧の速さ、そしてGPU稼働コストの効率に直結する。推論サービスを運用する企業にとって、応答遅延とコストの両面に効く実務的な改善である。
4050億パラメータのLlama 3.1 405Bを動かすとき、重みをGPUの高速メモリ（HBM＝GPUに直結した高帯域メモリ）へ読み込むのに10〜20分かかっていた。原因は経路にある。従来はストレージからいったんCPUのメモリへ移し、そこから各GPUへ順番にコピーするため、処理が一本道になり目詰まりが起きる。この間、最も高価なGPUが起動待ちで遊んでしまう。
AWSが公開した手法は、この経路を変える。高性能並列ファイルシステムのAmazon FSx for Lustreと、NVIDIAのGPUDirect Storage（CPUを介さずストレージから各GPUのメモリへ直接データを送る技術）を組み合わせ、ネットワーク経由で各GPUのHBMへ並列に転送する。
If you're iterating on deploying large language models (LLMs) on AWS GPU instances, you've probably noticed the larger the model to be loaded into GPU High Bandwidth Memory (HBM), the longer the painful wait until the GPUs are ready for inference.
引用は「モデルが大きいほど、GPUが推論できるようになるまでの待ち時間が長く苦しくなる」という現場の実感を指す。この待ち時間そのものを攻めるのが今回の核心だ。
数値が設計の前提を決める。P5en（NVIDIA H200を8基積んだインスタンス）は16本のネットワーク接続を持ち、合計で400GB/秒の帯域がある。このうち8本以上を、ストレージからGPUへの直接転送に充てられる。受け側のファイルシステムも太くないと意味がない。
テスト構成のFSx for Lustreは約94GiB/秒のスループットを出し、容量を増やすほどスループットも線形に伸びる。つまり「もっと速く読みたい」なら容量を足せばよく、頭打ちの壁にぶつかりにくい設計になっている。
読み込みが速くなる効果は単なる待ち時間短縮にとどまらない。新しいインスタンスがすぐ応答できるようになり、オートスケール（負荷に応じてGPUを自動で増減する仕組み）の反応も速くなり、障害からの復旧も早まる。これらはすべて、高価なGPUが遊ぶ時間を削るという一点に収束する。
サンプル実装はaws-samplesとして公開されており、安全なテンソル形式を高速に読むfastsafetensorsも併用される。
今回の発表は読み込み速度だけの話ではない。あわせて紹介されたTurboQuantは、GPUメモリ上の文脈データ（モデルが直近の会話や文章を覚えておくための作業メモリ）を圧縮する技術で、扱える文章量＝文脈窓を大幅に拡大する効果がある。
読み込みを速くする手法と、メモリを節約して長文を扱う手法は、別々の課題を解く。前者は「起動の速さ」を、後者は「一度に処理できる量」を改善する。どちらも巨大モデルの運用コストと使い勝手に効くため、同じ発表でセットで示された。
TurboQuantの論文は公開されており、KVキャッシュ（文脈を保持する領域）の量子化による圧縮を扱う。長文脈アプリを設計する実装担当にとっては、同じGPUメモリでより長い入力を受け付けられるかを左右する要素になる。
得をするのは、自前のGPU基盤でLLM推論を運用する国内企業だ。コールドスタート（停止状態から応答可能になるまでの時間）が縮み、オートスケールの反応も速くなるため、応答遅延と稼働コストの両方が下がる。
長文脈アプリを設計する実装担当も追い風を受ける。TurboQuantが文脈データを圧縮するため、同じGPUメモリでより長い文章を扱える。
一方、見直しを迫られる側もいる。ストレージからCPUを経由してGPUへ送る一本道の経路を前提にチューニングしてきた構成は、直接転送方式への移行で設計を組み直す必要が出る。さらに、起動が遅いことを前提に待機用GPUを多めに確保していた構成は、読み込みが速くなるとその待機分が過剰になり、従来のコスト前提が崩れる。
立場別、明日から動ける一手。
公式ブログが示すP5en（H200×8基）の400GB/秒・テスト系94GiB/秒という帯域条件が自社の推論インスタンス構成に当てはまるかを確認する。
現行のモデル読み込み時間（コールドスタート）とGPU稼働コストを、直接転送方式導入後の想定値と比較する。
自社の最大モデルでストレージからGPUメモリへの読み込み時間を、現行方式とサンプル実装で測る。
AWS公式ブログで公開された直後の技術発表のため、現時点で目立ったSNS上の議論は確認できていない。論点は、従来10〜20分かかったLlama 3.1 405Bの読み込みをCPU経由なしの直接転送でどこまで縮められるか、P5enの400GB/秒・テスト系94GiB/秒という帯域が自社構成で再現できるか、TurboQuantによる文脈窓拡大の実効に集まる見込みの技術トピックである。
※トレンド検出時刻付近の人気投稿を表示
