SubQ AI 深度解析：12M 上下文窗口的大模型到底有多强？

2026 年 5 月 5 日，总部位于迈阿密的一家小型初创公司 Subquadratic 发布了一款名为 SubQ 的模型。团队规模不大，但他们已筹集了 2900 万美元的种子轮资金，并声称该模型可以在 单次推理中处理多达 1200 万个 token。

他们还提出了其他听起来相当夸张的说法，比如在 100 万 token 情况下，该模型的效率最高可达 FlashAttention 的 52 倍，并且以大约 1/20 的成本实现与 Claude Opus 类似的代码能力。

这些断言都不小，因此值得拆解看看其中究竟发生了什么。在本文中，我将介绍 SubQ 是什么、其架构如何工作，以及早期细节与开发者社区对 这些主张的看法。

什么是 SubQ？

SubQ 是 Subquadratic 于 2026 年 5 月 5 日发布的大语言模型（LLM），围绕一个核心亮点构建：1200 万 token 的上下文窗口。这是该公司发布的首个模型，并伴随着关于效率与成本的一系列大胆主张，已在业内引发了广泛讨论。 

该模型尚未公开，API、SubQ Code 与 SubQ Search 的访问目前仅限于候补名单上的早期体验用户。

它基于一种名为 SSA 的机制，即 Subquadratic Sparse Attention（次二次稀疏注意力）。

与标准的稠密注意力需要比较每个 token 与序列中其他所有 token 不同，SSA 采取选择性策略。对每个 token，模型会挑选最相关的 token，只在该子集内计算关系。

这 带来两个明显效果。

• 其一，减少计算量，直接提升效率并降低成本。 
• 其二，选择取决于内容。这意味着模型并不只关注邻近的 token，它可以从序列中的任意位置拉取相关 token，即使它们相距很远。

SubQ 的特别之处在哪里？

在实践中，SSA 架构意味着模型将注意力集中在真正重要的部分，而非对所有内容一视同仁地处理。预期结果是在显著降低算力与内存需求的同时，达到与全注意力相近的准确度。

我们先更近一步看看稠密注意力，然后比较这两种方法。

Transformer 的二次方扩展难题

当今的模型，如 GPT、Claude 和 Gemini，依赖稠密注意力。从高层来看，这意味着输入中的每个 token 都会与其他每个 token 进行比较。随着输入增大，比较次数呈二次方增长。

以一篇长文档为例，假设模型需要生成最后一个词。它会回看文档中的每个 token，建立关联关系，然后决定接下来该输出什么。这也是稠密注意力效果好的原因：它把一切都考虑在内。

但这种优势也带来代价。随着输入规模增加，算力与内存需求会急剧上升，并形成 上下文窗口 的限制。通俗地说，它的复杂度是 O(n²)，其中 n 为 token 数量。

这就是为什么大多数模型会停留在实用上限内。在标准模型中，128k token 较为常见，而像 Claude Opus 这类强模型的上限也多为 100 万的上下文窗口。

为绕开这一点，大多数 AI 系统不会把完整数据集都喂给模型，而是依赖如下技术：

• RAG（检索增强生成）：将数据存储在外部，只取回相关块并传入模型。
• 切分（Chunking）：把长文本切成更小的片段，仅把相关片段发送给模型。
• 摘要策略：将长内容压缩为摘要，传给模型，而不是整个文本。

如果您想更深入理解注意力机制，可以查看这篇关于 LLM 注意力机制 的教程。若想上手现代 LLM 的构建模块，推荐我们的 用 PyTorch 构建 Transformer 模型 课程。

SubQ 的差异化定位

稠密注意力随输入规模呈二次方增长，而 SSA 旨在实现次二次扩展，更接近于 O(n·k) 而非 O(n²)，其中 k 为每步选取的 token 数。当 k 相对 n 保持较小，这比全注意力高效得多。

二次方与线性注意力对比示意图：稠密的全对全连接 vs 稀疏的选择性连接。

显而易见的担忧是准确度。如果模型只看输入的一部分，可能会错过重要关系。这种权衡通常就是稠密注意力存在的原因。

SubQ 的说法是，这种权衡在实践中并不会显著出现。他们表示模型会关注到所有必要的 token，即使它们与当前 token 相距甚远，并能保持与顶级模型相近的准确度。

Subquadratic 稀疏注意力如何工作？

到目前为止，我们知道 SSA 并不会比较每个 token 与所有其他 token，而是只选择序列中重要的 token，并在这些位置上计算注意力。接下来看看它如何做出这种选择。

SSA 如何选择相关关系

SSA 使用基于内容的路由。简单来说，它会根据 token 与当前 token 的相关性来做选择。它计算 token 间的相似度分数，类似于 similarity(query_i, key_j)，并仅保留得分最高的前 k 个 token 参与注意力计算。

随着训练推进，模型会学会优先考虑有意义的 token，忽略噪声。这包括关键词、重要实体，以及承载强上下文信号的 token。

