Clef 家族：Workers AI 上的决策模型（Clef、Clef-flash、Clef-omni）

AI 参与说明（Agent：Grok）：本文由 Grok Bot 根据 Cloudflare 官方 Changelog（2026-10-01 / 2026-10-09）、Workers AI 模型页与定价页、Cloudflare Blog 公告与 Hugging Face 模型卡整理。资料核对日期为 2026-10-12。文中未调用 Workers AI 做实测；延迟与基准数字均引自官方材料，并标明互相冲突或未独立复现之处。执行入口 Grok Bot；模型标识与 reasoning effort 未取得运行记录；提供方 xAI。

Clef 是 Cloudflare 在 Workers AI 上推出的决策模型产品线，不是用来写文章的大语言模型。 你给它一段状态（state）和一组类型化问题（questions），它为每个允许的选项打分并返回概率，调用方可以直接路由、拦截或升级人工。2026-10-01 先上线 Clef 与 Clef-flash；2026-10-09 补上 Clef-omni，并把托管版 Clef-flash 降价、把托管版 Clef 提速。

本文先讲整条产品线共用的原理与 API，再逐项对照三个模型的模态、上下文、定价与官方延迟声明，最后说明个人站点或 Workers 栈怎样选、值不值得试。

产品线：决策模型在 Workers AI 上解决什么

和 LLM 的分界

A decision model scores every allowed answer in one pass; it does not generate free-form text. 没有「先写一段分析再自己解析 JSON」的步骤，也没有 reasoning token 要等。选项集合事先定好，模型只在选项上分配概率。

典型用法：工单是否紧急、该派给哪个团队、用户提交是否触碰策略、Agent 在调工具前问一句「该不该做」。Cloudflare 把这类模型放进 Workers AI binding，让决策可以落在请求路径上，再交给 LLM 去做需要生成文本的步骤。Changelog：Introducing Clef

三个模型各管什么

权重均以 Apache-2.0 在 Hugging Face 开源（Cloudflare/clef、Cloudflare/clef-flash、Cloudflare/clef-omni）。托管侧通过 env.AI.run() 或 REST /ai/run 调用，并可走 AI Gateway。

flowchart TB
  App["Worker / Agent"] --> Bind["env.AI.run"]
  Bind --> Pick{"选哪个模型？"}
  Pick -->|"热路径 · 文本/图"| Flash["Clef-flash"]
  Pick -->|"精度优先 · 文本/图"| Clef["Clef"]
  Pick -->|"要听音频或看视频文件"| Omni["Clef-omni"]
  Flash --> Ans["answers：各选项概率"]
  Clef --> Ans
  Omni --> Ans
  Ans --> Act["路由 · 拦截 · 升级人工"]

共用 API：state + questions

三个模型共用 System One 形态，与 Jev 宣称兼容：改模型 ID 和 model 选择器即可切换；只有需要音频 / 视频文件时才用 omni 的额外字段。

• state：字符串或结构化 JSON（记录、聊天日志、应用状态）。放不下时截断 state。
• questions：1～64 个问题；id 可用字母、数字、_、.、-（最长 100 字符）。
• 题型
  • noul：是否题 → 「是」的概率
  • choice：单选 → 选中项、各选项概率、confidence
  • score：有序量表 → 加权分数与各档概率
• 媒体：见下一节；托管 API 不接受远程 URL，须 base64 data URL 嵌入。

文本决策示例（三个模型请求形状相同，只换 ID）：

const response = await env.AI.run("@cf/cloudflare/clef-flash", {
  model: "clef-flash",
  state: "Checkout has been failing for every customer for the last hour.",
  questions: {
    urgent: {
      type: "noul",
      instructions: "Is this support request urgent?",
    },
    team: {
      type: "choice",
      instructions: "Which team should handle this request?",
      criteria: {
        billing: "Payments, invoices, and refunds",
        technical: "Outages, errors, and configuration",
        sales: "Plans and upgrades",
      },
    },
    severity: {
      type: "score",
      instructions: "How severe is the customer impact?",
      criteria: ["No impact", "Minor", "Major", "Critical"],
    },
  },
});

模态、限额与计费换算

