Subquadratic 发布 SubQ Snap 长上下文决策模型
Introducing SubQ Snap: A Long-Context Decision Model
Subquadratic 发布 SubQ Snap,一个面向智能体工作流的长上下文决策模型,支持最多 384K tokens 的文本与图像上下文,可在约 1 秒内处理 100K tokens 并返回决策。
日期
2026年10月12日
Subquadratic 是唯一一家专门致力于研究基础模型算法如何在计算、内存和数据方面进行扩展的公司。近期大多数 AI 进展都来自通过增加参数、数据和计算量来扩展 transformer。我们研究的是底层的扩展关系,目标是构建在计算、内存和样本效率上最优的算法和模型。我们从注意力机制入手,在标准 transformer 中,其计算成本随上下文长度呈二次增长。为解决这一挑战,今年早些时候我们发布了 Subquadratic Sparse Attention (SSA),这一架构创新为 SubQ 提供支持,后者是首个完全次二次的 LLM,并通过其更新始终保持在前沿竞争力水平。
今天我们发布 SubQ Snap,一个基于相同基础研究构建的、面向智能体工作流的决策模型。我们的决策模型旨在承担智能体工作流中数据密集但结构化的决策,例如选择哪些文件相关、下一步使用哪个工具、测试结果是否通过,或哪个步骤需要前沿模型。智能体几乎在每一轮都会做出这些判断,因此一个能够快速且正确做出这些判断的模型可以降低整个工作流的成本和延迟。
好的决策依赖于上下文。现实世界的工作流通常需要对大量信息进行推理,例如,正确的下一步行动可能取决于代码库的其余部分、合同的先前页面,或工具调用和先前操作的漫长历史。然而,在长上下文下,二次注意力使每次调用都变得缓慢且昂贵,这完全违背了使用决策模型的初衷。因此,如今的决策模型停留在 32K token,并在看不到大部分所需信息的情况下做出决策。
Snap 消除了这一权衡。在 SSA 的驱动下,Snap 旨在高效处理这种不断增长的上下文,同时不牺牲使决策模型最初变得有用的速度和准确性。它能在最多 384K token 的文本和图像下做出每个决策,在不到一秒内处理最多 100K token 的请求,并在 Decision Index v0.2.1 上比 Jev 高出四分。
这使我们能够构建首个从前沿 LLM 手中接过实际工作的决策模型。如今,决策模型大多在 LLM 周围工作:评判其输出,或选择应由哪个 LLM 处理每项任务。然而,我们相信,当决策模型能够承担当今 LLM 所做工作流中的决策,甚至在某些情况下独立完成大规模任务时,它们会变得更加令人兴奋和有用。
下面,我们将更详细地展开上述权衡,描述 Snap 是如何构建并克服这一权衡的,并展示它在决策质量、长上下文使用、端到端智能体任务和成本方面的表现。
TL;DR
- 最多 384K token 的上下文。 Snap 可以在单次调用中对长代码库、文档、交互历史和其他工件进行推理,无需截断或分块。
- 长上下文下速度快。 Snap 可以处理 100K token 并在约 1 秒内返回决策。
- 多模态。 Snap 在同一上下文中接受文本和图像,允许将截图、图表、示意图和扫描页面与周围的文档和日志一起进行推理。
- 强大的长上下文性能。 Snap 在 1MM tokens 的 Decision RULER 上得分 96.3,在 Decision LCR 上得分 74.0,而 Jev 借助分块仅得 48.0%。
- 在企业任务上具有竞争力的决策质量。 在涵盖工具使用、安全、法律、金融、支持路由和代码的 16 项 Decision Index 基准测试中,Snap 平均得分 67.6,而 Jev 为 61.6,并在 16 项任务中的 13 项上领先。
- 在标准短上下文评估中达到前沿性能。 SubQ Snap 在 Decision Index 公开套件上得分 61.7,其中所有请求均低于 34k tokens,而 Jev 得分为 57.9。它在五个子领域中的四个领先 Jev,包括艺术与人类品味(+12.11)、语言理解(+7.46)、检索与分类(+6.27)以及工具与自动化(+3.39)。
- 每次决策仅需几美分。 Snap 每百万输入 tokens 成本为 $0.05,输出 tokens 免费。
Decision RULER
| 上下文长度 | SubQ Snap | Jev |
|---|---|---|
| 32K | 99.8 | 94.1 |
| 64K | 99.8 | N/A |
| 128K | 99.5 | N/A |
| 256K | 99.8 | N/A |
Decision LCR
| 上下文长度 | SubQ Snap(单次) | Jev(分块) |
|---|---|---|
| 72K–115K | 74.0 | 48.0 |
Decision Index
| 基准测试 | SubQ Snap | Jev |
|---|---|---|
| Decision Index 0.2.1(完整索引,技能) | 61.7 | 57.9 |
来自 Decision Index 的企业工作流
| 工作流 | 基准测试 | 测试内容 | SubQ Snap | Jev | 增益(分) |
|---|---|---|---|---|---|
| 客户支持路由 | CLINC150+OOS | 意图 + 超出范围 | 91.5 | 89.2 | +2.3 |
| BANKING77 | 银行意图(77 类) | 80.6 | 79.5 | +1.1 | |
| 安全 | PhishNChips | 钓鱼检测 | 47.1 | 25.1 | +22.0 |
| 搜索与检索 | Amazon ESCI | 产品相关性 | 48.7 | 43.8 | +4.9 |
| BRIGHT | 困难文档排序 | 44.3 | 40.6 | +3.7 | |
| 文档验证 | RAGTruth | RAG 幻觉检测 | 64.8 | 51.3 | +13.5 |
| HoVer | 多文档声明核查 | 54.2 | 45.7 | +8.5 | |
| 法律 | ContractNLI | 完整 NDA 条款审查 | 70.7 | 59.1 | +11.6 |
| 金融 | FinEntity | 金融新闻中的实体情感 | 92.8 | 80.8 | +12.0 |
| 医疗 / 制药 | NLI4CT | 临床试验报告 NLI | 72.8 | 69.0 | +3.8 |
| 代码 | CRUXEval | 预测代码输出 | 73.8 | 57.1 | +16.7 |
| 工具使用 / 自动化 | ToolRet | 工具检索 | 63.1 | 59.9 | +3.2 |
| BFCL | 函数调用 | 96.2 | 94.3 | +1.9 | |
| API-Bank | 下一个 API 调用 | 86.4 | 88.0 | −1.6 | |
| When2Call | 调用、询问、回答或拒绝 | 67.0 | 74.6 | −7.6 | |
| 客户反馈 | ACOS | 方面级评论分析 | 26.7 | 27.3 | −0.6 |
| 平均(16) | 67.54 | 61.6 | +5.96 |
Nimble Suite 13
| 基准测试 | SubQ Snap | Jev |
|---|---|---|
| Nimble Suite 13(宏观,13 个决策集) | 82.9% | 76.0% |

