Cloudflare Clef-omni 扩展多模态决策能力，但准确性仍是上限
Cloudflare Clef-omni 于 10 月 9 日推出，在同一决策管线中原生处理音频、视频、图像和文本。该公司还下调了 Clef-flash 的价格，并将托管 Clef 推理速度最高提升 2.0 倍。综合来看，这些变化让这一推出仅一周的模型家族，对开发者当前用于自动化决策的多阶段系统构成了更广泛的挑战。
关键变化不在于又一个模型能够接收媒体输入。通用模型早已具备这一能力。Cloudflare 正将多模态理解打包为一种受约束的决策服务：它为允许的答案返回概率，而不是生成开放式文本。
这一差异使 Cloudflare 同时面对 TypeSafe 的 Jev，以及一种更成熟的架构模式：连接独立的转录、视觉、语言和分类组件。Clef-omni 希望开发者用一次模型调用替代这条链路。该方法承诺减少编排工作，但 Cloudflare 自己的基准测试结果也表明，组件更少并不自动意味着决策更好。
Cloudflare Clef-omni 将四类输入转化为一次决策
Cloudflare Clef-omni 旨在直接评估混合媒体，无需先将每种输入都转换为文本。
该模型接受文本、图像、WAV 或 MP3 音频，以及 MP4 或 WebM 视频。一次请求可组合其中多种输入，并附带一个描述模型必须回答问题的 schema。响应会为允许选项分配置信度，而非撰写叙述性答案。
Cloudflare 以设备检查说明这一模式。开发者可以发送标签照片、机器录音和风扇视频。随后，模型可判断标签是否清晰可见、机器声音是否正常，以及风扇是否在转动。
这一工作流通常需要多个阶段：一个模型转录音频，另一个模型对视频进行采样或生成描述，随后由应用代码整合这些输出。最终的分类器或语言模型再将累积的证据转化为决策。
Clef-omni 则会将媒体映射为一个统一序列。Cloudflare 表示，同步的音频和视觉帧可保留用于联合处理。模型从这一综合表征中为每个有效答案评分，无需生成中间转录文本或字幕。
对于在转换过程中会丢失上下文的信号，这是一项实质性差异。转录文本可以保留说出的词语，却会丢失语气、背景噪声、时间信息以及声音和运动之间的关系。一组视频描述可以说明可见物体，却可能遗漏某个声音是否恰好在机械故障发生时出现。
Cloudflare 基于混合专家基础模型 Qwen3-Omni-30B-A3B-Instruct 构建了该模型。混合专家模型会让不同输入经由选定的参数组处理，而非在每次计算中激活整个网络。Cloudflare 保留了基础模型的理解骨干网络，但移除了其文本转语音输出组件。
随后，该公司冻结了 Qwen3 骨干网络，并训练低秩适配器，即 LoRA 模块。LoRA 会更新一组较小的新增参数，同时保持基础模型的大部分参数不变。Cloudflare 还采用了标签平滑交叉熵训练和 Brier 分数校准，后者用于衡量预测概率与实际观察结果的匹配程度。
这一架构使 Clef 多模态模型不只是一个能够处理媒体的聊天机器人。它是为那些已明确知道需要回答哪些问题的应用而构建的、受 schema 约束的评分器。这一定位也带来了其核心限制：只有当 schema、证据和允许选项能够涵盖真实问题时，系统才能作出有用的决策。
Clef 多模态模型瞄准管线复杂性
Cloudflare 竞争的不只是另一家模型供应商，还包括连接式模型管线的成本与脆弱性。
多阶段媒体工作流会带来运维依赖。语音识别可能因口音或嘈杂录音而失败；视频采样可能跳过相关帧；图像描述模型可能遗漏后来证明重要的细节。最终的决策系统只能看到经过转换的输出，其中包括上游引入的每一个错误。
每个阶段还都有各自的延迟、可观测性、扩展行为和故障响应。开发者必须决定是重试失败的转录、在证据不完整的情况下继续，还是停止整个请求。如果最终决策依赖时序，他们还必须保留时间戳、视频帧和衍生文本之间的关联。
Clef-omni 的直接处理减少了这些交接环节。Cloudflare 表示，托管模型作出纯文本决策的中位延迟约为 130 毫秒。图像请求约需 150 毫秒，而音频输入则需数百毫秒。
在该公司的示例中，一段包含声音的 21 秒视频大约可在 1.5 秒内获得评分。这些是 Cloudflare 的测量结果，并非独立保证。实际延迟将取决于负载大小、网络距离、并发量，以及应用设计问题的方式。
潜在收益依然清晰。支持平台可以在一次请求中评估客户的文字描述、产品照片和语音录音。安全工作流可以结合屏幕截图、口述说明和结构化事件数据。质量控制应用则可以将可见运动与机械声音进行比对。
输出格式与输入格式同样重要。Clef 模型生成受 schema 约束的概率，因此应用无需解析对话式文本便可使用响应。审核系统可以请求一个允许的分类，而路由系统可以为多个目标评分。
这并不会消除应用逻辑。团队仍需要置信度阈值、升级规则、审计记录，以及针对重大情形的人工审核。由于概率分布并不保证正确性，他们还需要为不确定结果制定策略。
更准确的理解是整合。开发者不再需要维护独立的感知和分类阶段，而可以测试一个端点能否覆盖足够多的工作流。即使模型本身并非在每项评估中都表现最佳，这也可能减少基础设施工作。
同样的原则也适用于个人信息工作流。一个整合会议、文档和采集媒体的系统，仍然需要可靠的检索与上下文管理。围绕知识融合构建的工具，体现了更广泛的需求：连接异构信息，而无需强迫用户手动重建上下文。
Cloudflare 的押注是，开发者希望在自动化决策路径中实现类似整合。如果 Clef 多模态模型能保留有用的跨媒体证据，更简单的架构就会成为竞争优势。如果它遗漏领域特定信号，团队即便要承受额外复杂性，也会回归专用组件。
更快的 Clef 推理改变了部署方程
Clef 更新在一定程度上是托管基础设施的故事，其中报告的最大中位速度提升达到 2.0 倍。
Cloudflare 并未为其原始 Clef 模型的更快版本发布新权重。该公司表示，改进主要来自其托管服务层。这意味着自行托管的用户重新下载现有模型，并不会自动获得同样的提升。
对于接近 800 token 的输入，Cloudflare 报告称中位延迟从 262 毫秒降至 152 毫秒。报告中的第 95 百分位延迟从 438 毫秒降至 351 毫秒。这相当于中位值提升了 1.7 倍。
在约 3,400 token 时，中位延迟据称从 616 毫秒降至 305 毫秒。第 95 百分位从 777 毫秒降至 531 毫秒。这是 Cloudflare 报告中中位速度提升最高、达到 2.0 倍的工作负载。
对于接近 16,000 token 的输入，该公司报告中位延迟从 2,721 毫秒降至 1,635 毫秒。其第 95 百分位数值从 3,250 毫秒降至 1,805 毫秒。该规模下的中位改进为 1.7 倍。
这些测量很重要，因为决策模型往往嵌入在另一项操作之中。路由决策可能发生在智能体选择工具之前；安全评分可能阻止内容发布；安全分类可能决定某个事件是否获得即时关注。
处于这些位置的延迟会不断累积。一个在智能体循环中反复调用模型的应用，可能将数百毫秒的延迟累积为明显等待时间。长尾延迟同样重要，因为用户体验到的是缓慢请求，而不只是中位请求。
Cloudflare 将部分 Clef 推理速度提升归因于迁移至 SGLang——一个面向语言和多模态模型的开源服务框架。Cloudflare 与该项目合作，通过上游 SGLang contribution 增加了对 Clef 的支持。
这一合作的重要性超出了托管服务本身。它为自行托管者提供了受支持的服务路径，尽管其结果会因硬件和配置而异。这也表明，模型性能不能脱离推理软件单独评估。
更快的托管模型强化了 Cloudflare 的平台论点。使用 Workers AI 的开发者可在同一供应商体系内结合模型执行、应用代码和 AI Gateway 控制。更低的延迟降低了在现有 Worker 中插入决策步骤的代价。
然而，基础设施优化并不会改善模型判断。半时间返回的错误答案依然是错误答案。因此，开发者应将评估拆分为两个问题：Clef 是否满足其准确性和校准需求，以及 Cloudflare 的服务层是否达到其延迟目标。
这一区别可避免标题式的速度提升掩盖应用风险。快速审核模型可以处理更多内容，但也可能扩大误报；快速路由模型可以加速智能体，但不佳的置信度估计可能让更多请求被导向错误工具。
更便宜的 Clef-flash 伴随着更小的托管上下文
Cloudflare 通过接受一项明确的产品取舍降低了 Clef-flash 的成本：其托管上下文窗口如今大幅缩短。
该公司表示，Clef-flash 现在比 Jev 更便宜，后者是其最直接的决策模型对标对象。具体商业价格可能变化，因此买家应查阅当前文档，而不应将发布公告视为永久价格表。
更持久的事实是上下文缩减。托管 Clef-flash 先前宣称拥有 64,000 token 的窗口。现在，它通过 Workers AI 最多接受 24,000 token。
Cloudflare 表示，仅有 0.24% 的观测到的 Clef-flash 请求超过了新上限。基于这一使用情况，该公司选择降低托管上限并减少服务成本。更大的 Clef 模型仍保留 64,000 token 的托管上下文。
可下载的 Clef-flash 权重未发生变化。Cloudflare 表示，这些权重在自托管时支持 256,000 token 的上下文。这使模型的理论能力与托管产品配置的限制之间形成了明显差异。
对于许多分类任务而言，24,000 token 依然足够。客户工单、政策节选、事件摘要或较短的 agent trace 都能轻松容纳。但处理长文档、延展 trace 或大量证据集合的团队，必须围绕这一新边界进行规划。
他们可以截断输入、对其进行摘要、仅检索相关段落、使用更大的 Clef 服务，或自托管 Clef-flash。每种选择都会改变系统。截断可能移除决定性证据，而摘要则可能引入另一个模型和新的错误来源。
检索可以控制输入规模，但结果会取决于检索层选择了哪些内容。自托管能够保留更多上下文，但也会增加容量规划、更新、安全工作和推理工程方面的负担。
因此，更便宜的 Clef-flash 并不只是一次简单的降价。Cloudflare 正在针对其目前观察到的绝大多数请求进行优化。输入异常长的客户则需要通过迁移或架构调整承担相应成本。
这一决定也进一步明确了该系列的定位。Clef-flash 面向上下文相对受限、需要高频且低延迟决策的场景。完整版 Clef 处理更大规模或要求更高的案例。Clef-omni 则针对决定性信息跨越文本、音频、图像和视频的工作流。
分层路由模式自然随之而来。应用可以先使用 Clef-flash，再将较长或不确定的案例升级交给另一模型。不过，这一模式需要谨慎校准。在通用基准上看似合理的置信度阈值，可能会在企业自身数据上表现不同。
开发者应使用完整的生产样本测试上下文限制，而不是只看平均输入长度。少数超过 24,000 token 的请求，也可能恰恰是缺失上下文会造成最大损害的复杂请求。
Cloudflare Clef-omni 仍面临准确性考验
Cloudflare 公布的结果显示该模型能力不俗，但并未表明它在所有任务或模态上都是通用赢家。
在 Cloudflare 的基准测试集中，Clef-omni 在多项偏文本的评估中取得了较强结果。它在 BFCL case exact match 上达到 98.2，在包含范围外示例的 CLINC150 上取得 97.7 的 macro-F1。在 BANKING77 上，它也取得了 94.8 的 macro-F1。
不过，该模型在若干测试中落后于 Clef 系列的另一成员。完整版 Clef 在 ToolRet、家电决策、When2Call、BRIGHT 和 PhishNChips 上得分更高。Clef-flash 则在 BFCL、API-Bank 和家电评估中领先。
Jev 也仍保有优势。Cloudflare 的表格显示，Jev 在 When2Call 和 BRIGHT 上领先。这些结果表明，输入覆盖范围更广并不自动意味着更优。
类似的混合表现也出现在工作流评估中。在公开的 decision model evals 中，Clef-omni 在发票处理上落后于完整版 Clef；在客服精确操作和 agent-trace 主操作上，也落后于 Clef-flash。
在安全事件场景中，Clef-omni 在精确操作上与 Clef-flash 和 Jev 持平，但低于完整版 Clef。这些差异很重要，因为商业工作流通常需要组合多个正确选择。模型可能正确选出主要操作，却遗漏影响合规或后续处理的次要操作。
这些基准对新模态的证据也较为有限。许多列出的评估集中于文本分类、检索、工具使用或结构化工作流。它们并未证明 Clef-omni 在多样化生产环境中，能够多可靠地跨同步语音、声音、运动和图像进行推理。
Cloudflare 报告了多模态延迟，但发布材料并未对音频和视频准确率提供同样详细的公开拆解。对于嘈杂录音、多位说话者、镜头运动、压缩视频、重叠声音，以及跨模态证据相互冲突等问题，仍存在疑问。
这一验证缺口应影响采用决策。评估工厂检查的团队，应创建包含正常和异常声音的案例，并加入符合现实条件的背景噪声。支持组织则应测试不同口音、设备麦克风以及不完整的客户录音。
安全团队应分别衡量误报和漏报。单一准确率分数可能掩盖一种偏向最常见类别、因而看似表现良好的系统。校准同样值得测试，因为下游自动化往往依赖置信度数值是否对应真实错误率。
Cloudflare 快速的开发节奏提升了独立评估的必要性。该公司表示，最初的 Clef 项目从内部决策到发布不足一周。迭代速度令人印象深刻，但不能替代广泛的外部测试。
开放权重有所帮助。研究人员可以复现测试、检查行为，并比较自托管结果与 Workers AI 的表现。但开放获取并不会让基准变得中立。所报告的数据仍取决于 Cloudflare 对模型、提示词、基础设施和指标的选择。
最稳妥的结论比发布时的表述更为收敛。Cloudflare Clef-omni 为多模态决策提供了可信的单次调用架构。它是否能改善真实工作流，取决于发布基准尚未提供的领域证据。
开发者接下来应关注什么
下一阶段将由独立多模态测试、生产采用情况和竞争对手反应决定，而不是功能清单。
第一个信号是评估覆盖范围。开发者应关注那些要求同时使用音频和视频证据的公开测试，尤其是在这些信号相互矛盾时。有价值的基准应测试模型能否注意到：可见的机器运行正常，但音频却揭示了间歇性故障。
这类结果将强化 Cloudflare 的说法，即统一管道能保留转录和字幕处理中丢失的信息。疲软的结果则可能表明，原生输入虽然方便，却未必比专业组件更准确。
第二个信号是生产环境表现。Cloudflare 已描述了内部 Clef 部署，用于关闭垃圾信息问题、审核插件库中的钓鱼内容、识别可能的个人信息，以及检测恶意域名。这些案例涉及影响重大的分类，但主要证明了使用情况，而非经过衡量的可靠性。
开发者需要错误率、校准结果、升级处理模式，以及持续流量下的尾延迟数据。他们还应关注团队是否将 Clef-omni 用于真正跨模态的决策，还是主要把它作为另一种文本和图像评分器。
第三个信号是竞争对手的反应。Jev 仍是最直接的对比对象，因为 Clef 支持其 API 形式，且 Cloudflare 多次以其作为基准对手。兼容性降低了切换阻力，因此 TypeSafe 必须通过准确率、经济性、延迟或专业化工具来捍卫自身位置。
通用多模态模型提供商同样重要，即使它们并不将自身系统定位为决策模型。结构化输出、受约束解码和专用分类端点，能够缩小运营层面的差异。在领域准确率比管道简洁性更重要的场景中，专业音频和视觉系统仍会保持吸引力。
对开发者而言，实际的下一步是使用真实示例进行受控评估。将统一模型与现有管道进行比较，再衡量完整操作准确率、校准、延迟和故障处理。应纳入少见的长输入和低质量媒体，因为平均值往往掩盖了决定运营风险的案例。
不要先问模型是否理解四种模态。应先问：它能否基于这些模态，以可接受的错误率做出正确且有边界的决策。然后测试它在不确定、接收到相互矛盾的证据，或超过托管上下文限制时会如何表现。
Cloudflare 让这项实验更容易开展，但并没有消除开展实验的必要性。Cloudflare Clef-omni 的价值最终取决于更简单的架构能否经受杂乱生产数据的检验，而不是某个端点是否能在技术上接受所有文件类型。
