LiquidAI d1-3B 本地部署：不能聊天的视觉决策模型

在 Hugging Face 上，LiquidAI/d1-3B 自发布以来已经积累了 10,843 次下载。但很多人加载后会发现一件反常的事：你没法让它生成一句描述，也没有任何文本输出，每次请求返回的 usage 里都写着 "output_tokens": 0。

Liquid AI 把 d1-3B 称为"决策模型"（decision model）。它读取文本、JSON 和图像，然后针对你预先定义好的问题（是/否、单选题、量表打分）在一次前向传播中直接给出答案。它不写句子。如果你想要的是能对相册自动配文的 Qwen-VL 或 Gemma，这个模型不适合你；但如果你曾经为了一个 yes/no 问题消耗掉 7B 聊天模型的大量 token，它可能正好对症。

它到底是个什么样的模型

Liquid AI 的 Open d1 系列包含两个模型：d1-3B（文本+图像）和 d1-omni-600M（文本+图像或文本+音频，标注为实验性）。

d1-3B 的规格大致如下：参数量 3.12B，视觉编码器是 SigLIP2 NaFlex 形状优化版本（400M），上下文长度 32,768 token，词表 128,000，权重格式为 Safetensors / BF16，基础模型是 LFM2.5-VL-3B（文本骨干与 LFM2.5-2.6B 做了权重平均），许可证为 lfm1.0（LFM Open License）。

架构上它沿用 LFM2.5-VL-3B，Liquid 做的事情主要在权重层面：把 LFM2.5-2.6B 的权重与 VL 模型的文本骨干做平均，用不同随机种子和数据配比微调出多个 checkpoint，再合并。Liquid 官方博客给出的结论相当朴素——长输入训练、打乱选项顺序、修复数据捷径，比任何花哨技巧都更重要。

SigLIP2 NaFlex 是 Google 提出的视觉编码器系列，SigLIP 意为「Sigmoid Loss for Language-Image Pre-training」，用 sigmoid 损失替代 CLIP 的 softmax 对比损失，在 batch 内不需要全局归一化，小批量训练更稳定。NaFlex（Native Flexible Resolution）指模型可以按原始宽高比和可变分辨率处理图像，而不是强制拉伸成固定 224×224 或 384×384。这对决策类任务尤其重要：当你判断一张网页截图里是否有报错弹窗时，保持原始分辨率和长宽比能保留细小的 UI 文字与布局信息，避免因缩放导致的关键视觉线索丢失。

权重平均（weight averaging） 指把两个或多个训练好的模型参数按权重线性组合成一个新模型，例如把 LFM2.5-2.6B 的权重按一定比例混入 VL 模型的文本骨干。这种做法常见于模型融合（model merging），可以在不重新训练的情况下把纯文本模型的语言能力迁移到多模态模型中，成本远低于从头预训练。缺点是融合后的模型可能出现能力偏移，需要通过多随机种子、多数据配比的 checkpoint 合并来筛选出表现较均衡的结果，这也是 Liquid 在 d1-3B 上采用的主要工程手段。

三种问题类型，零输出 token

d1-3B 的调用方式与聊天模型完全不同。你需要先定义问题，每个问题有一个类型：

• noul：返回 P(yes)，即"是"的概率
• choice：返回被选中的选项、置信度以及每个选项的概率
• score：在 2–10 级序数量表上返回期望等级、置信度和概率分布

多个具名问题可以共享同一个 "state"（比如一张工单、一份文档、一张图片），在同一次前向传播中一并作答。返回结构大致是 {"answers": {...}, "usage": {"input_tokens": n, "output_tokens": 0}}。

对于路由、内容审核过滤器或 agent 护栏这类场景，这其实是更实用的 API 形态。你拿到的是概率，不需要再去解析聊天模型偶尔冒出的"Sure! Here's your answer:"之类的畸形 JSON。模型卡称这些答案是"校准过的"，但校准得好不好是另一回事：Liquid 没有公布 d1 的校准误差数据，OrcaRouter 的一篇评测也把校准误差列为最明显的未解问题——你得自己测。

