SubCube 深度实战：亚二次稀疏注意力 SSA 如何打破 Transformer 的 O(n²) 铁律——1200万 Token 时代从架构原理到生产级部署的完全指南（2026）

一、背景：为什么我们需要一场注意力革命？

2026年5月，一家位于迈阿密的初创公司 Subquadratic 发布了一个令人震惊的技术突破：他们的 SubQ 模型实现了 1200万 Token 上下文窗口，在 MRCR v2 检索基准测试中取得 83 分，直接碾压 OpenAI GPT-5.5 的 74 分。

1200万 Token 是什么概念？

• 一次性读完 20 本长篇小说
• 一次性加载整个 Linux 内核代码库
• 大海捞针测试准确率高达 92.1%
• 处理百万级 Token 时，比传统 Transformer 快 52 倍
• 推理成本仅为 Claude Opus 的 5%

这个突破的核心，是一种名为 SSA（Subquadratic Selective Attention，亚二次选择性注意力） 的全新架构。它从根本上改变了注意力机制的扩展方式，将计算复杂度从 O(n²) 降到接近 O(n)。

1.1 传统 Transformer 的致命瓶颈

自从 2017 年 Google 发布《Attention Is All You Need》以来，Transformer 架构一直是 AI 的基石。它的核心——自注意力机制——让每个 Token 都能与上下文中所有其他 Token 计算关联，赋予了模型无与伦比的理解能力。

但这个设计的代价是 二次复杂度（O(n²)）：

序列长度     注意力计算次数
1,000        1,000,000（100万）
10,000       100,000,000（1亿）
100,000      10,000,000,000（100亿）
1,000,000    1,000,000,000,000（1万亿）

输入长度翻倍 → 计算量变为 4 倍。这意味着：

• GPT-5.5 号称支持百万级 Token，但在 MRCR v2 上只拿了 74 分
• Claude Opus 4.7 更是只有 32.2 分
• 企业级长上下文应用成本极其高昂
• 真正的"功能上下文"远小于"名义上下文"

1.2 行业的各种"绕路"方案

为了规避 O(n²) 的问题，业界发展出了多种妥协方案：

这些方案各有巧妙之处，但都是 在绕开问题，而不是解决问题。

1.3 名义上下文 vs 功能上下文

这是理解 SSA 价值的关键概念：

• 名义上下文（Nominal Context）：模型声称能接收的最大 Token 数
• 功能上下文（Functional Context）：模型能在这个窗口内稳定地进行检索、关联和推理的 Token 数

GPT-5.5 的名义上下文可能达到百万级，但功能上下文在 MRCR v2 上只表现为 74 分。Claude Opus 4.7 更是只有 32.2 分——这意味着虽然模型"能接收"大量 Token，但其中大部分信息在推理时实际上被浪费了。

SSA 瞄准的正是功能上下文——不仅要让模型接收长输入，还要让它真正利用这些输入。

二、核心概念：SSA 的设计哲学

2.1 SSA 的核心思想：只计算真正有意义的注意力

SSA（Subquadratic Selective Attention）的出发点非常直观：

传统 Transformer 的做法是：如果有 1000 个单词，就会查看这 1000 个单词之间所有可能的关联，产生 1000² = 100 万种组合。而 SSA 的核心思想是：只有一部分关联是真正有意义的，我们只处理这些有意义的部分。

Subquadratic 联合创始人 Alexander Whedon 的解释：

"标准注意力机制会处理词与词之间所有可能的关系，但真正有意义、真正会影响结果的关系，其实只占很小一部分。SubQ 要做的，就是从海量 Token 关系中，找到那些真正重要的连接，并把算力集中到这些地方。"

SSA 具备三个关键特性：

1. 计算与内存的线性扩展：注意力成本取决于被选中的位置数量，而不是完整序列长度
2. 基于内容的路由能力：模型根据语义决定"去哪里看"，而不是依赖位置模式
3. 从任意位置进行稀疏检索：保留了从序列中任意远位置恢复具体信息的能力

2.2 SSA vs 其他稀疏注意力方案：代码级对比

1. 固定模式稀疏注意力（Longformer、BigBird）

