2026 年 9 月，TypeSafe AI 的 Jev 把「决策模型（decision model）」这个概念带进了主流视野。两周后的 10 月 1 日，Cloudflare 发布了同类的两个模型——Clef 和 Clef-flash。它们托管在 Workers AI 上，同时在 Hugging Face 以 Apache-2.0 协议开放权重。
Clef 的定位很直接：正面挑战 Jev，并把「开源 + 多模态 + 自托管」作为核心差异点。它有 27B 参数、内置视觉编码器，支持 64k 上下文，同时完全兼容 Jev / SystemOne API。对正在做技术选型的人来说，问题不再是「决策模型有没有用」，而是「托管 API 还是自托管开放权重，哪个更适合我的团队」。
以下基准均来自 Cloudflare 官方公布的内部跑分，足以帮你排除明显不适配的方案，但不能替代用自己的数据集复测。
先说结论
- 想零运维、追求精度：Jev 或 Clef 的托管版本都可以，Clef 在多数分类基准上略占优势，且多模态是它独有的。想最快上手，可直接付费体验 defapi 上的 Clef 托管 API。
- 要图像/视频输入：Jev 目前是纯文本，Clef 是唯一选择。
- 要自托管或数据不出边界：Clef 的 Apache-2.0 权重在硬性要求上更有优势，代价是 27B 的 GPU 门槛和运维。
- 要极低延迟：Clef-flash（9B，中位 38.8ms）比 Jev（524ms）快一个数量级，代价是牺牲部分精度。
- 只是想快速试一下：两者都能用兼容 API 起步，但别用公开基准代替采购验收。
如果你之前读过我们的 Jev vs Laya 对比，这篇可以看作同一分析框架在第三个候选上的延续。
Clef 是什么
Clef 是 Cloudflare 训练的一个决策模型系列，核心特征：
| 项目 | Clef | Clef-flash |
|---|---|---|
| 底座 | Qwen3.8-27B（含视觉编码器） | Qwen3.5-9B |
| 输入 | 文本、JSON、图像、视频 | 文本、JSON、图像、视频 |
| 上下文 | 64k | 64k |
| 输出 | 每个问题的每个选项一个 logit，逐问题 softmax | 同左 |
| License | Apache-2.0 | Apache-2.0 |
| 托管 | Cloudflare Workers AI | Cloudflare Workers AI |
它的工作方式与 Jev 同类，但实现不同：没有自由文本生成，也没有输出解析。你传入一个 state（文本、JSON、图像或视频）和一组带类型的 schema 问题，它会在一次 forward pass 中返回每个问题在全部允许选项上的概率。
命名上，Cloudflare 用了一个音乐比喻：五线谱开头的谱号（clef）决定了后面音符的音高，决策模型则决定了后续动作的定义域。官方也顺势把 CF（Cloudflare）做成了双关。
架构：prefill + 并行打分，而不是逐 token 生成
理解 Clef 的关键在于它不是自回归的：
- 底座 Qwen 只做一次 prefill-only 前向，处理完整个输入。
- 一个小的 joint schema head 读取底座最后一层 hidden states，把 state 里的证据路由到每个问题，并对所有问题的所有选项联合打分。
- 每个选项得到一个 logit，逐问题做 softmax 就是概率。
这中间没有逐 token 生成的中间文本。相比 LLM 先生成一段推理再格式化成 JSON，Clef 直接从内部表征里导出 schema 选项。
官方描述的两阶段注意力路由值得留意：每个合法选项先从 prompt 中抽取与自身相关的上下文（option-specific evidence routing），随后各字段之间、字段与原始 payload 之间再互相做交叉注意力（joint cross-field attention），最后在 schema 约束下打分（schema-bound scoring）；整个过程使用一个 lexical prior 来保持选项之间的语义意图。
训练上，Cloudflare 冻结了 Qwen 底座，联合优化 routing head 和 rank-256 的 LoRA adapter：
- label-smoothed cross-entropy（保证合法 schema 输出）
- Brier loss（改进概率校准）
- RLCD（Reinforcement Learning for Calibrated Decisions，作为第二优化目标，给相邻序数选项部分分、奖励完整正确的 record、并加 reference penalty 防止分布漂移）
这里有个有意思的细节：Cloudflare 在同一周刚发布过基于 DiffusionGemma 改造的决策模型实验，Clef 是那条技术路线的延续，只是换了底座。也就是说，它并非照抄 Jev 的架构，而是从「暴露 LLM logprobs 做确定性概率」这条独立路径走过来的。
和 Jev / SystemOne 的兼容性
Clef 与 Jev / SystemOne 是完全兼容的：使用同一个 POST /v1/systemone 请求体，返回同样的 model、answers、usage 结构。choice 返回 choice / confidence / probabilities，score 返回期望分 score / confidence / legend / probabilities，noul 返回命题为真的概率。
三类原语和 Jev 对齐：
| 原语 | 含义 | 返回 |
|---|---|---|
noul | 二元命题，true/false | 0.0–1.0 的概率 |
choice | 命名选项，选一个 | 选项 + confidence + 各选项概率 |
score | 有序选项，打分 | 期望分 + confidence + 各档概率 |
对一个已经接了 Jev 的系统，这意味着迁移门槛极低——甚至可以同时在两个 provider 后面挂同一个客户端做影子流量。但要提醒一点：wire protocol 兼容不等于语义完全一致。不同模型的选项数上限、置信度计算方式、以及校准曲线都可能不同，旧阈值必须用边界样本重测。
一个具体的官方例子（Cloudflare Workers AI 端点）：
curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run/@cf/cloudflare/clef \
-X POST \
-H "Authorization: Bearer $CLOUDFLARE_AUTH_TOKEN" \
-d '{
"model": "clef",
"state": "Checkout has been failing for every customer for the last hour.",
"questions": {
"urgent": { "type": "noul", "instructions": "Is this support request urgent?" },
"team": {
"type": "choice",
"instructions": "Which team should handle this request?",
"criteria": {
"billing": "Payments, invoices, and refunds",
"technical": "Outages, errors, and configuration",
"sales": "Plans and upgrades"
}
},
"severity": {
"type": "score",
"instructions": "How severe is the customer impact?",
"criteria": ["No impact", "Minor", "Major", "Critical"]
}
}
}'多模态：Clef 目前独有的能力
这是 Clef 相对 Jev 最清晰的产品差异。Jev 目前只做文本分类，而 Clef 内置视觉编码器，能读图像和视频帧。
用法是在 record 中添加 images（PIL 图像）或 videos（帧数组），再传给 processor；processor 的可选参数放在 media_kwargs 中。文本与多模态 record 可以混在同一个 batch 里：
from PIL import Image
record = {
"state": {"task": "Review the attached receipt."},
"images": [Image.open("receipt.jpg")],
"questions": {
"legible": {"type": "noul", "instructions": "Is the receipt total legible?"},
},
}Cloudflare 给出的落地场景是威胁情报：把一个域名连同 Browser Run 渲染出的页面截图丢给 Clef，让它输出「95% 时尚网站、85% 电商、<1% 钓鱼」这类多标签概率。官方称，同一工作流里 Clef 用 2.2s 完成抓取、渲染和分类，而最快的通用 LLM gpt-oss-120b 花了 4.7s，且只返回两个分类。这个对比在延迟和覆盖度上很有参考价值，但要注意它衡量的是整个工作流，而不是单纯的模型推理。
基准表现：谁在哪些地方领先
云厂商的跑分都要持保留态度。下面是官方 Decision Index 0.2.1 内部跑分的一部分（百分数，越高越好）：
| 基准 | Clef | Clef-flash | Jev | 谁领先 |
|---|---|---|---|---|
| BFCL（case exact） | 98.5 | 98.8 | 95.8 | Clef 系 |
| ToolRet（nDCG@10） | 69.2 | 66.4 | 65.3 | Clef |
| API-Bank（accuracy） | 91.9 | 93.1 | 88.2 | Clef 系 |
| BANKING77（macro-F1） | 94.2 | 90.9 | 79.7 | Clef |
| CLINC150+OOS（macro-F1） | 97.4 | 66.8 | 89.3 | Clef |
| Home appliance（case exact） | 83.0 | 97.7 | 52.3 | Clef 系 |
| ContractNLI（macro-F1） | 81.4 | 84.3 | 71.7 | Clef 系 |
| MMLU（accuracy） | 90.3 | 91.8 | 91.7 | 接近 |
| GPQA Diamond（accuracy） | 48.0 | 51.0 | 78.3 | Jev |
| MMLU-Pro（accuracy） | 65.9 | 65.3 | 82.7 | Jev |
| BBH（accuracy） | 73.7 | 68.9 | 92.9 | Jev |
| When2Call MCQ（accuracy） | 72.4 | 65.6 | 81.0 | Jev |
| BRIGHT（nDCG@10） | 45.9 | 39.3 | 47.5 | Jev |
结论不是「Clef 全面碾压」。更准确的说法是：Clef 在分类、工具调用、结构化索引类任务上强，Jev 在需要一点泛化推理的题目（GPQA、MMLU-Pro、BBH）上反而领先。 这背后是两者在底座和训练目标上的差异：Clef 基于 Qwen 底座 post-train，Jev 则沿 SystemOne 路线做了不同的决策优化。选型要看你的任务更像哪一类。
再看延迟（毫秒，越低越好）：
| 指标 | Clef | Clef-flash | Jev | Laya |
|---|---|---|---|---|
| 中位延迟 | 209.3 | 38.8 | 524.1 | 5.8 |
| p95 延迟 | 238.6 | 122.4 | 536.0 | 222.5 |
Laya 的中位数极快，但在上面的质量基准里明显落后，属于「用速度换精度」的取舍。Clef 系列则在质量与延迟之间选择了不同定位：Clef 追求质量，Clef-flash 追求速度。这些数字来自不同硬件和部署环境，不能直接横向比较，只能作为相对参考。
Workflow evals（端到端业务流，来自 TypeSafe Evals）：
| 工作流 | Clef | Clef-flash | Jev |
|---|---|---|---|
| Invoice processing（exact） | 64.7 | 57.1 | 61.8 |
| Customer service（exact） | 76.3 | 77.0 | 76.0 |
| Security incidents（exact） | 62.9 | 61.7 | 61.7 |
| Agent trace observability（primary） | 68.5 | 69.8 | 71.6 |
Cloudflare 的说法是「4 个里赢了 3 个」。公平地讲，差距都在个位数，而且用的是 Cloudflare 自己跑的 TypeSafe 评测集——真要采购，还是得用你自己的数据复测。
部署与 License：开源的分量
Clef 的两个模型均以 Apache-2.0 协议发布在 Hugging Face，权重为标准分片 safetensors，可直接本地运行：
- Transformers（
image-text-to-textpipeline） - vLLM（
vllm serve "Cloudflare/clef"） - SGLang
- Docker Model Runner、llama.cpp / Ollama / LM Studio（量化版）
文件结构也很清晰：底座权重、joint_head.safetensors + joint_head_config.json（joint schema head）、joint_schema_model.py（负责 record 编码、batching 和 systemone 封装）。官方在单张 H200、torch 2.11 + transformers 5.10.2 上测试过。
这里必须打破「开源 = 免费」的错觉：
- Apache-2.0 免 License 费，但要自己出 GPU。 27B BF16 不是消费级显卡能舒服跑的规模，Clef-flash 的 9B 才更现实。
- 要自己承担运维。 模型服务、显存常驻、版本升级、安全补丁、监控，都是成本。
- 托管版本省掉了这些：除了 Cloudflare Workers AI，也可以直接付费使用 Clef 或 Clef-flash 的托管 API，代价是改用按量计费。
Cloudflare 还强调了一项面向企业的能力：默认不读取、不存储、不用你的请求和响应训练，除非你主动使用它的 fine-tuning 产品。自托管版本则天然满足数据不出边界的要求。这一条正好补上了 Jev 对比文章中「托管 API 的数据保留需要向厂商确认」留下的疑问。
新的 RL fine-tuning 平台
Clef 发布里还有一块容易被忽略但很重要的内容：Cloudflare 推出了 强化学习微调服务。
原因是 Cloudflare 内部有大量高度专业化的分类需求（Trust & Safety 投稿审核、支持工单分诊、判断爬虫好坏），这些场景沉淀了多年的标注决策数据。微调会牺牲一部分通用能力，换取特定领域的更高精度——Cloudflare 有 15 年以上的网络数据，这正好是它的强项。
平台的技术组件也值得关注：
- Cloudflare AI Gateway：把 AI 流量自动沉淀成数据集
- Workers AI：用 base Clef 生成 rollouts
- Cloudflare Containers：RL sandbox，用于打分和回放 agent 动作
- [新] Trainer：更新微调后的 Clef 权重
- Workers AI + BYO Model：把微调模型重新部署回 Workers AI
目前由 FDE（forward-deployed engineer）团队牵头，之后会开放成自助（self-serve）平台。对已经重度使用 Cloudflare 的团队来说，这是一条把「自有标注数据」变成「专属决策模型」的路径，也是 Jev 目前没有对标的公开能力。
选型建议：看条件，不看口号
如果满足这些，就选 Clef（或 Clef-flash）
- 输入里有图像或视频，需要多模态分类。
- 数据不能进入第三方托管 API，需要 Apache-2.0 权重 + 自托管 / 离线部署。
- 需要 64k 上下文来塞更长的 state。
- 想用 Cloudflare 生态做微调，把自有标注数据变成专属模型。
- 延迟敏感且能接受精度取舍时，Clef-flash 是极快的选择。
- 想立刻验证：直接在 defapi 上跑一条 Clef 或 Clef-flash 请求。
如果满足这些，就选 Jev
- 只做文本决策，且想要零运维的托管 API。
- 任务偏泛化推理（GPQA / MMLU-Pro / BBH 这类），Jev 目前更强。
- 已有 Jev 集成、阈值和校准曲线，迁移收益不足以覆盖重测成本。
- 团队没有 GPU 运维编制，也不打算深入投入模型服务。
两者都可以，那就看这些
- 用你真实的 state 分布、选项集、score criteria 做一轮影子流量。
- 同时测 correct rate、calibration、p50/p95 latency、失败兜底和成本。
- 别把「API 兼容」当成「零迁移」，阈值一定要用边界样本重测。
- 把数据保留、residency、SLA、支持承诺写成采购门槛，不要用公开基准代替。
FAQ
Clef 真的和 Jev 完全兼容吗？
wire protocol 兼容：同一个 POST /v1/systemone 请求体，同样的 answers / usage 响应结构，choice / score / noul 三类原语一致。但模型内部的选项上限、置信度公式和校准曲线不同，旧阈值不能原样照搬。
Clef 是开源的，是不是就能免费用在生产环境？
License 免费不等于 TCO 为零。27B 需要足够强的 GPU，再加上模型服务、显存、监控、升级和安全补丁。Clef-flash（9B）或托管版本通常更划算。
Clef 和 Clef-flash 怎么选？
Clef 是精度型号，在多数基准上更强；Clef-flash 是延迟型号，中位 38.8ms，比 Clef 快约 5 倍，但在 CLINC150、ContractNLI 等任务上精度下降明显。热点路径用 flash，关键判断用 Clef，是常见的组合。两者都已托管，可在 defapi 直接付费体验：Clef、Clef-flash。
官方基准能直接拿来做采购决定吗？
不能。这些是 Cloudflare 内部跑分，而且 Clef 还在 TypeSafe 自己的评测集上比较。用来排除明显不适配的方案可以，最终决定要用同一数据集、同一失败定义和同一置信度阈值复测。
图像输入实际怎么用？
在 record 里加 images（PIL 图像）或 videos（帧数组），可选的 processor 参数放 media_kwargs，然后让 encode_record 带上 processor。文本和多模态可以混批。
自托管 Clef 需要什么？
单张 H200 级别 GPU、torch 2.11 + transformers 5.10.2，图像/视频还需要 pillow。官网没给出消费级硬件的保证，生产前务必用目标硬件压测 p95。
Jev 会被 Clef 取代吗？
不一定。两者在基准上互有胜负，Jev 在泛化推理类任务领先，且是纯托管路径。真正的变化是决策模型这个品类从「一家独大」变成了「有竞争、有开源、有多模态」，对买方是好事。
下一步
想直接体验托管路径，可以付费使用 defapi 上的 Clef（27B 精度型号）或 Clef-flash（9B 速度型号），并可与 Jev API 做影子流量对照。如果图像输入或自托管是硬需求，直接读 Clef 的 Hugging Face 模型卡 和 Cloudflare 发布博客，再用你自己的数据跑一轮对比。想先补齐决策模型的基础概念，可以看 Jev 与 Laya 的选型对比 和 System One 入门。