Liquid AI d1-3B 与 Qwen 3 8B：8B 分类工作负载是否应迁移至决策模型？

Somewhere in most production stacks there is a Qwen 3 8B being paid to answer yes or no. It moderates a comment, tags a support ticket, decides whether a retrieved passage is relevant, or scores another model's output against a rubric — and it does that by generating text which something downstream then parses. Liquid AI d1-3B, the 3.12B decision model Liquid AI open-weighted on October 7, 2026, exists to do exactly that job without generating anything: a state in, a set of named questions in, and probabilities, labels and confidences out in a single forward pass with zero output tokens. Qwen 3 8B is the vendor's April 2025 open-weights workhorse — roughly 8.2B dense parameters, 119 languages, thinking on or off per request, and sixteen months of community deployment behind it. The question this pairing actually asks is narrow and practical: for the slice of your traffic that is a classification, is an 8B generalist the cheapest way to get a label in 2026, or has the shape of that job changed underneath it?

你实际上花钱让8B做的事情

把两份输出契约放在一起对比就会发现，这种低效是结构性的，而非渐进性的。

Qwen 3 8B 的分类调用是一次生成。你写一个提示词来描述各个标签，模型可选地对输入进行推理——在这个模型上，你可以按请求开启或关闭该推理，而这是它在这类工作中最有用的一个调节项——然后它会返回一个答案。那个答案就是文本。如果你要求 JSON，通常就会得到 JSON，偶尔也会得到嵌在句子里的 JSON，或者一段前言，或者你并不想要的结尾解释。你关心的标签就在 token 流中的某处，由解析器把它取出来。模型写出的每一个 token 都会计费，包括你丢弃的那些。

Liquid AI d1-3B 没有 token 流。问题通过类型来声明：noul 用于是/否，回答为 0 到 1 之间的 P(yes)；choice 用于从命名选项集中选择一个标签，回答为该标签加上一个置信度以及每个选项的概率；score 用于有序的 2 到 10 量表上的位置，回答为期望等级及其分布和图例。响应带有一个累计总数，显示为 output_tokens: 0。没有什么可解析的，因为什么都没有写入；当你想要未取整的分布而不是 argmax 时，还有一个原始的 probabilities 访问器。

改变你账单的部分，取决于多个问题同时出现时会发生什么。一个状态可以承载很多问题：这是不是一个退款请求，应该由哪个团队负责，它有多紧急。状态及其图像只读取一次，而 Liquid 报告称，在一个状态上问三个问题，耗时是问一个问题的 1.3 倍，而不是 3 倍。它没有压缩掉的是输入计费——供应商的计费说明明确写道，每个问题都作为独立的提示计费，包括其文本和所有图像。延迟更低，输入 token 相同。这是对标题数字的一个诚实星号，而这类事情你只有去读定价段落、而不是看基准测试，才会发现。

十六个月的 Qwen 3 8B 能为你带来什么

在将较小的模型视为升级之前，要准确认识现有模型带来了什么，因为它不只是参数数量。

• 背景 — Qwen 3 8B 原生可处理 32,768 个 token，并通过 YaRN 验证可扩展至 131,072 个 token。Liquid AI d1-3B 则固定支持 32,768 个 token，没有文档记载的扩展路径。对于作为长文档的状态，8B 是两者中唯一能够容纳它的模型。

• 语言 — Qwen 3 8B 支持 119 种语言和方言，而 Liquid AI d1-3B 有记录的则为十六种。

• 推理控制 — Qwen 3 8B 允许你按请求开启或关闭思考。Liquid AI d1-3B 没有可控制的推理模式，这究竟是一种简化还是一种限制，取决于你之前用思考来做什么。

• 广度——8B 能写作、解释、总结、翻译和编码。Liquid AI d1-3B 这些都不做。它的模型卡直言不讳：它不是聊天模型，也不写文本。

• 证据——Qwen 3 8B 已有十六个月的公开基准测试、量化、微调与生产使用记录。Liquid AI d1-3B 的 Decision Index 得分 48.57 是由 Liquid 使用官方评分器得出的，而非提交至公开排行榜，而且该结果才发布几天，尚无第三方复现。

• 视觉——这一行走的是相反方向。Liquid AI d1-3B 能接收图像，厂商报告其在十一个公开图像基准上取得 74.1 的分数，这些基准按对每个基准选项集作出决策的方式解读，并报告称去掉图像后，同样的问题得分会跌至 45.1。纯文本的 Qwen 3 8B 要想做到其中任何一项，都需要在它前面配一个单独的视觉模型。

• 速度——在 RTX 4090 上，一个问题的处理时间为 8 毫秒，在 Jetson AGX Thor 上为 16 毫秒，在 Jetson Orin Nano 上为 50 毫秒，而在 4090 上，每次遍历可处理 64 个打包状态，速率为每秒 475 个。基于生成的分类器没有可比的数值，因为其延迟取决于答案有多长。

坦率的总结是，8B 是更好的通用工具，而 3B 决策模型是更好的专用工具，唯一重要的问题是，你的流量中有多少属于专用场景。

成本的算术，仔细计算。

这正是这种比较要么能回本、要么不能的地方，因此值得用真正的结构而不是一句口号来做。

