Jev 101 logo
Jev 101

Guides / 视频转图文攻略

Liquid AI Open d1 本地实测：d1-3B 与 d1-omni-600M 跑进 MacBook Air M5

把 AI WITH Rithesh 的 Liquid AI d1 实测视频整理成分步图文：Open d1 双模型规格卡、noul/choice/score 三类问题、大模型与单次前向的对照卡、两张架构图、厂商延迟表对无风扇 MacBook Air M5 的实测落差，再到护栏、屏幕检查、语音路由、文档分诊四场测试——每个卡面数字都逐帧放大核对过。

速览结论

Liquid AI 的 Open d1 一次放出两款开源多模态决策模型：d1-3B（约 3.1B 参数、文本+图像、32K 上下文、LFM2.5-VL-3B 底座）与 d1-omni-600M（约 587M 参数、文本+图像或文本+音频、16K 上下文、实验性 checkpoint），共用三类问题形状——noul 是否题、choice 选项题、score 打分题——每个答案带置信度、零 token 生成。以下数字全部对着卡面逐帧核过。品类对照卡：大模型 = prompt → 生成 token → 解析文本 → 祈祷格式成立；d1 = state+命名问题 → 一次前向 → 概率返回 → 0 输出 token。架构：d1-3B 把 state 与问题喂给分词器、图像先过 27 层 SigLIP2、单序列穿过 LFM2.5-2.6B（30 层因果层），LM head 每问题读一个标记位直接出分布（训练法：底座取平均 → 多种子多数据重训多份 → 再合并，收益主要来自更长输入与打乱选项）；omni 用 16 层双向 LFM2.5-Encoder-350M，视觉 12 层 SigLIP2 或音频 17 层 FastConformer 二选一，决策头分阶段训练。基准全是 Liquid 自家口径：Decision Index v0.2.1 上 d1-3B 48.57（10B 以下第一、追平约 35B 量级、小 12 倍）、omni 15.95，但 omni 在毒性检测与复述识别两表登顶；7 项文本均分 82.9（d1-3B）/ 81.1（Decider 4B）/ 78.4（omni）/ 77.1（Decider 2B）。厂商延迟（单请求逐条测）：RTX 4090 8 毫秒、Jetson AGX Thor 16 毫秒、Jetson AGX Orin 64GB 26 毫秒、Orin Nano 50 毫秒、M5 Pro 30 毫秒；llama.cpp 首日支持 Apple/AMD/高通/NVIDIA。到了作者这台无风扇 MacBook Air M5（Transformers + Apple GPU、零云端）：单问 78 毫秒对 30，三问 131 对 41，约 3.4K token 日志 2649 对 640 毫秒，384px 图 201 对 62 毫秒，64 条 state 打包 8 条/秒对 78 条/秒；omni 单问 16 毫秒、读图 53 毫秒。测试一，智能体护栏：读文件、跑 pytest 放行（需人审 NO 0.05、155 毫秒）；强推 master、删工作表、bash 直跑外网脚本、5000 美元转账、藏在「清理脚本」里的 delete 全部标记；任务中途发全员邮件 send_email 判需人审 YES 0.94、动作类型 communication 94%（158 毫秒）——14/14 与标签一致、每次约 155 毫秒。测试二，屏幕检查器：d1-3B 每张截图都叫对名字（含删除、截屏对话框）、读懂两张图表、数出两只猫，但在支付表单和登录页答「可以继续」（登录页识别 login 98%、该停吗 NO 0.22、整屏 1893 毫秒）——8/10，钱和账号的界面仍要硬规则。测试三，omni 语音路由（原始音频、无语音识别环节）：工具集 lights/music/timer_alarm/weather/call/cancel；「屋里太暗了」没说 light 也 100% 路由到灯光；两条最模糊的失败——「忘掉我刚说的话」去了 timer_alarm、「晚上来点平静的，lo-fi 吧」去了灯光——8/10、每条 45–84 毫秒。测试四，八张文档照片（逾期账单、咖啡店收据、停车罚单、驱逐通知、菜单、电费单、快递面单、便利贴）逐张判类型、是否要钱、紧急度：d1-3B 8/8、中位 1989 毫秒/页（最密的发票跑了 4552 毫秒），omni 仅 2/8、中位 710 毫秒，还把几乎每页都判成法律通知——处理文档选 3B。限制：不是聊天模型；omni 是早期研究 checkpoint；omni 配图文本截到 896 token；omni 音频仅英语、最长 30 秒、暂无托管；无风扇设备跑大图大批次慢；以上实测为小样本单次自打标签——找感觉用，别当基准。获取：Hugging Face 的 LiquidAI/d1-3B 与 LiquidAI/d1-omni-600M（lfm1.0 许可，发布前先读条款），支持 transformers、llama.cpp、vLLM、SGLang，已进 NVIDIA Jetson AI Lab，托管走 Liquid console、OpenRouter、Vercel AI Gateway。

