注:本稿では第三者検証済みのベンチマークを共有します。包括的なモデルカードは近日公開予定です!
SubQは、長文脈の検索、推論、ソフトウェアエンジニアリングのワークロード向けに設計された、線形スケーリングのアテンション機構であるSSA(Subquadratic Sparse Attention)を中核に構築されています。
その核心的な主張はシンプルです。エンタープライズAIが解決すべき難しい問題は、長文脈の問題であるということです。コードベース、契約書、企業コーパス、データベース、スプレッドシート、研究コーパス、そして長期実行されるエージェントセッションが失敗するのは、答えが存在しないから滅多にありません。関連する証拠が広大な文脈全体に分散しており、間接的に参照され、複数の情報を同時に視野に入れた時にのみ意味を持つ場合に失敗するのです。
密なアテンションは現代の言語モデルを可能にしましたが、同時に長文脈を高コストなものにしました。すべてのトークンが他のすべてのトークンと比較されるため、アテンションはシーケンス長に対して二次関数的に増大します。SSAはこのスケーリング挙動を変えます。すべてのペアワイズな相互作用を計算する代わりに、SSAはコンテンツ依存の選択を用いて、シーケンス内の位置に関係なく、重要な位置にアテンションを振り向けます。
これが重要なのは、長文脈能力が単に大きなプロンプトウィンドウではないからです。名目上のコンテキストウィンドウは、モデルが処理できるトークン数を示します。機能的なコンテキストウィンドウは、モデルが確実に推論できるトークン数を示します。SSAは後者の問題のために設計されています。
SubQは、MRCR v2において最先端の密なアテンションモデルに匹敵し、主要な長文脈検索タスクで同等の性能を達成し、100万トークン時点で密なアテンションと比較して52.2倍のプレフィル高速化を実現します。その結果、検索の失敗が許されない本番ワークフローにおいて、100万トークン規模のコンテキストをより安価に提供し、より高速に反復し、より有用にするモデルアーキテクチャが得られます。
以下では、現在の長文脈システムの何が破綻しているのか、SSAの仕組み、その訓練方法、そして実際のソフトウェアエンジニアリングやエンタープライズAI導入にとって結果が何を意味するのかを説明します。
長文脈が依然として未解決である理由
ほとんどのエンタープライズAIの仕事は、短い文章に対する単純なQ&Aタスクのようには見えません。それは次のようなものです:
- ある関数が一つのモジュールで定義され、他の多数のモジュールで呼び出され、別の場所にあるテストによって制約されるコードベース
- ある義務が、定義、例外、そして数ページ離れた参照条項に依存する契約書
- 結論が多数の論文にわたる証拠の突き合わせに依存する研究ワークフロー
- 事前の計画決定、中間編集、レビューノート、リグレッションすべてが重要となる、長期にわたるコーディングタスク
これらは単なる検索問題ではありません。断片化したコーパスに対する多段階推論の問題なのです。
短文脈システムの失敗モードは、単に何らかの文脈が欠落していることではありません。断片について推論せざるを得なくなることです。成果物全体が文脈に収まらない場合、システムはチャンク分割、検索、要約、オーケストレーションによって補います。これらの技術は有用ですが、独自の失敗モードを持ち込みます。
RAGシステムは意味的類似性を保持しますが、位置、階層、隣接コンテキスト、参照構造を失います。チャンクは正しいテキストを含んでいるかもしれませんが、そのテキストがなぜ重要なのかを見失うのです。エージェントワークフローは大きなタスクを小さなモデル呼び出しに分解しますが、エラーはステップを経るごとに蓄積し、オーケストレーションロジックは手作りのポリシーとなり、呼び出し間で文脈は繰り返し圧縮されます。最終的に、これらのシステムの人間によるキュレーションは、それらを「苦い教訓」にさらし、汎化能力を低下させます。
業界の対応は、モデルの周りに足場を構築することでした。SSAは、その足場が必要とされる理由の多くを取り除く試みです。
密なアテンションのコスト
アテンションはモデルに組み込まれた検索操作です。各トークンはクエリとして機能し、他のすべてのトークンと自分自身を比較し、関連性をスコアリングし、その情報を次の表現へと集約します。
このメカニズムは、すべてのトークンに全文脈へのアクセスを与えるため強力です。そして同じ理由で高コストです:すべてのクエリがすべてのキーと比較されるのです。その結果、シーケンス長に対して二次関数的にコストが増大する全ペア計算となります。
小さなコンテキストサイズでは、これは許容可能です。現実世界の問題が必要とする数十万から数百万トークンという規模では、これが支配的な制約となります。文脈を2倍にしてもコストは2倍になりません。4倍になります。管理可能だったものが、訓練、提供、反復にとって急速に法外なものになります。
さらに悪いことに、この計算の大部分は重要ではありません。訓練されたモデルでは、アテンションの重みの大部分はゼロ近傍です。モデルは依然として完全な比較を実行しますが、これらの相互作用のごく一部だけが意味のある形で出力に影響を与えます。密なアテンションは単に二次関数的なだけでなく、無駄に二次関数的なのです。
FlashAttentionはこの計算の実行方法を改善しました。完全なアテンション行列の実体化を避け、メモリ移動を最適化することで、今日のコンテキスト長において密なアテンションをはるかに実用的なものにしました。しかし、それは根本的なスケーリングを変えるものではありません。比較の数は変わりません。モデルは依然として二次関数的な作業を実行します。単にその作業をより効率的に実行しているだけです。
同じパターンがシステムレベルの回避策にも当てはまります。検索パイプライン、コンテキスト圧縮、再帰的分解、エージェントオーケストレーションはすべて、密なアテンションシステムをより使いやすくします。しかし、それらのいずれもスケーリング則を変えません。それらは制限を迂回しますが、二次関数的なコストは、それらが迂回しようとしている境界線であり続けます。
従来の効率的アーキテクチャが犠牲にしてきたもの
この分野は何年もアテンションを安価にしようと試みてきました。難しいのはコスト削減ではありません。検索を壊さずにコストを削減することです。
これまでのアプローチはすべて、どこかでそのトレードオフを行ってきました。
固定パターンのスパースアテンションは、トークンが注意を向けられる位置を制限することで計算量を削減します。スライディングウィンドウ、ストライドパターン、拡張マスクは、サブ二次関数的なスケーリングを達成するのに十分なほど検索空間を縮小します。しかし、ルーティングの決定は、コンテンツではなく位置に基づいて事前に行われます。モデルは、何を探しているのかを知る前に、どこを見るべきかを決定します。関連情報がパターンの外にある場合、それは単に見られません。
状態空間モデルやリカレントな代替案は異なるアプローチを取ります。それらは全ペア比較を完全に取り除き、シーケンス全体で進化する圧縮された状態で置き換えます。これにより、構造上線形のスケーリングが得られます。また、これは制約ももたらします。状態には固定容量があります。シーケンスが長くなるにつれて、情報は要約されるか、曖昧になるか、破棄されなければなりません。これらのモデルは要点と構造を保持します。それらは、任意の過去に導入された特定の事実を検索するのが弱いです。なぜなら、その事実はもはや回復可能な形で存在しない可能性があるからです。
ハイブリッドアーキテクチャは両方のアイデアを組み合わせます。効率的な層が計算の大部分を担い、検索を保持するために密なアテンション層が保持されます。これは実際には機能しますが、根本的なスケーリング挙動は変わりません。密な層は負荷を支え続けます。文脈が長くなるにつれて、その二次関数的なコストが支配的になり、モデルは本来逃れるはずだった領域に留まります。その利益はスカラー的です。
DeepSeek Sparse Attentionは、より新しいスパースアプローチです。アテンションの二次関数的コストを、各クエリに対してどのキーに注意を向けるかを選択する高速なインデクサーにオフロードします。そのインデクサー自体が二次関数的です。それはすべてのクエリをすべてのキーに対してスコアリングします。定数は小さいですが、アーキテクチャが本来逃れようとしていたのと同じO(n²)スケーリングです。複雑性は移動されましたが、除去されていません。
このパターンは一貫しています。固定スパース性は、コンテンツ依存のルーティングを放棄することで効率性を達成します。リカレントモデルは、正確な検索を放棄することで効率性を達成します。ハイブリッドは、密なアテンションを再導入することで能力を回復し、それとともに元のコストも戻ります。DeepSeek Sparse Attentionは二次関数的にスケールし、非常に大規模になるとコストが法外になります。
未解決の問題は「アテンションを高速化する」ことではありません。より正確には:効率的で、コンテンツ依存であり、長文脈にわたる任意の位置から検索できるメカニズムを構築することです。
それがSSAが果たすために設計された役割です。
SSAの仕組み
SSA(Subquadratic Selective Attention)は、アテンション作業の割り当て方を変えます。
核となるアイデアはコンテンツ依存の選択です。各クエリに対して、モデルはシーケンスのどの部分に注意を向ける価値があるかを選択し、それらの位置に対して正確にアテンションを計算します。
密なアテンションは、すべてのペアが重要かもしれないと仮定するため、それらすべてを評価します。実際には、ほとんど重要ではありません。ほとんどのペアワイズな相互作用は無視できる程度のシグナルしか持ちませんが、モデルはそれらを計算するために依然として完全な二次関数的コストを支払います。SSAはその仮定を取り除きます。それはアテンションを近似しません。それは実際にシグナルを持つ位置にアテンションを制限し、残りをスキップします。
これにより、SSAには共に重要な3つの特性がもたらされます:
- 計算とメモリにおける線形スケーリング。 アテンションコストは、全シーケンスではなく選択された位置の数に応じて増大するため、長文脈が経済的に利用可能になります。
- コンテンツ依存のルーティング。 モデルは位置ではなく意味に基づいて見る場所を決定します。関連情報は、それがどこに現れても検索できます。
- 任意の位置からのスパース検索。 リカレントや圧縮アプローチとは異なり、SSAはシーケンスのずっと前に導入された特定の情報を回復する能力を保持します。
実際的な区別は重要です。SSAは密なアテンションの単なる高速な実装ではありません。それはモデルが実行するアテンション作業の量を削減します。その削減こそが速度として現れるものです。
ウォールクロックの入力処理時間で測定すると、SSAはB200上でFlashAttention-2を用いた標準的なアテンションと比較して、128Kトークンで7.2倍の入力処理高速化を達成します。FlashAttention-3はB200上でFlashAttention-2に対する高速化は見られませんでした。256Kでは13.2倍、512Kでは23.0倍、100万トークンでは52.2倍に上昇します。
| コンテキスト長 | B200上でのFlash Attentionに対するSSAの速度向上 |
|---|---|
| 128K | 7.2倍 |
| 256K | 13.2倍 |
| 512K | 23.0倍 |
| 100万 | 52.2倍 |
これは本番環境にとって重要なスループットの逆転です。密なアテンションは文脈が長くなるにつれてSSAと比較して相対的に遅くなります。SSAは、長文脈ワークロードが最も価値を持つようになる場所で、まさにより有利になります。
長文脈動作のためのSSAの訓練
アーキテクチャは必要ですが、十分ではありません。モデルは長いコンテキストウィンドウを持ちながら、それをうまく活用できない可能性があります。SSAは、長文脈の使用を可能にするだけでなく、信頼できるものにするために訓練されます。
我々は3段階の訓練プロセスを使用しました:
- 事前学習は、基本的な言語モデリング能力と、選択メカニズムが使用する長文脈表現を確立します。
- 教師ありファインチューニングは、エンタープライズワークロードで要求される指示追従、構造化推論、コード生成パターンへと動作を形成します。
- 強化学習は、教師ありの例だけでは引き出すのが最も難しい動作、すなわち、局所的な推論に頼るのではなく、利用可能な文脈を積極的に使用する信頼性の高い長文脈検索とコーディング動作を対象とします。
この最終段階が重要です。長文脈の失敗はしばしばもっともらしく見えます。決定的な証拠がはるか以前のシーケンスに現れている場合でも、モデルは近くの証拠の方が使いやすいため、近くの文脈から回答するかもしれません。別の場所で定義されたインターフェースに違反する、局所的に正しいコードパッチを生成するかもしれません。後のステップを規定すべき正確な制約を保持するのではなく、以前の決定を要約するかもしれません。SSAのRL段階は、これらの失敗モードを中心に設計されています。
訓練データは、情報密度が高く相互参照構造を持つ長文のソースを重視しています。これは、選択メカニズムに大きな位置距離にわたるルーティングを学習させる種類のデータです。目標はベンチマークの暗記ではありません。目標は、モデルがその場所に関係なく重要なものに注意を向けるように教えることです。
訓練インフラ:100万トークン実験を実用的にする
長文脈訓練は単なるモデリングの問題ではありません。それは規模においてのみ現れるシステムの問題です。
100万トークンのシーケンス長では、短い文脈では見えない失敗モードが拘束力を持ちます:メモリ圧迫、デバイス間でのシーケンス分割、勾配の不安定性、数値精度、カーネル効率。これらはエッジケースではありません。それらは訓練がそもそも実行されるかどうかを決定する制約です。
このシステムは100万トークン以上で安定して訓練され、訓練パイプライン全体で線形メモリスケーリングを維持し、シーケンスが単一デバイスの制限を超える場合に、分散シーケンス並列処理を使用してシーケンスをデバイス間で分割します。
その結果、長文脈訓練が可能になるだけではありません。それが反復可能になります。
密なアテンションの下では、長文脈実験は非常に高価であるため、予約された実行として扱われます。SSAの線形スケーリングにより、それらは日常的になります。開発ループが変わります:より多くのアブレーション、より多くの評価、より速いフィードバック、そして長文脈で実際に重要な動作に対する的を絞った修正。
これがより深い意味合いです。SSAは推論のコストを削減するだけではありません。そもそも長文脈動作を学習するコストを削減します。
名目上の文脈ではなく、機能的な文脈の評価
宣伝されているコンテキストウィンドウは、モデルがどれだけの文脈を使用できるかを教えてくれません。問題は、モデルがそのウィンドウ全体に分散された証拠を検索し、接続し、推論できるかどうかです。
我々はSubQを2つの軸で評価します:
- 導入の実現可能性: 計算量削減とウォールクロック速度
- 検索能力: RULER、およびMRCR v2
より一般的なベンチマークは、モデルカードで公開される予定です(近日公開)。
Needle-in-a-Haystackは、単一ターゲットの正確な検索をテストします。
RULERはこれを多段階検索、集計、変数追跡、選択的フィルタリングに拡張します。
MRCR v2はさらに進みます。モデルは文脈全体に分散された複数の証拠を見つけ出して統合する必要がありますが、関連セットは事前に与えられていません。
これは実際の仕事の形に近いものです。一つの事実を見つけるだけでは十分ではありません。モデルはどの証拠が重要かを判断し、それらを首尾一貫した回答にまとめなければなりません。
結果
計算と速度
SSAの線形スケーリングは、文脈長を2倍にするとアテンションの計算コストが4倍ではなく2倍になることを意味します。100万トークンでは、標準的な二次アテンションと比較して62.5倍のアテンションFLOP削減が見られます。
| コンテキスト長 | 標準アテンションに対するアテンションFLOP削減 |
|---|---|
| 128K | 8倍 |
| 100万 | 62.5倍 |
ウォールクロック速度は、より製品に関連する結果です。SSAは、100万トークンで密なアテンションに対して52.2倍のプレフィル高速化を達成します。これは、インタラクティブなツールのように動作する長文脈システムと、オフラインのバッチジョブのように感じるシステムとの違いです。
| コンテキスト長 | 入力処理速度の向上 |
|---|---|
| 128K | 7.2倍 |
| 256K | 13.2倍 |
| 512K | 23.0倍 |
| 100万 | 52.2倍 |
RULER
RULERは、多段階検索、集計、変数追跡、選択的フィルタリングなど、単純なニードル検索を超えた検索と推論の動作をテストします。
| モデル | RULER @ 128K |
|---|---|
| SSA / SubQ | 95.0% |
| Opus 4.6 | 94.8% |
エンタープライズワークフローにとって、これが重要なのは多段階タスクが複合化するからです。チェーンの早い段階での参照漏れは、下流のすべての結論を破綻させる可能性があります。
MRCR v2
MRCR v2は、最も要求の厳しい検索ベンチマークです。長い文脈にわたって隣接しない複数の証拠を見つけ出し、統合する能力を評価します。
| モデル | MRCR v2 スコア |
|---|---|
| SSA / SubQ | 65.9% |
| Gemini 3.1 Pro | 26.3% |
| Opus 4.6 | 78.3% |
| Opus 4.7 | 32.2% |
| GPT 5.4 | 36.6% |
| GPT 5.5 | 74.0% |
SubQは65.9%を記録し、78のOpus 4.6の範囲内に十分入り、39のGPT 5.4、23のGemini 3.1 Proを上回っています。
この結果は、名目上の文脈と機能的な文脈の違いを示す最も明確な証拠です。モデルは長い入力を受け付けながらも、その入力に対して確実に推論できない場合があります。MRCR v2は、それが単にトークンを処理するだけでなく、証拠を検索して組み合わせることを要求するため、そのギャップを表面化させます。
SWE-Bench Verified
SWE-Bench Verifiedは、実際のGitHub issueに対するエンドツーエンドのソフトウェアエンジニアリング能力を評価します。これは純粋な検索ベンチマークではありません。モデルがコードベースの理解を用いてバグを特定し、実装上の制約について推論し、パッチを生成できるかどうかをテストします。
| モデル | SWE-Bench Verified |
|---|---|
| SSA / SubQ | 81.8% |
| Gemini 3.1 Pro | 80.6% |
| Opus 4.6 | 80.8% |
| Opus 4.7 | 87.6% |
| GPT 5.4 | 報告なし |
| GPT 5.5 | 報告なし |