長い文脈を毎回抱えると、後ろのトークンほど生成コストが高いって話。論文では、前線のオープンウェイトモデルだと最大7倍くらい差が出るって報告してる。

そう。しかも長いほど遅くてメモリも食う。図2ではローカルモデルでも後半トークンの生成が約2倍遅くなる例がある。だから「長文脈モデルが本当に必要か」をRQとして立ててる。

頻繁に圧縮して、履歴や入力を短い文脈に保つ運用。だいたい16K〜50Kくらい。これを長いホライズンのタスクと長入力タスクで評価してる。

そう。SWE-bench Verified、SWE-bench Multilingual、Terminal-Bench 2.1、FRAMES、τ2-bench、BFCLv3みたいなベンチ。長入力側はLongBench v2、LOONG、AA-LCR、NIAH、RULER、Counting-Stars、BABILong。

主な精度実験はClaude Opus 4.5とGPT 5.6 Sol。コストやスループットはGLM 5.2、Kimi K2.6、Qwen 3 Coder Next。ローカルはDGX Spark上のモデルも見てる。

論文の報告では、広い範囲の長いホライズン・長入力タスクで、短い文脈を維持しても精度の犠牲が小さいかほぼない。長いホライズンのソフトウェア工学タスクでは、文脈あたり最大1アクションでも性能が崩れない、とも述べてる。

そこからsemantic state space models、SSSMっていう概念も出してる。ただ、これは概念の提示で、本格評価は提示本文からは確認できない。

256Kと16Kの比較で、GLM 5.2は3.6倍、Kimi K2.6は5.6倍、Qwen 3 Coder Nextは7倍。量子化や構造的スパース化に匹敵するか上回る場合がある、って論文は言ってる。

そこは大事。主比較は「長い文脈をそのまま保持」と「頻繁な圧縮で短く保つ」運用。他の手法との全面比較ではない。

対象は提示されたベンチ群とモデルに限られる。短い文脈は16K〜50Kで、絶対的に小さいというより共通の文脈窓に比べて短い、という意味。長入力はツールで選択読みに還元できる、という議論だけど、圧縮誤りや状態管理コストの詳細は提示本文からは確認できない。

抜粋からは確認できない。失敗条件も同様。だから「すべての長文脈タスクで不要」とは言えない。長文脈が真に必要なケースは今後の検証課題、って整理になる。

いや、雨が降らないなら置いてこいって話。必要なときだけ持てばいい。