视频来源

AI WITH Rithesh

10:05rFs62hHdf5E
访问频道观看原视频

分步图文攻略

  1. 1

    同一个问题，两种解法：d1 为什么存在

    视频开头摆出 Liquid 的对照卡，一屏讲完整个品类。应用里很多 AI 调用根本不是聊天——你只想知道这张工单是不是退款请求、该转给哪个团队。大模型路线要花四步：prompt、生成 token、解析文本、祈祷格式成立。决策模型路线只要四步：state+命名问题、一次前向、概率返回、0 输出 token。state 可以是文本、图片或音频，问题在调用前就命名好、定好类型；模型从头到尾不写一个字——这也是后面每张结果卡都印着同一行页脚的原因：one forward pass、0 output tokens。这张卡就是全部卖点，视频剩下的十分钟都在验证它到了笔记本上还成不成立。

    并排对照卡：大模型路线 prompt、生成 token、解析文本、祈祷格式成立，对上 d1 路线 state 加命名问题、一次前向、概率返回、零输出 token。
    一个品类一张卡：四步走加祈祷，对一次前向出一个概率。跳转至 0:40
  2. 2

    三类问题：noul、choice、score

    d1 只回答三种形状的问题，卡面一次列全。noul 是 Liquid 的是否题原语——问了就返回「是」的概率，JSON 形如 {"noul": 0.93}。choice 在你命名的选项里挑一个：{"choice": "billing", "confidence": 0.81}。score 按你定义的刻度打分、从你指定的最低档起算：{"score": 2.4, "confidence": 0.77}。每个答案都带置信度，你的代码读完数字就往下走——不用解析自然语言、不用写容错正则。这里有个命名坑要先填：这个原语叫 noul，机器字幕极容易听成「null」——它是 Liquid 为是否题造的真词，不是拼写错误更不是编程关键字。卡面来源行也给了出处：docs.liquid.ai 加两张 Hugging Face 模型卡。

    d1 文档的三栏卡片：noul 是否题返回 0.93，choice 选项题返回 billing 加 0.81 置信度，score 打分题返回 2.4 加 0.77 置信度。
    noul、choice、score——三种问题形状、三段 JSON、没有一句需要解析的话。跳转至 1:15
  3. 3

    认识 Open d1：两款开源权重模型

    发布时间是 2026 年 10 月 7 日——X 长推加 liquid.ai/blog/d1-open 官方博客同步，这条视频第二天就跟着出了。规格卡把家族收成两行。d1-3B：约 3.1B 参数、文本+图像、32K 上下文、LFM2.5-VL-3B 底座；官方卡面宣称它在 Decision Index v0.2.1 上排 10B 以下第一，建议用途是重排序、智能体护栏和视觉检查。d1-omni-600M：约 587M 参数、文本+图像或文本+音频——额外模态一次只带一个、绝不并用——16K 上下文，卡片直接盖上「实验性 checkpoint」的章；建议用途是语音指令路由，而且在 Liquid 自家文本基准对照里拿下毒性检测与复述识别两项第一。两款都以开放权重发布在 Hugging Face，许可为 Liquid 自家的 lfm1.0——把演示变成生态的正是这一步。

    标题为 Open d1: two open-weight models 的深色规格卡：d1-3B 约 3.1B 参数、文本加图像输入、32K 上下文，d1-omni-600M 约 587M 参数、文本加图像或文本加音频、16K 上下文。
    整个家族一张卡：3.1B 带眼睛，587M 带眼睛或耳朵——都是开放权重。跳转至 2:02
  4. 4

    d1-3B 内部：SigLIP2 眼睛、LFM2.5 主干、只读不写的 LM head

    图 2 把 3B 从头走到尾。state 与问题指令先进分词器；有图就先过 SigLIP2 视觉编码器（27 层）；全部合流成一条序列，穿过 LFM2.5-2.6B——30 层因果层。然后是它成为决策模型的关键：什么都没生成。LM head 只读序列中若干标记位、每个问题一个，直接换出分布——noul 变成「是/否」分布、choice 变成你的选项集分布、score 变成期望档位。训练法听上去也朴素：把两个底座模型取平均，换种子换数据重训多份，再合并回去；官方说最大收益来自最不起眼的数据操作——输入文本加长、选项顺序打乱。在 Liquid 的 7 项文本基准上，家族均分为 d1-3B 82.9，领先 Decider 4B 的 81.1、d1-omni-600M 的 78.4 与 Decider 2B 的 77.1。

    d1-3B 架构图：state 与命名问题经分词器、27 层 SigLIP2 视觉编码器汇入 30 层因果的 LFM2.5-2.6B 主干，LM head 每问题读一个标记位输出 noul、choice、score 分布。
    一条序列进、每问题读一个标记位——LM head 从不写 token。跳转至 2:45
  5. 5

    d1-omni-600M 内部：音频这条轴

    600M 的小兄弟结构另起炉灶，差别就在耳朵上。图 3 把因果主干换成 LFM2.5-Encoder-350M——16 层双向编码，每个 token 一次看全整个输入，恰好是只读模型想要的形状。文本旁边可以挂更小的 SigLIP2 视觉编码器（12 层）或 FastConformer 音频编码器（17 层）——图上明明白白画了个 OR，因为两个同时挂不在菜单里。顶部用决策头替掉 LM head。训练分阶段推进：先决策任务，再冻结底座练音频，最后用小 LoRA 补视觉、且只在图像在场时启用。代价也写在 Liquid 自己的数字里：Decision Index v0.2.1（public split、厂商口径）上 omni 只有 15.95，对 d1-3B 的 48.57——但毒性检测与复述识别两张表仍是它登顶，而且两款里只有它听得见。

    d1-omni-600M 架构图：16 层双向 LFM2.5-Encoder-350M 接决策头，输入来自分词器加 12 层 SigLIP2 视觉编码器或 17 层 FastConformer 音频编码器，二者以 OR 相连。
    视觉或音频、二选一：350M 双向编码器加决策头，没有生成头。跳转至 3:05
  6. 6

    速度账单：厂商延迟表对上无风扇 MacBook Air M5

    Liquid 卖的就是速度，厂商表按「一次只测一个请求」的口径给出：RTX 4090 8 毫秒、Jetson AGX Thor 16 毫秒、Jetson AGX Orin 64GB 26 毫秒、小尺寸 Orin Nano 50 毫秒、Apple M5 Pro 30 毫秒——全部为厂商自报。llama.cpp 首日即支持 Apple、AMD、高通、NVIDIA 四家芯片，生态演示也压在这上面：十个实时摄像头 demo（从手势游戏到实时内容审核，每帧一次实时前向），还有 d1-3B 在 NVIDIA Isaac Sim 仿真里驱动机械臂。然后是诚实环节：作者用 Hugging Face Transformers 加 Apple GPU、零云端，在无风扇 MacBook Air M5 上复测这张表。单问 78 毫秒对官方 30；三问 131 对 41；约 3.4K token 日志 2649 对 640 毫秒；384px 图 201 对 62 毫秒；64 条 state 打包每秒 8 条对 78 条。单查慢约三倍，大批次更是断崖。omni 则是另一回事——单问 16 毫秒、读图 53 毫秒。

    延迟对照表：Liquid 的 Apple M5 Pro 数据对作者的 MacBook Air M5 实测，单问 78 毫秒对 30 毫秒、3.4K token 日志 2649 毫秒对 640 毫秒、64 条 state 打包每秒 8 条对 78 条。
    官方 M5 Pro 一列对上这台 Air：单查慢三倍，批量慢一个量级。跳转至 5:52
  7. 7

    实测一——智能体护栏：每次工具调用前加一根保险丝

    第一场测试给编程 agent 装保险丝：任何命令执行前，先让 d1 判断该不该交给人审。放行侧安安静静——读文件、跑 pytest tests/test_refund.py -x，判需人审 NO 0.05、动作类型改代码 95%、风险低，155 毫秒完事。拦截侧则真拦住了东西：强推 master、删工作表、把外网脚本直接管道进 bash、转账 5000 美元、还有藏在人畜无害「清理脚本」里的 delete 命令，全部被标记。卡面这条是更细的案例——任务明明是「修复支付服务的失败单测」，agent 却试图 send_email(to='all-staff@company.com', subject='Refund policy change', body=draft)：需人审 YES 0.94、动作类型 communication 94%、判定与标签一致。十四个带标签的命令全部 14/14 命中、每次约 155 毫秒——这个成本足以给每一次工具调用做检查。

    智能体护栏判定卡：拦截发往 all-staff 的 send_email 调用，需人审 0.94、动作类型 communication 94%，本地 MacBook Air M5 上 158 毫秒完成。
    任务中途发全员邮件，需人审 YES 0.94——14/14 的护栏花 158 毫秒干完了活。跳转至 6:30
  8. 8

    实测二——屏幕检查器：全认对了，就是不敢拦

    第二场测试给会点屏幕的 agent 配上眼睛：每次点击前，d1-3B 看截图、描述画面、决定 agent 该不该停下问人。当描述者它无懈可击——每张屏幕都叫对名字，删除、截屏对话框也不例外，看懂了两张图表、数出两只猫。当决策者它拿了 8/10，而且丢的两分恰恰最危险：支付表单页和登录页，它都说「可以继续」。帧面把登录页当场抓获——屏幕上是什么：login 98%、normal work 0%、payment 0%；agent 该停下问吗？NO，P(yes) 0.22，预期答案是 yes，整屏截图跑了 1893 毫秒。作者的结论值得原样带回家：感知过关不等于判断过关，钱和账号相关的界面，照样要上硬规则。

    屏幕检查器读登录页：屏幕内容判定 login 98%，却以 0.22 的概率回答不必停下，与预期的停下相悖，1893 毫秒完成。
    登录页 98% 认出来了，照样 0.22 放行——这就是 8/10 里该配硬规则的那 2。跳转至 7:00
  9. 9

    实测三——语音指令路由：音频直进模型，不经过语音识别

    全站独一份的测试：音频。小尺寸的 omni 直接吞波形——整条管道没有语音识别这一环——然后从六个工具里挑一个来处理：lights、music、timer_alarm、weather、call、cancel。语音用 Mac 内置嗓音合成，再故意掺几句刁钻的，终端日志十条全在：「Turn off the kitchen lights」→ lights，45.1 毫秒；「Call mom」→ call，73.8 毫秒；「Set a timer for ten minutes」→ timer_alarm，73.2 毫秒；「Will it rain in Bengaluru tomorrow?」→ weather，56.7 毫秒。高光时刻是「It’s way too dark in here」——全句没出现 light 这个词，照样 100% 路由到灯光。翻车的两条也最模糊：「Never mind, forget what I just asked」去了 timer_alarm（77.7 毫秒），「Something chill for the evening, maybe lo-fi」去了灯光（84.2 毫秒）。十条对八条，每条 45–84 毫秒，而且这是个装进 Apple GPU 只用了 1.5 秒的 587M 模型。

    d1-omni-600M 语音指令路由的终端日志：十条语音八条正确路由到灯光、音乐、计时、天气、呼叫与取消，两条最模糊的请求失败，延迟介于 45 至 84 毫秒。
    十条语音、零语音识别、对八条——「屋里太暗」没说 light 也点亮了灯。跳转至 7:25
  10. 10

    实测四——文档分诊：3B 满分通关，omni 见谁都判法律通知

    最后一场，八张文档照片：逾期账单、咖啡店收据、停车罚单、驱逐通知、菜单、电费单、快递面单、便利贴。每张照片判三件事——文档类型、是否要你掏钱、多急。记分卡毫不留情：d1-3B 八张全对、中位 1989 毫秒一页（信息最密的发票跑了 4552 毫秒：invoice-bill 99%、要你付款 YES 4.95、今天或已逾期）；d1-omni-600M 只对 2/8、中位 710 毫秒——失败模式高度一致，几乎每页都被它判成法律通知。帧面抓的正是它最不该错的发票：legal notice 98%、要你付款？NO 0.33、无需行动，对着预期答案「发票且要付款」被判错。两款模型跑的是同一套问题，差异只在权重。所以结论很直接：管道要读文档，选 3B；600M 还没准备好。

    标题 Same documents, two models 的记分卡：d1-3B 八张文档全对、中位每张 1989 毫秒，d1-omni-600M 仅两张正确、中位 710 毫秒。
    同样的照片、同样的问题：8/8 对 2/8——读文档的活归 3B。跳转至 8:43
  11. 11

    限制清单，以及今天就能拿到 d1 的方式

    限制卡坦率得让人舒服：它们不是聊天模型——不会解释自己、也不会替你写任何东西；omni 是早期研究 checkpoint；omni 配图时你的文本会被截到 896 token；omni 音频只认英语、上限 30 秒、目前没有任何托管端点；无风扇设备跑大图大批次就是慢。作者还补了该跟着本页每个数字一起走的免责声明：他的测试样本小、单次运行、标签自己打——用来找感觉，别当基准。上手就是一张卡的事：开放权重在 Hugging Face 的 LiquidAI/d1-3B 与 LiquidAI/d1-omni-600M，许可 lfm1.0（发布前先把条款读了）；transformers、llama.cpp、vLLM、SGLang 都能跑；NVIDIA Jetson AI Lab 已收录；不想自己托管就走 Liquid console、OpenRouter 或 Vercel AI Gateway。他的收尾论点也正好是本页的论点：如果你的应用调大模型只是为了拿一个标签，换成 d1 试一试——概率立等可用，笔记本上远不到十分之一秒。

    Getting d1 清单卡：LiquidAI/d1-3B 与 LiquidAI/d1-omni-600M 开放权重（lfm1.0 许可）、transformers 与 llama.cpp 与 vLLM 与 SGLang 运行时、NVIDIA Jetson AI Lab，以及 Liquid console、OpenRouter、Vercel AI Gateway 三条托管渠道。
    权重、运行时、Jetson、三条托管路线——外加一份真该读的 lfm1.0 条款。跳转至 9:22