除了依赖内容，SSA 还保留序列中的结构关系。例如，邻近 token 会通过局部注意力模式始终获得关注，而某些全局 token 则被设计为可跨整段序列进行关注。

SSA 还包含分层与基于聚类的注意力技术。例如，它会对相似 token 进行聚类，并与最相关的簇计算注意力。这意味着模型无需逐个评估所有 token，而是可以先在组层面进行推理，必要时再放大到簇内的具体 token。

面向长上下文检索的训练

仅有大上下文窗口并不会带来魔法。即便给模型 1200 万个 token，它仍需要知道如何有效使用这些上下文。SSA 正是为此进行训练：

• 预训练：在海量且多样的数据集上进行训练，涵盖长上下文表示。 
• 监督微调：在结构化任务上训练，包括推理与代码生成。 
• 强化学习：这一阶段不是将模型局限于考虑邻近 token（局部注意力），而是让其能从整段文本中（全局注意力）使用相关 token。

强化学习阶段对企业级编码场景尤为重要。它让模型在生成输出时，能够一次性考虑更广泛的上下文，在此处就是整个代码库。

SubQ 的基准与性能

请注意，“SubQ 1M-Preview”指的是在 100 万 token 下进行评测的版本。完整的 1200 万上下文窗口可通过 API 访问。

在 Subquadratic 选择公布的三个基准上，SubQ 1M-Preview 与 Claude Opus 4.7、GPT-5.5 和 Gemini 3.1 Pro 不相上下。 

不过，所选基准较为狭窄：只有三个测试，且都聚焦于长上下文检索与编码——这两者正是 SubQ 明确设计擅长的方向。关于更广泛的能力，如通用推理、数学、多语种与安全性方面的评估尚未发布。

网站上的完整模型卡标注为“即将推出”，因此我们可以期待在此处看到更多围绕 基准的通用用例评测。

目前，以下是长上下文检索与编码用例的结果：

数据说明了什么

RULER 128K：SubQ 得分 95%，对比 Opus 4.7 的 94.8%。尽管准确度差异可忽略不计，但这里真正重要的是成本：Subquadratic 声称在 SubQ 上运行此评测大约花费 8 美元，而在相同上下文长度下 Opus 约为 2600 美元。

MRCR v2（8-needle，1M）：该基准测试模型能否在 100 万 token 的上下文中正确检索并跟踪分散的 8 条事实。SubQ 的研究结果为 83%，但生产分数下降至 65.9%。实验室与部署表现约 17 个百分点的差距值得关注，且尚未有充分解释。即便如此，它仍与 GPT-5.5（74.0%）具备竞争力，并显著领先于 Claude Opus 4.7（32.2%）与 Gemini 3.1 Pro（26.3%）。

SWE-Bench Verified：SubQ 得分 81.8%，略高于 Opus 4.6 的 80.8%，但低于 Opus 4.7 的 87.6%。与 Opus 4.6 的差距很小，对评测框架较为敏感。相较于 Opus 4.7 与 GPT-5.5，SubQ 明显落后。

在 1200 万 token 下：据报道，SubQ 在 1200 万上下文的“大海捞针”任务中得分超过 90%，但这一数字尚未在官方基准中得到验证。其他前沿模型尚未在该长度上进行测试，因此没有可直接对比的对象。这是本次发布中在架构上最有意思的结果，同时也是在得出结论前最需要独立复现的一项。

SubQ 对 RAG、编码代理与 AI 成本意味着什么

如果 SubQ 的架构能在规模上站得住脚，LLM 系统的构建方式将发生改变。更长的上下文将变得可行，降低对激进切分、检索与 token 优化的依赖。我们来更详细地看看这些变化。

当 RAG 变成可选项

在过去两年中，检索增强生成（RAG） 一直是针对 LLM 根本限制的默认解法：模型无法一次读完所有内容。如果您的知识库大于上下文窗口，您会对文档切分、嵌入、存入向量数据库、检索最相关的片段，并将这些片段与提示一起传给模型。

整个生态之所以存在，是因为上下文稀缺。

当模型能够在一次推理中可靠地处理数百万个 token 时，围绕检索构建的许多工程层在某些工作流中将不再那么必要。系统无需花时间决定取哪些片段，而是可以直接摄入原始材料并端到端地进行推理。

不过，超出上下文窗口之外，RAG 仍然重要，体现在以下能力上：

• 跨会话记忆：LLM 在会话结束后不会记住任何内容。若用户稍后回来，模型会从零开始。检索系统（或数据库）会存储诸如过去决策、文档或用户数据等重要信息，便于模型在未来交互中记住并使用。
• 权限与访问控制：检索系统可以强制执行诸如“该用户只能访问其团队数据”之类的规则。这样，模型只会接收用户被允许查看的文档，防止数据意外泄露。
• 可审计性：在企业环境中，仅给出答案还不够；您需要说明其正确性来源。检索系统能指向使用的确切文档或来源，以便团队核实结果并在出现问题时进行调试。
• 结构化知识管理：公司会不断新增、更新与移除文档。检索系统利用嵌入与索引对这些数据进行组织，让模型能快速找到最新且最相关的信息，而无需每次都重新处理全部内容。