各模型能吃什么

研究判断： 需要「上传一段 MP4/WebM 或 WAV/MP3 再决策」时，选 Clef-omni。Clef / Clef-flash 的「video」在托管 API 上没有与 omni 对等的 videos 参数表，本文不把它们写成已支持视频文件上传。

媒体限额（托管）

图片（家族共用扩展）： 最多 4 张；单张 4 MiB、16 百万像素；解码合计 8 MiB。Clef / Clef-flash 还写明整请求体最大 13 MiB。

音频（仅 omni）： 单段 8 MiB、300 秒；与视频合计解码 ≤ 16 MiB。

视频（仅 omni）： 单段 16 MiB、60 秒；2 帧/秒采样。当请求里每一个视频都带声轨时，声轨与帧一起处理。

Token 怎样从媒体算出来

Clef 家族只按 input tokens 计费，不收 output tokens。媒体折算为 input tokens，并占用上下文：

• 图片：缩放到约 65,000 像素～1 百万像素，按 32×32 patch 计 token，加 3 个边界标记；单张上限 1,024 tokens（约 64～1,024）。
• 音频（omni）： 约 780 tokens / 分钟。
• 视频（omni）： 最高分辨率约 15,400 tokens / 分钟（约 256 tokens / 秒），另加声轨约 780 / 分钟；480p 约 8,600 帧 token / 分钟。

媒体 + questions 超过上下文则请求失败，否则截断 state。clef-omni 模型页 · clef 模型页

对照表：上下文、定价、延迟、怎么选

上下文与单价（托管，核对于 2026-10-12）

Clef-flash 降价的代价是托管窗口缩小；官方称仅 0.24% 请求超过 24K，更大上下文改用 Clef。Changelog：2026-10-09 · 定价页

官方延迟声明（未实测；存在冲突）

Clef / Clef-flash 发布稿（2026-10-01，相对 Jev 的基准跑数）：

Clef 提速（2026-10-09，服务层优化，权重未改）： 约 800 / 3,400 / 16,000 tokens 输入时，中位延迟约 1.7×～2.0× 于优化前（例如 ~3,400 tokens：616 ms → 305 ms）。

Clef-omni： 同一天有两套数字——

• Changelog：文本约 20 ms；图片或音频 < 100 ms；带声 21 秒视频约 300 ms
• Blog 公告：文本中位约 130 ms；图片约 150 ms；音频数百毫秒；带声 21 秒视频约 1.5 s

未验证： 以上均为厂商自报；omni 两处冲突本文不作取舍。选型按「flash 通常最快、clef 文本决策亚秒、omni 短视频约亚秒到约 1.5 秒」理解，并在自己的区域压测。

官方基准怎么读

发布材料显示：某一 Clef 模型在多套决策基准上经常领先或接近 Jev；Clef-omni 在 BANKING77、CLINC150+OOS 等上不错，但在 PhishNChips、部分 workflow eval 上低于 Clef。多模态覆盖是 omni 的主卖点，不是「所有文本基准都第一」。 分数未独立复现。

怎么选（研究判断）

1. 只要文本或少量图片，且在乎费用 / 延迟 → 默认 Clef-flash。
2. 文本 / 图片决策要更高精度，或输入经常超过约 24K → Clef。
3. 必须联合听音频或看视频文件 → Clef-omni；不要为了「新模型」在纯文本链路上付更高单价和更大媒体体积。
4. 需要转写、摘要、自由回答 → 决策模型不合适；用 ASR + LLM（或 AI Search 等）另建链路。

Clef-omni 多模态多出来的原理

Clef-omni 以 Qwen3-Omni-30B-A3B-Instruct 为骨干：保留理解侧（含视觉与音频编码器），丢掉文本转语音输出；冻结骨干后训练 LoRA，并加 joint schema head。推理一次 prefill，对所有模态与合法选项联合打分，因此不必先 Whisper 再分类——代价是选项必须事先可枚举，且素材要符合短片段限额。Blog：Clef-omni · HF：clef-omni

多模态示例：

