SubQ Snap 1.1 vs Granite 4.2 3B：按 token 计价算错了账

IBM 的Granite 4.2 3B标价为每百万输入 token 0.03 美元。SubQ Snap 1.1标价为 0.04 美元。如果每 token 费率就是账单，那么这个 30 亿参数的 Apache-2.0 模型就会击败在 Artificial Analysis Decision Index v1.0 上并列第一的决策模型，这篇文章也会很短。费率并不是账单。一旦你按一次决策而不是按一个 token 来计价——包括每个模型为产出一个决策必须输出什么——排名就会翻转，又会因单个配置设置而翻回去，并最终落在两家供应商都没有宣传的某个位置。

Granite 4.2 3B 是 IBM 的小型稠密推理模型，于 2026 年 8 月 25 日与 8B 和 30B 的同系列模型一同发布，但发布时异常低调——只有一篇技术博客文章，而非发布会活动。Snap 1.1 是 Subquadratic 的决策模型，自 2026 年 10 月 22 日起上线，它从固定答案集中返回一个选择，而不是生成文本。它们只在一种工作负载上重叠：接收一段文本并判断它是什么。除此之外，它们的一切都不同，包括“便宜”意味着什么。

首先，这两个模型实际上究竟是什么

Granite 4.2 3B 是一个基于 Granite-4.1-3B-Base 构建的三十亿参数稠密解码器。它是一个推理模型，具备三种模式：输出思维链的思考模式、低投入模式，以及直接作答的非思考模式。IBM 报告称，AIME 2025 为 78.33，GPQA 为 54.80，LiveCodeBench v6 为 69.71，MMLU-Pro 为 67.84，IFBench 为 74.3，τ³-Bench 为 45.8——均为厂商数据，无一经过独立复现。在长上下文方面，其报告称 64K 时 RULER 为 67.52，128K 时为 55.30。Artificial Analysis 将其智能指数定为 9，从绝对值看并不突出，但高于其尺寸级别的中位数。

有意思的部分在于硬件要求。它以 bf16 精度运行时占用六到八 GB 内存，量化后不到两 GB，这意味着笔记本电脑、单张消费级 GPU，或者内存充足的 CPU 都能跑。它仅支持文本，覆盖十二种语言，支持 OpenAI 兼容的工具调用，并以 vLLM、SGLang、Transformers、GGUF、llama.cpp、MLX 和 Ollama 形式提供。如果你的约束是“必须能在我自己掌控的环境中运行”，这个模型满足要求。

SubQ Snap 1.1 在几乎所有维度上都是相反类型的产品。它没有权重。它仅通过 Subquadratic 的 API 运行。它最多可接收 384K token 的文本和图像，外加一个包含 2 到 255 个备选项的答案集，并返回一个带有校准概率的选择。它无法写出一个句子，而这正是关键所在：没有需要解析的输出，也没有需要付费的输出。

输出 token 陷阱

这就是按 token 比较所掩盖的算术。假设有一百万次路由决策，每次读取 6,000 个 token 的工单文本——对于中型支持运营来说，这是一个合理的月工作量；对于大型运营来说，则只是一个繁忙的下午。那就是六十亿个输入 token。

• 在非思考模式下使用 Granite 4.2 3B——6B 输入 token，按每百万 token 0.03 美元计算，为 180 美元；再加上每次决策约五个输出 token，即 5M 输出 token，按每百万 token 0.12 美元计算，为 0.60 美元。总计：约 180.60 美元。

• Granite 4.2 3B 在思考模式下——60 亿输入 token 费用为 180 美元，再加上每次决策约 800 个推理 token，也就是 8 亿输出 token，按每百万 token 0.12 美元计算，费用为 96 美元。总计：约 276 美元。

• SubQ Snap 1.1 — 60亿输入 token 按每百万 $0.04 计算为 $240，而且完全没有输出行。

所以，诚实的答案其实是三个不同的答案。配置为直接作答时，Granite 比 Snap 便宜 25%，文章到这儿就真的可以结束了。配置为思考时，Granite 比 Snap 贵 15%，因为推理 token 是整条流水线里最贵的东西，而没有人会为它们做预算。Snap 的优势从来都不是它的输入价格——那比 Granite 高 33%——而是这种架构根本没有办法把 token 花在深思熟虑上。

这不是理论上的风险。Artificial Analysis 对 Granite 4.2 3B 的独立评测称该模型“非常冗长”，并记录到它在 Intelligence Index 上接受评估时生成了 9200 万个输出 token，而同类模型的中位数为 6700 万个。冗长性是模型在推理模式下的一项实测属性，而正是这一属性决定了按 token 计价的价格优势能否在路由工作负载的实际考验中继续成立。