# 固定窗口注意力 - 每个Token只关注固定范围的邻居
def fixed_window_attention(tokens, window_size=512):
    for i, token in enumerate(tokens):
        start = max(0, i - window_size)
        end = min(len(tokens), i + window_size)
        # 问题：窗口外的信息直接丢失！
        attend_to(tokens[start:end], token)

问题：第 1 个词和第 10000 个词的关联永远不会被发现。需要额外全局注意力 Token（如 [CLS]）弥补，增加工程复杂度。

2. 状态空间模型（Mamba、RWKV、RetNet）

def state_space_attention(tokens, hidden_size=256):
    state = zeros(hidden_size)
    for token in tokens:
        state = update_state(state, token)  # 压缩到固定大小
        output = generate_output(state)

问题：256 维隐藏状态压缩 100 万 Token 的历史，必然丢失大量细节。NVIDIA 研究发现 Mamba 需要加回注意力层才能追上 Transformer。

3. DeepSeek 稀疏注意力（DSA）

def deepseek_sparse_attention(tokens):
    # 选择器本身需要 O(n²) 的全量评分
    importance_scores = compute_all_pair_scores(tokens)  # O(n²)
    selected_positions = select_top_k(importance_scores)
    compute_attention(tokens[selected_positions])

问题：选择"哪些位置值得关注"的过程本身是 O(n²)，复杂度只是被转移而非消除。

4. SSA —— 真正的线性选择

def ssa_attention(tokens):
    for query_token in tokens:
        # select_important_keys 本身是 O(n)
        important_keys = select_important_keys(query_token)  # O(n)
        for key_token in important_keys:  # O(k), k << n
            compute_attention(query_token, key_token)

核心差异：SSA 的选择机制本身也是线性复杂度，端到端都是线性的。

2.3 内容相关的路由

SSA 的"内容相关选择"完全由内容驱动，而非位置模式或统计特征：

• 查询 "这个函数在哪里被调用？" → 路由到函数调用相关位置
• 查询 "合同违约条款是什么？" → 路由到责任相关条款
• 查询 "是否存在内存泄漏？" → 路由到资源分配和释放位置

每次查询的注意力路由模式都不同，这正是 SSA 与 Longformer 等固定模式方案的根本区别。

三、架构分析：SSA 的技术实现

3.1 三阶段训练流程

第一阶段：预训练——建立基础语言建模能力和选择机制依赖的长上下文表示。训练数据包含大量长文档（书籍、代码库、法律文书），迫使模型在训练中就学会处理长距离依赖。

第二阶段：监督微调（SFT）——引导至企业工作负载所需的指令遵循、结构化推理和代码生成模式。

第三阶段：强化学习（RL）——最关键的阶段。长上下文的失败往往"看起来合理"：模型基于邻近上下文作答（因为更容易），即使决定性证据出现在序列更早位置。RL 阶段强调高信息密度、具备跨引用结构的训练数据，迫使选择机制学习大跨度位置间的路由。

3.2 SSA 在 B200 GPU 上的实测性能

加速比呈指数级放大——上下文越长，优势越大。FlashAttention-3 在 B200 上未带来额外加速，说明 FlashAttention 系列优化已接近硬件极限。SSA 是算法层面的突破。

3.3 FlashAttention vs SSA：执行方式 vs 分配方式

FlashAttention 优化注意力的 执行方式：避免显式构建注意力矩阵、优化内存访问，但比较次数不变，仍是 O(n²)。

SSA 优化注意力的 分配方式：减少需要计算的比较次数本身，从 O(n²) 降到 O(n)。

打个比方：FlashAttention 像把冒泡排序做了极致低级优化；SSA 则是换成了快速排序。算法层面的改进，系统级优化无法企及。

四、基准测试深度分析

4.1 MRCR v2：多参考检索基准

Claude Opus 4.7 的低分揭示了"名义上下文"与"功能上下文"的根本差异。另一个数据来源显示 SubQ 得分 65.9%（低于 Opus 4.6 的 78 分），数据差异提醒我们对基准结果保持审慎。

4.2 SWE-Bench Verified

优势仅 1 个百分点，需要更多独立验证。

4.3 RULER 128K

4.4 大海捞针测试

1200 万 Token 上下文中准确率 92.1%，目前无其他模型能在接近此长度下测试。

4.5 理性审视