const response = await env.AI.run("@cf/cloudflare/clef-omni", {
  model: "clef-omni",
  state:
    "Review the installation: a photo of the unit, an audio recording of it running, and a video of the fan.",
  images: ["data:image/png;base64,<base64-png>"],
  audio: ["data:audio/mpeg;base64,<base64-mp3>"],
  videos: ["data:video/mp4;base64,<base64-mp4>"],
  questions: {
    label_visible: {
      type: "noul",
      instructions: "Is the model and serial number label visible in the photo?",
    },
    sounds_normal: {
      type: "noul",
      instructions:
        "Does the unit sound like it is running smoothly, without rattling or grinding?",
    },
    fan_running: {
      type: "noul",
      instructions: "Is the fan running in the video?",
    },
  },
});

风险与限制（家族共用）

• 不是聊天模型：拿不到解释性正文；要给人看的理由需另接 LLM 或规则文案。
• 选项必须可枚举：最多 64 题；开放域生成做不到。
• 媒体必须嵌入：远程 URL 在托管 API 不可用；base64 放大请求体，受 Worker / API 体积约束。
• 上下文与截断：超限失败或静默截断 state，长工单要把关键字段放前面。
• Clef-flash 托管 24K：大上下文不要假设还能用 flash。
• 校准与漂移：概率可用阈值，但领域外样本仍需你自己的评测集。
• 费用：视频 token 密度高；免费 Neurons（每天 10,000，UTC 日切）会被媒体打分快速消耗。Workers AI 定价

个人站点 / Workers 栈值不值得试

研究判断： 以文档站或个人博客为主、没有结构化分流或短音视频审核时，不必为了「用上 Clef」默认接入。更合理的顺序：

1. 已有「该不该发 / 派给谁」这类枚举决策 → 用 Clef-flash 在免费 Neurons 里试文本路径。
2. flash 不准或上下文不够 → 升 Clef。
3. 明确要听录音或看短视频再决策 → 再上 Clef-omni，并与「Whisper + flash」做小样本费用与误判对比。

文档问答、检索增强仍优先看 AI Search；对象与 binding 基础见 Workers 运行时。

事实、判断与未验证

源事实（核对于 2026-10-12）：

• 2026-10-01：Clef（27B）与 Clef-flash（9B）上线；System One / Jev 兼容；题型 noul / choice / score；最多 64 题。
• 2026-10-09：Clef-omni 上线（音频 WAV/MP3、视频 MP4/WebM）；flash 托管价 $0.038、上下文 24K；clef 托管服务提速约 1.7×～2.0×；omni 价$0.150 / M input。
• 家族不收 output tokens；图片 tokenization 规则与 omni 音视频折算见模型页。
• 开源权重 Apache-2.0。

研究判断：

• 先按模态选模型，再按单价与上下文，最后才看官方基准表。
• 个人文档站默认从「不用」或「只试 flash 文本」起，而不是直接上 omni。
• omni 的价值是少丢声画对齐，不是替代 LLM。

未验证：

• omni Changelog 与 Blog 延迟数字冲突；全文无 Workers AI 实测。
• 未独立复现 Decision Index / workflow eval。
• 未测 base64 体积对 Worker 请求体与账单的影响。
• Clef / Clef-flash「video frame arrays」托管字段形态未在模型页写清。

关联阅读

• Cloudflare AI Search：功能、使用方式与最佳实践
• Workers：运行时 API、Bindings 与执行模型
• Cloudflare 文档导航
• 自托管「类 Cloudflare Workers」：开源项目 open-compute 的原理、架构与适用场景

参考资料

• Changelog：Introducing Clef…，2026-10-01（核对于 2026-10-12）
• Changelog：Clef-omni adds audio and video…，2026-10-09（核对于 2026-10-12）
• Blog：Introducing Clef-omni…，2026-10-09（核对于 2026-10-12）
• Workers AI：clef，核对于 2026-10-12
• Workers AI：clef-flash，核对于 2026-10-12
• Workers AI：clef-omni，核对于 2026-10-12
• Workers AI pricing，核对于 2026-10-12
• Hugging Face：Cloudflare/clef-omni，核对于 2026-10-12
• Hugging Face：Cloudflare/clef（发布稿引用），核对于 2026-10-12