arXiv 2606.09659·2026-06-09 👁️ — 回閲覧

Latent Context Language Models：350Bトークンで訓練したencoder-decoder圧縮がKV-cacheプルーニングを撃破——16倍圧縮でもGSM8Kで81%、ベースラインは0%に転落

Ang Li, Sean McLeish, Haozhe Chen, Nimit Kalra, Zaiqian Chen, Artem Gazizov, Venkata Anoop Suhas Kumar Morisetty, Bhavya Kailkhura, Harshitha Menon, Zhuang Liu, Brian R. Bartoldson, Tom Goldstein, Sanae Lotfi, Micah Goldblum, Pavel Izmailov

Goldstein、Goldblum、Izmailovの各グループにまたがる15人の著者チームが、encoder-decoder方式の文脈圧縮を本格的なスケールで復活させた。0.6Bエンコーダと4Bデコーダを約350Bトークンで訓練し、速度・メモリ・精度の新たなパレートフロンティアを達成。モデルとコードは全て公開。

arxiv.org/abs/2606.09659 ↗

何が発表されたか

「End-to-End Context Compression at Scale」（arXiv:2606.09659、cs.CL、2026年6月8日投稿）と題された論文は、研究コミュニティの多くが「試したが損失が大きすぎる」とお蔵入りにしていたアイデア——encoder-decoder方式の文脈圧縮——を取り出し、こう問い直した。後付けのトリックとして扱うのをやめて、事前学習級のスケールで本気で訓練したら何が起きるのか？　15人の著者チームはTom Goldstein、Micah Goldblum、Pavel Izmailovの研究圏にまたがり、共著者にはZhuang Liu、Sanae Lotfi、Brian Bartoldson、Bhavya Kailkhura、Sean McLeishらが名を連ねる。

動機となる問題は、長文脈デプロイの誰もがぶつかるものだ。KVキャッシュは文脈長に比例して線形に増大し、数十万トークンの規模では、ボトルネックは重みではなくキャッシュそのものになる。既存のKVキャッシュ圧縮手法は、品質を大幅に劣化させるか、1本の長いプロンプトを圧縮するだけで相当な時間と計算を要するかのどちらかだ。著者らの答えが Latent Context Language Models（LCLMs） である。小型のエンコーダが長いトークン列をはるかに短い潜在埋め込み列に写像し、デコーダは生のトークンの代わりにその潜在ベクトルを読む。

仕組み

アーキテクチャは意図的にシンプルだ。0.6Bパラメータのエンコーダ（Qwen3-Embeddingから初期化）が固定1024トークンのウィンドウで文脈を読み、Nトークンごとに平均プーリングして1つの潜在ベクトルにまとめる。MLPアダプタがその潜在ベクトルを 4Bパラメータのデコーダ（Qwen3-4B-Instructから初期化）の埋め込み空間へ射影する。チームは 1:4、1:8、1:16 の3つの圧縮率でバリアントを訓練した。

本当に効いているのは訓練予算だ。各モデルは4段階のパイプライン——アダプタのウォームアップ、エンコーダ訓練、継続事前学習、そして教師ありファインチューニング——を経て、合計約 3500億トークン を消化する。訓練データには圧縮ブロックと非圧縮ブロックが交互に織り込まれ、補助的な再構成タスクも加わる。従来の圧縮器論文はせいぜい数十億トークンのファインチューニングだった。このレシピが本物の継続事前学習スケールまで押し上げられたのは初めてであり、著者らが貢献を新しいメカニズムではなく「at scale」と位置づけた理由もそこにある。

数字

SnapKV、KVzip、FastKVzip、Expected Attention、Attention Matchingという強力なKVキャッシュ圧縮ベースライン群に対し、論文は汎用タスク性能・圧縮速度・ピークメモリの3軸で新たなパレートフロンティアを報告している。

