LLM推論の「見えないメモリ問題」を解く：トークンレベル仮想化でKVキャッシュを再利用可能にする「vToken」

LLM推論はなぜメモリで詰まるのか：KVキャッシュの正体

LLM（大規模言語モデル）の推論がメモリ不足で詰まる最大の原因は、モデル本体ではなく「KVキャッシュ（Key-Value Cache）」にある。KVキャッシュとは、推論中に過去トークンそれぞれのKeyベクトルとValueベクトルを保持するメモリ領域のことだ。LLMはトークンを1個生成するたびに、それまでの全トークンとの関連度を注意機構（Attention）で計算する。このとき過去分のKey/Valueを毎回再計算すると計算量が爆発するため、一度計算した値をキャッシュに保存し、新規トークン分だけを追加計算する仕組みになっている。KVキャッシュがなければ、生成のたびに過去全体を再計算するか、文脈を無視した推論に退化してしまう。つまり、これはLLM推論に必須のメモリ領域である。

問題はサイズの増え方にある。KVキャッシュの容量は「シーケンス長×バッチサイズ×レイヤー数×隠れ次元×2（KとV）×精度バイト数」で近似でき、シーケンス長とバッチサイズに比例して線形に増加する。例えばLlama-2 7B（32層・隠れ次元4,096）をFP16で動かすと、1トークンあたり約512KiBのキャッシュが必要だ。

4,096トークンで約2GiBという数字は、モデル重み（約13GiB）と比べても無視できない。リクエストを複数並列処理するバッチ運用ではこの値がバッチサイズ倍になり、数百GB級のGPUメモリでもすぐに枯渇する。

推論エンジンのスループットは「どれだけ多くのリクエストを並列処理できるか」で決まるが、その上限を握るのがKVキャッシュのメモリである。1リクエストあたり数GiBのキャッシュが必要な状況でバッチサイズを増やすと、GPUメモリは瞬時に満杯になる。すなわちKVキャッシュのメモリ効率が、LLM推論基盤のスループット上限を直接決めている。

PagedAttention：OSの仮想記憶に学んだブロック管理

PagedAttentionは、vLLMの中核技術としてSOSP 2023で発表されたKVキャッシュ管理方式である。OSの仮想記憶（ページング）に着想を得て、KVキャッシュを固定サイズのブロック（1ブロックあたり16トークン）に分割して管理する。従来の連続メモリ確保方式では、各リクエストに連続したメモリ領域を事前に確保する必要があった。そのため、リクエストごとに必要なトークン数が異なる場合、確保済み領域の間に小さな空き領域（メモリホール／アロケータレベルのフラグメンテーション）が発生し、メモリ利用率が低下する。PagedAttentionはブロック単位で動的に割り当てることでこの断片化を解消し、不要になったブロックを即座に解放して別のリクエストに再利用できるようにした。