Liquid 在开放权重发布前两天公布的说法是：其托管的决策模型在六个真实应用中的四个上追平或超过 GPT-6.1 Sol，成本低 19 倍到 200 倍，并且在每项任务上回答都更快。在复述这一说法之前，请先阅读方法说明：每个应用在 2026 年 10 月 5 日对每个模型各运行一次，聊天模型在默认推理设置下以 JSON 作答，d1 的成本按每百万输入 token 0.04 美元计算。0.04 美元这个数字是托管 d1 的输入费率，而且这是唯一存在的费率——没有需要另加的输出行。

现在为 Qwen 3 8B 分类器构建同样形式的估算，不用引用任何服务商的价格，这种不对称就已经显而易见。8B 有两条计费行，而决策模型只有一条，并且增长的是第二条：先进行推理的分类要为其推理付费，而给 JSON 灌水的分类要为其灌水付费。决策模型的输入费用由状态和问题固定。而 8B 的输入费用并不由任何仅凭状态就能预测出的东西固定。

两个反制因素使这没有变成一场溃败。首先，决策模型把每个问题都当作独立的提示词来计费，因此就一份长文档提出五个问题会使输入量变成五倍——而 8B 模型在一次调用中提出全部五个问题，只需为这份文档付费一次。其次，也是更重要的，决策模型只能回答它在后训练中被训练成能以那种形式回答的问题。任何需要解释、总结或用文字表达的判断，都会让你回到通用模型上，并且实际上让你再次为两者付费。

这两者真正擅长的是什么

把基准测试剥离出去，这种划分比参数数量所显示的更清晰。

Liquid AI d1-3B面向的是是/否、从列表中选择以及评分这类任务，其延迟下限是任何生成式模型都无法达到的，运行硬件包括 50 毫秒的 Jetson Orin Nano 和一台笔记本电脑。Liquid 在 10 月演示的应用全都是这种形态的不同版本——一个为 150 张支持工单回答是或否的 SQL 谓词，一个智能体上下文压缩循环，对每个工具输出进行保留、裁剪或丢弃，并去除 52% 的 token，以及一个检测应用，在四条生产线上分拣合格与缺陷零件，在其从未接受过训练、仅凭一段简短描述便理解的任务上达到 85% 至 97% 的准确率。最后一个演示最清楚地说明了这一类别的用途：一项答案只是少数几种可能之一、状态是一张图像、且从未要求给出解释的工作。

Qwen 3 8B适用于那些必须以语言形式返回的工作，或者要覆盖 119 种语言，或者要容纳超过三万两千个 token 的文档，或者在给出结论前先出声推理的工作。当分类不属于上述三种形态时，它也是正确的答案——当标签集合是开放式的，当判定标准足够微妙、以至于你希望有思考过程，当同一次调用必须同时处理简单和困难的情况、而你不想在两个模型之间做路由时。而当评审者问起有哪些独立基准测试时，它也是稳妥之选，因为答案是：很多，最早可以追溯到一年半以前。

做对这件事的团队并不做选择。他们把决策交给通用模型，只用在答案是数字的那部分流量上，并让 8B 处理所有需要成句回答的内容。过滤器是 3B 和 8 毫秒；8B 则留给有效负载。

部署这对

Liquid AI d1-3B 以权重形式发布，部署工作已提前完成：首日即支持 llama.cpp，涵盖从 DGX 到 Jetson 的完整 NVIDIA 技术栈，支持 NVFP4 量化，提供 8 位权重与激活变体，并在 Hugging Face 上提供 GGUF 转换版本。Qwen 3 8B 拥有这一权重级别中任何模型里最完善的自托管生态。两者均不在我们的目录中，此处也不构成对任何一方的可用性声明——Liquid AI d1-3B 的托管途径是厂商自有 API 与第三方平台，在这些平台上，托管的 d1仅按输入 token 计费，每百万 token 收费 $0.04，图像按每 32×32 像素块 1.5 个 token 计费。

一旦两者进入同一条流水线，路由问题就不再是理论问题了。你有一个自有的小模型、一个可以自托管或租用的 8B 模型，还有你肯定要租用的生成式调用——而针对每个请求决定某个输入该落到哪一个模型上，正是路由层存在的意义。一个端点覆盖 200 多个模型，按供应商标价 0% 加价透传因此供应商调价当天，你这边就会同步生效，自动故障转移这样上游的一个糟糕下午就不会变成你的服务中断。当你的分类流量以每年数十亿次调用计时，3B 决策模型带来的节省，真正被收拢兑现的地方正是这一层。

裁决

如果你的 8B 正在被用来回答封闭式问题——这是否有毒、这是否相关、它该归入哪个队列、它有多紧急——那么你就是在为一个标签付出通才模型两行输出的成本以及一次生成的延迟，而 Liquid AI d1-3B 是一个直接替代方案，只不过证据链更弱，并且有真正的许可证差异需要权衡。接受 32K 上下文上限、十六种语言，以及 Liquid 之外还没有人给它打过分这一事实。

如果你的 8B 被要求进行解释、总结、翻译、承载长文档，或在做决定前进行推理，那么这个比较并不适用于你。保留 8B，并且只把决策模型当作预筛选器，用于你能够提前识别为简单类型的流量。

真正值得关注的数字，不是任一模型的基准测试得分，而是 d1 Decision Index 的首次独立复现有多快落地，因为那一刻，这种对比就不再是厂商的说法，而开始成为你可以据此规划的事实。