イントロダクション：100万トークン時代の「メモリの壁」
「モデルのパラメータ数はもはや、推論コストの唯一の決定要因ではありません。真のボトルネックは、私たちが入力する『文脈（コンテキスト）』の中に潜んでいます」
近年、LLM（大規模言語モデル）の進化は目覚ましいものがあります。OpenAIのAPIでは、GPT-4oなどの旧モデルが廃止され、長文脈理解やツール実行機能が大幅に向上したGPT-5.2が新たな標準モデルへと移行しています。また、AnthropicのClaudeにおいても、Claude Sonnet 4.5から4.6への進化に伴い、ベータ版ながら100万トークンに達するコンテキストウィンドウがサポートされるようになりました。
このように、各社のモデルが数十万から100万トークンを超えるコンテキストを扱うようになり、RAG（検索拡張生成）や長文要約タスクにおいて革命的な利便性を提供しています。さらに、タスクの複雑度に応じて推論の深さを自動調整する機能（ClaudeのAdaptive Thinkingなど）や、コンテキスト上限に近づいた際の自動要約機能（Compaction）といった新しいアプローチも登場し、より高度な処理が可能になっています。システムを運用する上では、廃止されたレガシーモデルから最新モデルへの移行計画を立てるとともに、これらの新機能を活用したアーキテクチャの見直しが急務となっています。
しかし、その裏側でインフラエンジニアたちは、ある深刻な問題に直面しています。
それが「VRAM（ビデオメモリ）の枯渇」です。
「計算速度、つまりFLOPS（1秒間に処理できる浮動小数点演算の回数）の問題であれば、GPUを追加すればある程度は解決します。しかし、メモリ容量の問題、特にKVキャッシュによるVRAMの圧迫は、単純なスケールアウトでは解決しきれない構造的な課題を含んでいるのです」
本記事では、株式会社テクノデジタル 代表取締役であり、AIエージェント開発・研究者として最前線で活躍するHARITA氏にインタビューを行い、なぜ今「メモリ管理」が最大の技術的負債になり得るのか、そしてvLLMなどの最新技術がもたらす「PagedAttention」の本質的価値とは何かについて、語ってもらいました。
計算量より深刻なメモリ帯域幅の問題
――本日はよろしくお願いします。早速ですが、最近のLLM推論における最大の課題は何だとお考えですか？
HARITA： よろしくお願いします。一言で言えば、「Memory Wall（メモリの壁）」の再来ですね。これまでのAI開発、特に学習フェーズでは「いかに速く計算するか」が焦点でした。しかし、推論、それも100万トークン規模のロングコンテキストを扱う推論においては、「いかに効率よくメモリを使うか」が勝負の分かれ目になっています。
NVIDIAのH100のようなハイエンドGPUを使っても、その計算能力を使い切る前にVRAMが一杯になってしまうケースが後を絶ちません。これは、高速道路の車線は十分に広いのに、料金所の手前にある駐車場が満車で車が入ってこられないようなものです。経営者視点で見れば、高額なインフラ投資に対するROI（投資対効果）を著しく低下させる要因になり得ます。
――なるほど。駐車場、つまりVRAMがボトルネックだと。
HARITA： ええ。特にRAGシステムを構築している現場で、この課題は顕著です。業務システムに大量のドキュメントを参照させようとすると、プロンプトだけで数万から数十万トークンを消費します。さらに、最新モデルのように長文脈での推論や複雑なツール実行を行う場合、モデルの重みデータ（Weights）だけでなく、推論中に生成される一時データが爆発的に増えるのです。この一時データの管理こそが、今日のテーマである「KVキャッシュ」の話につながります。
Q1: なぜ「KVキャッシュ」が最大の技術的負債になるのか？
――「KVキャッシュ（Key-Value Cache）」という言葉はよく耳にしますが、具体的に何がそんなに問題なのでしょうか？
HARITA： KVキャッシュ自体は悪者ではありません。むしろ、LLMがスムーズに言葉を紡ぐための「必須の記憶」なんです。Transformerモデルの仕組み上、次の単語を予測するためには、これまで生成したすべての単語の情報を参照する必要があります。毎回最初から計算し直していたら、計算量が膨大すぎて実用的なスピードは出ません。
そこで、過去の計算結果（KeyとValueのテンソル）をメモリ上に保存（キャッシュ）しておき、再利用する。これがKVキャッシュです。問題は、このキャッシュが「あまりにも場所を取りすぎる」ことです。
自己回帰生成におけるメモリ消費のメカニズム
――場所を取るとは、具体的にどれくらいの量なのでしょうか？
HARITA： 良い質問です。少し技術的な話をしましょうか。KVキャッシュのサイズは、以下の要素に比例して線形に増加します。
- バッチサイズ（同時に処理するリクエスト数）
- シーケンス長（入力トークン数 + 生成トークン数）
- モデルの層の数（Layers）
- 隠れ層の次元数（Hidden Size）
例えば、70B（700億パラメータ）クラスのモデルで、FP16（16ビット浮動小数点）精度を使い、コンテキスト長が32kトークンだとしましょう。この時、1つのリクエストに対するKVキャッシュだけで、数GBから十数GBのVRAMを消費することがあります。もしバッチサイズを増やして10人、20人のユーザーを同時に捌こうとすれば...。
――あっという間に80GBのVRAMが埋まってしまいますね。
HARITA： その通りです。モデル本体の重みが140GBくらいあるとして、残りのVRAM領域をKVキャッシュで奪い合うわけです。しかも、ここには「見えない浪費」が隠されています。
静的確保から動的確保へのパラダイムシフト
――見えない浪費？
HARITA： 従来のディープラーニングフレームワーク、例えばPyTorchの標準的な実装などは、メモリを「連続した領域」として確保しようとする傾向があります。そして、最大シーケンス長に合わせてあらかじめメモリを予約（Reserve）してしまうことが多いんです。
例えば、最大2048トークンまで生成できる設定にしていると、実際には「こんにちは」と5文字しか返さない場合でも、2048トークン分のメモリ領域を確保してしまう。これを「内部断片化（Internal Fragmentation）」と呼びます。
――それはもったいないですね。ガラガラのレストランで、1人客のために8人席をリザーブしているような状態ですね。
HARITA： まさにその例えです！ しかも、隣の席との間隔も空けないといけないから、実際にはもっと無駄が多い。最適化されていないシステムでは、VRAMのかなりの割合がこの「予約されているけど使われていない」無駄な領域として浪費されている可能性があります。
これを解決しない限り、どんなに高価なGPUを並べても、ロングコンテキスト時代の推論基盤としては不十分と言わざるを得ません。ここで登場するのが、システム思考に基づいたアプローチです。
Q2: 技術選定の分かれ道：PagedAttentionとその他のアプローチ
――そこで注目されているのが、vLLMなどで採用されている「PagedAttention」ですね。これはどのような技術なのでしょうか？
HARITA： PagedAttentionは、一言で言えば「OS（オペレーティングシステム）のメモリ管理技術をAIに輸入した」ものです。コンピューターサイエンスの基礎に立ち返った、非常に興味深い解決策です。
OSのメモリ管理に学ぶ仮想メモリ方式
――OSの技術というと、仮想メモリのことでしょうか？
HARITA： その通りです。OSは、物理メモリがバラバラに散らばっていても、それを「ページ」という単位で細切れに管理し、あたかも連続したメモリがあるかのようにCPUに見せかけますよね？ PagedAttentionはこれと同じことをKVキャッシュに対して行います。
従来のAttentionアルゴリズムは、KVキャッシュがメモリ上で連続していることを前提としていました。しかし、PagedAttentionはKVキャッシュを小さなブロックに分割し、メモリ上の空いている場所に飛び飛びで保存することを可能にします。
これによって何が起きるか。
- 事前予約が不要になる: 必要な時に必要な分だけブロックを確保すればいい。
- 断片化の解消: メモリの隙間（ホール）を有効活用できるので、無駄な空き領域がほぼゼロになる。
結果として、同じGPUでも、扱えるバッチサイズが数倍に跳ね上がります。スループット（単位時間あたりの処理量）が劇的に向上するわけです。ビジネスの観点から見れば、インフラコストを抑えつつサービス提供規模を拡大できる、非常に強力な武器になります。
――FlashAttentionとはどう違うのですか？ よく混同されるのですが。
HARITA： よく聞かれます（笑）。簡単に整理しましょう。
- FlashAttention: 「計算速度」の最適化です。メモリへのアクセス回数を減らすことで、計算そのものを速くします。
- PagedAttention: 「メモリ容量」の最適化です。メモリの無駄遣いをなくすことで、より多くのデータを詰め込めるようにします。
実はこれらは競合するものではなく、補完関係にあります。最新のvLLMなどは、バックエンドでFlashAttentionのカーネルを使いつつ、メモリ管理にPagedAttentionを使うというハイブリッド構成が主流です。
量子化（Quantization）との併用におけるトレードオフ
――他にもVRAM節約術として、4bit量子化やAWQなどが流行っていますが、これらとの関係は？
HARITA： 量子化は「データの密度を下げる」アプローチです。KVキャッシュ自体をFP16からINT8やFP8に圧縮する技術（KV Cache Quantization）も実用化されています。
ただ、アーキテクトとして注意したいのは「精度の劣化」です。特に日本語のような複雑な言語や、厳密な論理性が求められるタスクでは、過度な量子化が回答品質に悪影響を与えることがあります。
PagedAttentionの良いところは、「精度を一切犠牲にしない」点です。データの中身を変えるのではなく、置き方を変えるだけですから。まずはPagedAttentionで物理的な無駄をなくし、それでも足りない場合に量子化を検討する。この順序が、リスク管理の観点からは妥当だと考えられます。
Q3: 現場の「落とし穴」：理論値が出ない時のデバッグ視点
――非常に強力な技術であることは分かりました。では、vLLMさえ導入すれば万事解決なのでしょうか？
HARITA： いえ、そこが落とし穴です。「銀の弾丸はない」というのはAI開発でも同じです。実務の現場では、「vLLMを入れたのに期待したほど速くならない」「逆にレイテンシが悪化した」という声も聞かれます。まずはプロトタイプを作って実際に動かし、仮説を検証するプロセスが不可欠です。
バッチサイズとシーケンス長のジレンマ
――なぜそんなことが起きるのですか？
HARITA： 「スループット」と「レイテンシ」のトレードオフを見誤っているケースが多いですね。
PagedAttentionを使うと、メモリ効率が良くなるので、バッチサイズを極端に大きく設定できます。例えば、同時に200リクエストを処理できるようになったとしましょう。しかし、200個のリクエストを一度に計算するということは、それだけ1回の計算サイクルに時間がかかるということです。
結果として、個々のユーザーから見ると「最初の1文字が出てくるまでが遅い（TTFT: Time to First Tokenが悪化）」とか「生成速度がもっさりしている（TPOT: Time Per Output Tokenが悪化）」という体感になります。
――サーバー全体の処理量は増えているけど、一人ひとりの待ち時間は増えてしまうわけですね。
HARITA： その通りです。特にチャットボットのようなリアルタイム性が求められる用途では、バッチサイズを詰め込みすぎない方が良いでしょう。逆に、夜間のバッチ処理で大量のドキュメントを要約するなら、レイテンシを犠牲にしてでもバッチサイズを最大化すべきです。
このあたりのパラメータ（max_num_seqs や block_size など）を、自社のユースケースに合わせてチューニングできるかどうかが、エンジニアの腕の見せ所ですね。技術の本質を見抜き、ビジネス要件への最短距離を描く設計が求められます。
マルチGPU環境での通信ボトルネック
――他に気をつけるべき点はありますか？
HARITA： マルチGPU環境での「通信オーバーヘッド」です。巨大なモデルを複数のGPUに分割して載せる（テンソル並列化）場合、KVキャッシュの管理も分散されます。
PagedAttentionは複雑なメモリ管理を行うため、GPU間の同期タイミングがシビアになります。NVLinkのような高速なインターコネクトがない環境、例えばPCIeだけで接続されたコンシューマー向けGPUのクラスターなどでは、通信待ちがボトルネックになって、PagedAttentionの恩恵が相殺されてしまうこともあります。
ハードウェア構成とソフトウェア設定のバランス。ここをシステム全体として俯瞰（ふかん）する視点が欠かせません。
Q4: 将来への投資：これからの推論基盤はどうあるべきか
――最後に、今後の展望についてお聞かせください。HBM（広帯域メモリ）の容量は増え続けていますが、それでもソフトウェア的な工夫は必要でしょうか？
HARITA： 間違いなく必要です。ハードウェアの進化は素晴らしいですが、それ以上に「人間の欲望」の進化が速いからです（笑）。
今は100万トークンで驚いていますが、すぐに1000万、1億トークンのコンテキストを扱いたいというニーズが出てくるでしょう。動画や音声などのマルチモーダルデータをコンテキストに含めれば、データ量は桁違いに増えます。ハードウェアの進化を待っているだけでは、ビジネスのスピードに追いつけない可能性があります。
ハードウェア進化とソフトウェアの役割分担
――具体的に注目している次世代技術はありますか？
HARITA： 「Prefix Caching（プレフィックス・キャッシング）」あるいは「Prompt Caching」と呼ばれる技術に注目しています。
これは、システムプロンプトや、RAGで頻繁に使われる共通のドキュメント部分のKVキャッシュを、リクエスト間で共有・使い回す技術です。PagedAttentionのブロック構造を利用すれば、同じデータに対応するブロックを複数のユーザーで参照するだけで済みます。
これにより、メモリ消費を抑えるだけでなく、プロンプトの処理時間をほぼゼロに短縮できます。これは「計算しない」という究極の最適化です。
コンテキストウィンドウ無限化への備え
――それはRAGにおいては革命的ですね。
HARITA： ええ。これからの推論基盤アーキテクトは、「モデルをどう動かすか」だけでなく、「キャッシュをどう管理・共有するか」を設計する必要があります。ステートレスなAPIサーバーという概念から、ステートフルなキャッシュサーバーという概念への転換が求められるかもしれません。
技術は日々変わりますが、「限られたリソースで最大の価値を生む」というエンジニアリングの本質は変わりません。変化を恐れず、しかし基本原理を大切にする。まずは手を動かしてプロトタイプを作り、アジャイルに検証を繰り返す。そんな姿勢でインフラを作っていきたいですね。
編集後記：メモリを制する者がLLMを制する
インタビューを通じて見えてきたのは、VRAM不足という事象が単なる「容量の問題」ではなく、計算リソースの管理手法そのものの変革を求めているという事実でした。
- KVキャッシュの肥大化は構造的な課題: ロングコンテキスト時代において、メモリ管理は計算速度以上に重要なファクターとなる。
- PagedAttentionはパラダイムシフト: OSの仮想メモリ技術を応用し、物理メモリの断片化を解消することで、ハードウェアのポテンシャルを最大限に引き出す。
- 「銀の弾丸」ではない: 導入後のバッチサイズ調整や、レイテンシとスループットのバランス設計こそが、エンジニアの真価を問う。
これからのAIエンジニアには、モデルのアルゴリズムだけでなく、その下のレイヤーであるシステムアーキテクチャへの深い理解が求められます。
コメント