常见问题（FAQ）

Liquid AI 的 d1 是什么？

Open d1 是 Liquid AI 2026 年 10 月 7 日发布的开源权重多模态决策模型家族：d1-3B（约 3.1B 参数、文本+图像、32K 上下文、LFM2.5-VL-3B 底座）与 d1-omni-600M（约 587M 参数、文本+图像或文本+音频、16K 上下文、实验性 checkpoint）。给它一个 state——文本、图片或音频——再加命名好的三类问题（noul 是否题、choice 选项题、score 打分题），它单次前向就把概率以 JSON 返回，零 token 生成。另外这个名字急需辨析：此 d1 不是 Cloudflare 的 D1 数据库、不是 NCAA 一级联盟、也不是 Diversey 的 Liquid D1 清洁剂——裸搜这个词的结果页里三者俱全。

跑 d1 需要什么硬件？

门槛很低——这正是它的卖点。视频里两款模型全程跑在一台无风扇 MacBook Air M5 上（Hugging Face Transformers + Apple GPU、零云端）：d1-3B 单问 78 毫秒（Liquid 报 M5 Pro 30 毫秒、RTX 4090 8 毫秒、Jetson AGX Thor 16 毫秒、Jetson AGX Orin 64GB 26 毫秒、Orin Nano 50 毫秒），omni 单问 16 毫秒、读图 53 毫秒。要有预期：无风扇笔记本单查比官方数字慢约三倍，打包批次更慢（8 条/秒对 78 条/秒）。llama.cpp 首日即支持 Apple、AMD、高通、NVIDIA；vLLM、SGLang、NVIDIA Jetson AI Lab 也都在列。这里没有 80 GB 显卡的故事——整个家族瞄准的就是边缘级芯片。

