Clef：Cloudflare 的 27B 决策模型究竟是什么

Clef是一个由 Cloudflare 发布的、拥有 270 亿参数的多模态决策模型。你给它一个状态——一个字符串、一个 JSON 对象、一张图像、一段视频片段——再加上一个最多包含 64 个带类型问题的 schema，它就会在单次前向传播中为每个问题的每个允许选项返回一个概率。整个流程中没有任何文本生成，也没有输出解析：模型为每个允许选项输出一个 logit，你按问题做 softmax，然后就完成了。权重采用 Apache-2.0 许可，位于 Hugging Face 上的 Cloudflare/clef仓库中；Cloudflare 还通过自己的 Workers AI 平台提供该模型。

有两个日期对定位很重要，但它们都不是这个页面存在的原因。权重发布于 2026 年 9 月 30 日，Cloudflare 的公告文章日期是 2026 年 10 月 1 日，也就是说在撰写本文当天，Clef 已经问世十二天了——久到算不上新闻，而本页面也不把它当作新闻来对待。它之所以存在，是因为“clef”是人们真的会输入的查询词，而在此之前，这个博客上没有任何内容回答过它。这次发布只是用来给这个模型标注日期；下面这些参考资料才是重点。

尺寸问题，由出版商一锤定音

有两个参数量正在一起流传，而其中只有一个属于这个模型。

• Clef 是 27B。Cloudflare 自己的模型页面将其描述为“一款 27B 多模态决策模型”，Hugging Face 上的模型卡在开篇也这样写道：“Clef 是一个 27B 多模态模型，可将状态和带类型问题的模式转化为决策。”

• 9B 是另一个模型，而不是这个模型的第二个尺寸。 9B 检查点是 Clef Flash，它是一个独立的姊妹模型，拥有自己的仓库和自己的模型页面。凡是搜索 9B Clef 的人，要找的其实都是 Clef Flash。二者不能互换，数据也不能通用。

• 还有第三个成员。Clef Omni 于 2026 年 10 月 9 日发布，是一个 30B 的混合专家模型，拥有 3B 激活参数，基于不同的骨干网络构建。它同样能读取音频。如果你见过 "30B" 与 Clef 一同出现，那指的是 Clef Omni，而不是 Clef。

所以这个页面上模型的规模是 27B，就这样，仓库以 BF16 safetensors 格式发布它。发布出来的文件集总共约 55 GB，分布在二十五个文件里——如果你打算自行托管而不是直接调用，那这个数字才是关键。

Clef 与 Clef Flash 有何关联

Cloudflare 将 Clef 作为一个系列推出，而真正有用的部分正是这个系列结构，而非附带说明。Clef 和 Clef Flash 共用同一套配方：为较大的模型冻结一个 Qwen3.8-27B 主干，为较小的模型冻结一个 Qwen3.5-9B 主干，保留视觉编码器，并在其之上训练一个小型联合 schema 头，外加低秩适配器。相同的输出契约，不同的容量，以及截然不同的延迟表现。

那个共享契约正是两个模型值得放在一起理解的原因：为其中一个编写的 schema 就是为另一个编写的 schema，而切换由哪个模型作答只需改一个模型标识符，无需重写。权衡在于速度与能力之间，而 Cloudflare 自己在 10 月 9 日的博文通过将 Clef Flash 的托管价格降至每百万输入 token 0.038 美元、同时将 Clef 保持在每百万输入 token 0.24 美元，使这一取舍更加鲜明。注意那篇博文还做了另一件事：它把 Clef Flash 的托管上下文窗口从先前宣传的 64,000 token 缩减到 24,000 token，而 Clef 本身则保持在 64,000。

架构：冻结的骨干网络加一个评分头

Clef 不是一个戴着分类器帽子的语言模型。这个设计值得精确说明，因为它解释了该模型几乎所有其他特性。

• 主干网络 — 包含其视觉编码器的 Qwen3.8-27B，直接沿用并冻结，以普通分片式 safetensors 格式存储。

• 联合模式头——一个小型 Transformer 头，读取主干的最终隐藏状态，将证据从该状态路由到每个问题，并对所有问题的所有选项进行联合评分，而不是一次只处理一个问题。

• 训练 — 秩为 256 的低秩适配器、标签平滑交叉熵，外加用于校准的 Brier 损失，以及 Cloudflare 的“校准决策强化学习”循环。