1. 基准只运行一次，无法取平均
2. SWE-Bench 优势幅度小
3. 模型规模较小，CTO 承认比大厂模型小得多
4. 需要独立复现验证

五、代码实战：从 RAG 到直接上下文的范式切换

5.1 SubQ API 基础使用

import httpx

SUBQ_API_BASE = "https://api.subq.ai/v1"
SUBQ_API_KEY = "your-api-key-here"

async def call_subq(prompt: str, context: str = None, max_tokens: int = 4096):
    """
    调用 SubQ API
    核心优势：context 可直接传入超长文本（最高1200万Token）
    不需要 RAG、向量索引、分块
    """
    messages = []
    if context:
        messages.append({
            "role": "system",
            "content": f"以下是完整的参考材料：\n\n{context}"
        })
    messages.append({"role": "user", "content": prompt})
    
    async with httpx.AsyncClient(timeout=300) as client:
        resp = await client.post(
            f"{SUBQ_API_BASE}/chat/completions",
            headers={"Authorization": f"Bearer {SUBQ_API_KEY}"},
            json={
                "model": "subq-v1",
                "messages": messages,
                "max_tokens": max_tokens,
                "temperature": 0.1
            }
        )
        return resp.json()["choices"][0]["message"]["content"]

5.2 超长代码库分析：告别 RAG

import os

EXCLUDE_DIRS = {
    '.git', 'node_modules', 'venv', '__pycache__',
    '.venv', 'dist', 'build', 'target', '.tox'
}
SOURCE_EXTS = {'.py', '.js', '.ts', '.go', '.rs', '.java', '.cpp', '.h'}

def collect_codebase(repo_path: str) -> str:
    """收集整个代码库"""
    parts = []
    for root, dirs, files in os.walk(repo_path):
        dirs[:] = [d for d in dirs if d not in EXCLUDE_DIRS]
        for f in files:
            if any(f.endswith(ext) for ext in SOURCE_EXTS):
                path = os.path.join(root, f)
                try:
                    with open(path, 'r', encoding='utf-8', errors='ignore') as fh:
                        rel = os.path.relpath(path, repo_path)
                        ext = f.rsplit('.', 1)[-1]
                        parts.append(f"### {rel}\n```{ext}\n{fh.read()}\n```\n")
                except Exception:
                    pass
    return "\n\n".join(parts)

async def analyze_codebase(repo_path: str, question: str):
    """SSA 一次性分析整个代码库——无需 RAG"""
    code = collect_codebase(repo_path)
    est = len(code) * 1.3  # 粗略估算 Token
    if est > 12_000_000:
        print("⚠️ 超出 1200 万 Token 限制")
        return None
    
    return await call_subq(
        prompt=f"基于以上完整代码库：\n{question}\n"
               "要求：引用文件路径和行号，分析跨文件依赖，给出代码示例。",
        context=code,
        max_tokens=8192
    )

5.3 法律文档全量分析

async def analyze_legal_docs(docs: list[dict], query: str):
    """数百页法律文档一次性送入上下文"""
    ctx = "以下是所有法律文档：\n\n"
    for doc in docs:
        ctx += f"## {doc['filename']}\n{doc['content']}\n\n---\n\n"
    
    return await call_subq(
        prompt=f"基于以上文档：\n{query}\n"
               "要求：引用文档名和条款编号，识别跨文档引用和矛盾。",
        context=ctx,
        max_tokens=8192
    )

5.4 RAG vs SSA 对比

# 传统 RAG：需要 embedding 模型 + 向量数据库 + 分块策略 + 检索逻辑
# 信息可能遗漏，上下文碎片化

# SSA：一个 API Key + 完整文档 = 100% 信息覆盖 + 完整上下文理解

5.5 混合策略（过渡期）

async def hybrid_analysis(ctx: str, question: str, est_tokens: int):
    """小于 12M 直接 SSA；超出则分层处理"""
    if est_tokens <= 12_000_000:
        return await call_subq(prompt=question, context=ctx)
    
    chunks = smart_chunk(ctx, target=10_000_000)
    summaries = []
    for chunk in chunks:
        s = await call_subq(
            prompt=f"提取与问题最相关的关键信息（保留原文引用）：\n{question}",
            context=chunk, max_tokens=16384
        )
        summaries.append(s)
    
    combined = "\n---\n".join(summaries)
    return await call_subq(
        prompt=f"综合各部分分析，回答：\n{question}",
        context=combined, max_tokens=8192
    )

