先看证据

总参数30B,活跃参数3B关键事实
Workers AI上下文窗口64,000 tokens关键事实
最多4图、4段音频、2段视频关键事实
视频最长60秒,按每秒2帧采样关键事实
文本中位延迟约130ms,图像约150ms关键事实
21秒带声音视频约1.5秒关键事实

把机制串起来

输入先把素材压到可处理的规模

传统生成模型会续写一段文本,决策模型则接收预先定义的问题和答案选项,直接为每个选项输出概率,方便程序据此路由或采取动作。概率还要看校准:模型报出的 0.8,长期来看应接近八成正确;Brier 分数用预测概率与实际结果的平方误差衡量这一点。多模态联合输入的价值在于让问题答案同时依据文字、画面和声音,而不是把转写或图像描述当作必经中间结果。

机制再把计算集中到关键步骤

调用者把文本情境、媒体输入和 `noul`(是/否)、`choice`(选项)或 `score`(有序评分)问题放在一次请求中;模型对每个合法答案给出概率,因此输出空间由 schema 限定。推理时先对完整多模态输入做一次 prefill,把音频与视频帧同步放进同一序列,再由联合 schema head 汇总证据并给选项打分;文章还描述了候选答案证据向量与字段向量跨注意力读取上下文。这样省去了“先转写、再推理”的串行环节,但同步处理并不等于所有模态都理解准确,也受输入长度与媒

结果最后落到可验证的工作结果

['适合多模态分类、意图识别及固定选项路由', '音视频可同次提交,省去独立转写与描述调用', '高难推理或精确工作流优先实测文本版 Clef、Jev', '留意每次最多4图、4段音频、2段视频等输入限制']

变化不在“看懂一切”,而在接口少了一道转换

Cloudflare于2026年10月9日发布Clef-omni,这是Clef决策模型家族中面向文本、图像、音频和视频输入的开源权重模型。它针对的是多模态应用里常见的一段工程链路:先把音频转成文字、把视频抽成字幕或帧描述,再把这些结果交给模型判断。Clef-omni试图让开发者把媒体和问题一起提交,在一次请求里得到结构化决策。

这项变化值得读,不是因为“一次调用”本身就证明模型理解能力更强,而是因为它重新划定了应用层的工作边界。过去,开发者要维护转录、描述、对齐和后续分类等环节;现在,其中一部分可以交给同一个模型入口处理。代价是输出仍受预设问题与候选答案约束,减少的是串联步骤,不是所有任务都能被模型接管。

它把输入变成问题,把回答变成概率

Clef的核心不是自由生成一段文字,而是让调用方提交情境和问题 schema。问题可以是二元判断 `noul`、从给定选项中选择的 `choice`,或按序评分的 `score`;模型为允许的答案返回概率。这个设计让下游程序不必再从一段自然语言里猜测模型到底选了什么,也更容易把结果接入分类、路由或审核逻辑。

Clef-omni以Qwen3-Omni-30B-A3B-Instruct的理解部分为基础,采用视觉和音频编码器;模型卡称,语音输出相关权重虽在文件中,但推理时不加载。Cloudflare描述的路径是对完整输入做一次 prefill,让媒体进入同一序列,再由联合 schema head 对候选答案打分,音频与视频帧也会同步处理。训练方面,Cloudflare称冻结了主干、训练LoRA适配器,并结合标签平滑交叉熵和Brier score校准;公开资料没有给出足以评估训练数据来源、规模和完整配方的信息。

固定 schema 是效率来源,也是能力边界

这种接口最适合问题事先能说清楚的工作:这段客服音频属于哪个意图、视频里是否出现某个事件、这张图是否符合给定类别。它把“理解媒体”和“按业务规则作答”收进一条模型路径,减少中间文本可能带来的信息损失,也省去开发者维护部分转换组件。对已有分类或路由系统而言,关键变化是可把多种媒体作为同一决策请求的输入,而不是先强行转成文本。

但 schema 同时规定了模型能回答什么。面对没有覆盖的情况,模型不能通过开放式解释补足问题定义;候选项、问题措辞和业务阈值仍要由系统设计者负责。概率输出也不自动等于可靠置信度,尽管Cloudflare报告使用Brier score做校准训练,实际应用仍需针对自身数据检查概率是否可用,特别是错误决策会触发后续动作时。

基准显示它擅长分类,不代表擅长复杂流程

Cloudflare公布的内部 Decision Index 结果呈现出明显分化。Clef-omni在BANKING77意图分类上取得94.8 macro-F1,在CLINC150+OOS上取得97.7,并在Amazon ESCI上报出57.8;但在Home appliance simulator的case-exact accuracy只有69.3,低于同一对比中的Clef-flash 97.7。它在When2Call上为63.3,也低于Jev的80.97。不同任务的指标不可简单横向折算,但这些差距足以提醒读者:多模态输入覆盖面,不等于复杂工作流判断更强。

在TypeSafe的工作流评测中,Clef-omni在公开列出的五项指标上均低于Clef。Cloudflare还报告,文本决策中位延迟约130毫秒、图像约150毫秒,带声音的21秒视频约1.5秒;这些数字来自厂商材料,公开信息不足以独立复现完整测试条件。与其把这些结果读成全面胜负,不如把它们视为适用性线索:意图分类一类的清晰任务值得重点评估,复杂推理和多步骤工作流则不能仅凭“全模态”标签推定表现。

部署前先核算媒体限制与错误成本

在Workers AI上,Clef-omni的托管输入价格为每百万token 0.15美元,媒体输入也按输入token计费,且不收输出token费用。每次请求最多包含4张图、4段音频和2段视频;视频最长60秒、按每秒2帧采样,音频与视频合计解码大小上限为16 MiB,远程URL不接受。文档还标明64,000 token上下文。对成本和延迟的估算因此不能只看文本token,还要把媒体解码、采样和业务请求规模纳入测试。

Clef-omni是Apache-2.0开源权重模型,Cloudflare称曾在单张H200上以bfloat16运行,主干约需64 GB显存;这说明自托管不是零成本的替代路径。另一个需要谨慎处理的细节是参数口径:官方文档称模型为30B-A3B,Hugging Face页面另有35B参数元数据字段,公开材料没有解释两者如何对应。技术负责人可以把它纳入候选方案,但应先用真实媒体样本、明确的schema和可接受的错误成本做小规模评估,再决定是否让它承担生产决策。