Cloudflare 开源 Clef 决策模型：不生成文字，39 毫秒做一次判断

Cloudflare 在 10 月 1 日发布了两款自己训练的决策模型 Clef 和 Clef-flash，托管在 Workers AI 上，同时把模型权重以 Apache 2.0 协议开源到了 Hugging Face。它的定位很明确：不做生成，只做判断。

这事的技术含量，得从"决策模型"和"大语言模型"的分工说起。

决策模型到底是个什么东西

平时用的大模型是生成式的：给一段输入，它一个字一个字往外吐，产出自由文本。你要做分类或路由，还得在输出里解析 JSON、处理幻觉、等它把推理 token 跑完。

决策模型的思路反过来。开发者先设定一组可接受的选项（带类型的问题），模型读入输入状态后，直接针对这些选项计算概率并返回，不产生任何自由文本，也没有需要解析的中间过程。比如客服系统收到一条消息，可以一次性问三件事：这条是否紧急、该交给业务还是账务还是技术、严重程度几级。拿到概率后，程序直接分派工单，或者当模型"拿不准"时转人工。

据报道，Cloudflare 这次发布的两款模型参数和底子是这样的：

模型	规模	基座	上下文	价格（每百万输入 token）
Clef	27B	Qwen3.8-27B	64K	0.24 美元
Clef-flash	9B	Qwen3.5-9B	64K	0.09 美元

两款都支持最多 4 张图片输入，接口兼容同类决策模型 Jev 的 API，既有用 Jev 的应用改起来成本较低。

快在哪，准在哪

Cloudflare 自己公布的 43 项评测里，延迟是最扎眼的：

• Clef 中位延迟 209.3 毫秒
• • Clef-flash 中位延迟 38.8 毫秒
• • Jev 中位延迟 524.1 毫秒
    Clef-flash 的中位延迟不到 Jev 的十分之一。官方在部分标准集上也给了准确率对比，例如 BANKING77（宏观 F1）Clef 94.2、Clef-flash 90.9、Jev 79.7；BFCL 上 Clef 98.5、Clef-flash 98.8。

但这里必须泼一盆冷水：这些数据是 Cloudflare 在自家环境里自测的，尚未被第三方独立复现。而且准确度并不是全面领先——云厂商公布的多项指标里，Jev 在个别测试上仍然更高。所以"最快"和"最准"这两个标签，要分开看。

真正让它快的原因不是单纯的模型小，而是非自回归的决策步骤：传统生成式推理要逐步产出文本，决策模型跳过了"生成文字"这个环节，直接对预设答案打分。这一步省下来，就是延迟从几百毫秒掉到几十毫秒的关键。同时因为答案被限制在预设选项里，输出天然"无幻觉"——它没法编出一个你没给的选项。

对开发者和从业者意味着什么

第一，agent 的"热路径"有了更便宜的选择。现在很多 agent 每走一步都要调一次大模型，成本高、延迟高。把"要不要继续""该走哪条路"这类判断前置给决策模型，让大模型只负责真正需要生成和推理的部分，账会好看很多。Cloudflare 官方举的例子是：一个网站分类任务里，Clef 配合 Browser Run 在 2.2 秒完成，而同样的流程用 gpt-oss-120b 要 4.7 秒。

第二，落地成本算得清。0.09 美元/百万 token 的 flash 版本，加上 Apache 2.0 的权重，团队可以先用托管版试，觉得敏感就下载权重自己在边缘或内网跑。

# 权重开源在 Hugging Face，可以直接拉到本地pipinstall-U"huggingface_hub[cli]"huggingface-cli download Cloudflare/clef

第三，别把它当万能药。几个实际的坑：

1. 概率校准比准确率更重要。决策模型输出的是每个选项的概率，你要设"拒判阈值"——低于多少分就转人工。阈值设不好，要么大量误判直接进流程，要么全部转人工、白用。
2. 2. 模型不是越强越好，是越合适越好。毫秒级的 guardrail 检查、边缘网关上的前置筛选，用 flash 更划算；流程复杂、判断维度多、要求准的，再上 27B 版本。
3. 3. 自测数据要留个心眼。上线前一定用自己业务的真实样本跑一轮，别直接拿厂商 benchmark 当预期。客服分流这类场景，准确率差几个点，用户体感差别很大。

收尾

从"什么活儿都丢给大模型"，到"把判断和生成拆开、各用各的模型"，这个分工思路其实挺健康。大模型少空转，成本账比能力账更好看。

不过决策模型这条赛道能走多远，还得看第三方能不能复现出同样的延迟和准确率。你会把 agent 里的判断环节换成决策模型吗？你怎么看，评论区聊聊。