六、成本分析与生产级考量

6.1 成本对比（基准：1M Token = $100）

SSA 成本始终线性增长，传统架构呈二次增长。差距随上下文长度指数级扩大。

6.2 Subquadratic 公司概况

• 团队：11 名博士核心团队，CEO Justin Dangel，CTO Alexander Whedon
• 融资：$2900 万，估值 $5 亿
• 投资人：软银愿景基金前合伙人、Tinder 联合创始人
• 产品：SubQ API、SubQ Code（CLI 智能体）、SubQ Search
• 计划：2026 Q4 推出 5000 万 Token 模型
• 基础设施：运行在 neoclouds

6.3 风险评估

技术风险：模型规模较小、基准只运行一次、neoclouds 的可靠性存疑。

商业风险：Magic.dev 的前车之鉴（1 亿 Token 宣传 + 5 亿美元融资，但 2026 年未见落地）。生态不成熟。

建议：多供应商策略、小范围 POC、持续关注大厂跟进。

七、对行业格局的影响

7.1 RAG 的命运

• 短期（1-2年）：混合方案为主流
• 中期（3-5年）：随 5000 万 Token 推出，RAG 被大幅替代
• 长期：RAG 可能成为历史，类似 MapReduce → Spark

7.2 对大厂的压力

OpenAI、Anthropic、Google 面临架构重新设计的巨大投入。最可能的应对：加速研发线性注意力架构。

7.3 新应用场景

八、SSA 的数学原理

8.1 线性扩展的数学基础

传统密集注意力：
  S = Q × K^T    → n × n 矩阵   ← O(n²)
  O = softmax(S) × V

SSA 选择性注意力：
  indices[i] = Select(Q[i], K)    → 每行 k 个    ← O(n)
  S[i] = Q[i] × K[indices[i]]^T  → k 维         ← O(k)
  O[i] = softmax(S[i]) × V[indices[i]]           ← O(k×d)

关键：Select(Q[i], K) 不是全量两两比较，而是通过基于内容的路由在 O(n) 时间内找到每个 query 应关注的 key。

8.2 吞吐反转现象

SSA 带来了"吞吐反转"：随着上下文长度增加，稠密注意力相对于 SSA 变得更慢。这意味着 SSA 的优势在长上下文最有价值的区间内不断扩大。

在生产环境中，这种差异直接决定了长上下文系统是表现为 可交互的工具（秒级响应）还是 离线批处理任务（分钟甚至小时级）。

九、给开发者和企业的建议

9.1 对开发者

1. 保持关注，但不必焦虑：学习 SSA 原理，关注 API 进展，但不要立即抛弃现有技术栈
2. 思考新应用场景：如果上下文不再是限制，你能做什么？
3. 技能储备：长上下文 Prompt 工程、大规模文本处理、新的评估方法

9.2 对企业

1. 评估痛点：如果业务涉及大量文档处理、复杂代码库管理、跨文档信息检索，SSA 可能非常适合
2. 短期（6个月）：监控发展、小范围 POC
3. 中期（1-2年）：逐步迁移、建立混合架构（SSA + RAG）
4. 长期（3-5年）：全面评估、重构应用架构

9.3 风险管理

• 保持多供应商策略
• 建立抽象层便于切换
• 持续评估 ROI
• 关注 Magic.dev 等前车之鉴

十、总结展望

Subquadratic 的 SSA 架构代表了 AI 大模型从"堆参数"向"拼效率"的关键转变。它通过内容相关的选择性注意力机制，实现了真正的线性扩展，在 1200 万 Token 上下文中保持了强大的检索和推理能力。

这不仅仅是一个技术指标的提升，更可能引发：

• 架构范式的转变：从 Transformer 的 O(n²) 到 SSA 的 O(n)
• 应用模式的创新：RAG → 直接上下文
• 行业格局的重塑：给大厂压力，给创业公司机会

但同时，技术需要时间验证，生态需要逐步建立，商业化充满挑战。对于开发者和企业来说：保持关注，积极学习，小步快跑，谨慎试错。

AI 的未来，充满无限可能。而 SSA，可能是通往那个未来的一条全新路径。