智能体需要决策,而不仅仅是生成
自动化工作流中的许多决策并不需要开放式文本生成。例如,在选择哪些文件相关、下一步使用哪个工具,或测试结果是否通过时,可能的答案集合可以预先定义。决策模型正是为这些用例而构建的。给定一些上下文、一个问题以及一组允许的答案,我们从模型中为每个答案采样一个概率,而不是生成开放式响应。这种从开放式生成到应用程序定义答案空间的限制被称为特化,其回报是效率。对预定义答案可能性进行评分取代了自回归生成,消除了生成应用程序不需要的文本所带来的延迟和成本。
特化为与语言模型交互定义了一种新接口,但并未规定架构。因此,近期发布的决策模型以不同方式实现特化。Laya、Perplexity 的 Decider 和 TypeSafe 的 Jev 暴露相同的接口(一个问题、一组有限的可接受答案、一个结构化预测),但采用不同的架构设计。例如,Laya 将双向编码器与决策头配对,而 Decider v1.1 则调整预训练语言模型以使用非因果注意力。
该接口可以通过将有界决策路由到专用模型来降低智能体工作流的成本,同时将更大、更昂贵的生成模型调用保留给真正需要开放式生成或扩展推理的任务。例如,一个编码智能体可以将工具选择和结果验证路由到决策模型,同时将更大生成模型的调用保留给代码合成和扩展推理。然而,狭窄的答案空间并不意味着小上下文。即使只是在三个工具之间做选择,也可能依赖于散布在整个代码库或漫长交互历史中的证据,而专业化并不能降低将其作为输入处理的成本。这一成本,即对长上下文的注意力计算,正是 Snap 旨在消除的约束。
智能体工作流中的上下文成本
在现实世界的智能体工作流中,可靠的决策往往依赖于整个上下文长度中的证据,包括远离问题本身的证据。直观的例子包括:40 轮之前陈述的用户约束、大型代码库中定义在不同模块里的函数,或单独文档中的限定条款。当前的决策模型要么处理所有这些证据,要么通过基于 RAG 和分块的工作流来减少证据。
在单个请求中处理所有内容会显著延长决策模型需要处理的上下文长度,而这会牺牲速度。对于决策模型而言,几乎所有的推理计算都是预填充。消除自回归生成去掉了输出的成本,但没有去掉读取输入的成本。在密集自注意力下,该成本随上下文长度呈二次增长,因此上下文翻倍会使注意力计算变为四倍。在长上下文下,这会侵蚀最初促使人们采用决策模型的节省效果。
另一方面,减少输入可能会牺牲信息。检索、摘要、截断和分块都会在上游决定模型能看到什么、看不到什么。在实践中,这些削减可能造成信息损失:截断可能丢弃 40 轮之前的约束,检索可能遗漏相关证据,摘要可能删除后来证明重要的细节。每个额外步骤还可能给工作流增加延迟和复杂性。
这种权衡在智能体循环内部变得尤为重要,因为同一个模型可能被反复调用来做出微小但影响重大的决策。Snap 旨在处理四种常见角色:路由、工具选择、检查和停止。