• 输出 — 每个问题、每个允许选项对应一个 logit。对每个问题做 Softmax 即可得到概率。除此之外不会输出任何内容。

联合评分是让 Clef 区别于一堆独立分类器的关键所在。由于所有问题都在一次前向计算中针对同一个隐藏状态进行评分，问题之间可以相互提供信息，而且整个过程是非自回归的——不存在解码循环，延迟数据正是由此而来。Cloudflare 将这种推理描述为仅预填充（prefill-only）的单次前向计算。

上下文、限制以及输入内容

在上下文和模态方面，供应商的材料是具体的，而凡是它保持沉默之处，这种沉默值得记录，而非粉饰掩盖。

• 上下文窗口——根据模型页面，在 Cloudflare 托管的 Workers AI 端点上为 65,536 个 token。这个数字正是 Cloudflare 的发布文章拿来与它归因于 TypeSafe 的 Jev 的 32,000 个 token 窗口作对比的数值。

• 自托管上下文——Cloudflare 10 月 9 日的文章称，如果你自行运行，Hugging Face 上的权重经过训练可支持 256,000 个 token 的窗口。该仓库中捆绑的编码器默认设置为max_length=16,384，这只是一个默认值，而非上限，但如果你按原样使用该加载器，得到的就是这个值。

• 最大输出 — 未公布。没有可公布的 token 预算：模型对每个问题返回一个固定的概率向量，因此自然的限制是 schema（1 到 64 个问题，每个问题 2 到 26 个选项），而不是以 token 计的长度。

• 输入模态 —— 文本、JSON、图像和视频。Workers AI 页面将视觉标记为受支持，并接受 PNG、JPEG 或 WebP 图像，每次请求最多四张。另外，Clef Omni 增加了音频；Clef 本身则没有。

• 输出模态 — 概率。Clef 无法起草回复、总结会话串，也无法生成句子，而且它不会编造你未声明的类别。

• 许可证 — Apache-2.0，沿用 Qwen3.8-27B 基础检查点。Cloudflare 的模型页面链接到许可证文件，而非在页面文字中指明其名称；该许可证文件本身即为 Apache-2.0。

有一个实现细节被记录为一个陷阱，这一点值得反复强调：confidence 字段报告的是概率的集中程度，而不是答案正确的概率。一个校准良好的模型可能返回低置信度的正确答案，也可能返回高置信度的错误答案。

Cloudflare 声称的，与实际测量到的

这是需要仔细阅读的部分，因为标题两半之间的间距很大。

与 Clef 相关的每一项性能数据都来自 Cloudflare。模型卡发布了一张四十多行的表格，其来源被描述为“我们内部运行的 Decision Index 0.2.1 套件”，而该排行榜由 Cloudflare 托管。其下方的工作流评估取自 TypeSafe 的公开评估集，但这次运行仍然是 Cloudflare 的。截至今天，我找不到对这两张表中任何一张的独立第三方复现——没有外部实验室，没有中立的排行榜，也没有已发表的复现。把这些数字当作供应商的最佳情况，而不是实测结果。

这些数字背后的模式比任何单个单元格都更能说明问题。Clef 最强的结果出现在分类类任务上：在 Cloudflare 的测试中，它在 BANKING77 意图上报告了 94.2 的 macro-F1，而 Jev 为 79.7；在带范围外处理的 CLINC150 上为 97.4 macro-F1，而后者为 89.3。范围外这一数字在运营层面才是有意思的那个，因为拒绝分类是路由中困难的那一半。它还报告了 BFCL 上的 98.5 case-exact 以及 CRUXEval 上的 86.7。

这些落后之处始终指向同一个方向。在同一张表中，Clef 报告 GPQA Diamond 为 48.0，而 Jev 为 78.3；MMLU-Pro 为 65.9，而 Jev 为 82.7；BBH 为 73.7，而 Jev 为 92.9。这三项是表中最大的差距，且都说明了同一个弱点：在模型训练所覆盖的形态之外进行推理。在四项端到端工作流评估中，两个模型足够接近，因此其排序算不上一个发现。

延迟是唯一一个优势属于结构性而非边际性的地方，因此也最有可能在接触生产环境后依然成立。Cloudflare 报告称，Clef 的中位数为 209.3 毫秒、p95 为 238.6 毫秒，而 Jev 为 524.1 毫秒和 536.0 毫秒。这种排序源于非自回归设计，而不是某个基准测试的偶然特性——但这些绝对毫秒数是在 Cloudflare 自己的硬件上测得的，单看它们本身意义不大。