校准（calibration） 是分类模型的重要属性，指模型输出的概率是否与真实正确率一致。若模型对 100 个样本都给出「是」的概率 0.9，一个校准良好的模型应该大约有 90 个确实是「是」。常见的度量有 ECE（Expected Calibration Error，期望校准误差），它把预测概率分桶，比较每桶的平均置信度与实际准确率之差，再加权平均。模型卡里说答案是「校准过的」，但没有给出 ECE 或可靠性图，所以这个说法无法验证。对于路由、审核、agent 护栏这类用概率做阈值判断的场景，校准误差往往比准确率更关键：一个准确率很高但过度自信的模型，会让你在设定 0.9 阈值时频繁误判。落地前建议用自己的数据画一张可靠性图。

基准表现：Qwen-VL 和 Gemma 去哪了

如果你想知道 d1-3B 与同尺寸的 Qwen2.5-VL-3B 或 Gemma 相比如何，答案是：Liquid 没有公布这样的对比。它只把 d1-3B 与其他决策模型以及自己的骨干模型做比较。

在 Decision Index v0.2.1（公开 split）上，d1-3B 得分为 48.57，是 Liquid 表格中 10B 以下的最好成绩，落后于 Winnow-12B（50.02），领先于 Decider 35B-A3B（47.11）。需要注意的是，其他行来自公开排行榜，而 d1-3B 这一行是 Liquid 自己跑官方 scorer 得出的，而非提交到榜单，解读时应保留余地。

文本任务方面，d1-3B 在 SQuAD 2.0 上拿到 85.3（Decider 4B 为 76.0），Civil Comments 93.0，MASSIVE intent 87.3，PubMedQA 66.0，BoolQ 86.7，XNLI 85.0，PAWS-X 76.9，七项平均 82.9。Decider 4B 在 BoolQ、XNLI 和 MASSIVE 上胜出，模型卡版本还加入了 HelpSteer2（d1-3B 36.7 对 Decider 4B 42.0），加入后两者平均分收窄到 77.1 对 76.2，只能算微弱领先。Decision Index 的 Knowledge 类别只有 23.8，所以别指望它掌握事实知识——它的工作是判断你递给它的内容。

视觉指标则有些微妙。在 11 项图像基准上，模型卡报告 d1-3B 平均 74.1，LFM2.5-VL-3B 为 73.9，也就是说把它改造成决策引擎几乎没有改变平均视觉质量。但逐项拆开看差异明显：VL-RewardBench 上 d1-3B 得 65.0，远超 LFM2.5-VL-3B 的 50.9（+14.1）；MMVP 77.0 对 73.7；但 CV-Bench 82.1 对 87.6，VisualWebBench 71.4 对 78.3，POPE 88.5 对 90.1。它作为视觉"裁判"更强，但空间推理和读取网页截图的能力明显下滑。如果你的计划是"判断这张 UI 截图里有没有报错弹窗"，VisualWebBench 上 6.9 分的差距值得你犹豫一下。

Liquid 没有放 Qwen-VL 和 Gemma 的对比，与其说是刻意回避，不如说是因为生成式模型和决策模型的比较本身就不太对等。但这确实把问题留给了使用者：一个 3B 分类器是否真的比你已经在跑的 VLM prompt 更好？换之前，先用你自己的数据建一个 200 条左右的评测集。

许可证说"开放"，但请读细则

Liquid 博客说你可以"无限制地"下载、微调和部署。Hugging Face 上的标签是 lfm1.0，即 LFM Open License v1.0。它基于 Apache 2.0，但有一处关键改动：一旦公司年收入超过 1000 万美元，商业权利即终止，之后需要向 Liquid 购买付费许可证。这一限制同样适用于微调衍生模型。许可证没有 copyleft 条款，所以你的微调成果可以保持闭源。

对独立开发者和多数初创公司来说这不是问题。但对有一定规模的公司而言，"无限制"这个说法并不准确，Liquid 本可以不用这个词。

GGUF 体积与延迟：4090、M5 Pro、Jetson

Liquid 没有公布内存或显存占用数字，但官方 GGUF 仓库给出了文件体积，可作为不错的下界参考：Q4_K_M 为 1.67 GB，Q8_0 为 2.87 GB，BF16/F16 为 5.4 GB。Q4_K_M 在笔记本上绰绰有余，纸面上也塞得进近年的手机——但 Liquid 自己的速度表里并没有手机。

