Cloudflare于2026年10月1日开源并发布面向结构化决策的Clef与Clef-flash模型，支持在Workers AI部署并在Hugging Face以Apache 2.0许可证放出权重。两款模型以返回概率化的结构化判断为主，适用于客服分流、威胁情报和信任审核等场景，同时Cloudflare推出了针对Clef的RL微调服务和边缘推理部署方案。
Cloudflare于2026年10月1日发布两款面向结构化决策的模型Clef和Clef-flash，并将它们部署到Workers AI。公司同时在Hugging Face开放模型权重，采用Apache 2.0许可证，允许开发者下载后在本地运行和实验。
与主要负责生成文本的通用大语言模型不同，决策模型接收一段状态信息和一组预先定义的问题，直接为每个可能答案返回概率。Cloudflare表示，这类输出可以被软件用于客服分流、威胁情报、信任与安全审核，以及智能体在调用工具前的权限或风险判断。
这次发布也意味着Cloudflare开始正面进入由TypeSafe AI的Jev推动的一个细分领域：让模型成为软件系统中的判断模块，而不只是面向人的聊天界面。
两款模型面向不同的延迟需求
Cloudflare称，Clef是一个270亿参数的多模态模型，基于Qwen3.8-27B进行后训练；Clef-flash则是90亿参数版本，基于Qwen3.5-9B，主要面向对延迟更敏感的场景。两款模型都支持视觉输入，并提供64K上下文窗口。
在模型卡中，Cloudflare描述的输入可以包括文本、JSON、图像和视频。模型输出不是一段需要再次解析的自由文本，而是围绕问题类型给出结构化结果。当前支持的主要问题包括“是或否”的判断、从多个选项中选择一个答案，以及按照有序标准进行评分。
这套接口与TypeSafe AI的Jev及System One API兼容。Cloudflare在开发者文档中表示，已有Jev集成的开发者可以通过更换端点和模型名称来试用Clef。对于部署在Workers上的应用，模型可以通过Workers AI绑定或REST API调用。
Cloudflare还把Clef与自己的边缘网络结合起来。公司的说法是，运行在Workers AI上的请求可以利用分布在网络各处的GPU，缩短用户与推理服务之间的网络往返时间。在这一架构中，Clef负责快速判断，另一个大语言模型则可以继续承担复杂推理、文本生成或工具执行任务。
Cloudflare公布的速度和评测结果来自公司测试
Cloudflare在官方公告中披露，基于43项评测运行，Clef的中位延迟为209.3毫秒，p95延迟为238.6毫秒；Clef-flash的中位延迟为38.8毫秒，p95延迟为122.4毫秒。作为对比，Jev的中位延迟为524.1毫秒，p95延迟为536.0毫秒。
在Cloudflare发布的10项决策基准中，至少有一款Clef模型在其中7项取得最高分。官方列举的结果包括：在BANKING77宏平均F1指标中，Clef得分为94.2；在CLINC150+OOS中，Clef得分为97.4；在BFCL案例精确匹配指标中，Clef-flash得分为98.8；在家电模拟器测试中，Clef-flash得分为97.7。
Cloudflare还引用Typesafe的工作流评测，称Clef在发票处理、客户服务和安全事件三个领域的精确行动指标上超过Jev；在代理轨迹可观测性测试中，Jev仍然领先。Hugging Face上的两个模型卡保留了更完整的评测表，并明确说明这些结果来自Cloudflare的内部运行。
这些数据不能直接视为独立第三方结论。基准的任务设计、数据版本、运行环境、模型配置和成本计算方式都会影响结果。尤其是延迟数据，既反映模型本身，也反映了Cloudflare对推理服务和边缘部署的调优。开发者在真实业务中仍需要用自己的数据测试准确率、概率校准、失败样本和端到端延迟。
此前，AIFlux曾报道TypeSafe AI推出Jev并尝试把模型从聊天带入软件系统；Cloudflare的Clef正是在相近的“类型化决策”方向上提供了一个可托管、也可本地运行的替代方案。
从分类模型到智能体控制层
Cloudflare给出的例子是客服工单分流。系统可以先判断请求是否紧急，再判断应由账单、技术或销售团队处理，并对客户影响程度进行评分。下游程序可以根据这些概率决定自动转派、升级处理，或者在结果不确定时交给人工审核。
在威胁情报场景中，Cloudflare表示，其团队曾将Clef与Browser Run结合，用于识别网站域名类别。官方文章称，从抓取和渲染网页到完成分类，该流程耗时2.2秒；同一工作流中，gpt-oss-120b耗时4.7秒。不过，这仍然是Cloudflare内部场景下的比较，不能据此推断所有网站分类或安全任务都能得到同样结果。
这种设计也把模型的作用从“回答问题”转向“决定下一步”。当模型输出带有概率时，开发者可以设置阈值：高于阈值的结果自动执行，接近边界的结果转交人工，低于阈值的结果则拒绝或进入另一条流程。概率是否经过良好校准，将直接决定这种自动化机制是否可靠。高置信度的错误判断，可能比明确返回“不确定”更危险。
因此，Clef更适合被看作智能体系统中的一个控制层组件，而不是通用大语言模型的替代品。它可以在调用外部工具、路由请求或触发高风险操作前增加一道快速判断，但权限、审计、回滚和人工复核仍需要由外围软件负责。
Cloudflare近期还在AI Gateway中测试Auto Router，尝试让网关根据请求类型、复杂度、风险和成本自动选择模型。这个自动路由项目与Clef结合后，可能形成从请求分类、模型选择到最终执行的完整控制路径，但两者目前仍需分别评估，不能把产品愿景当成已经验证的系统能力。
RL微调服务仍处于早期阶段
除模型发布外，Cloudflare还推出了面向Clef的强化学习微调服务。公司计划先通过一支前置工程师团队，与客户合作收集场景数据、调整模型，再逐步建设自助式平台，让客户能够捕获请求、训练模型，并将微调后的版本重新部署到Workers AI。
Cloudflare列出的技术组件包括AI Gateway、Workers AI、用于强化学习沙箱的Cloudflare Containers，以及一个新的Trainer组件。公司设想，AI Gateway可以积累客户自己的请求和响应数据，Containers负责回放和评分，Trainer则用于更新微调模型的权重。
这一产品方向针对的是通用模型难以覆盖的具体分类任务。例如，客户可能希望模型按照自身的信任与安全政策审核内容，或者根据多年积累的标注数据处理客服请求和机器人流量。针对单一领域微调模型，可能提高准确率和速度，但也可能牺牲一部分通用能力，并带来数据质量、分布变化和持续校准的问题。
Cloudflare目前把这项服务定位为设计合作伙伴项目，而不是已经全面开放的自助产品。客户是否能够获得稳定的业务收益，以及微调后的模型在新数据和边界案例中的表现，仍需要后续披露和独立测试确认。
开源权重扩大了试用范围，也把验证责任交给开发者
Clef和Clef-flash的Apache 2.0授权以及Hugging Face发布，使开发者不必只能通过Workers AI试用。Cloudflare的模型卡提供了本地加载示例，说明模型可以在配备足够显存的设备上运行；官方测试环境使用单台H200，并依赖PyTorch、Transformers和图像处理库。
这种托管与本地并行的发布方式，降低了开发者验证接口和模型行为的门槛，也让企业可以比较边缘托管、本地推理与其他模型服务之间的成本和延迟。但开放权重不等于已经完成生产级验证。开发者还需要检查许可证与基础模型的关系、硬件需求、输入限制、视觉和视频处理成本，以及模型概率是否适合自身的风险阈值。
目前可以确认的是，Cloudflare已经发布Clef和Clef-flash，将它们放入Workers AI，并在Hugging Face以Apache 2.0许可证开放权重。至于模型在不同业务领域中的真实准确率、客户采用规模和商业结果，Cloudflare此次公告并未提供独立第三方证据，仍应等待后续评测和客户披露。