对于已经在本博客上读过 Clef 基准测试表的任何人，有一点值得注意：服务相关数字在 10 月 9 日发生了变化。Cloudflare 将 Clef 的 serving 迁移到了 SGLang，并将这项工作贡献到了上游，报告称在约 800 个输入 token 时中位加速为 1.7 倍，在约 3,400 个 token 时中位加速为 2.0 倍。这些是服务层的改动，而不是新的权重，模型本身没有变化。如果你引用的是 10 月 9 日之前的延迟数据，那它已经过时了。

致电 Clef，并妥善处理与 Cloudflare 的关系

运行它有两种方式，而且这两种都不神秘。

第一个是 Cloudflare 自己的端点。Clef 由 Workers AI 提供服务，这是 Cloudflare 自家的推理平台，每百万输入 token 收费 0.24 美元，输出 token 不收费——这是因为根本没有输出 token。媒体输入会被转换为 token，并按相同的输入费率计费。这是发布方在托管自己的服务，而这就是全部关系：那些把这款模型名称与 Cloudflare 配对的搜索，指向的是一个恰好添加了它的第三方托管方。Cloudflare 构建了它。

第二项是你自己的硬件。权重以 Apache-2.0 许可在 Hugging Face 上发布，因此允许自托管，无需商业洽谈。Cloudflare 自己的测试在单台 H200 上使用了 torch 2.11 和 transformers 5.10.2，图像和视频输入还需要 pillow。如果你读到 Clef 也能在 SGLang 上运行，截至 10 月 9 日的服务变更，这一说法是准确的；上游相关改动计划在 SGLang 0.5.22 中发布。

这套 API 的形态是刻意不追求新意的。Clef 的请求体与响应体同 TypeSafe 的 SystemOne 格式兼容，所以，一条已经接上那种形态的决策模型的流水线，只要改一个 URL 和一个模型字符串，就能指向 Clef。这是一条实打实的切换成本论据，而它是双向的——这才是诚实的读法：正因为接口相同，接入 Clef 很便宜，放弃它也同样便宜。对于已经有决策端点跑在生产环境的团队而言，明智的姿态是让两者都跑你自己的流量，而不是去做迁移。如果你经由 OrcaRouter 路由，TypeSafe 的 Jev 1.13 是我们目录上的在列模型，那么现有方案与你自托管的任何方案之间的 A/B 测试，就落在同一把密钥之下，而不是两份合同——200 多个模型，按供应商标价原样透传，不按 token 加价，并且故障转移由我们替你处理。

本页不会告诉你的一件事是，Clef 是否可以通过我们获取。Cloudflare 在 Workers AI 和 Hugging Face 上发布了它，而我尚未核实通过我们自己的模型列表的途径，因此没有什么可宣称的。

还有什么仍未解决？

对 Clef 来说，最有用的一件事就是由外部对 Decision Index 进行复现。该测试套件是公开的，而 Cloudflare 称这些评测可复现，因此第三方运行结果就是厂商表格与事实之间的差别。在这一点实现之前，对 Clef 已发布概况的诚实总结是：它是一个非常强的受限分类器，采用快速的非自回归设计，但作为通用推理器，它比作为基准与之比较的那个模型要弱得多。

有三件具体的事会改变这种解读。对 BANKING77 和 CLINC150 范围外数字的中立复现，因为相较现有方案三十个百分点的差距要么就是全部真相，要么就是人为造成的假象。真实并发下的 p95 指标，因为在单块 H200 上测得的 209 毫秒中位数，说明不了负载下热路径的任何情况。以及一个经过微调的 Clef，在基座模型从未训练过的任务上击败基座模型——Cloudflare 的 RL 微调平台正是为产出这样的结果而设计，但尚未用客户结果证明这一点。

在那之前，读者所能依赖的是这件事的形态：27B 参数、一个冻结的 Qwen3.8-27B 主干及其视觉编码器、一个联合 schema 头、65,536 个 token 的托管上下文，输入文本、JSON、图像和视频，输出概率，Apache-2.0。这足以判断该架构是否适合你的问题。它尚不能回答的问题是，厂商自己的评分板对该模型的判断是否正确，而 Cloudflare 之外无人核实过。