一文读懂 SubQ：为什么“次二次稀疏注意力”可能改变长上下文 AI？

摘要

大语言模型越来越强，但它们在处理超长文本时仍然面临一个核心瓶颈：上下文越长，注意力计算成本越高。传统 Transformer 的注意力机制通常具有近似 O(n²) 的计算复杂度，这意味着输入长度翻倍，注意力计算量可能接近变成四倍。

最近，Subquadratic 推出的 SubQ 模型引发了不少关注。官方称，SubQ 使用了一种 Subquadratic Sparse Attention，次二次稀疏注意力 架构，可以把长上下文处理成本从传统的平方级增长，压到接近线性增长；同时支持最高 1200 万 token 的上下文窗口，并在长上下文与代码任务上给出了较亮眼的基准测试结果。(Subquadratic)

这篇文章将用尽量通俗的方式，带你理解：

• 为什么传统 Transformer 处理长文本很贵？
• 什么是“次二次稀疏注意力”？
• SubQ 到底声称解决了什么问题？
• 这些性能数据应该如何理性看待？
• Hermes Agent + HyperFrames 这类 AI 视频生成工具又和内容创作有什么关系？

---

1. 长上下文为什么难？

我们平时使用大模型时，经常会遇到一个问题：
想让 AI 阅读一本书、一整个代码仓库、几十份 PDF 或者一段很长的聊天记录时，模型不是变慢，就是成本变高，甚至还可能“看了但没真正理解”。

根本原因之一在于 Transformer 的核心机制：注意力机制 Attention。

在标准 Transformer 中，每个 token 都需要和其他 token 建立关系。假设输入长度是 n，那么 token 两两交互的数量大致是：

n × n = n²

也就是说，输入越长，计算量不是线性增加，而是平方级增长。

举个例子：

1,000 个 token  → 大约 1,000,000 次关系计算
10,000 个 token → 大约 100,000,000 次关系计算
100,000 个 token → 大约 10,000,000,000 次关系计算

这就是所谓的 Quadratic Attention，二次方注意力瓶颈。

VentureBeat 对 SubQ 的报道中也提到，标准 Transformer 的注意力会比较输入中几乎所有 token 对，因此输入变长后，计算成本会以平方级上升；这也是当前长上下文模型成本高、延迟高的重要原因。(Venturebeat)

---

2. 一个生活化比喻：全班群聊 vs 圈层沟通

为了更容易理解，可以把 token 想象成一个班级里的学生。

传统 Transformer：全班每个人都互相私聊

如果班里有 1000 个学生，传统注意力机制相当于：

每个学生都要和其他所有学生聊一遍

这种方式信息最完整，但代价也非常高。学生越多，交流次数暴涨。

稀疏注意力：只找真正重要的人聊

稀疏注意力的思路是：

不是所有人都需要互相聊天。
有些人只需要和附近同学交流；
有些信息只需要通过班长、课代表、老师这样的关键节点传播。

这样一来，模型不再计算所有 token 之间的关系，而是尝试只计算“最可能有用”的关系。

这就是 Sparse Attention，稀疏注意力 的核心思想。

---

3. 什么是“次二次稀疏注意力”？

“次二次”这个词听起来有点拗口，其实它指的是：

计算复杂度低于 O(n²)

常见的复杂度可以简单理解为：

O(n²)     ：平方级，输入越长，成本暴涨
O(n log n)：低于平方级，增长较慢
O(n)      ：线性级，输入翻倍，成本大约也翻倍

SubQ 官方宣称，其架构可以实现接近 O(n) 的长上下文扩展方式，也就是输入长度增长时，计算成本更接近线性增长，而不是平方级增长。(Subquadratic)

这类机制的关键点在于：

不是所有 token 关系都同等重要。
模型应该学会判断哪些 token 之间真的需要建立注意力连接。

换句话说，传统 Transformer 更像是“暴力全连接”，而次二次稀疏注意力更像是“智能筛选连接”。

---

4. SubQ 声称做到了什么？

根据 SubQ 官方页面，SubQ 被定位为一个面向长上下文任务的 sub-quadratic LLM，主要卖点包括：

