（以下はLIQID社ホームページに掲載されたブログの弊社和訳です：The Memory Wall Is the Real Bottleneck in Your AI Cluster.）

推論クラスターの性能が期待通りに上がらないとき、 多くの 場 合、最初に疑われるのはGPUです。「GPUを増やそう」「より新しいGPUに置き換えよう」「更に高性能なGPUに置き換えよう」と考えがちです。 しかし、性能が伸び悩むエージェント型ワークロードのデータパスをたどると、ほとんどの場合、原因は同じところに行き着きます。GPU自体に問題があるの ではなく、GPUに十分なデータを供給できず、GPUがデータ待ちの状態、すなわち「GPUスタベーション( GPU starvation )」に陥ってるのです。

プロセッサの処理速度と、そこにデータを供給するメモリシステムの帯域・容量との乖離、いわゆる「メモリの壁（Memory Wall）」は、コンピュータアーキテクチャの分野で何十年も前から知られている課題です。しかし大規模言語モデル（LLM）の登場により、この問題は単なる学術的な懸念事項から、エンタープライズAIにおける最大のコスト要因へと姿を変えました。

本番環境における「メモリの壁」の実態

最新のLLM（大規模言語モデル）の推論システムでは、CPU側のDRAMが極めて重要な役割を担っています。長文コンテキストを 処理するためのKVキャッシュ、アテンションの状態、バッチ処理を管理するメタデータ、埋め込み(Embedding)ストア、そしてエージェント型ワークフ ローにおいて蓄積されるツール呼び出しの状態など、その多くがCPU側のDRAM上に保持されます。
例えば、70B（700億パラメータ）のモデルで128Kトークンのコンテキストを処理する場合、アクティブなコンテキスト1件あたり約70GBものKVキャッシュが生成されます。並列でエージェントを動かせば、そのメモリ需要は乗算的に膨れ上がります。

この膨大な需 要に対し、従来のサーバーが提供できるのはCPUあたり1〜2TBのDRAMに過ぎません。この天井は物理的な制約によるものです。DIMMスロットの数 やCPUのピン数によって、パラレルバスに接続できるメモリ容量には限界があり、さらに容量を求めて高密度RDIMMを採用しようとすると、コストは跳ね 上がります。

DRAM容量が足りなくなると、推論スタックのデータは通常、NVMeストレージへと退避されます。DRAMのアクセス速度が約200ナノ秒で あるのに対し、NVMeは約100,000ナノ秒です。トークン生成ループの真っ只中で発生するこのおおよそ500倍程のレイテンシペナルティを、GPUの処理能 力で隠蔽することはできません。パイプラインのストール（失速）は上流へと波及します。並列リクエストの状態を保持する場所がないためバッチサイズは縮小し、 Tensor Coreの稼働率は低下、スループットは失速し、トークンあたりの消費電力は急増します。クラスターは忙しそうに稼働しているように見えます。しかしその 実態は、「データ待ち時間」が含まれています。

なぜサーバーを増やすほど経済性は悪化するのか

メモリ不足に対する従来の解決策は、サーバーを増やすことでした。なぜなら、これまでメモリ容量を増やすにはサーバーを増設するしか 方法がなかったからです。しかし、AIワークロードにおいてこのアプローチは、この方法しか選択肢がなかった際の過去の対策となりつつあります。

サーバーを1台追加するたびに、本来は不要なCPUまで増え、望まない電力や冷却のオーバーヘッドが発生し、その筐体内に固定された新たな1〜 2TBのDRAMのサイロ（孤島）が生まれます。その一方で、各サーバーは自前のピーク負荷に合わせてメモリをプロビジョニングするため、フリート（サーバー群）全体で 見ると実際のメモリ利用率は平均30〜50%程度にとどまります。結果として、システム全体ではメモリを過剰に購入しているにもかかわらず、個々のワーク ロードは依然として「メモリの壁」に直面し続けることになります。あるノードで浮いている余剰容量を、隣のラックでGPUスタベーションに陥って いるワークロードへ融通することはできないのです。

これこそが、エンタープライズAIにおける「メモリの壁」の本質です。問題は、メモリ容量そのものが不足していることではなく、メモリ の配置と割り当ての方法にあります。必要なメモリ総量はすでに存在しているにもかかわらず、それが利用すべき場所ではなく、それぞれのサーバーに分散・固定化さ れているだけなのです。

