Subquadratic 发布 SubQ Snap：384K 上下文决策模型，专接 Agent 的路由/选工具/判通过

核心背景与行业痛点

Agent 每一轮都在做大量「小决定」：哪些文件相关、下一步调哪个工具、测试结果算不算通过、这一步值不值得交给前沿大模型。把这些判断都交给生成式 LLM，既慢又贵；而现有决策模型（如 TypeSafe 的 Jev、Perplexity Decider）上下文多停在 32K，只能靠 RAG、截断或分块，常把 40 轮之前的约束或另一个模块里的函数定义丢掉。Subquadratic 10 月 12 日发布的 SubQ Snap，正是冲着「长上下文 + 低延迟决策」这个空档来的。

架构亮点与底层机制

1. SSA 次二次稀疏注意力：按内容选择注意力，计算量随上下文线性增长，官方称每 token 计算成本恒定。
2. 决策头取代自回归解码：输入「状态 + 问题 + 可选答案」，直接输出每个答案的概率，省掉生成文本的时间与费用。
3. 多模态：截图、图表、扫描页可与日志、代码放在同一上下文，最长 384K。

权威 Benchmark 与实测跑分对比

以下均为厂商自测：Decision Index 0.2.1 得 61.7（Jev 57.9）；16 项企业任务均分 67.6 vs 61.6，13 项领先，钓鱼识别 +22.0、CRUXEval +16.7，但 When2Call 落后 7.6、API-Bank 落后 1.6；Decision LCR 一次读完 74.0，对比 Jev 分块 48.0；Decision RULER 在 32K–1M 区间保持 96.3–99.8。延迟官方给出约 80ms（极短上下文）、250ms（32K）、660ms（100K）、2.5s（384K）。

开发者实战落地与开箱指南

在 console.subq.ai 注册拿 key，调用 POST https://api.subq.ai/v1/systemone，model 填 subq-snap-preview，问题类型支持 noul（是/否）、choice、score。注意：这个接口不兼容 OpenAI 格式；公测按先到先得开放，容量满了会进候补名单。建议做法：把编码 Agent 里的工具选择、结果校验、停止判定交给 Snap，代码生成仍交给大模型，并用自己的标注集复核厂商分数。