上下文窗口：12M tokens
推理速度：官方标称 150 tokens/s
成本：官方称约为其他领先模型的 1/5
架构：fully sub-quadratic sparse-attention architecture

官方还声称，在 1200 万 token 场景下，SubQ 可以将注意力计算量减少接近 1000 倍。(Subquadratic)

这意味着什么？

如果这些数据能够在更多第三方测试中被验证，那么 SubQ 这类架构可能会显著降低以下任务的成本：

完整代码仓库分析
长篇合同审查
大型知识库问答
多月项目记录总结
企业内部文档检索
复杂 Agent 的长期记忆管理

过去这些场景通常需要 RAG、向量数据库、文档切片、摘要链、多 Agent 调度等工程方案绕开上下文限制。SubQ 的思路则更激进：
既然模型上下文不够，那就直接把上下文窗口做得更长，同时让长上下文计算变便宜。

---

5. SubQ 的基准测试数据怎么看？

SubQ 官方页面列出了一些关键 benchmark：

SWE-Bench Verified：SubQ 1M-Preview 得分 81.8%
RULER @ 128K：95.0%
MRCR v2 8-needle, 1M：65.9%

其中，SWE-Bench Verified 主要衡量模型解决真实软件工程问题的能力；RULER 更偏向长上下文理解与检索能力。SubQ 官方页面显示，其 SWE-Bench Verified 得分为 81.8%，RULER @ 128K 得分为 95.0%。(Subquadratic)

但是，这里需要注意两点。

第一，SubQ 的技术报告目前仍标注为 “coming soon”，也就是说，外界还缺少完整论文、开源细节或更透明的复现实验材料。(Subquadratic)

第二，VentureBeat 在报道中也特别指出，研究社区对 SubQ 的反应比较复杂：有人认为这是值得关注的架构突破，也有人要求更多独立验证，担心它可能只是一次包装精美的长上下文营销。(Venturebeat)

所以更稳妥的说法是：

SubQ 提出了一个非常值得关注的方向，
但它是否真的能成为新一代长上下文架构，
还需要等待技术报告、API 实测和更多第三方评估。

---

6. 为什么长上下文这么重要？

很多人会问：
“RAG 不是已经能解决知识库问答了吗？为什么还需要 1200 万 token 上下文？”

原因是，RAG 解决的是“从海量资料里找一小部分相关内容”，而超长上下文模型想解决的是“直接把大量资料放进模型，让模型整体理解”。

这两者并不完全相同。

RAG 的典型流程

用户提问
↓
检索相关文档片段
↓
把片段塞进 prompt
↓
模型生成答案

这种方式成本较低，但存在几个问题：

检索可能漏掉关键片段
文档切片可能破坏上下文
模型只能看到局部信息
多跳推理容易失败

长上下文模型的理想状态

把完整代码库、完整文档集、完整历史记录交给模型
让模型在全局范围内推理

这对以下场景非常有价值：

代码重构：理解整个项目结构
法律审查：对比多份合同条款
科研分析：跨论文综合推理
企业助理：理解长期项目历史
AI Agent：保留长期任务状态

如果长上下文计算成本真的降下来，AI 应用的工程架构可能会发生变化：
过去我们花大量精力做“检索、切片、摘要、路由”，未来可能更多转向“直接全量上下文推理”。

---

7. 稀疏注意力并不是新概念，难点在于“既快又准”

需要强调的是，稀疏注意力本身不是今天才出现的新概念。

此前很多研究都尝试过：

局部窗口注意力
块状稀疏注意力
滑动窗口注意力
全局 token 注意力
检索增强注意力
低秩近似注意力

这些方法的共同目标都是降低注意力成本。

但难点在于：

如果稀疏得太狠，模型会漏掉重要信息；
如果保留太多连接，计算成本又降不下来。

所以真正困难的地方不是“让注意力变稀疏”，而是：

让模型知道什么时候该看哪里。

SubQ 的核心主张正是：
它的 Sparse Attention 不是固定模式，而是根据内容动态判断哪些 token 关系重要。VentureBeat 的报道中也提到，SubQ 的 SSA 会基于内容选择需要关注的位置，而不是只依赖固定的位置模式。(Venturebeat)