这些决策中的每一个可能都只有很小的答案空间,但正确做出决策所需的证据可能跨越更大的工件。
SubQ Snap:让长上下文决策更高效
Snap 支持最多 384K token 的混合文本和图像上下文。这使智能体能够分析大型工件,例如带有日志的代码仓库、合同及其附件,或文档连同截图、图表和扫描页面。
Snap 旨在完全避免上下文与延迟之间的权衡。SSA 使长输入读取更高效,而决策头使有界答案的生成更高效。
SSA 将注意力计算成本从二次复杂度降至线性复杂度,使 Snap 能够处理更多的底层工件,而不会随着上下文增长而付出同样高昂的注意力成本。这使得在计算和延迟不呈二次增长的情况下,将序列长度进一步大幅延长成为可能。随后,决策头将得到的表示直接映射为允许答案上的概率分布,从而避免自回归生成。
这些共同解决了决策模型工作负载的两个方面:
- SSA 解决了读取成本问题。内容相关的选择减少了处理长输入所需的注意力工作量,这建立在我们早期工作的基础上。
- 决策头解决了回答成本问题。它将上下文表示直接映射为可接受答案 A 上的分布,避免自回归生成。
评估
我们从四个维度评估 Snap,这些维度既反映了决策模型需要做好的方面,也反映了我们构建 Snap 所要处理的工作负载。
第一,通用决策质量。Snap 仍然是一个决策模型,因此它需要在广泛的任务中做出准确的选择。我们使用 Decision Index 和 Bespoke Labs 的 Nimble 基准来衡量这一点。
第二,企业决策质量。我们的重点是企业工作流。并非广泛索引中的每个任务都能反映企业将如何使用决策模型。因此,我们单独评估 Decision Index 中与企业工作负载最接近的一个子集,例如工具使用、支持路由、安全、法律、金融、文档验证和代码。
第三,长上下文检索。我们的核心论点之一是,当你对整个工件进行推理时,才能做出更好的决策。因此,检索是 Snap 设计支持的许多工作流的前提条件,也是 SSA 旨在使长上下文长度变得切实可行的一项能力。我们使用 Decision RULER 进行评估,它在 11 种不同类型的长上下文检索任务上测试模型。
最后,长上下文推理。找到相关证据只是任务的一部分。模型还需要结合工件不同部分或跨多个文档的信息,才能做出正确的决策。我们使用 Decision AA-LCR 进行评估,它测试对真实多文档输入的推理。
这些评估共同检验了 Snap 是否不仅能在一系列决策基准上表现良好,还能做出真实企业工作流所需的那类决策。
通用决策质量
我们使用 Decision Index 和 Bespoke Labs 的 Nimble 基准集合来评估通用决策质量。
Decision Index
Decision Index 是决策模型的公开基准。它涵盖五个加权领域的 37 个基准。每个基准都以多项选择决策的形式提出,评分方式使得随机猜测计为 0 分,完美回答计为 100 分。这确保了具有不同选项数量的任务能够被公平比较。索引中的每个请求都是一个简短决策,其中最长的约为 34K token,这意味着它衡量的是短上下文决策。在 Decision Index 0.2.1 上,Snap 得分为 61.70,而 Jev 为 57.90,并且在五大类别中的四个上优于 Jev,包括艺术与人类品味(+12.11)、语言理解(+7.46)、检索与分类(+6.27)以及工具与自动化(+3.39)。