已公布的延迟（单请求）方面：RTX 4090（bf16）单问题 8 ms、384px 图像 17 ms，打包吞吐 475 states/s；Apple M5 Pro（MPS）30 ms / 62 ms / 78 states/s；Jetson AGX Orin 64GB 26 ms / 83 ms / 110 states/s；Jetson Orin Nano 50 ms / 202 ms / 38 states/s。4090 的 8 ms 依赖 model.compile(mode="reduce-overhead")，不加则是 16 ms。一个 3.4k token 的 state 在 M5 Pro 上要 640 ms，在 Orin Nano 上要 1640 ms——长文档即使不做解码，时间成本也是真实的。

GGUF 是 llama.cpp 使用的模型文件格式，取代早期的 GGML。它把权重、词表、量化元数据和提示词模板打包进单个文件，支持 mmap 加载，可在 CPU、Metal、CUDA、ROCm 等后端运行。文件名里的 Q4_K_M、Q8_0 是量化方案：Q8_0 为每权重 8 位，几乎无损；Q4_K_M 为 4 位量化，采用 k-quant 分组并混合不同精度的张量（M 表示中等质量档），体积约为 BF16 的四分之一，精度损失在多数分类任务上可接受。此外，state 在 d1 语境中指一次请求要判断的上下文对象（一段文本、一份 JSON、一张或多张图像），多个问题共享同一 state 才能在同一次前向传播中复用 KV 缓存，这正是它比逐问题调用聊天模型省算力的原因。

如何在本地运行 d1-3B

Transformers

需要 5.14 或更新版本，并启用 trust_remote_code=True：

pip install "transformers>=5.14" torch torchvision pillow

import torch
from transformers import AutoModel

device = "cuda" if torch.cuda.is_available() else "mps" if torch.backends.mps.is_available() else "cpu"
dtype = torch.float32 if device == "cpu" else torch.bfloat16

model = AutoModel.from_pretrained("LiquidAI/d1-3B", trust_remote_code=True, dtype=dtype).to(device)
# then: model.system_one(state, questions, images=None)
# or:   model.system_one_batch([(state, questions[, images]), ...])

llama.cpp

Liquid 声称提供 day-one 支持。GGUF 模型卡的快速上手会拉取 Q8_0 文件，想要 1.67 GB 的版本就把 tag 换成 Q4_K_M：

llama-server -hf LiquidAI/d1-3B-GGUF:Q8_0

然后向 /v1/systemone 发 POST 请求，body 包含 state（或图像专用时传 null）、可选的 base64 images 以及 questions 对象。

curl http://127.0.0.1:8080/v1/systemone -H "Content-Type: application/json" -d '{
  "state": "I was charged twice this month, please refund one of them.",
  "questions": {
    "refund":  {"type": "noul", "instructions": "Is the customer asking for a refund?"},
    "team":    {"type": "choice", "instructions": "Which team should handle this?",
                "criteria": {"billing": "Charges, refunds, invoices", "technical": "App or site faults",
                             "fraud": "Suspected unauthorised use"}},
    "urgency": {"type": "score", "instructions": "How urgent is this?",
                "criteria": ["Can wait", "Today", "Blocking the customer now"]}
  }
}'

这不是 /v1/chat/completions，所以你现有的 OpenAI 客户端代码不会直接可用。GGUF 页面没有说明需要哪个 llama.cpp 版本，建议先更新到最新。

vLLM、SGLang、Docker

Hugging Face 的"Use this model"面板会生成 vLLM、SGLang 以及 docker model run hf.co/LiquidAI/d1-3B 片段，但这些是由 Hub 自动生成的。模型卡和博客都没有提到它们，考虑到 d1 使用自定义的 system_one API，建议先测试再信任。

MLX

模型卡、GGUF 卡和博客都没有提到 MLX。目前在 Mac 上，你的选择是 MPS 上的 PyTorch（Liquid 的 M5 Pro 数据来源）或带 Metal 的 llama.cpp。

谁应该下载它

如果你在做路由器、内容过滤器、agent 护栏、重排序器，或者需要在每一帧上做 yes/no 判断的摄像头流水线，可以下载。如果你需要字幕、OCR 输出或任何要作为文本展示给用户的生成内容，那就跳过——生成式 VLM 仍是更合适的工具，Liquid 公布的任何数据也没有说 d1-3B 能在这方面竞争。

"一个不会说话的视觉模型"可能是 Liquid 今年发布的最实用的东西，因为我见过的大多数生产环境 VLM 调用，本质上都是伪装成聊天的分类器。一个完全离线运行、只回答你指定问题的 3B 视觉模型，你会用它做什么？在亲自校准之前，你会信任它给出的置信度分数吗？