重點
- 10 月 1 日 Cloudflare 公開 Clef（27B）與 Clef-flash（9B）。Qwen 骨幹只做 prefill，joint schema head 對每個問題的每個合法選項給一個 logit。
- 骨幹權重凍結。Clef 用 Qwen3.8-27B，Clef-flash 用 Qwen3.5-9B，兩者都留著 vision encoder。同時訓練的是 routing head 與 rank 256 的 LoRA。
- 後訓練用 label-smoothed cross-entropy 與 Brier loss。次要目標 RLCD 對相鄰序數選項給部分分數，並用 reference penalty 限制分布偏移。
- 部落格短表裡，Clef 的 BANKING77 macro-F1 是 94.20，Jev 是 79.74。When2Call accuracy 是 Jev 80.97，Clef 72.37。
- 請求延遲中位數：Clef-flash 38.8 ms，Clef 209.3 ms，Jev 524.1 ms。Laya 是 5.8 ms。
評分方式
Clef 讀一份 state，對一組有型別的問題輸出機率。模型卡寫明沒有自由文本生成，也不做輸出解析。每個問題一組 logit，依該問題做 softmax。問題型別是 noul、choice、score，請求格式與 Jev / System One 相容。state 可以是文字或 JSON。兩份模型卡都接受圖片與影片。
自迴歸模型要逐 token 生成文字。Clef 的決策步驟沒有這段中間文字。部落格的描述是：Qwen 做一次 prefill-only pass，接著平行評分所有合法 schema 選項，分數來自骨幹的內部表示。
注意力分兩段。每個合法選項先從 prompt 抽出相關 context。各欄位參數再彼此 cross-attend，並回到原始 payload，然後才評分。部落格把 lexical prior 寫成選項之間保住語意的依據。模型卡把這顆頭叫做 joint schema head：一顆小 transformer，讀骨幹最後一層 hidden states，把 state 裡的證據分到各個問題，一次評完所有問題的所有選項。
部落格把 context window 寫成 64k，對照寫的是 Jev 的 32k。模型卡裡 encode_record 的 max_length 預設 16,384 tokens，另外可以設 max_state_tokens。本站 9 月那篇 Jev 筆記記的是 request context 64k，state 加最長單一問題另有 32k 上限。64k 對 32k 這個對照，和那篇筆記的切分不一致。
威脅情報的域名分類是文中的一個內部例子。某次結果大約 95% 時尚、85% 電商、不到 1% 釣魚，含擷取、渲染與分類共 2.2 秒。同一流程的 gpt-oss-120b 花 4.7 秒，只回到兩個類別。這是單一例，不是 Decision Index 的一列。
訓練
Clef 從 Qwen/Qwen3.8-27B 後訓練，Clef-flash 從 Qwen/Qwen3.5-9B 後訓練。部落格寫他們凍結這兩個骨幹，一起調 routing head 與 rank 256 的 low-rank adapters。
有效 schema 輸出用 label-smoothed cross-entropy，機率校準用 Brier loss。訓練資料是內部合成集，會置換欄位順序、prompt 與 schema 結構。第二段目標叫 Reinforcement Learning for Calibrated Decisions（RLCD）：
- 相鄰的序數選項拿部分分數
- 整筆紀錄都精準時給獎勵
- reference penalty 壓住分布偏移
同一週他們先試過另一條路：改 DiffusionGemma，把語言模型的 logprobs 露出來當機率。那次實驗建立在 Matt Mastracci 的研究上。他往 vLLM 送過讓 DiffusionGemma 支援更好的 pull request。Clef 改用 Qwen 當骨幹，決策改由 schema head 評分。
權重以 Apache-2.0 放在 Hugging Face。
和 Jev 的分數
分數是 Cloudflare 自己跑的 Decision Index。模型卡標成 0.2.1。分數是百分比，延遲是請求延遲的毫秒數。下表是部落格挑出的十列，小數兩位。模型卡把同一批分數四捨五入到小數一位。兩列延遲與部落格相同。
| Benchmark | Clef | Clef-flash | Jev |
|---|---|---|---|
| BFCL · case exact | 98.47 | 98.76 | 95.75 |
| ToolRet · nDCG@10 | 69.19 | 66.43 | 65.28 |
| API-Bank · accuracy | 91.93 | 93.11 | 88.19 |
| Home appliances · case exact | 82.95 | 97.73 | 52.27 |
| When2Call · accuracy | 72.37 | 65.58 | 80.97 |
| BANKING77 · macro-F1 | 94.20 | 90.93 | 79.74 |
| CLINC150+OOS · macro-F1 | 97.43 | 66.77 | 89.27 |
| BRIGHT · nDCG@10 | 45.91 | 39.26 | 47.52 |
| Amazon ESCI · macro-F1 | 57.48 | 57.39 | 55.21 |
| PhishNChips · accuracy | 79.60 | 75.05 | 62.55 |
這十列裡，When2Call 與 BRIGHT 是 Jev 較高。CLINC150+OOS 上 Clef-flash 是 66.77，低於 Jev 的 89.27。PhishNChips 另有 DiffusionGemma Jev 的 85.35，高於 Clef 的 79.60。
模型卡的完整表有 41 項分數，加上中位數與 p95，共 43 列。部落格說他們跑了 43 個 eval benchmarks，數字相同。完整表裡 Jev 明顯較高的還有 GPQA Diamond（Jev 78.3，Clef 48.0，Clef-flash 51.0）、BBH（92.9、73.7、68.9）與 MMLU-Pro（82.7、65.9、65.3）。RAGTruth 的 hallucination F1：Clef 79.4，Jev 76.5，Clef-flash 35.6。
四個 Typesafe 工作流由模型卡寫明：各模型用同一資料修訂、同一批案例，對照共識標籤。部落格印出的是其中一種指標。發票的 primary action 只出現在模型卡。
| 工作流 | 指標 | Clef | Clef-flash | Jev |
|---|---|---|---|---|
| Invoice processing | Exact actions | 64.7 | 57.1 | 61.8 |
| Invoice processing | Primary action | 86.2 | 73.3 | 83.1 |
| Customer service | Exact actions | 76.3 | 77.0 | 76.0 |
| Security incidents | Exact actions | 62.9 | 61.7 | 61.7 |
| Agent trace observability | Primary action | 68.5 | 69.8 | 71.6 |
部落格印出的四個分數裡，Clef 有三項高於 Jev。agent trace 的 68.5 低於 Jev 的 71.6。Clef-flash 只有 customer service 的 77.0 高於 Jev。security incidents 兩邊都是 61.7。
| 延遲 | Clef | Clef-flash | Jev | DiffusionGemma Jev | Kev 9B | Laya |
|---|---|---|---|---|---|---|
| 中位數（ms） | 209.3 | 38.8 | 524.1 | 84.4 | 51.4 | 5.8 |
| p95（ms） | 238.6 | 122.4 | 536.0 | 211.2 | 187.9 | 222.5 |
Clef 的中位數低於 Jev 的 524.1 ms。同一張表裡，DiffusionGemma Jev 84.4 ms、Kev 9B 51.4 ms、Laya 5.8 ms 都比 Clef 的 209.3 ms 低。Clef-flash 的中位數 38.8 ms 只高於 Laya。p95 以 Clef-flash 的 122.4 ms 最低。
參考資料
- Cloudflare，〈Introducing Clef: our open-source decision models, and new RL fine-tuning platform〉（2026-10-01）
- Hugging Face，Cloudflare/clef README
- Hugging Face，Cloudflare/clef-flash README