編輯｜冷貓、陳陳

你有沒有想過，為什么 AI 讀一篇短文游刃有余，卻在面對一整個代碼庫時頻頻出錯？

原因無他，因為注意力撐不住。

現(xiàn)代大模型的核心機制叫做注意力機制，每個詞都要跟上下文里的所有其他詞兩兩比較，才能理解彼此的關系。這個設計讓模型變得無比強大，但也埋下了一個隱患：上下文越長，計算量就越夸張。放到百萬 token 級別，這種代價幾乎是天文數(shù)字。

于是有研究者開始琢磨縮短上下文的方法，把長文檔切碎、檢索、壓縮，再喂給模型。這樣一來模型拿到的，只是碎片化信息。

Subquadratic，這家專注于前沿 AI 研究與基礎設施的公司，在最近的一篇文章中給出了一個不同的思路：與其把文檔切短來喂給模型，不如先來改造模型，讓它真正讀得了長文檔。

他們提出了一種名為 SubQ 的模型，其核心是SSA（Subquadratic Sparse Attention），即亞二次稀疏注意力機制。這是一種經(jīng)過線性擴展的注意力機制，專為長上下文檢索、推理和軟件工程工作負載而設計。

其核心需求很簡單：企業(yè) AI 需要解決的真正難題，本質(zhì)上都是長上下文問題。代碼庫、合同、企業(yè)知識庫、數(shù)據(jù)庫、電子表格、研究語料，以及長時間運行的智能體會話。

以往，模型在回答問題時之所以經(jīng)常失敗，并不是因為答案不存在，而是因為相關證據(jù)分散在大量上下文中，彼此之間是間接引用的，只有同時理解多處信息時才真正有意義。

稠密注意力（Dense attention）成就了現(xiàn)代語言模型，但也讓長上下文變得昂貴。每個 token 都要與其他所有 token 進行比較，因此注意力計算量會隨著序列長度呈二次方增長。

SSA 改變了這種擴展方式。

它不是計算所有 token 兩兩之間的交互，而是通過內(nèi)容相關的選擇機制，將注意力路由到真正重要的位置，無論這些位置出現(xiàn)在序列中的哪里。

這點非常重要，因為長上下文能力并不只是更大的提示詞窗口。名義上的上下文窗口，告訴你模型最多能處理多少 token；而真正有效的上下文窗口，決定了模型能在多少 token 中穩(wěn)定地進行推理。SSA 瞄準的正是后一個問題。

在 MRCR v2 上，SubQ 能夠跟上前沿的稠密注意力模型；在核心長上下文檢索任務中，它達到了同等水平；并且在 100 萬 token 場景下，相比稠密注意力實現(xiàn)了 52.2 倍的預填充加速。其結果是一種新的模型架構：讓百萬 token 上下文的服務成本更低、迭代速度更快。

Subquadratic 聯(lián)合創(chuàng)始人 Alexander Whedon 對這項研究進行了宣傳，稱 SubQ 是 LLM 智能的一次重大突破。

據(jù)他介紹，SubQ 是首個基于完全亞二次稀疏注意力架構（SSA）構建的模型，也是首個擁有 1200 萬 token 上下文窗口的前沿模型。

在 100 萬 token 場景下，它比 FlashAttention 快 52 倍；而成本還不到 Opus 的 5%。

Whedon 認為，當前基于 Transformer 的大語言模型，在計算上存在天然浪費。標準注意力機制會處理詞與詞之間所有可能的關系，但真正有意義、真正會影響結果的關系，其實只占很小一部分。

SubQ 要做的，就是從海量 token 關系中，找到那些真正重要的連接，并把算力集中到這些地方。

這也意味著，SubQ 有望將計算量降低近 1000 倍，為大語言模型的擴展提供一條不同于傳統(tǒng) Transformer 堆算力的新路徑。

Subquadratic 為此發(fā)布了技術博客，讓我們來深入地了解這一顛覆了傳統(tǒng) Transformer 架構的大模型新技術。

• 博客標題：How SSA Makes Long Context Practical
• 博客鏈接： https://subq.ai/how-ssa-makes-long-context-practical

為什么長上下文仍未被解決

大多數(shù)企業(yè)級 AI 工作，并不像是在一小段文本上進行干凈的問答。它更像是：

• 一個代碼庫：某個函數(shù)在一個模塊中定義，卻在幾十個模塊中被調(diào)用，并受到其他地方測試的約束；
• 一份合同：某項義務取決于一個定義、一個例外條款，以及相隔數(shù)頁的引用條款；
• 一個科研流程：結論依賴于對多篇論文中證據(jù)的整合與協(xié)調(diào)；
• 一個長期運行的編程任務：早期的規(guī)劃決策、中間修改、評審意見以及回歸問題都至關重要。

這些都不是簡單的查找問題，而是針對碎片化語料進行多跳推理的問題。

短上下文系統(tǒng)的失敗，并不僅僅在于缺少了一些上下文，而在于它們被迫對碎片進行推理。當完整對象無法裝入上下文時，系統(tǒng)通常通過分塊（chunking）、檢索（retrieval）、總結（summarization）和編排（orchestration）來彌補。