如果这一点成立，那么它比简单的滑动窗口注意力更灵活。

---

8. 对开发者有什么影响？

如果 SubQ 这类架构被验证并逐步开放，对开发者可能有几个直接影响。

8.1 代码助手会更懂整个项目

现在很多 AI 编程助手虽然能读文件，但很难真正理解整个大型仓库。

未来如果模型可以低成本处理百万级甚至千万级 token，那么它可以一次性读取：

完整源码
历史 PR
issue 讨论
测试用例
架构文档
CI 配置

这会让 AI 编程助手从“局部代码补全”进化到“项目级软件工程助手”。

8.2 RAG 架构可能被重新设计

并不是说 RAG 会消失，而是 RAG 的角色可能改变。

过去 RAG 是因为模型上下文不够，不得不只取几个片段。
未来 RAG 可能更多用于：

权限控制
数据更新
结构化索引
高精度召回
多源数据融合

而不是单纯为了“省 token”。

8.3 Agent 会更适合长任务

AI Agent 最大的问题之一是“记不住长期状态”。

如果长上下文足够便宜，Agent 可以保留更多任务历史，例如：

用户长期偏好
项目演进过程
多轮工具调用结果
历史失败尝试
长期计划状态

这会让 Agent 更像一个真正的长期协作伙伴。

---

9. Hermes Agent + HyperFrames：AI 科普视频的新玩法

原文最后提到的 Hermes Agent 和 HyperFrames，更偏向内容创作工具链。

根据相关社区信息，HyperFrames 可以让 AI Agent 使用 HTML、CSS、JavaScript、GSAP 动画等方式生成视频画面，并通过 headless Chrome 与 FFmpeg 渲染成 MP4。(Reddit)

这类工具的意义在于：

过去制作一个 AI 科普视频，需要写脚本、做分镜、配动画、剪辑、导出；
现在可以尝试让 Agent 根据文本自动生成视频结构和动画。

对于技术博主、自媒体作者、知识分享者来说，这意味着一篇文章可以进一步扩展成：

CSDN 博客
B 站科普视频
小红书图文
公众号长文
短视频脚本
课程讲义

也就是说，AI 不只是模型本身在进化，围绕 AI 的内容生产工具链也在快速进化。

---

10. 理性总结：SubQ 值得关注，但别急着神化

SubQ 的出现确实很有看点。

它抓住了大模型行业的一个核心矛盾：

模型越来越需要长上下文，
但标准 Transformer 的注意力计算成本太高。

它给出的答案是：

用次二次稀疏注意力减少无效计算，
让模型只关注真正重要的 token 关系。

如果 SubQ 的官方数据能够被更多第三方验证，那么它可能会推动长上下文 AI 应用进入一个新阶段。尤其是在代码分析、企业知识库、法律文档、科研阅读、长期 Agent 等场景中，这种架构的潜力非常大。

但同时，我们也应该保持技术社区应有的谨慎：

技术报告尚未完全公开；
部分 benchmark 仍需要更多独立复现；
真实 API 成本、稳定性、延迟和可用性还需要实测；
长上下文“能放进去”和“能正确用起来”是两回事。

所以，最合理的态度不是盲目吹捧，也不是直接否定，而是：

持续关注，等待实测，用数据说话。

---

参考资料

• SubQ 官方网站：SubQ 12M token context、SSA 架构、benchmark 数据。(Subquadratic)
• VentureBeat 对 Subquadratic / SubQ 的报道与独立验证讨论。(Venturebeat)
• Hermes Agent + HyperFrames 社区介绍：基于 HTML、CSS、JS、GSAP、Chrome、FFmpeg 生成视频。(Reddit)

---

写在最后

如果说过去几年大模型的主旋律是“参数更大、数据更多、推理更强”，那么接下来很可能会进入另一个阶段：

谁能更便宜、更稳定、更有效地处理超长上下文，
谁就更接近下一代 AI 基础设施。

SubQ 是否真的会成为这个方向的代表，还需要时间验证。
但“稀疏注意力”和“长上下文低成本推理”这个方向，值得每一个 AI 开发者持续关注。