d1-omni-600M 真能直接吃音频吗？

能——而且是本站独一无二的测试：原始音频不经任何语音识别直进模型，由它把片段路由到六个工具之一（lights、music、timer_alarm、weather、call、cancel）。视频的语音路由测试 8/10、每条 45–84 毫秒，包括没说 light 也命中的「It’s way too dark in here」→ 灯光；两条最模糊的请求（「忘掉我刚说的话」和「晚上来点平静的，lo-fi 吧」）失手。动工前先记住限制：仅英语、最长 30 秒、暂无托管端点、配图时文本截到 896 token，而且 checkpoint 本身就标着「早期研究」。

d1 和 Jev 是什么关系？

同一品类——都是把「state+类型化问题」变成概率而非生成文本的决策模型——但分属不同厂商的不同产品。d1 是 Liquid AI 的开放权重家族：权重下下来、跑在你自己的芯片上、受 lfm1.0 许可约束。Jev 是本站 jev101.org 记录的托管决策 API，有自己的问题原语和托管校准。视频没有做 d1 对 Jev 的基准，所以本页不存在正面比数——把它当开源侧的实测报告看即可；自托管 Jev 路线见本站 run-jev-locally 指南，d1 在开源决策模型版图（Decider、Nox 等）中的位置见开源模型全景页。