這些方法雖然有效，但也會引入新的失效模式。

RAG 系統(tǒng)能夠保留語義相似性，但會丟失位置信息、層級結構、相鄰上下文以及引用關系。一個片段可能包含正確的文本，卻丟失了為什么它重要這種信息。

基于 Agent 的工作流會將大任務拆解為多個小的模型調(diào)用，但錯誤會在步驟間不斷累積，編排邏輯變成人工編寫的策略，同時上下文在多次調(diào)用之間被反復壓縮。

最終，這類系統(tǒng)對人工設計的依賴，削弱了泛化能力。

行業(yè)的應對方式，是在模型之外不斷構建腳手架。而 SSA 的嘗試，是盡可能減少這些腳手架存在的必要性。

稠密注意力的成本

注意力機制本質(zhì)上是內(nèi)置在模型中的一種檢索操作。每一個 token 都充當一個 query，與其他所有 token 進行比較，評估它們的相關性，并將這些信息聚合為自身的下一步表示。

這種機制之所以強大，是因為它讓每個 token 都可以訪問完整上下文；而它之所以昂貴，原因也正相同：每個查詢都要與所有 key 逐一比較。最終形成的是一種 all-pairs 的計算，其成本會隨著序列長度呈二次增長。

在較小的上下文規(guī)模下，這種開銷尚可接受。但在真實問題所需的規(guī)模下，幾十萬到上百萬 token，它就成為了主要瓶頸。上下文長度翻倍，計算成本并不會翻倍，而是變?yōu)樗谋�。原本可控的開銷，很快就會在訓練、推理和迭代過程中變得難以承受。

更糟的是，這其中大部分計算其實是無效的。在訓練好的模型中，絕大多數(shù)注意力權重接近于零。模型依然執(zhí)行了完整的比較過程，但真正對輸出產(chǎn)生影響的交互只占很小一部分。

換句話說，稠密注意力不僅是二次復雜度，而且是浪費性的二次復雜度

FlashAttention 改進了這種計算的執(zhí)行方式。通過避免顯式構建完整的注意力矩陣，并優(yōu)化內(nèi)存訪問，它讓稠密注意力在當前上下文規(guī)模下變得更加實用。但它并沒有改變底層的擴展規(guī)律：比較次數(shù)依然不變，模型仍然執(zhí)行二次規(guī)模的計算，只是執(zhí)行得更高效。

同樣的情況也出現(xiàn)在系統(tǒng)層面的各種補救方案中。檢索 pipelines、上下文壓縮、遞歸拆解以及基于 Agent 的編排，都在提升稠密注意力系統(tǒng)的可用性，但沒有改變其擴展定律。它們是在繞開這一限制，而不是消除這一限制；二次成本依然是它們所繞行的那條邊界。

這個領域多年來一直在嘗試降低注意力機制的成本。難點從來不只是降低成本，而是在不破壞檢索能力的前提下降低成本

真正尚未解決的問題，并不是讓注意力更快，而是更精確的目標：構建一種同時具備高效率、基于內(nèi)容的路由能力，并能夠在長上下文中從任意位置進行檢索的機制。

這正是 SSA 試圖解決的問題。

SSA 的工作原理

SSA（Subquadratic Selective Attention，亞二次選擇性注意力）改變了注意力計算的分配方式。

注：與前文 SSA（Subquadratic Sparse Attention，亞二次稀疏注意力機制）不同

其核心思想是基于內(nèi)容的選擇（content-dependent selection）。對于每一個 query，模型會先判斷序列中哪些位置值得關注，然后只在這些位置上精確計算注意力。

稠密注意力假設「任意一對 token 都可能重要」，SSA 去除了這一假設，只在真正有信息量的位置上計算注意力，其余部分直接跳過

這使 SSA 同時具備三個關鍵特性：

• 計算與內(nèi)存的線性擴展：注意力成本取決于被選中的位置數(shù)量，而不是完整序列長度，使長上下文在經(jīng)濟上變得可行。
• 基于內(nèi)容的路由能力：模型根據(jù)語義決定「去哪里看」，而不是依賴位置模式，因此無論關鍵信息出現(xiàn)在何處，都可以被檢索到。
• 從任意位置進行稀疏檢索：不同于循環(huán)或壓縮類方法，SSA 保留了從序列中任意遠位置恢復具體信息的能力。

這一點在實踐中非常關鍵。SSA 并不僅僅是對稠密注意力的「更快實現(xiàn)」，而是從根本上減少了模型需要執(zhí)行的注意力計算量。這種減少，直接體現(xiàn)為速度提升。

以實際運行時間（wall-clock）衡量，在 B200 GPU 上、128K token 長度時，SSA 相比采用 FlashAttention-2 的標準注意力實現(xiàn)，實現(xiàn)了7.2× 的輸入處理加速。FlashAttention-3 在 B200 上相較于 FlashAttention-2 并未帶來額外加速。

