九天前我写过 TypeSafe Jev 决策模型——那种不生成文字、只输出概率的「条件反射」式模型。当时文末提了一嘴开源复刻潮：48 小时冒出 6 个复刻版，但都停留在「能跑通 API」的程度，没一个敢公布完整训练细节。9 月 27 日这个格局被 LibertAI 的 Deem 打破了：两套 Apache-2.0 权重、完整训练配方、连基准工具都开源，还附带一个 0.8B 的 CPU 版——你不需要 GPU，就能把一个决策模型拉到自己电脑上跑。
我在这台 Mac 上把 0.8B 版完整跑了一遍：下载权重、起服务、发请求、量延迟、验边界。这篇文章记录的就是这次实测的过程、数据和三个坑。
Deem 是什么：一对「强自知之明」的模型
Deem 9B（deem-9b-v1）：基座 Qwen3.5-9B-Base，LoRA 合并后的决策模型。官方数字：JevBench public hard 65.8 分（置信门控模式）、68.9（extended reasoning 模式），对比闭源品类第一的 Jev 74.1 还有差距，但已经是「最强开源决策模型」。短决策 P50 约 100ms（低功耗边缘 GPU 上）。
Deem 0.8B（deem-0.8-v1）：Qwen3.5-0.8B 全参微调，主打 CPU。官方数字：362ms 短决策（busy desktop CPU）、0.9GB 内存（int8 路径）、长政策留出集 96.3% 准确率。
比数字更值得看的是模型卡的诚实度：它明说冻结的 9B 基座裸考只有 0.568，明说加一个新训练域反而让 hard 集分数变差，明说 0.8B 在外部 hard split 上只有 0.333（强项在长政策域）。「哪里不行写清楚」的发布在开源圈不多见。
实测第一步：把服务跑起来
我的环境：Apple Silicon Mac、Python 3.13、torch 2.14.0、transformers 5.17.0。权重 1.4GB（bf16 safetensors），跑起来后进程常驻内存 1.37GB。
第一个坑就在安装这一步。GitHub 仓库 README 写着 pip install deem[torch]，但 PyPI 上的 deem 是一个完全无关的同名包（RBM 集成聚合模型，2023 年就在了）。装了它你会得到一堆跟决策模型毫无关系的东西。正确做法是克隆仓库：
git clone https://github.com/Libertai/deem.git
cd deem
# 服务端是纯标准库 HTTP，Python 侧只需要 torch + transformers
pip install "torch" "transformers>=5.17"
# 启动服务（权重自动从 HuggingFace 下载，约 1.4GB）
DEEM_CHECKPOINT=LibertAIDAI/deem-0.8-v1 \
DEEM_MODEL_ID=deem-0.8-v1 \
DEEM_DEVICE=cpu \
python serve/deem_server.py服务起在 127.0.0.1:8300，暴露 POST /v1/systemone 端点——与 Jev 商业 API 同一套接口形状，官方称 TypeSafe SDK 改个 BASE_URL 就能对接。对已经在 Jev 那篇里接过 API 的人来说，客户端代码一行不用改。
实测第二步：复现「30 进 31 出」
noul（「某命题为真的概率」）是最基础的原语。模型卡的 v1.1 更新说明有个大胆宣称：v1.0 曾把「60 天旧订单」判成「在 30 天退货窗口内」（yes 先验 bug），v1.1 修复后边界锐利到「30 进 31 出」。我构造退货场景逐天测了一遍：
curl -s http://127.0.0.1:8300/v1/systemone -d '{
"state": "Order 31 days old.",
"questions": {"within": {"type": "noul", "instructions": "Within the 30-day window?"}}
}'
# 返回：{"answers": {"within": {"type": "noul",
# "value": 6.144174602214718e-06, "confidence": 0.9999877116507956}}}31 天订单，P(在窗口内) = 0.0006%，模型几乎笃定它出界了。完整边界测试结果：
| 订单天数 | P(在 30 天窗口内) | 判断 |
|---|---|---|
| 25 天 | 0.9968 | 界内 ✓ |
| 30 天 | 0.9526 | 界内 ✓（第 30 天算界内） |
| 31 天 | 0.0000061 | 界外 ✓ |
| 60 天 | 0.000013 | 界外 ✓（v1.0 在这里会翻车） |
「30 进 31 出」在我这台 Mac 上原样复现，v1.1 的时间比较修复是真的，不是宣传口径。
三个官方没明说的坑
坑一：362ms 是 x86 Rust 的数字，Mac 上不是。 官方 362ms 来自他们自己写的 Rust 运行时——手写 AVX-512 int8 内核。AVX-512 是 x86 指令集，Apple Silicon 用不上。我实测 Python 服务栈（torch CPU 后端）的真实延迟：单题 4.2-7.0 秒，三题合并请求 11.6 秒（约 3.9 秒/题，批量有摊薄）。又试了 DEEM_DEVICE=mps 走 GPU：输出与 CPU 位级一致（同一题都是 6.144e-06），但延迟 5.2 秒没变快——35 个 token 的 prefill，瓶颈不在算力。Mac 用户把延迟预期放宽到秒级；362ms 要在 x86 机器上编译 Rust 运行时才成立——手头没有 x86 环境，这个数字我没能亲手验证，姑且当官方口径看待。
坑二：输入措辞对置信度的影响大得离谱。 同样问退货窗口，用 JSON 对象当 state（{"order_age_days": 45}）时模型只给出 0.407 的弱判断，10 天订单也只有 0.852；换成自然语言句子（”Order 31 days old.”）立刻变成 0.0000061 的笃定判断。训练数据以自然语言政策文本为主，JSON 字段式输入偏离了训练分布。想在生产里用，先把 state 写成完整句子，或者两种措辞都测一遍再上线。
坑三：0.8B 的主观量表不可靠。 三题合并测试里，「重复扣款」这种我预期 medium/high 的客服工单，severity 被判成 low（0.844）。订单年龄、路由这类有客观依据的判断它很稳——同一请求里 25 天退货窗口判 0.958、客诉路由 billing 判 0.753 全对——但主观分级别太当真，这与模型卡自认「0.8B 强项是长政策域」一致。要主观量表，得上 9B——约 18GB 权重，需要 GPU 或大内存机器，我这次没跑。
它到底怎么「思考」：一次 prefill，零生成
Deem 最有意思的设计藏在源码里（这正是全开源的好处）。它不让模型生成「yes」再解析，而是把问题渲染成固定格式，在 Answer k: ( 槽位直接读下一个 token 的 logits——选项映射成字母 A、B、C…，softmax 只在这些字母的 LM head 行上做。noul 问题没有选项，源码里 A 行代表「否」、B 行代表「是」。
这个设计带来三个实际影响：
- 没有解码阶段。服务端返回的 usage 里
completion_tokens恒为 0，一次 prefill 出全部答案。这是它敢喊 100ms P50 的底气——省掉的是整个自回归过程。 - 提示注入没有文本出口。state 里的
<、>会被转义成\u003c，模型根本不生成文字，往 state 里塞伪造的「Answer 1: (」也骗不出一句话。比让 LLM 输出 JSON 再解析的方案干净得多。 - 每个问题独立成 prompt。一份 state 配 N 个问题会渲染成 N 个单题提示批量过前向，问题越多，state 前缀的 KV cache 复用越值钱。
另一个硬约束：torch 后端只认 26 个单 token 字母，超过 26 个选项的请求直接 4xx；255 选项的满配上限只有 Rust 运行时支持。用 Python 服务的话，选项数别超过 26。
什么场景我建议你别用
这些建议全部来自上面的实测：
- 需要解释理由的场景。 Deem 只给概率和置信度，没有推理过程（9B 的 extended reasoning 会生成验证 trace，但那是 9B 的事）。要「为什么」的审计场景，用生成式模型。
- Mac 上的低延迟在线判断。 Python 路径秒级延迟，做实时路由会心疼；离线批处理、夜间跑单、CI 检查无所谓。
- 超过 26 个选项的分类（Python 服务）。 硬上限，超了直接报错。
- 把 0.8B 的主观量表当生产依据。 见坑三。
生态速览：决策模型这一周
- EmpirioLabs Aplomb 1 Omni（9/27）：把决策原语扩到多模态——音频、视频、图片都能进 state，接口
POST /v1/decisions，只收输入 token。多模态决策此前是空白。 - Supersonic Labs Julia-1（9/27 上架 HuggingFace）：144M 参数小模型，2000 个类型化决策上 73.15%（对照 Jev 72.70%），但在 72 类银行意图分类上被拉开到 64% vs 87%——再次验证「小模型的短板在类别多的时候」。
- 无训练复刻技巧：GeekNews 9/27 有一篇把 GLM-5.3-Flash 直接变成 Jev 式决策模型的做法——不训练，只读选项对应 token 的下一 token 概率。Deem 本质上是这个思路的「认真训练版」：同样的读出机制，用 124.8k 行经过真值校验的数据把概率校准到位。校准成本便宜得惊人——0.8B 的 SFT 阶段在 training_meta.json 里显示 1750 步、约 31 分钟、峰值内存 6.5GB。
上手路径建议
- 先跑 0.8B 熟悉
/v1/systemone的三个原语（noul / choice / score），拿你业务里真实的政策文本当 state 测判断质量； - 精度不够再上 9B（约 18GB，需要 GPU 或大内存机器，9B 部分本文未实测）；
- 要 362ms 级延迟，找 x86 Linux 机器编译 Rust 运行时；
- 已有 TypeSafe SDK 的，改 BASE_URL 直接接本地 8300 端口；
- 想把它嵌进 Agent 流水线的，它适合放在 OpenAI Agents API 或 Gemini Antigravity 这类托管 Agent 的路由层——用一次 prefill 的成本替掉「调大模型判断走哪个分支」的那一步。端侧部署的更多选择可以参考之前写过的 MiniCPM5-2B 端侧 Agent 指南，那是生成式路线，Deem 是判别式路线，两条路可以并存。
决策模型这个品类的价值不在「更聪明」，而在「更便宜、更快、更可控」。Deem 把这三件事的开源门槛拉到了「一台没有 GPU 的笔记本」这个档位——下次准备给 Agent 手写 if-else 之前，先试一试它。