長文を扱うLLMは、入力が長くなるほどKVキャッシュが膨らみ、推論の速度とメモリの両方がボトルネックになります。NYUやColumbiaなどの研究チームが発表したLatent Context Language Models（LCLM）は、16個のトークンを1つの潜在トークンに圧縮し、デコーダがその潜在表現をそのまま文脈として読む方式です。精度を大きく落とさずに推論を速くし、メモリ消費も抑える新しいパレートフロンティアを示しています。

この記事では、LCLMの仕組みと従来のKVキャッシュ圧縮との違い、ベンチマーク結果、公開モデルの使い方を整理します。

  • LCLMが長文推論のボトルネックをどう解くか
  • エンコーダ・デコーダ構成と16倍圧縮の仕組み
  • RULERやGSM8Kでの性能とKVキャッシュ圧縮との比較
  • Hugging FaceとGitHubで公開されたモデルの利用方法
End-to-End Context Compression at Scale
Long-context language model inference is bottlenecked by memory, as the KV cache grows with context length. Recent techn…
arXiv.org

長文推論が抱える課題

LLM（大規模言語モデル）が長いドキュメントや多ターンの会話を扱うとき、入力トークンごとにKVキャッシュ（キーとバリューの中間表現を保存する仕組み）が蓄積されます。コンテキストが長くなるほどメモリ使用量が増え、最初のトークンが出るまでの時間（TTFT）も伸びます。

これに対し、SnapKVやKVzipといったKVキャッシュ圧縮は広く研究されています。ただし論文「End-to-End Context Compression at Scale」が指摘するように、多くの手法は全文をprefillしたあとで圧縮する必要があり、圧縮のたびに追加の計算コストがかかります。クエリ依存の圧縮はマルチターン会話でキャッシュを再利用しにくく、vLLMやSGLangのような本番向け推論エンジンとも相性が悪い場合があります。

LCLMが提案する解決策

LCLMはエンコーダ・デコーダ型のソフトトークン圧縮です。小さなエンコーダが長い入力を短い潜在トークン列に変換し、大きなデコーダがその潜在トークンを通常の文脈の代わりに消費します。圧縮は並列化でき、デコーダのネイティブなコンテキスト長を超える入力も扱えます。

Pavel Izmailov氏の発表によると、基本アイデアは「16トークンを1つの潜在トークンにエンコードし、LLMが潜在トークンの上で動く」ことです。圧縮率は1:4、1:8、1:16の3段階で学習され、最大16倍の圧縮に対応します。

3層の構成

公開された0.6Bエンコーダ＋4Bデコーダ構成は次の流れで動きます。

  1. エンコーダ（Qwen3-Embedding-0.6Bベース）が入力を1024トークン単位のウィンドウで処理する
  2. プーリングで連続16トークンの隠れ状態を平均し、1つの潜在トークンにまとめる
  3. アダプタ（MLP）がエンコーダの次元をデコーダの埋め込み空間に射影する
  4. デコーダ（Qwen3-4B-Instruct-2507ベース）が潜在トークン列を文脈として読み、応答を生成する

アーキテクチャ探索では、平均プーリング・因果マスク・MLPアダプタ・ウィンドウサイズ1024の組み合わせが最も有効と報告されています。

大規模学習で汎用性を確保

従来のソフトトークン圧縮は、特定ドメインのファインチューニングに依存し、汎用タスクでの性能低下が課題でした。LCLMはこの点を、段階的な学習レシピと大規模データで克服しています。

学習は4段階で進みます。アダプタのウォームアップ、エンコーダの学習、エンコーダとデコーダの継続事前学習、最後にSFT（教師あり微調整）です。16倍圧縮モデルでは合計350Bトークン超を学習に使い、Common Crawl、コード、科学・推論、長文データ、指示形式データを混ぜた継続事前学習データに加え、補助的な再構成タスク（圧縮後の潜在表現から原文を復元させる）も導入しています。