隨著上下文長度增加，加速效果進一步擴大：

• 256K：13.2×
• 512K：23.0×
• 1M：52.2×

這也再次印證：SSA 的優(yōu)勢，正是在長上下文場景中呈現(xiàn)指數(shù)級放大。

這正是對生產(chǎn)環(huán)境至關重要的「吞吐反轉(zhuǎn)」：隨著上下文長度的增加，稠密注意力相對于 SSA 會變得更慢。而 SSA 的優(yōu)勢，恰恰在長上下文工作負載最有價值的區(qū)間內(nèi)不斷擴大。

SSA 的訓練

架構是必要條件，但并不充分。一個模型可以擁有很長的上下文窗口，卻仍然無法很好地利用它。SSA 的訓練目標，是讓長上下文的使用變得可靠，而不僅僅是可行。

研究團隊采用了三階段訓練流程：

• 預訓練（Pre-training）：建立基礎語言建模能力，以及選擇機制所依賴的長上下文表示。
• 監(jiān)督微調(diào)（Supervised fine-tuning）：將模型行為引導至企業(yè)工作負載所需的指令遵循、結構化推理和代碼生成模式。
• 強化學習（Reinforcement learning）：針對那些難以僅通過監(jiān)督樣本誘導出的行為進行優(yōu)化，例如穩(wěn)定的長上下文檢索能力，以及在編碼時主動利用可用上下文，而不是退回到局部推理。

最后這一階段至關重要。長上下文的失敗往往「看起來是合理的」。

模型可能會基于鄰近上下文作答，因為這些證據(jù)更容易使用，即使決定性證據(jù)出現(xiàn)在序列更早的位置；它可能生成一個在局部看似正確、卻違反其他位置定義接口的代碼補�。凰赡軐ο惹皼Q策進行概括，而不是保留應當約束后續(xù)步驟的精確條件。

SSA 的強化學習階段正是圍繞這些失效模式設計的。訓練數(shù)據(jù)強調(diào)高信息密度、具備跨引用結構的長文本來源。這類數(shù)據(jù)會迫使選擇機制學習在大跨度位置之間進行「路由」。目標不是記住基準，而是讓模型學會無論關鍵信息位于何處，都能關注到它。

評估結果

研究團隊認為，需要評估的是「功能上下文（functional context）」，而非「名義上下文（nominal context）」：一個模型宣稱的上下文窗口大小，并不能說明它真正能利用多少上下文。關鍵在于模型是否能夠在這個窗口內(nèi)檢索、關聯(lián)并推理分布在其中的證據(jù)。

研究團隊從兩個維度對 SubQ 進行評估：

• 部署可行性（Deployment viability）：計算量削減與實際運行時間（wall-clock speed）
• 檢索能力（Retrieval capability）：RULER 與 MRCR v2

計算與速度

SSA 的線性擴展特性意味著，當上下文長度翻倍時，注意力機制的計算成本僅隨之翻倍，而不是像傳統(tǒng)二次復雜度那樣增長四倍。在 100 萬 token 規(guī)模下，相比標準的二次注意力機制，其注意力 FLOPs 降低了 62.5×。

從產(chǎn)品角度來看，「實際運行時間」（wall-clock speed）才是更關鍵的指標。在 100 萬 token 的規(guī)模下，SSA 相比稠密注意力實現(xiàn)了 52.2× 的預填充加速。這種差距，本質(zhì)上決定了一套長上下文系統(tǒng)究竟是表現(xiàn)為一個可交互的工具，還是更像一個離線批處理任務。

RULER

RULER 用于評估模型在超越簡單大海撈針檢索任務之外的行為表現(xiàn)，重點涵蓋多跳檢索、信息聚合、變量跟蹤以及選擇性過濾等能力。

對于企業(yè)級工作流來說，這一點至關重要，因為多跳任務會產(chǎn)生「連鎖放大效應」：一旦在鏈條早期遺漏了某個關鍵引用，后續(xù)的每一步推理都可能被污染，最終導致整體結論失真。

MRCR v2

MRCR v2 是當前要求最嚴苛的檢索類基準之一。它重點評估模型在長上下文中定位并整合多個非相鄰證據(jù)片段的能力，而不是僅僅依賴局部信息完成推理。

SubQ 得分為 65.9%，處于 Claude Opus 4.6 的 78 分區(qū)間之內(nèi)，并領先于 GPT?5.4 的 39 分以及 Gemini 3.1 Pro 的 23 分。

這一結果清晰地揭示了名義上下文與功能上下文之間的差異。一個模型也許能夠接收很長的輸入，但仍然無法在這些輸入之上進行可靠的推理。MRCR v2 正是通過要求模型檢索并整合證據(jù)，而不僅僅是處理 token，從而暴露了這一差距。

SWE-Bench Verified

SWE-Bench Verified 用于評估模型在真實 GitHub issue 上的端到端軟件工程能力。它并非一個純粹的檢索型基準，而是測試模型是否能夠基于對代碼庫的理解來定位 bug、推理實現(xiàn)約束，并生成可行的補丁。