SubQ Snap评测：决策模型跑分与价格战真相

一款叫SubQ Snap的模型发布了。在Hacker News上，它发帖数小时后只拿到7个赞和1条评论，那条评论还是句反问：“OpenAI的Decision API在Luna上不是支持1M上下文吗？”而在LinkedIn，同一场发布在14小时内收获220个表情和39条评论，企业账号热情洋溢地宣布“我们今天发布了一个新模型”。

同一天，同一个产品，两个平台读出了截然不同的信号。这篇分析想搞清楚：哪边是对的。

结论是：两边都对，也都不完全对。

决策模型到底是什么

SubQ Snap来自研究机构Subquadratic，它不生成文本，只做选择。你向它发送上下文、一个问题、一组允许的答案，它返回每个答案的概率。没有开放式输出。

这个限制恰恰是它的商业逻辑：不生成token，就不按token逐字计费。对固定答案打分很快，而速度在agent场景里意味着一切——哪个文件重要、下一步调用哪个工具、测试是否通过，这些判断每时每刻都在发生。

Subquadratic为Snap列出了四个职责：路由、工具选择、校验、停止。清单很干净，但用普通LLM加精心设计的提示词，今天也能搭出来。发布会通稿里没人提这一点。

讽刺的是，这款模型在When2Call测试中输给了竞品——67.0对74.6。这个测试恰好考察的是“该调用工具、该提问、该回答还是该拒绝”，正是Snap主打的四项职责之一。负责判断是否行动的家伙，在这个具体判断上不是最好的。

决策模型（Decision Model） 是区别于生成式LLM的一类专用模型：它不输出自由文本，而是对给定的一组候选答案计算概率分布，本质上是一个受约束的分类/打分器。这一范式在工业界已有先声——OpenAI的Decision API、Perplexity Decider等都属此列。其商业价值在于：由于不生成token，推理成本可以按输入长度而非输出长度计价，且延迟极低（通常毫秒级）。典型应用场景是agent loop中的"下一步该做什么"——路由到哪个子agent、调用哪个工具、结果是否通过校验、是否应该停止。这类判断每次只需一个离散答案，用生成式LLM去"写"出答案既慢又贵，因此决策模型以专用形态切入。

上下文墙与定价战

真正的问题不在答案，而在输入。下一次正确的调用，可能取决于四十轮对话之前某条约束、代码库深处某个函数的定义、合同第九页的某个条款。

标准Transformer的注意力计算是二次方的：上下文翻倍，算力翻四倍。这就是决策模型一直做不大的原因。Jev每请求64K、32K状态，微软的模型跑32K——它们在看不到大部分关键信息的情况下做决定。

Snap的答案是Subquadratic Sparse Attention（SSA），把成本从二次方降成线性，于是能一次读完整个代码仓库或合同。Subquadratic声称100K token在1秒内返回，但这个数字没有硬件说明，也没有第三方验证。架构是真正的研究，不是套壳API。

但价格战才是这个市场最刺眼的部分。三周内六款托管决策模型发布：Jev、Perplexity的Decider、Cloudflare的Clef、OpenAI的Decisions API、微软的Decision-1，加上SubQ Snap。价格已经滑到每百万输入token以美分计。

模型	每百万输入价格	上下文
Perplexity	$0.04	~262K
微软 Decision-1	$0.042	32K
Jev	$0.042	64K
SubQ Snap	$0.05	384K
OpenAI (gpt-6-luna)	$0.10	n/a
Cloudflare Clef	$0.24	64K

市场以这种速度移动时，模型本身不是护城河。工作流才是。赢家拥有路由逻辑，而不是一份供应商合同。

二次方注意力与稀疏注意力：标准Transformer中，self-attention需要计算每个token与所有其他token的相关性，序列长度为N时计算量与内存都是O(N²)。当上下文从32K涨到384K，理论算力涨约144倍——这正是决策模型长期停留在32K-64K的硬约束。Subquadratic Sparse Attention（SSA）的思路是让每个token只关注部分关键token，把复杂度降到接近O(N)线性。类似路线包括Longformer、BigBird、FlashAttention（优化常数因子）以及Mamba/SSM等。但稀疏注意力通常以一定的精度损失为代价，能否在长上下文下游任务上不退化，是这类架构最需要独立验证的环节。

跑分里的星号

官方给出的图表很好看。Decision Index 0.2.1从61.7降到57.9，长文档测试从74.0升到48.0（此处数字方向待确认）。Snap在16项企业任务中领先13项，钓鱼检测从25.1跳到47.1，代码输出预测从57.1升到73.8。

但每一个数字都来自Subquadratic自己，没有外部实验室跑过Snap。长上下文测试是他们自己对RULER和LCR的改版。更关键的是，那个96.3分、被称为头条成绩的Decision RULER，运行在1M token上下文中——而产品本身只支持384K。

他们发布了一个产品根本无法接受的基准测试。

这些数字应该被当作简历，而不是审计报告。一切自报，只对比一个对手，用的是厂商自己改版的测试。等独立排行榜跑出结果的那天，数字会变的。

RULER与LCR是长上下文评测中被广泛引用的两个基准。RULER由英伟达等机构提出，覆盖"大海捞针"、多针检索、变量追踪等合成任务，测试模型在超长上下文中定位和整合信息的能力；LCR（Long Context Retrieval）类测试则聚焦检索精度。厂商对基准做"改版"是常见操作，但改版后的分数不能与公开榜单直接比较——不同改版的难度、数据分布、评分口径都可能不同。这也是为什么业界强调"第三方复现"：当一家机构用自己改过的RULER跑出96.3分，且运行在1M上下文（产品仅支持384K）时，该数字的参考价值大幅下降。

肾脏猫与肽精华

研究时有个让人发笑的发现：在Reddit搜“subq snap”，模型完全不在结果里。跳出来的是猫肾衰竭的皮下输液论坛、SNAP-8肽抗皱精华的评测、还有弹簧注射器的讨论帖。

“subq”是医学上“皮下”的缩写。这家公司用一个医学缩写加一个零食品牌词命名产品，然后把它丢进了AI炒作风暴。有一阵子，任何人想谷歌这个模型，看到的都是猫的体液和护肤建议。某种程度上，这很诚实。

大多数人不需要决策模型

至少现在不需要。如果你的agent每天只做几百次调用，用便宜LLM做路由就够了。为了省几分钱而增加的复杂度，是你今后要永远维护的复杂度。

就算真需要，也别在第一天就基于一个带等待列表的公开预览版来构建——模型ID字面意思是subq-snap-preview。那不是稳定性承诺，那是警告。

唯一能让人认真对待Snap的，是一次真实的仓库测试：agent读自己的代码库、挑文件、检查结果、把账单递过来。这样跑一周，胜过发布帖里的任何一张图。

Snap是真实的工程，SSA不是套壳，384K上下文在1秒内返回确实有意思。但三周前，其他人也一样有意思。领先位置每时每刻都在换人，所谓“第一”是一份备忘录，不是护城河。