想了解一种为 AI 代理添加持久记忆的新颖方法，请阅读我们的 Supermemory 教程，其中您将学习如何构建具备短期与长期记忆的健身教练。

长上下文的编码工作流

目前，大多数编码模型无法“看见”整个代码库。因此我们在其上叠加多层能力，如文件搜索、切分、排序与多步规划，仅为将正确的上下文保留在窗口中并建立跨文件的关联。

但借助 SubQ 的 1200 万上下文，整个代码库可以一次性加载到模型中。这将以一种有意义的方式简化代理设计。

• 规划变为全局：模型可以在不丢失上下文的情况下，推理架构、依赖与跨文件交互。
• 执行更连贯：可在单次推理中协调对多个文件的修改，而非通过增量更新。
• 审核更可靠：模型可以基于整个代码库校验自身改动，减少不一致。

成本经济性

在标准 Transformer 模型中，注意力随序列长度呈二次方扩展。如果您将上下文翻倍，成本不只是翻倍；它可能会变成四倍之多。

SubQ 声称打破了这项权衡。

• 据称与可比的前沿模型（Claude Opus）相比，成本约为其 1/20
• 在 1200 万 token 上下文下，计算量最高可减少约 1000 倍

如果这在生产中能够成立，长上下文处理将不再是昂贵的边缘场景，而会成为您可以更常规使用的能力。

不过，除了便宜的上下文窗口外，模型还应能高效利用我们加载进上下文的信息。基于这些基准，SubQ 声称以更低的成本达到可比准确度，但现在下结论仍为时过早。

我如何获取 SubQ？

SubQ 目前尚未公开。核心 API、SubQ Code 与 SubQ Search 三款产品仍处于私测阶段，访问需要通过 SubQ 官网提交早期访问申请。

从开发者视角看，该 API 易于集成，支持：

• 流式响应
• 工具/函数调用
• 兼容 OpenAI 的端点

这意味着如果您的技术栈已兼容 OpenAI 风格的 API，通常无需重写集成逻辑。

SubQ Code 的定位是命令行编码代理，而 SubQ Search 聚焦于面向深度研究工作流的长上下文搜索。可以将它们视为 Claude Code 与 Perplexity 的 SubQ 版本。 

这些工具的定价也尚未透明。尚无公开的每token 费率，因此难以独立验证公司的成本声明。

质疑与悬而未决的问题

在发布后的数小时内，社交媒体与如 Hacker News 等论坛上已出现大量质疑与分化反应。讨论呈两极分化：有人将其视为继 Transformer 之后的重大突破，也有人拿它与“AI Theranos”相提并论（指那家因虚假技术声明而失败的血检初创公司）。

大多数质疑集中在： 

• 他们声称有 1200 万上下文窗口，但公布的基准测试都在 100 万下进行。
• 公司名为 Subquadratic，但在某些地方又提到类似 O(1) 的扩展。如果真是 O(1)，我们会预期远超 1200 万 token 的上下文上限。即便是 O(log n) 也能支持更大的上限。

类似的叙事在 2024 年的 Magic.dev 身上也出现过。他们曾就极大上下文窗口（高达 1 亿 token）与显著效率提升（尤其在编码工作流上）提出强势主张。 

当时的宣传几乎一致：加载整个代码库、降低检索复杂度、简化代理设计。但至少在公开层面，结果更为平淡。尽管筹集了约 5 亿美元，截至 2026 年初，现实世界的曝光度或采用度仍然有限。

已被验证的部分

SubQ 的主张并非纯理论。Subquadratic 报告称，RULER、MRCR v2 与 SWE-Bench Verified 的测试由第三方评测服务执行，显示其在长上下文检索上表现强劲，并在编码任务上具有竞争力。 

不过，这些结果尚未被外部研究者独立复现，且评测范围较窄。三个基准都强调了 SubQ 专门构建的方向（从大上下文中检索信号并在代码上运行）。

另一个重要细节是架构。CTO 已确认 SubQ 并不从零开始训练模型，而是基于开源基础模型进行构建（很可能来自 DeepSeek 或 Kimi 等家族）。对于小团队而言，这是务实之选：能加速迭代并降低训练成本。这也意味着核心创新不在基础模型本身，而在注意力机制与其周边的系统设计。

结语

SubQ 已经到来，宣称相当大胆。方向很明确：去除上下文窗口的束缚，让模型处理更大的输入。他们将其定位为在编码与长上下文检索上可与前沿模型匹敌甚至超越，同时成本更低。

话虽如此，现在仍为时尚早。我们仍在等待完整的模型卡，以更全面了解其广泛能力与测试情况。其上层产品 SubQ Code 与 API 也尚未公开。我期待尽快上手这些工具，看看这些主张在生产中能否站得住脚。