学習データでは圧縮対象のテキストを<|memory_start|>と<|memory_end|>で囲み、圧縮セグメントと非圧縮セグメントを交互に配置します。これにより、文脈の途中でも潜在表現に条件づけできるようになります。

ベンチマークで何が変わったか

評価はH200 GPU上で実施され、デコーダはすべてQwen3-4B-Instruct-2507に統一されています。長文ベンチマークRULER（4K〜16K）とLongBench、短い高密度入力のGSM8Kで、KVキャッシュ圧縮のベースラインと比較されています。

16倍圧縮での主な結果は次のとおりです。

ベンチマーク LCLM（Mean） SnapKV KVzip
RULER 4K 75.06 14.31 62.73
RULER 8K 70.23 14.11 61.73
GSM8K 81.05 0.08 0.00

16倍圧縮では入力トークンの93.75%を削減する設定ですが、LCLMは長文タスクと短い数学問題の両方でKVキャッシュ圧縮を上回ります。論文の図1では、RULERとLongBenchにおいて精度対TTFTのパレートフロンティアが従来手法より外側に位置し、高い圧縮率ほど速度面での優位が大きいと示されています。

4倍圧縮ではRULER 4Kで91.76と、非圧縮のQwen 4B Instruct（94.41）に近い精度を維持します。圧縮率を上げるほど精度は下がりますが、速度とメモリの削減幅は大きくなります。

エージェント用途への展開

LCLMは長文エージェントのバックボーンとしても設計されています。高圧縮率で文脈を圧縮した状態でエージェントが概要を把握し、必要な区間だけEXPANDツールで展開する仕組みです。RULERのNeedle-in-a-Haystack（NIAH）タスクでは、16倍圧縮でエージェントループを使うと非エージェント版より平均17〜20ポイント精度が向上し、圧縮による情報損失を動的に補えます。

公開モデルと使い方

GitHub - LeonLixyz/LCLM: latent context language models
latent context language models. Contribute to LeonLixyz/LCLM development by creating an account on GitHub.
GitHub

研究チームはモデルとコードをオープンソースで公開しています。

推論時は圧縮したいテキストを<|memory_start|>と<|memory_end|>で囲みます。Hugging Face上の参照実装ではLCLM.from_pretrained("latent-context/0.6b-4b-LCLM-16x")で読み込めます。vLLM向けには、エンコーダで潜在トークンを.ptファイルに書き出し、デコーダがそれを読む2段階パイプラインも用意されています。

KVキャッシュ圧縮との違い

観点 LCLM KVキャッシュ圧縮
圧縮のタイミング デコーダのprefill前に入力を圧縮 多くはprefill後にキャッシュを削減
推論エンジンとの相性 vLLM等と互換 ヘッド・レイヤーごとの非均一な削減は統合が難しい
汎用性 350Bトークン超の継続事前学習で汎用タスクに対応 ドメイン特化や品質低下のトレードオフが大きい場合がある
コンテキスト長の拡張 デコーダのネイティブ長を超える入力も可能 元のコンテキストウィンドウ内に収まる必要がある場合が多い

ソフトトークン圧縮は以前から研究されていましたが、精度・速度・メモリのバランスでKVキャッシュ圧縮に劣ると見なされがちでした。LCLMは大規模なアーキテクチャ探索と学習レシピにより、そのギャップを埋めたと論文は報告しています。

今後の実装に向けて

LCLMは研究プロトタイプの段階ですが、長文RAG、コードエージェント、マルチターン会話など、コンテキスト長の増大が課題になる場面に直接効く技術です。16倍圧縮でRULER 4Kの精度が75前後に留まる点は、用途に応じて4倍や8倍を選ぶ必要があることも示しています。

本番環境への組み込みを検討するなら、まずHugging Faceの公開チェックポイントで自社のワークロードを試し、圧縮率と精度のトレードオフを測るのが現実的な第一歩です。vLLM連携の2段階パイプラインが整っているため、既存の推論基盤への試験導入もしやすい構成になっています。