本記事は、LIQID社の公式ブログ記事"The Memory Wall Is the Real Bottleneck in Your AI Cluster"の日本語解説記事です。LLM推論基盤における「GPUスタベーション」の原因と、それを根本解決する「メモリプーリング」技術について解説します。
- AI推論のボトルネックはGPU性能ではなくデータ供給速度（メモリの壁）であることが多い。
- 長文コンテキスト処理（128K等）やエージェント型ワークロードでは、CPU側のDRAM上に膨大なKVキャッシュやメタデータが生成される。
- 容量不足でNVMeストレージへ退避されると、約500倍程のレイテンシペナルティが発生し、GPUがデータ待ち状態（GPUスタベーション）に陥る。
- 単純なサーバー増設は「DRAMのサイロ化」を生み、全体のメモリ利用率は30〜50%に低迷。コストと電力効率を悪化させる。
- メモリプーリング（LIQID EX-5410C等）を導入することで、アプリを変更せずにネイティブDRAM並みの速度でメモリを動的割り当て可能になり、ドルあたりのトークン生成数を50%向上できる。
1. 本番環境で起きている「メモリの壁」の実態
推論クラスターの性能が伸び悩むとき、多くの場合「GPUを増設しよう」「最新のGPUに置き換えよう」と考えがちです。しかし、エージェント型ワークロードのデータパスを辿ると、原因はGPU自体ではなくGPUに十分なデータを供給できず、データ待ち（GPUスタベーション）に陥っていることにあります。
なぜCPU側のDRAMが重要なのか？
最新のLLM推論システムでは、以下のようなデータがCPU側のDRAM上に保持されます。
- 長文コンテキスト処理用の KVキャッシュ
- アテンションの状態・メタデータ
- 埋め込み（Embedding）ストア
- エージェントのツール呼び出し状態
例えば、70B（700億パラメータ）モデルで128Kトークンのコンテキストを処理する場合、アクティブなコンテキスト1件あたり約70GBものKVキャッシュが生成されます。並列でエージェントを動かせば、メモリ需要は乗算的に膨れ上がります。
従来の物理サーバーが抱える限界
従来のサーバーでは、提供できるDRAMは、物理的な制約（DIMMスロット数やCPUピン数）によりCPUあたり1〜2TBが限界の場合が多く見られていました。
DRAM容量が溢れるとデータはNVMeストレージへ退避されます。トークン生成ループの最中に発生する500倍のレイテンシペナルティは、どれだけ高性能なGPUであっても隠蔽できません。結果としてバッチサイズは縮小し、Tensor Coreの稼働率は低下、トークンあたりの消費電力が急増します。
2. なぜ「サーバー増設」で経済性が悪化するのか？
メモリ不足の従来の対策は「サーバーを増やすこと」でした。しかし、このアプローチはAIワークロードにおいて非効率な過去の対策となりつつあります。
サーバー増設による負のループ
- 不要なリソースの増加: サーバーを1台追加するたびに不要なCPU・電力・冷却のオーバーヘッドが発生。
- メモリのサイロ（孤島）化: 筐体内に固定された1〜2TB程のDRAMが個別に存在。
- 低い稼働率: 各サーバーがピーク負荷に合わせてメモリを積むため、フリート全体の平均メモリ利用率は30〜50%程度。
⚠️ 問題の本質
問題はメモリ容量そのものの不足ではなく、メモリの配置と割り当ての方法にあります。システム全体には十分なメモリが存在しているにもかかわらず、各サーバーに分散・固定化されているため、隣のノードでGPUスタベーションが起きていても融通できません。
3. 構造的解決策：「メモリプーリング」
この課題に対する構造的アプローチがメモリプーリング（Memory Pooling）です。
オープンなインターコネクト規格をベースに、メモリをサーバー外部に配置し、高速・低レイテンシのファブリックを介して接続します。メモリは各筐体に固定された属性ではなく、「ファブリックが必要な場所へ動的に割り当てるプール化リソース」へと進化します。
LIQID 「EX-5410C」の特徴
LIQIDが提供するメモリプーリング・ファブリック「EX-5410C」の主な特長は以下の通りです。
- 大容量プール: 1システム当たり最大100TBのDRAMをプール可能
- ノード間共有: 最大32台のサーバーノード間で共有
- 超低遅延: 約200ナノ秒のアクセスレイテンシ（ネイティブDRAMと同等）
- 透過的な動作: OSからは通常のメモリとして認識されるため、既存のソフトウェア（LLM推論基盤、DB、スケジューラー）の変更は不要
例えば、あるノードが長文コンテキスト推論で6TBのメモリを必要とする場合、共有プールから動的に割り当てられ、ジョブ完了後はプールへ返却されて再利用されます。
さらに、Kubernetes、Slurm、OpenShift、Ansibleと連携することで、スケジューラーの実行サイクルに合わせたリアルタイムな割り当てが可能になります。
4. 「メモリの壁」を解消した先に考えられる導入効果
| 評価指標 | 従来の固定構成 | LIQID メモリプーリング導入後 |
|---|---|---|
| ストレージ退避ペナルティ | NVMe退避（500倍遅延）が発生 | 常に高速メモリ保持でペナルティゼロ |
| バッチサイズ | 最小化 | 4〜8倍に拡大 |
| ワットあたりのトークン生成数 | 基準値 | 2倍に向上 |
| ドルあたりのトークン生成数 | 基準値 | 50%向上 |
| メモリ利用率 | 30〜50%（過剰投資） | 共有プール化により最適化 |
GPUがデータ待ちで空転する時間がなくなり、本来の計算処理に全サイクルを費やせるようになるため、GPU利用率と費用対効果が大幅に改善されます。
5. 今後の展望（CXL 3.0 / 3.1 へのロードマップ）
LIQIDのメモリプーリングは、すでに本番環境での実運用が始まっています。
さらに、CXLコンソーシアムが策定しているCXL 3.0 / 3.1のロードマップでは、複数ラックにまたがるメモリプーリングの実現が目標とされています。これにより、現在のラック単位の共有メモリアーキテクチャは、ラック列全体へと拡張される見込みです。
まとめ
「メモリの壁」は、回避策を模索するような制約事項ではありません。アプリケーション層に一切手を触れることなく、オープンスタンダードの上で解決できる既決のアーキテクチャ課題です。
2026〜2027年のインフラ戦略を検討する上で、単にメモリ確保のためにサーバーを増設し続けるのではなく、メモリプーリングによるアーキテクチャの最適化を検討することが重要となってきそうです。