这也解释了一个乍看之下似乎不对劲的数字。Artificial Analysis 将 Snap 1.1 估算为每百万个任务约 30 美元，而 Elephant 9B 为 8.4 美元。每百万个任务 30 美元意味着平均任务非常短，大约只有几千个 token。Decision Index 的基准测试组合很短。你的工单、合同和日志则不是，而且成本会在此基础上随输入长度线性增长。应把每个任务的数字视为该基准测试的属性，而不是报价。

3B 真正胜出的地方

更便宜的 token 只是其中最不重要的一点。Granite 4.2 3B 可在 Apache 2.0 下自托管，这意味着只要付清硬件费用，就完全没有按调用计费的成本，数据不会离开你的网络，没有速率限制，也没有供应商能背着你更改价格或模型。对于受合规约束的工作流来说，这不是偏好，而是硬性要求，而 Snap 1.1 根本进不了这个门。

它还做了更多事情。它会在路由决策之后编写摘要。它通过 schema 处理工具调用。它支持可选的上下文扩展到 512K，这是在第五个预训练阶段加入的，纸面上比 Snap 的 384K 更长——不过其 RULER 分数从 64K 时的 67.52 降至 128K 时的 55.30，这清楚地警告人们该窗口中有多少是可用的。而且它足够小，可以在边缘运行，放在应用程序旁边的容器中，决策与动作之间无需网络跳转。

Snap 1.1 真正胜出的地方

3B 生成模型天生不擅长的三件事。

校准是首要问题。Snap 1.1 报告的期望校准误差为 0.014，低于预览版中的 0.108；在它无法回答的问题上，弃答率为 86%——而在供应商的代理测试中，其自身的 1.0 版本非幻觉得分为 0.7%。这些是供应商提供的数据，也应按此看待，但它们描述的是一个将弃答作为明确目标进行训练的模型。3B 推理模型没有这样的目标。问它一张工单是否可回答，无论答案如何，它都会给出一个看似合理的句子。

长上下文单遍行为是第二点。Snap 在一次前向传递中处理 384K 个 token，且每个 token 的计算量保持恒定，这正是 Subquadratic Sparse Attention 的全部理由。Granite 的 RULER 衰减是稠密模型在达到其舒适长度十倍时的正常表现。如果你的决策取决于埋藏在日志包中第 200,000 个位置的信息，那么这种架构差异就不是学术层面的差异。

输出形态的确定性是第三点，而这一点被低估了。Snap 会在你的选项列表上返回一个数字。Granite 返回的是文本，然后由你来解析，而每个解析器都是一个可能让畸形答案变成服务中断的地方。约束解码弥补了其中大部分差距，这一点值得说明——它不是根本性的优势，而是你需要编写多少脚手架代码的差异。

没人会问的配置问题

如果你将 Granite 4.2 3B 用作路由器，你能做的最有价值的一项改动就是关闭思考。IBM 正是出于这个原因提供该模式，而上面的算术也说明了原因：让一个推理模型从五个标签中选一个，它往往会花八百个 token 来论证一个非思考模式就能答对的决策。在假定思考模式更好之前，请在你自己的数据上对这两种模式做基准测试。在答案集固定的任务上，它往往并非更好。

Snap 的对应手段恰恰相反：你要给它更少、更精准的选项。其 API 将问题数量上限设为 16 个，每个问题的备选答案上限设为 255 个；而它在 Decision Index 上的准确率为 20%——低于 d1-ultra 的 32%——其指数得分主要靠弃权支撑。收窄答案集，准确率问题就会缩小；交给它一个开放式判断，它就会拒绝，而且拒绝得正确，还常常如此。

我实际会构建的东西

对于规模可观的客服或文档处理流水线，最便宜且经得起推敲的设计是两阶段设计。Granite 4.2 3B 以非思考模式运行，作为第一轮分类器处理简单的多数情况——那些明显是退款、明显是故障、明显是垃圾信息的工单——在这些场景中，3B 模型既准确，边际成本又为零。Snap 1.1 处理剩余部分：长对话串、模糊案例，以及正确答案可能是“升级”而自信猜测比拒绝更糟的情况。你只需为需要它的那部分支付每百万 token 0.04 美元，并且恰好在校准真正重要的决策上获得经过校准的概率。

两家供应商都不出售那种设计，因为每一家都想包揽整个层级。Granite 4.2 3B 不在 OrcaRouter 的目录中——它是 Apache 2.0，因此自托管是常规路线，而且它也被多家推理提供商提供。Snap 1.1 也不是我们的；它通过 Subquadratic 自己的 API 运行。OrcaRouter 对这类设计的贡献是它背后的生成层级：一个密钥背后有 200+ 个模型，按提供商目录价 0% 加价透传，以及自动故障转移，因此撰写升级摘要的模型与决定升级的模型不是同一个依赖项。

需要关注的是，当别人运行 Snap 1.1 时，它的校准是否依然成立。其 20% 的准确率是自身发布材料中最弱的数字，而正是这个数字决定了上述两阶段设计是否比看起来更便宜——Snap 弃权越频繁，回落到真正必须给出答案的那一阶段的工作就越多。