• 最初のトークンまでの時間（TTFT）： LCLMsはキャッシュプルーニング手法が依然として支払うフルのprefillコストを回避し、RULER系の設定では高圧縮率で最大 8.8倍 のTTFT高速化を報告。
• 情報密度の高いタスク： 16倍圧縮（トークンの94%を除去）でのGSM8Kにおいて、LCLMsは 81%の精度を維持し、競合手法は0%に崩壊。キャッシュプルーニングは重要でないと判定した項目を捨てるが、訓練された圧縮器は算術を残すことを学習する。
• メモリ： H200上で、16倍圧縮では128Kから512Kトークンまでピークメモリがほぼ横ばいで、ベースラインがメモリ切れを起こす 100万トークンの文脈までスケールする。

さらに先を見据えたエージェント実験もある。デコーダが圧縮文脈を流し読みし、逐語的に必要なチャンクの原文を EXPANDツール で取り出す方式で、ニードル・イン・ア・ヘイスタック課題における完全文字列一致の精度を大幅に向上させた。すべてが公開されている——モデルはHugging Face（latent-context）、コードはGitHub（LeonLixyz/LCLM）。

ビルダーが注目すべき理由

この論文の実務的な主張は、文脈圧縮は事後のキャッシュ手術ではなく訓練された能力であってこそ機能する、というものだ。この区別は3種類の読者に効く。長文脈ワークロードを提供しているなら、TTFTとメモリの数字は最も痛い2本のコスト曲線を同時に攻撃する。エンコーダは小さく、バッチ処理が安いからだ。エージェントを作っているなら、「流し読みしてEXPAND」のパターンは正真正銘の新しいメモリ階層である。生の履歴を読み直すより安く、テキスト要約より忠実で、必要に応じて無損失に復元できる。モデルを訓練しているなら、この結果は350Bトークンの投資がプルーニング手法ではいくら払っても買えない16倍の文脈ディスカウントを買える証拠と読める——平均文脈長が倍になるたびに、この取引はさらに魅力的になる。

正直な留保も述べておく。公開されたデコーダは4Bパラメータであり、このレシピがフロンティア規模のモデルで成立することは誰も示していない。訓練コストは現実のもので、圧縮器を作る側が負担する。16倍圧縮でのGSM8Kの数字は衝撃的だが、1つのタスク族にすぎない。0%ベースラインとの比較もこの設定に有利に働いている。キャッシュプルーニング手法はそもそも94%の追い出し率向けに設計されていないからだ。

実務家ノート

もし私が今日、長文脈サービングスタックを運用しているなら、この結果が自分の環境に移転すると信じる前に、公開された1:4モデルを自分の実トレースで現行のSnapKV系パイプラインと対決させる——この実験は安い。重みもコードも公開されており、デコーダはわずか4Bだからだ。私が見る指標は平均精度ではなく失敗モードだ。プルーニングは事実を静かに落とすことで失敗し、訓練された圧縮器は事実をぼかすことで失敗する。そしてEXPANDツールのパターンは、後者の失敗には復元経路を与えるが、前者には存在しない。エージェントビルダーには、生ログを真値として残しつつ、今すぐ圧縮メモリのプロトタイプを作ることを勧める。古いターンを潜在ベクトルで保存し、必要に応じて展開し、エージェントが実際に展開を必要とする頻度を測る。その比率が、あなたの本当の圧縮予算を教えてくれる。

見落とされがちな視点

この論文の静かな含意は、アーキテクチャではなく経済にある。KVキャッシュプルーニングは圧縮をサービング層に閉じ込め、すべてのプロバイダがリクエストごとに、永遠にコストを払い続ける。LCLMsはそのコストを訓練側へ移し、一度だけ払って将来のすべてのリクエストに償却する——これは命令チューニングがプロンプトエンジニアリングを打ち負かしたのと同じ種類のシフトだ。このレシピがデコーダのサイズとともにスケールするなら、「文脈圧縮」は推論最適化であることをやめ、出荷し、バージョン管理し、ファインチューニングできるモデル能力になる。追跡する価値のある未解決の問いは、フロンティアラボがencoder-decoder分割を採用するか、それとも圧縮器をモデル本体に折り込むかだ。どちらの道でも、この論文が公表した350Bトークンという値札は、この能力の構築コストに対する初めての信頼できる見積もりである。