ScaleDown 的小型模型用于应用内常规任务：分类、提取、总结

2026年10月13日，ScaleDown 揭开了三款小型任务专用模型的面纱，并将它们作为一个整体概念来销售：Classify、Extract 和 Summarize。每一款都是为围绕生产环境 LLM 调用的重复性工作而构建，而不是用于对话。三者都接受 1M token 的输入，三者都接受文本或图像，并且三者都可以通过 ScaleDown 自己的 API 访问——定价问题正是在这里变得有趣，因为三者的成本结构完全不同。该系列中的第四个模型 ScaleDown Compress 在供应商文档中被列为上下文裁剪工具，而不是这三款新模型之一。以下内容是供应商记录的内容，并与尚无人复现的内容分开呈现。

10月13日实际发布了什么

ScaleDown 运营一个 Decisions 端点已有一段时间——这是一种结构化评分接口，接收一个状态对象以及一张类型化问题映射表，并返回经校准的概率。10 月 13 日的公告标志着该公司开始将底层模型作为独立产品出售，而不再作为一个端点，也标志着它开始将这些模型描述为用于应用内工作的通用组件。

按供应商文档所述，这三种模型及其合约：

• ScaleDown Classify — 将文本分配至调用方提供的一组标签。每个标签都包含一个名称和一条评分标准，文档将其称为“模型用来为该标签打分的是/否问题”，并称其为整个请求中最重要的部分。单标签模式会返回一个总和为 1.0 的 softmax 分布以及一个最高标签；多标签模式则会根据调用方设定的阈值，独立地为每个标签打分。

• ScaleDown Extract——从非结构化文本中提取结构化字段。在该系列的文档中，这是将文档转换为代码可索引记录的模型。

• ScaleDown Summarize — 对长输入生成简短的摘要式概括，这正是 100 万 token 上下文窗口最明显意欲承担的任务。

三者共同遵循的约定才是值得写下来的部分。每个请求一百万 token 的输入，大致比主流中型 API 所能接受的量高出一个数量级，而正是这个数字让 Summarize 和 Extract 无需分块层就能胜任整篇文档的处理。纯文本或图像输入对 Extract 尤其关键：一张扫描的发票或一张表单截图进去，字段出来，中间没有 OCR 步骤。三者都由 ScaleDown 自家的 API 提供服务，其文档给出的基础 URL 是 span>api.scaledown.xyz/span>，并明确指出 span>api.scaledown.ai/span> 不是 API 主机。

那个与众不同的数字

定价是这三者不再可互换的地方。Classify 的标价为每百万输入 token 0.05 美元、每百万输出 token 0 美元，而该模型在第三方目录中的挂牌信息显示的是同一费率，有时还会附加促销折扣；该折扣并非 ScaleDown 的承诺，不应据此做规划。输出价格为零并非营销噱头——按评分标准打分的分类器输出的是标签和概率，而非生成的文本，因此没有可计费的内容。Extract 和 Summarize 确实会生成输出，所以它们的成本结构与 Classify 不可比，应直接向供应商询价，而非从分类器的费率推断。

Classify 的计费细节比表面费率更难推断。在单标签模式下，每个标签及其评分细则都会进入一次模型调用，因此你每增加一个标签，都会增加计费的输入 token；而要求用一句话解释所选结果，会以 2 倍费用重新发送它们，并且文档明确说明，解释是在最高标签确定之后生成的，因此它是在为答案辩护，而不是对答案进行再审视。在多标签模式下，每个标签都是一次单独的模型调用，每个分块也分别评分。因此，开启推理的六十标签分类体系并不是读者所设想的那种每百万 token 0.05 美元的操作；它是该费率乘以标签集，若开启推理则再翻倍。文档记载的上限——每个请求 20 个标签、多标签模式下 16 个、每批 50 个分块——才是设计时需要针对的实际约束。

还有一项已记录的行为，比这些上限中的任何一项都更重要。分类器“总是会返回一个胜者”，即使没有任何标签匹配。置信度过滤完全留给调用方。在一个包含 10 个标签的请求中，最高分 0.4 仍可能是正确答案，因为这些分数是标签集内的相对分数，而非绝对分数。此模型的每一次生产使用都需要有自己的阈值策略，而一个兜底标签——文档建议将其命名为 span>other/span>——在实践中并非可选。

为什么分类器上的 1M token 窗口才是有意思的部分