メモリプーリングがアーキテクチャを変える

この課題に対する構造的な解決策が「メモリプーリング（Memory Pooling）」です。これはオープンなインターコネクト規格をベースにしており、メモリをサーバーの外部に配置しながら、高速・低レイテンシのファブ リックを介してメモリコヒーレンシ（整合性）を維持したまま接続できる仕組みです。メモリは各筐体に固定された属性ではなく、ファブリックが必要な場所へ 動的に割り当てる「プール化されたリソース」へと進化します。

LIQIDの「EX-5410C」は、このメモリプーリングを実現するファブリック製品であり、業界をリードするソリューションの一つです。

主な特長は次のとおりです。

• 1システム当たり最大100TBのDRAMをプール可能
• 最大32台のサーバーノード間で共有可能
• 約200ナノ秒のアクセスレイテンシ
• ネイティブDRAMに近い速度とアクセスレイテンシ

重要なのは、OSからは通常のメモリとして認識される点です。そのため、LLM推論基盤、データベース、ジョブスケジューラーなどの既存ソフトウェアを変更する必要はありません。
例えば、あるノードが長文コンテキストを扱う推論ジョブの実行に6TBのメモリを必要とする場合、その容量は共有メモリプールから動的に割り当てられます。そしてジョブの完了後には、そのメモリはプールへ返却され、次のワークロードで再利用されます。

このオーケストレーションを担うのが「LIQID Matrix」です。さらに、Kubernetes、Slurm、OpenShift、Ansibleと連携することで、 リソースの割り当てを新たなハードウェアの調達サイクルではなく、スケジューラーの実行サイクルに合わせてリアルタイムに行えるようになります。

「メモリの壁」を解消した先にあるもの

メモリの壁を取り除くと、その効果は推論基盤全体へと波及します。

KVキャッシュが低速なストレージへ退避せず、常に高速なメモリ上に保持されるため、トークン生成ループからあの 「500倍程のNVMeペナルティ」が完全に姿を消します。並列リクエストの状態をすべて格納できるようになることで、バッチサイズは4〜8倍へと拡大。これ によりTensor Coreの稼働率が跳ね上がり、トークンあたりの消費電力が削減されます。GPUがデータ待ちで空転する時間がなくなり、本来の計算処理にす べてのサイクルを費やせるようになるため、GPU利用率は劇的に向上します。固定構成のシステムと比較したLIQIDの測定結果では、ワットあたりのトークン生成数が2倍、ドルあたりのトークン生成数が50%向上するという成果が出ています。

さらに、システム全体の経済性も大きく変わります。これまではメモリを増やすためにサーバーを追加する必要がありましたが、メモリプーリン グでは、コンピュートリソースとは独立してメモリ容量を最適化できるようになります。
これまで各サーバーに分散し、30～50％程の容量が使われないままになっていたDRAMは、実際の総需要に応じて利用できる一つの共有メモリ プールとなります。また、各サーバーがそれぞれのピーク負荷を見込んで過剰なメモリを搭載する必要もなくなります。ピーク需要への備えはサーバー単位では なく、ファブリック全体で一度確保し、それを複数のサーバーで共有すればよいからです。
その結果、より少ないハードウェアで、より多くのAIワークロードを効率よく処理できるようになります。

今後の展望

LIQIDのメモリプーリングは、すでに本番環境での実運用が始まっています。さらに、CXLコンソーシアムが策定しているCXL 3.0／3.1のロードマップでは、2026年後半から2027年にかけて、複数ラックにまたがるメモリプーリングの実現が目標とされています。これによ り、現在のラック単位の共有メモリアーキテクチャは、ラック列全体へと拡張される見込みです。LIQIDはすでにメモリプーリングの最前線におり、この次世代アーキテクチャへの移行においても、企業の導入・運用を支える有力なポジションを確立しています。

2026〜2027年のインフラ戦略を検討している企業にとって、重要なメッセージは明確です。「メモリの壁」は、も はや制約事項として回避策を設計するようなものではありません。アプリケーション層に一切手を触れることなく、オープンスタンダードの上で、ネイティブ DRAM並みのレイテンシを維持しながら解決できる「既決のアーキテクチャ課題」なのです。いまだにメモリ確保の目的でサーバーを追加している利用者は、「メモリの壁」という既に解決可能な課題に対して、回避可能な追加の設備投資を負担し続けていると言えます。