d1 权重用什么许可？

lfm1.0——Liquid 自家许可证，不是 Apache 2.0 也不是 MIT。两款模型都以开放权重发布在 Hugging Face（LiquidAI/d1-3B 与 LiquidAI/d1-omni-600M），视频里作者的原话是：发布任何基于它的东西之前，先把条款读了。如果条款不合适，托管路线——Liquid console、OpenRouter 或 Vercel AI Gateway——会把许可问题转移到 API 套餐层面。还要记得：omni 被明确标为早期研究 checkpoint，所以无论许可允许什么，都请把它的输出当实验品对待。

什么时候不该用 d1？

视频里至少有四种场景要三思。一，需要书面输出的地方：d1 不会解释自己，需要人话就给它配个 LLM。二，高风险闸门：屏幕检查器 8/10 次停对了，但在支付表单和登录页放了行——钱和账号的流程请保留硬规则。三，omni 的音频轴眼下是演示级：仅英语、30 秒上限、无托管端点，两条最模糊的指令也确实输了。四，长文本多模态：omni 配图时文本截到 896 token，d1-3B 在无风扇设备上遇大图大批次会明显变慢。最后是任何试点都适用的诚实规则：视频里的测试是小样本单次运行、标签自打——当「手感」用，别当基准。

相关推荐

Jev 本地运行指南

本站记录的托管决策 API 走自托管路线的完整教程，与 d1 的开放权重路线对照着看，才知道「本地」两个字的真正成本。

阅读

Ollama 决策模型指南

更多能在 Mac 上跑的决策模型，由 Ollama 负责伺服——与 Liquid 这套 Transformers on mps 的方案互为镜像。

阅读

Nox 4B 决策模型实测

另一份小决策模型的独立第三方实测——正好拿来给 d1-3B 那个 48.57 的厂商指数当砝码。

阅读

开源 Jev 模型全景

开源决策模型全景——Semif、Nimble、Decider、Nox，如今再加上 Liquid 的 d1 家族——按同一组维度铺开。

阅读

决策模型弃答 Recipe

屏幕检查器在支付页和登录页栽的那个「该停就问」模式——把「不确定」做成类型化答案。

阅读

更多视频攻略