分类器模型通常接受短输入。原因在于机制本身：一个按评分标准打分的分类器，必须将整个输入与每个标签的是/否问题进行权衡，而用二十条评分标准去评估一份十万 token 的文档，成本就是对该文档进行二十次完整遍历。ScaleDown 的答案是 1M 窗口加上批处理层——单次请求中最多可将 50 个块对照一个共享配置进行评分——而厂商的说法是，无论你发送一个块还是五十个块，每个块的校准结果都相同，唯一的区别在于共享配置按每次请求计费一次。

在基于这个论断继续构建之前，首先要检验的就是它。也正是这个论断让这个模型变得有意思：在应用内部而不是在边缘进行分类的全部理由在于，决策能够看到完整上下文——整个支持对话线程、整份合同、完整检索到的文档——而不是一个被截断的窗口。如果 1M 窗口在你的输入规模下站得住脚，那么架构问题（“我是否需要分块和投票方案？”）基本上就消失了。如果它站不住脚，你就得到了一个成本极低的短输入分类器，以及另一个需要解决的问题。

需要第二意见的说法

ScaleDown 的市场宣传称，对于大批量重复性工作，任务专用的小型语言模型在成本、速度和准确率上都优于前沿模型，并援引了一些数据，其中包括一个约五亿参数的模型在简单分类任务上达到 91.7%，而一个 720 亿参数的模型为 88.6%。这些都是厂商自己的数据，尚未被独立复现：ScaleDown Classify 目前在公开排行榜上尚无评分，也没有发布任何第三方基准测试条目。应将准确率论点视为一种具有合理机制的假设——在狭窄分类体系上，专用训练的小模型与通用大模型之间的样本效率差距确实存在且已有充分记录——而不是已确立的结论。

100 万 token 的输入数字同样是厂商声称的。该模型的第三方目录条目将上下文长度列为不适用，而不是照搬这个百万 token 的数字；这是目录本身的局限，而非矛盾，但这确实意味着该上下文窗口尚未在 ScaleDown 的文档之外得到佐证。

如果你已经在运行一条流水线，这适合放在哪里

这三个模型所针对的模式是一个循环，而不是单次调用：检索一份文档、对其分类、抽取字段、生成摘要，然后把摘要交给一个生成式模型来撰写回复。第四步按 token 计费是最昂贵的一步，而这正是 OrcaRouter 所覆盖的环节——只需一个与 OpenAI 兼容的密钥，就能在一个密钥背后接入 200 多个模型，按提供商标价原样传递、0% 加价，并且在某条服务路径性能下降时自动故障转移。我们不托管 ScaleDown Classify、Extract 或 Summarize；它们不在我们的目录中，也不是 chat-completions 的目标，而这里的路由层是该模式中负责生成的那一半，而非负责评分的那一半。

这个区分值得明确说清楚，因为人们会拿来做的成本比较其实具有误导性。一个按评分标准打分的分类器，每百万输入token只要几美分，而一个生成式模型每百万要几美元，二者并不是竞争对手；它们是两个不同的成本项，而之所以要把一个小模型放在分类这一步，是因为这样一来，你才有余力在真正负责写东西的那一步上用更好的模型。

什么会改变这一评估？

三件事，按其可能改变局面的程度排序。在公开基准上对按评分标准打分的分类任务进行独立评估，会把准确率方面的论据从供应商的说法变成一个数据点。公布一个延迟数值——供应商记录了成本驱动因素，却没有提供服务延迟——就能确定 1M 窗口是在吞吐场景下可用，还是仅适用于批处理。而第三方复现逐块校准的说法，将决定五十块一批是成本优化，还是另一个不同的模型。在至少其中一项落地之前，诚实的总结是：ScaleDown 已发布三款模型，它们有着异常清晰的契约和异常大的输入上限，其价格让基于阈值的分类阶段便宜到值得考虑，而支撑这些说法的数字都来自供应商自己。

简短版本

如果你有一个高吞吐量的分类或抽取阶段，分类体系稳定，输入是文本或图像，那么 ScaleDown 的三个模型值得本周在你自己的数据上做一次基准测试，因为合约很简单，输入限制也很宽松。在正式采用某个分类体系之前，要为标签倍增和 2 倍推理附加费做好预算，并预期需要自行编写置信度阈值。如果你的任务是开放式生成，这一切都不是针对你的。

模型选择同样取决于过去出过什么问题：这一类模型背后有记录的 AI 事故和智能体故障，都收录在the OrcaRouter AI Incident Archive中，其中每一条记录都带有各自的来源、严重程度、置信度评级和争议标记。