SubQ 1.1 Small 把上下文推到 1200 万 token，真正要看的是架构能不能省钱

SubQ 这次给出的数字很扎眼：SubQ 1.1 Small 在 Needle-in-a-Haystack 测试里，100 万、200 万 token 得到 100%，600 万、1200 万 token 也有 98%。

如果只看窗口大小，这很容易被归到“又一个超长上下文模型”。但更有意思的是另一件事：SubQ 不是只说能塞进更多 token，而是说它的 Subquadratic Sparse Attention，也就是 SSA，可以把注意力计算成本压下来。

这才是企业 AI 团队真正会卡住的地方。长上下文不是能不能读完一本厚书，而是读一次要多少钱、多久返回、错了能不能定位。

它发布了什么：小模型，第二次迭代，目标是把长上下文做进架构

SubQ 1.1 Small 是 SSA 模型的第二次迭代，也是小尺寸版本。模型卡称，它正在面向部分设计伙伴部署。SubQ 还计划在年底前推出覆盖 200 万到 1200 万 token 的模型线。

这几个信息放在一起看，重点就不是“Small”这个名字，而是 SubQ 想证明一条路线：长上下文能力不只靠外部检索、切片、重排和 Agent 流程补出来，也可以由模型架构承担一部分。

过去两年，企业处理代码库、合同、财报、尽调材料，常见方案还是 RAG。先切片，再召回，再重排，最后交给模型生成。这个方案便宜、可控、容易更新，但也有老毛病：证据可能被切碎，跨文件关系容易丢，召回错了后面全错。

Gemini、Claude 等长上下文模型已经把窗口拉到十万级、百万级，说明市场需求很明确。SubQ 的差异在于，它把卖点压在稀疏注意力和计算成本上，而不只是窗口长度。

更直白一点：如果 SSA 成立，它挑战的是“长上下文必须靠工程 workaround 才能用”的默认假设。

数据说明了什么：检索很强，但别把 NIAH 当成复杂推理通行证

模型卡里的长上下文成绩确实好看。NIAH 在 100 万、200 万 token 为 100%，在 600 万、1200 万 token 为 98%。RULER 128K 得分为 99.12%。

但这里要压住判断强度。NIAH 更像是在极长材料里找一根针。企业真正难的是，找到针之后，还要判断这根针和另外几根针之间的关系。

比如合同审阅，不只是找某个条款，而是判断例外条款、付款条件、违约责任是否互相冲突。代码库分析也不只是定位函数，而是看跨文件依赖、历史约束和潜在副作用。

我更在意的是最后一项。AutomationBench Finance 13% 不算好看，但它很诚实地提示了边界：长上下文和真实业务自动化之间，还有工具调用、流程约束、权限、审计、容错这些硬问题。

所以，SubQ 1.1 Small 目前最能说明的是：它在超长检索和部分长上下文基准上给出了强信号。它还不能说明：所有复杂长文档推理都已经被解决。

这句话对采购和工程团队很关键。不要因为 1200 万 token 就直接替换现有 RAG，也不要因为它还没跑出真实客户案例就忽略它。更合理的动作是延后大规模迁移，把它放进内部评测池。

成本才是硬考题：单层 attention 快，不等于整套系统便宜

SubQ 称，SSA 用学习到的稀疏注意力替代 dense attention。在 100 万 token 下，单个 attention layer 的计算量比 dense attention 少 64.5 倍，速度比 FlashAttention-2 快 56 倍。

这个口径很重要：100 万 token，单个 attention layer，对比 dense attention 和 FlashAttention-2。

它不能直接换算成 API 价格，也不能直接换算成企业部署成本。完整推理还会受层数、KV cache、硬件利用率、批处理、调度、输入输出长度影响。模型卡给的是一个关键部件的优势，不是整车油耗报告。

但这仍然值得企业 AI 负责人认真看。因为长上下文真正贵的地方，通常不在“窗口能不能开”，而在每次推理的成本和延迟。

对正在做 Agent 的团队，动作可以更具体一点：

• 采购侧.不要只问最大上下文，直接问 1M、2M、6M 输入下的端到端延迟、吞吐和价格口径。
• 工程侧.准备一组内部长文档基准，同一任务同时跑 RAG、现有长上下文模型和 SSA 模型。
• 评测侧.记录成功样例没意义不大，要记录错例：漏证据、错归因、跨段推理失败、输出不可审计。

如果 SubQ 后续只能在 NIAH 这类任务上漂亮，它就是一个强检索模型。如果它在企业内部基准里同时压住成本、延迟和错例率，才算把长上下文往生产能力推了一步。

训练路径给了答案，也留下了限制

SubQ 的训练路线不是只改推理框架。模型卡称，它从开源权重前沿模型出发，把 dense attention 替换为 SSA，再按 262K、512K、1M、2M 阶段扩展上下文，并继续预训练约一万亿 token 的长文档和代码数据。

这说明 SubQ 想把长上下文能力写进训练过程，而不是在模型外面搭一层工程补丁。这个方向更硬，也更难。

难点在于，注意力机制换了以后，通用能力、对齐能力、工具调用稳定性是否能长期保持，还要看更多开放评测和真实部署反馈。模型卡里的 GPQA Diamond、LiveCodeBench 数据给了积极信号，但还不是第三方验证。

接下来最该看三件事。

我的判断是，SubQ 1.1 Small 还不能让企业放弃 RAG。RAG 仍然便宜、可控、方便更新，尤其适合知识库经常变化的场景。

但它会让一类项目重新评估方案：整仓代码审查、长合同审阅、并购尽调、财务材料比对。这些任务里，切片本身就是风险源。能少切一点，可能就少错一点。

长上下文的竞争，表面看是窗口长度，底层看是经济账。SubQ 这次把问题推到了架构层面。答案还没完全出来，但考题已经变清楚了：不是能不能读 1200 万 token，而是读完以后，是否更准、更快、更便宜。