flowchart LR
    subgraph 従来方式[従来: 連続メモリ確保]
        A1[リクエストA<br>8トークン] --> M1[確保済み<br>8トークン分]
        A2[空き領域<br>3トークン分]
        A3[リクエストB<br>5トークン] --> M2[確保済み<br>5トークン分]
        A4[空き領域<br>2トークン分]
    end
    subgraph PagedAttention[PagedAttention: ブロック管理]
        B1[ブロック#1<br>リクエストA<br>8/16トークン]
        B2[ブロック#2<br>リクエストA<br>8/16トークン]
        B3[ブロック#3<br>リクエストB<br>5/16トークン]
        B4[ブロック#4<br>空き]
        B5[ブロック#5<br>空き]
    end

このブロック管理により、vLLMは従来の推論システム（Hugging Face TransformersやFasterTransformerの連続メモリ方式）と比較して、2〜4倍のスループット向上を達成した。不要ブロックの解放と再利用の効率化がこの高速性の基盤であり、vLLMが広く使われる理由の一つである。なお、ブロックサイズに16トークンが選ばれたのは、GPUメモリのキャッシュラインやカーネル実行効率、メモリ割り当ての粒度を考慮したバランス点である。ただし、このブロック単位の粒度は、後述するトークン削除ポリシーとの間で「ブロック内フラグメンテーション」という新たな問題を生むことになる。

トークン削除ポリシー登場：メモリ削減の「次の一手」

PagedAttentionがKVキャッシュの管理粒度を「ブロック」に変えたのとは別のアプローチとして、トークン削除ポリシーと呼ばれる研究群が注目を集めている。これらは「キャッシュ内のトークンのうち、推論に不要なものを削除してメモリを節約する」という発想に基づく。代表的な手法として、H2O、Scissorhands、StreamingLLMの3つが挙げられる。

**H2O（Heavy-Hitter Oracle, NeurIPS 2023）**は、注意機構のスコアが高いトークン（ヘビーヒッター）だけを保持し、残りを削除する方式である。各トークンが過去の全トークンからどれだけ注目されているかを累積し、その値が上位のトークンを優先的に残す。論文によれば、全トークンの20%だけを保持しても推論精度を保ちつつ、最大29倍のスループット向上が可能である。ヘビーヒッターは一度出現すると将来も高い注意スコアを維持する傾向があるため、少ない保持率でも精度が維持される。

Scissorhandsは、「重要度の永続性仮説」という発見に基づく。これは「ある時点で重要だったトークンは、将来の時点でも重要である可能性が高い」という観察結果である。Scissorhandsは確率的なアルゴリズムで重要トークンを選択し、KVキャッシュを最大5倍に圧縮する。さらに4ビット量子化と組み合わせれば最大20倍の圧縮が可能と報告されている。

**StreamingLLM（ICLR 2024）**は、少し異なる視点から問題にアプローチする。「Attention Sink（注意の沈み）」現象——初期トークンが不当に高い注意スコアを集めてしまう性質——に着目し、初期トークンと最新トークンのみを保持する戦略を採用した。この方式により、無限長のストリーミング推論を実現し、最大22.2倍の高速化を達成している。

これらの手法に共通するのは、トークン単位で「削除する/しない」を判断する点である。ブロック単位のPagedAttentionとは対照的に、削除ポリシーはより細かい粒度でメモリを効率化しようとしている。しかし、この粒度の差異が、次節で解説する「ブロック内フラグメンテーション」という新たな問題を引き起こすことになる。

見落とされていた落とし穴：ブロック内フラグメンテーション

PagedAttentionはKVキャッシュをブロック単位（16トークン）で管理し、H2OやScissorhandsなどの削除ポリシーはトークン単位で不要な要素を捨てる。ここに「管理粒度のミスマッチ」が潜んでおり、これが**ブロック内フラグメンテーション（intra-block fragmentation）**という落とし穴を生む。ブロック内フラグメンテーションとは、ブロックの中に削除済みトークンと生存トークンが混在することで、そのブロック全体を解放できなくなる現象を指す。

具体例で見てみよう。1ブロック16トークンのうち、削除ポリシーによって10トークンが削除対象になったとする。残るのは6トークンだけだが、PagedAttentionの解放単位はブロック単位であるため、生存トークンが1つでも残っている限り、そのブロックは「未使用だが占有中」のままメモリ上に居座り続ける。削除した10トークン分の領域は実際には空いているのに、ほかのリクエストからは一切使えない。つまり「削除したのにメモリが減らない」という状態が発生する。

flowchart LR
    subgraph ブロックA["ブロック#A（16トークン）"]
        A1["✓ 生存"]
        A2["✗ 削除"]
        A3["✓ 生存"]
        A4["✗ 削除"]
        A5["✗ 削除"]
        A6["✓ 生存"]
        A7["✗ 削除"]
        A8["✗ 削除"]
        A9["✓ 生存"]
        A10["✗ 削除"]
        A11["✗ 削除"]
        A12["✓ 生存"]
        A13["✗ 削除"]
        A14["✗ 削除"]
        A15["✓ 生存"]
        A16["✗ 削除"]
    end
    subgraph 結果["解放判定"]
        R1["生存トークンが残っているため<br>ブロック全体を解放できない"]
    end
    ブロックA -- "✓ 6 / ✗ 10" --> 結果

この問題の深刻さは、生存トークンが少ないブロックほどメモリの実効利用率が下がる点にある。H2OやScissorhandsをvLLMに統合しても、削除ポリシーが「捨てた」トークン分だけメモリが本当に解放されるわけではない。極端な例では、16トークンのうち1トークンしか生存していないブロックが大量に発生し、ブロック全体のうち約6%しか使われないままメモリを占有し続ける。削除率を上げれば上げるほど断片化が進み、理論上の削除効果と実際のメモリ節約量との乖離が拡大する。

この状況は、OSにおける物理メモリの断片化と構造的に似ている。仮想記憶を備えたOSなら、ページ単位の再配置（リパッキング）やスワップによって物理領域を詰め直し、断片化を解消できる。しかしLLM推論のKVキャッシュでは、トークンの物理的な並びを変えると注意機構の計算前提やキャッシュ済みの実行グラフが崩れるため、従来は再配置が実現されていなかった。ブロック管理という「大きな一歩」の裏で、この粒度のズレは長らく見落とされていたのである。

vTokenの核心アイデア：トークンレベル仮想化

vTokenの基本思想は、論理的なトークンの「生存状態」と物理的なブロック配置を分離する仮想化レイヤーを導入することにある。OSの仮想記憶がプロセスの論理アドレスと物理ページを分離して管理するのと同じ発想で、KVキャッシュにも「トークンの論理的な見え方」と「実際のメモリ上の置き場所」を別々に管理する層を挟む。これにより、ブロック内フラグメンテーションの原因だった「トークン単位の削除」と「ブロック単位の解放」という粒度の不一致を、メモリ管理層だけで吸収できる。

中心となる仕組みが**トークンテーブル（token table）**による間接参照である。トークンテーブルは各トークンの論理アドレスを管理する対応表で、モデルから見たシーケンス上の位置（何番目のトークンか）と、物理ブロック上の実位置（どのブロックの何番目か）をマッピングする。推論計算は常にトークンテーブル経由でKVキャッシュを参照するため、物理配置がどう変わっても、モデルからは論理的な順序が保たれているように見える。

削除対象トークンが発生したブロックに対しては、非同期リパッキングが働く。リパッキングとは、生存トークンをほかのブロックへ移動して空きを詰める処理だ。たとえば16トークンのブロックで4トークンだけが生き残った場合、その4トークンを空き領域のあるブロックへ移動し、空になったブロックを即座に解放して別のリクエストに再利用する。「非同期」である点が重要で、リパッキングは推論計算と並行してバックグラウンドで実行されるため、生成処理のレイテンシに影響を与えない。

sequenceDiagram
    participant M as 推論エンジン
    participant TT as トークンテーブル
    participant B as 物理ブロック群
    M->>TT: 論理トークン#3 の参照要求
    TT->>B: ブロック#A の位置2を指し示す
    Note over TT,B: ブロック#A に削除トークンが混在し<br/>生存トークンは4つのみ
    M->>TT: リパッキング要求（非同期）
    TT->>B: 生存トークンをブロック#Bへ移動
    B->>TT: マッピングを更新（論理順序は不変）
    B->>M: ブロック#A を解放・再利用可能に

設計の巧みさは、トークンテーブルの間接化により「論理的な順序」と「物理配置」が完全に分離された点にある。従来は物理配置を変えるとCUDA GraphやPagedAttentionカーネルの前提が崩れるため再配置が不可能だったが、vTokenではモデルから物理アドレスが見えないため、リパッキングを安全に実行できる。この間接化レイヤーが、削除ポリシーが「捨てた」トークンのメモリを初めて現実の解放へと変換するのである。

互換性を守る設計：PagedAttentionとCUDA Graphを壊さない

vTokenのトークンテーブルによる間接参照と非同期リパッキングは、メモリ効率を向上させるだけでなく、既存の推論エンジンとの互換性を維持するという重要な制約を満たすように設計されている。この互換性がなければ、どれだけ優れたアイデアでも実運用に導入する障壁は極めて高い。

CUDA Graphがもたらす制約とその本質

CUDA Graphは、GPU上の一連のカーネル起動を事前にキャプチャし、最適化された実行グラフとして再利用する仕組みである。通常、GPUカーネルを起動するたびにCPUからGPUへの命令発行（カーネル・ローンチ）のオーバーヘッドが発生するが、CUDA Graphはこの一連の処理を「グラフ」として事前に記録し、ワンショットで実行することでレイテンシを削減する。LLM推論のように同様の計算パターンが繰り返し実行されるワークロードでは、この効果が顕著である。

しかしCUDA Graphには重要な制約がある。キャプチャ時にKVキャッシュの物理アドレスが固定され、グラフ内にそのアドレスが直接埋め込まれる。そのため、推論実行中にKVキャッシュの物理配置を変更すると、キャプチャ済みのグラフが無効になり、再キャプチャが必要になる。vLLMのPagedAttentionもCUDA Graphを活用して高速な推論を実現しており、ブロック単位のメモリ管理はこのグラフ構造と密接に結合している。トークン削除ポリシーを導入してブロック内のデータを移動させようとすると、この結合が壊れるリスクがある。

トークンテーブルによる間接化が解決する互換性問題

vTokenはこの問題を、トークンテーブルによる間接参照で解決する。モデルの推論計算（PagedAttentionカーネル）は、従来通り物理ブロック上のデータを参照する。トークンテーブルは論理トークンと物理ブロックのマッピングを管理するだけで、計算そのものには介入しない。非同期リパッキングは、推論計算の合間のアイドル時間に実行され、生存トークンを別のブロックへ移動する。この移動はトークンテーブルのエントリを更新するだけで完了するため、PagedAttentionカーネルやCUDA Graphのキャプチャ済み実行グラフに影響を与えない。

sequenceDiagram
    participant Model as モデル推論計算
    participant TT as トークンテーブル
    participant Phys as 物理ブロック
    participant Async as 非同期リパッカー

    Note over Model,Async: ① 推論中の通常動作
    Model->>TT: 論理トークン位置を問い合わせ
    TT->>Phys: 物理ブロックアドレスを返す
    Model->>Phys: PagedAttentionカーネルで計算（CUDA Graph実行）

    Note over Model,Async: ② リパッキング（非同期）
    Async->>Phys: 生存トークンを別ブロックへコピー
    Async->>TT: マッピングエントリを更新
    Async->>Phys: 空いたブロックを解放

    Note over Model,Async: ③ 次の推論サイクル
    Model->>TT: 同じ論理トークン位置を問い合わせ
    TT->>Phys: 新しい物理ブロックアドレスを返す
    Model->>Phys: 変更に気づかず計算継続（CUDA Graph再キャプチャ不要）

この間接化により、モデルの推論計算からは物理アドレスの変化が完全に隠蔽される。CUDA Graphの再キャプチャは不要で、PagedAttentionカーネルの修正も最小限に抑えられる。vTokenの論文では、トークン削除ポリシーの統合に必要なコード量が500行超から50行未満に削減されたと報告されている。この統合の容易さは、互換性を重視した設計の成果である。

実運用における互換性の意義

vLLMは既に多くのプロダクション環境で稼働しており、カーネルや実行グラフの変更は運用中のシステムに大きなリスクをもたらす。vTokenが既存のPagedAttentionカーネルとCUDA Graphをそのまま利用できることは、導入時に既存の動作を保証できることを意味する。新しいメモリ管理技術を導入する際の最大の障壁は「動いているものを壊すリスク」であるが、vTokenはこのリスクを最小化する設計を採用している。

実装と評価：vLLM統合で検証された効果

vTokenは実際の推論エンジンであるvLLMに統合され、H2O・Random・Scissorhandsという3つの代表的なトークン削除ポリシーでその効果が検証された。評価には複数モデルが使用され、KVキャッシュ管理の改善が実運用レベルの指標でどの程度の効果を生むのかが定量的に示されている。

保持ブロック数の大幅削減

最も重要な成果は、Naive-Evict（削除対象トークンを含むブロックをそのまま維持する素朴な方式）をベースラインとした場合、リクエストあたりの保持ブロック数が27.2%〜72.3%削減されたことだ。これはブロック内フラグメンテーションが解消され、実際に不要になったトークンのメモリが物理的に解放・再利用できたことを意味する。削除ポリシーが削除対象として選んだトークンの分だけ、メモリが本当に回収されるようになった。

スループットと同時実行数の向上

メモリの実効利用率が上がった結果、GPU上で同時に処理できるリクエスト数も拡大した。SLA（サービス品質合意）制約下のスループットは最大1.37倍に向上し、アクティブなKVキャッシュ予算が制約される条件下では、最大同時実行数（concurrency）が最大2倍に拡大している。KVキャッシュのメモリ上限がバッチサイズの制約になるというLLM推論の基本的な構造において、解放されたメモリ分をそのまま追加の並列処理に振り向けられることが、この数字の根拠である。

統合コストの劇的な削減：500行超から50行未満へ

vTokenの設計上の特徴として、削除ポリシーとメモリ管理の分離が挙げられる。従来、H2Oのような削除ポリシーをvLLMに統合するには500行を超えるコード変更が必要だったが、vTokenのトークンテーブルによる間接参照レイヤーを利用することで、統合に必要なコード量は50行未満にまで削減された。削除ポリシーは「どのトークンを削除するか」の判断だけに集中し、実際のメモリ解放・ブロック管理はvTokenが担うため、新しいポリシーの追加が大幅に容易になっている。

方式間の比較

flowchart LR
    A[削除ポリシー<br/>H2O / Random / Scissorhands] -->|トークン選択の判断のみ| B[vToken メモリ管理レイヤー]
    B -->|トークンテーブル経由| C[ブロックの解放・再利用]
    B -->|非同期リパッキング| D[フラグメンテーション解消]
    C --> E[保持ブロック数 27.2〜72.3%削減]
    D --> F[同時実行数 最大2倍]
    F --> G[SLA制約下スループット 最大1.37倍]

この評価結果は、vTokenが理論上の提案に留まらず、既存のvLLM運用環境に対して実際の改善をもたらすことを示している。特に削除ポリシーの統合コストが劇的に下がった点は、運用面での実用性を大きく押し上げる要素と言える。

なぜこれが重要なのか：AIインフラの「次の常識」へ

LLMエージェントや長文コンテキスト処理の需要が拡大し続ける中、KVキャッシュのメモリ問題は今後さらに深刻化する。エージェントは複数回の推論を連鎖させ、各ステップで長い履歴を保持するため、1セッションあたりのキャッシュ消費量は従来のチャット用途を大きく上回る。数千〜数万トークンのコンテキストを扱うアプリケーションが一般化すれば、KVキャッシュの容量がGPUメモリの主要な消費源となり、推論基盤のスループットとコストを直接左右する。メモリ管理の効率化は、もはや任意の最適化ではなく、AIインフラの必須要件になりつつある。

これまで、トークン削除ポリシー（H2OやScissorhands）とメモリ管理（PagedAttention）は別々の研究ラインとして進化してきた。削除ポリシーは「どのトークンを捨てるか」を理論的に追求し、メモリ管理は「メモリをどう割り当てるか」を工学的に追求してきた。しかし両者の粒度の不一致がブロック内フラグメンテーションを生み、理論上の削除効果が実メモリ節約に結びつかないという断絶があった。vTokenはこの二つを橋渡しする「管理レイヤー」を提供し、削除ポリシーの成果を初めて実際のメモリ解放へと変換する。研究と実運用の間のこの溝を埋める点に、vTokenの最大の意義がある。

将来の展望も広がっている。主要な方向性は以下の通りだ。

トークンテーブルによる間接化はエンジン固有のカーネル実装に依存しないため、原理的にはこれらすべてに適用可能だ。特に分散推論では、ブロック内フラグメンテーションがノード間のメモリ不均衡を悪化させるため、非同期リパッキングによる再配置がより大きな効果を発揮すると見込まれる。

vTokenは「削除ポリシーの性能を引き出すための土台」であり、実運用で既存研究の理論的メリットを実際のメモリ節約へ変える役割を果たす。PagedAttentionがブロック管理を推論エンジンの「次の常識」にしたように、vTokenはトークンレベル仮想化という管理レイヤーをLLM推論基盤の標準的な構成要素へ押し上げる可能性を秘めている。

よくある質問

KVキャッシュとは何ですか？

KVキャッシュ（Key-Value Cache）は、LLMがトークンを逐次生成する際に、過去の各トークンに対応するアテンション機構の中間状態——KeyベクトルとValueベクトル——を保持するメモリ領域です。アテンション計算では、現在のトークンが過去すべてのトークンとの関連度を計算する必要があるため、このキャッシュがなければ毎回全トークンの再計算が発生し、推論が事実上成立しません。シーケンス長が長くなるほどKVキャッシュは線形に増加し、Llama-2 7Bのような中規模モデルでも数GBに達することがあり、推論サーバーのメモリ制約の主要因となっています。

PagedAttentionのブロックサイズはなぜ16トークンなのですか？

16トークンというブロックサイズは、GPUメモリのキャッシュラインサイズやCUDAカーネルの実行効率、メモリアロケーションの粒度などを考慮した上で、フラグメンテーションの抑制と計算効率のバランス点として選ばれています。ブロックサイズを小さくすればメモリの無駄は減るものの、ブロック管理のテーブルサイズが増大し、GPUカーネル内での並列処理効率が低下します。逆に大きくすれば管理コストは下がりますが、ブロック内の未使用領域が増えやすくなります。ただし、ブロック内フラグメンテーションの問題はブロックサイズの大小にかかわらず原理的に発生するものであり、サイズの調整だけでは解決できません。

vTokenはどのLLMでも使えますか？

vTokenは特定のモデルアーキテクチャに依存しない汎用的なKVキャッシュ管理レイヤーとして設計されており、vLLM上で動作するあらゆるLLMに適用可能です。論文の評価でもOPTやLlama系など複数のモデルで検証されています。ただし、vTokenはH2OやScissorhandsなどのトークン削除ポリシーと組み合わせて使用することを前提としているため、削除ポリシーが対象モデルに与える精度への影響は個別に評価する必要があります。vToken自体は削除ポリシーの精度特性を変えずにメモリ解放効果だけを高めるため、精度検証は採用する削除ポリシーの選定時に実施すれば十分です。

トークンを削除すると推論精度は下がりますか？

トークン削除ポリシー自体の精度への影響は、H2OやScissorhands、StreamingLLMなどの既存研究で広く検証されており、多くのタスクでは保持トークン数を適切に設定すれば精度低下を最小限に抑えられることが確認されています。vTokenはこれらの削除ポリシーの精度特性に一切手を加えず、「削除されたトークンが占有していたメモリを実際に解放する」ことだけを担当します。したがって、vTokenを導入することによる精度への追加的な影響はありません。削除ポリシーの性能を最大限に引き出し、理論上のメモリ節約効果を実運用で実現するための基盤技術と位置づけられます。

ブロック内フラグメンテーションを手動で解消できないのはなぜですか？

KVキャッシュ内のトークンを手動で並べ替えてブロックを詰めることは理論上可能ですが、推論実行中の物理アドレス変更はCUDA Graphのキャプチャ済み実行グラフを無効化し、PagedAttentionのGPUカーネルが前提とするメモリ配置を破壊します。CUDA GraphはGPUカーネル起動のオーバーヘッドを削減するために一連の処理を事前にキャプチャして最適化する仕組みであり、一度キャプチャされた物理アドレスが変わるとグラフ全体を再キャプチャする必要が生じ、推論レイテンシが大幅に悪化します。vTokenはトークンテーブルによる間接参照を導入することで、モデルから見た論理的なトークン順序は変えずに物理配置だけを安全に変更し、この問題を解決しています。

まとめ

本記事で見てきたように、LLM推論のメモリ問題の本質はKVキャッシュにある。KVキャッシュはシーケンス長に比例して線形に増加し、Llama-2 7Bクラスのモデルでも長いコンテキストではGB級に達する。これを管理するPagedAttentionはブロック単位（16トークン）でメモリを扱う一方、H2OやScissorhandsといったトークン削除ポリシーはトークン単位で削除を判断する。この粒度のミスマッチにより、削除対象トークンが混在するブロックは解放できず「ブロック内フラグメンテーション」が発生する。削除ポリシーの理論上の効果が、実際のメモリ節約に必ずしも結びつかないのはこのためだ。

vTokenはこの問題を「トークンレベル仮想化」で解消する。トークンテーブルによる間接参照で、論理的なトークン順序と物理的なブロック配置を分離し、削除対象が発生したブロックの生存トークンを非同期リパッキングで別ブロックへ移動させて空きブロックを即座に解放する。モデルから見たシーケンスは不変のまま物理配置だけを変更できるため、PagedAttentionカーネルやCUDA Graphとの互換性も維持される。この設計により、削除したトークンのメモリが確実に解放・再利用されるようになる。

評価で確認された効果は以下の通りだ。

さらに、削除ポリシーとメモリ管理を分離した設計により、新しいポリシーの追加コストも大幅に下がった。H2O等の既存研究は「どのトークンを消すか」を追求し、PagedAttentionは「メモリをどう割り当てるか」を追求してきたが、vTokenはその両者をつなぐ管理レイヤーとして機能する。LLMエージェントや長文コンテキスト処理の需要が拡大する中で、理論上のメモリ節約を実運用のスループット向上へ変えるこの技術は、LLM serving基盤の「次の常識」になり得る。

参考資料

1. vToken: Token-Level Virtualization for Reclaimable KV Caches
2. vToken (HTML)
3. Efficient Memory Management for Large Language Model Serving with PagedAttention
4. H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models
5. Scissorhands: Exploiting the Persistence of Importance Hypothesis for LLM KV Cache Compression at Test Time
6. Efficient Streaming Language Models with Attention Sinks
7. vLLM GitHub
8. H2O GitHub
9. StreamingLLM GitHub
10. vLLMとPagedAttention：LLM推論の革新的技術 (Qiita)
11. PagedAttentionとは？効率的なLLMメモリ (Ultralytics)
12. vLLMってなんだ？〜ローカルLLM推論を爆速化するOSSエンジン〜 (Qiita)
13. SGLang (GitHub)
14. ChatPaper (vTokenページ)
15. aimodels.fyi (vTokenページ)

関連記事

• Long-Context Fine-Tuning with Limited VRAM
• Models Take Notes at Prefill: KVキャッシュの編集可能性がもたらすLLM推論の新常識