Bespoke Nimble
Bespoke Labs 的 Nimble benchmark 包含来自 13 个公开数据集的 3,880 个人工标注示例,覆盖安全分类、意图检测、复述、蕴含、生物医学问题和摘要质量等任务。Snap 平均达到 82.9% 准确率,而 Jev 为 76.0%。

企业决策质量
Decision Index 企业工作流
聚合基准可能会掩盖模型之间的差异,因此我们还考察了 16 个直接对应常见企业工作流的 Decision Index 基准。
在这些基准上,Snap 平均得分为 67.6,而 Jev 为 61.6,并在 16 个基准中的 13 个上领先。其最大提升出现在钓鱼检测、代码执行预测、金融情绪、客户支持路由和合同审查方面。

长上下文检索
Decision RULER
RULER 将事实或针隐藏在长填充文本中,并要求模型找到、跟踪或计数它们。我们将 RULER 的 13 个任务中的 11 个重构为多项选择决策,同时保留原始样本、干扰项和隐藏事实。
我们用四个选项替换开放式答案。在可能的情况下,错误选项也会出现在填充文本的某处,确保模型必须找到正确选项。我们舍弃了两个问答任务,因为我们观察到即使移除上下文,模型也能凭记忆回答它们。
Snap 在 32K 到 1M token 范围内得分介于 96.3 和 99.8 之间,表明在长上下文上检索能力仍然很高。

Decision LCR
Decision LCR 改编自 AA-LCR,这是 Artificial Analysis 的一个长上下文基准,包含 100 个由人工编写的问题,基于 72K-115K token 的真实多文档集。我们将这 100 个问题转换为 118 个多项选择决策。每个决策使用不同的选项顺序评估三次,以避免评估中的位置偏差,并且一个问题只有在每个部分都回答正确时才能得分。随机/猜测概率为 19.2,移除文档后模型得分为 24-25。
SubQ Snap 得分为 74.0,Jev 模型得分为 48.0,领先 26 分,置信区间为 95%。Decision LCR 得分无法与已发布的 AA-LCR 结果比较,后者评分的是书面答案而非决策。这一结果既展示了 Snap 的长上下文推理能力,也表明许多问题从整体工件推理中获益,而非对分块进行推理。

定价与可用性
SubQ Snap 的定价为每百万输入 token 0.05 美元,输出 token 不收费。
SubQ Snap 以公开预览形式提供,先到先得,容量有限。一旦容量达到上限,新用户可能会被加入等待名单。随着我们上线更多容量,将逐步扩大可用范围。
立即在 subq.ai 试用 SubQ Snap。
Snap 只是开始。我们的语言模型 SubQ 1.1 Small 正处于早期访问阶段,面向选定的设计合作伙伴。如果您希望被考虑,请通过 sales@subq.ai 联系我们。
来源:Hacker News · subq.ai