2026 年 9 月，TypeSafe AI 的 Jev 讓「決策模型」這個詞走進主流視野。兩週後的 10 月 1 日，Cloudflare 發布了兩款可相比擬的模型——Clef 與 Clef-flash——託管於 Workers AI，同時以 Apache-2.0 開源權重發布在 Hugging Face 上。
Clef 的定位很直接：正面對決 Jev，並把「開源權重 + 多模態 + 可自架」當成差異化賣點。 它是 27B，內建視覺編碼器，支援 64k 上下文視窗，且與 Jev / SystemOne API 完全相容。對任何做技術評估的人來說，問題已不再是決策模型有沒有用——而是託管 API 還是開源權重自架更適合你的團隊。
以下每一項基準都來自 Cloudflare 公布的內部測試。它們足以排除明顯不合適的選項，但不能取代用你自己的資料重新測試。
重點速覽
- 零維運、最高準確率：Jev 與 Clef 的託管版本都可用；Clef 在大多數分類基準上領先，而且多模態輸入是它獨有的。想最快上手，可直接付費體驗 defapi 上的 Clef 託管 API。
- 圖片或影片輸入：Jev 目前只支援文字。Clef 是唯一選項。
- 自架或資料落地：Clef 的 Apache-2.0 權重是硬性條件的優勢。代價是 27B 的 GPU 佔用與維運。
- 極低延遲：Clef-flash（9B，中位數 38.8ms）比 Jev（524ms）快上一個數量級，但準確率有所犧牲。
- 只是想試試看：兩者都從相容的 API 起步，但別讓公開基準取代採購驗證。
如果你已經讀過我們的 Jev vs Laya 比較，本文把同一套框架套用到第三個候選者上。
Clef 是什麼
Clef 是 Cloudflare 訓練的一系列決策模型。主要特徵：
| 項目 | Clef | Clef-flash |
|---|---|---|
| 主幹模型 | Qwen3.8-27B（含視覺編碼器） | Qwen3.5-9B |
| 輸入 | 文字、JSON、圖片、影片 | 文字、JSON、圖片、影片 |
| 上下文 | 64k | 64k |
| 輸出 | 每個問題的每個允許選項一個 logit，每個問題做一次 softmax | 相同 |
| 授權 | Apache-2.0 | Apache-2.0 |
| 託管 | Cloudflare Workers AI | Cloudflare Workers AI |
它的運作模式與 Jev 同屬一個類別，但實作不同：不生成自由文字，也不做輸出解析。你給它一個 state（文字、JSON、圖片或影片）加上一組具型別的 schema 問題，它就在單次 forward pass 中回傳每個問題、每個允許選項的機率。
關於命名，Cloudflare 借用了一個音樂比喻：五線譜開頭的譜號（clef）為譜線與譜間賦予音名，而決策模型則定義出決定後續動作的上下文範疇。「CF」也是對 Cloudflare 的致意。
架構：prefill 加上平行評分，而非逐 token 生成
理解 Clef 的關鍵在於它不是自迴歸的：
- Qwen 主幹對整個輸入執行一次僅 prefill 的 forward pass。
- 一個小型的 joint schema head 讀取主幹最終的隱藏狀態，把來自 state 的證據路由到每個問題，並聯合為所有問題的所有選項評分。
- 每個選項得到一個 logit；每個問題各自做一次 softmax，將其轉為機率。
中間沒有任何生成的文字。LLM 是先產生推理再格式化成 JSON，而 Clef 直接從主幹的內部表徵推導出 schema 選擇。
Cloudflare 的兩階段注意力路由值得記住：每個有效選項先抽取與自身相關的上下文（選項專屬的證據路由），接著各欄位彼此互相 cross-attend，並回頭 attend 原始 payload（聯合跨欄位注意力），之後才進行受 schema 約束的評分。一個**詞彙先驗（lexical prior）**會跨選項保留語意意圖。
訓練方面，Cloudflare 凍結 Qwen 主幹，並將路由頭與 rank-256 的 LoRA 適配器聯合最佳化：
- label-smoothed cross-entropy（確保輸出符合合法 schema）
- Brier loss（改善機率校準）
- RLCD（Reinforcement Learning for Calibrated Decisions，校準決策強化學習）作為次要目標，對相鄰的序數選擇給予部分分數，對完全精確的紀錄給予獎勵，並施加參考懲罰（reference penalty）以防止分布漂移
這裡有個有趣的細節：就在 Jev 發布的同一週，Cloudflare 曾發表過一個建構在 DiffusionGemma 上的決策模型實驗。Clef 是那條路線的延續，只是換了不同的主幹。它不是 Jev 架構的複製品——它走的是把 LLM logprobs 揭露為確定性機率的獨立路徑。
與 Jev / SystemOne 的相容性
Clef 完全相容。相同的 POST /v1/systemone 請求 body 會回傳相同的 model、answers 與 usage 結構。choice 答案帶有 choice / confidence / probabilities；score 答案帶有預期的 score / confidence / legend / probabilities；noul 答案則回傳該命題為真的機率。
這三種原語與 Jev 一致：
| 原語 | 意義 | 回傳 |
|---|---|---|
noul | 二元命題，真/假 | 0.0 到 1.0 之間的機率 |
choice | 具名選項，選一個 | 選擇 + 信心度 + 各選項機率 |
score | 有序選項，評分 | 期望分數 + 信心度 + 各等級機率 |
對已經整合 Jev 的系統來說，這意味著極低的遷移成本——你甚至可以把同一個 client 放到兩個供應商後面做 shadow traffic。但要提醒一點：wire protocol 相容不等於語意等價。 選項上限、信心度公式與校準曲線可能因模型而異，所以舊的閾值必須在邊界樣本上重新驗證。
一個具體的官方範例（Cloudflare Workers AI 端點）：
curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run/@cf/cloudflare/clef \
-X POST \
-H "Authorization: Bearer $CLOUDFLARE_AUTH_TOKEN" \
-d '{
"model": "clef",
"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"]
}
}
}'多模態：Clef 目前獨有的能力
這是 Clef 與 Jev 最清楚的產品差異。Jev 只分類文字，而 Clef 內建視覺編碼器，能讀取圖片與影片幀。
用法是把 images（PIL 圖片）或 videos（幀陣列）加入 record，並把 processor 傳給 encode_record；選用的 processor 參數放在 media_kwargs。純文字與多模態 record 可以混在同一個 batch 裡：
from PIL import Image
record = {
"state": {"task": "Review the attached receipt."},
"images": [Image.open("receipt.jpg")],
"questions": {
"legible": {"type": "noul", "instructions": "Is the receipt total legible?"},
},
}Cloudflare 自家的展示案例是威脅情報：把一個網域加上 Browser Run 截圖交給 Clef，讓它輸出多標籤機率，例如「95% 時尚、85% 電商、<1% 釣魚」。他們回報，完整的取得、渲染與分類工作流用 Clef 花了 2.2 秒，而他們最快的通用 LLM gpt-oss-120b 花了 4.7 秒，且只回傳了兩個分類。這是個有用的延遲與覆蓋率比較，但注意它量測的是整個工作流，而不是單純的模型推論。
基準測試：誰在哪裡領先
廠商自家基準值得審視。以下是官方 Decision Index 0.2.1 內部測試的一個切片（百分比，越高越好）：
| 基準 | Clef | Clef-flash | Jev | 領先者 |
|---|---|---|---|---|
| BFCL (case exact) | 98.5 | 98.8 | 95.8 | Clef 系列 |
| ToolRet (nDCG@10) | 69.2 | 66.4 | 65.3 | Clef |
| API-Bank (accuracy) | 91.9 | 93.1 | 88.2 | Clef 系列 |
| BANKING77 (macro-F1) | 94.2 | 90.9 | 79.7 | Clef |
| CLINC150+OOS (macro-F1) | 97.4 | 66.8 | 89.3 | Clef |
| Home appliance (case exact) | 83.0 | 97.7 | 52.3 | Clef 系列 |
| ContractNLI (macro-F1) | 81.4 | 84.3 | 71.7 | Clef 系列 |
| MMLU (accuracy) | 90.3 | 91.8 | 91.7 | 平手 |
| GPQA Diamond (accuracy) | 48.0 | 51.0 | 78.3 | Jev |
| MMLU-Pro (accuracy) | 65.9 | 65.3 | 82.7 | Jev |
| BBH (accuracy) | 73.7 | 68.9 | 92.9 | Jev |
| When2Call MCQ (accuracy) | 72.4 | 65.6 | 81.0 | Jev |
| BRIGHT (nDCG@10) | 45.9 | 39.3 | 47.5 | Jev |
結論並不是「Clef 橫掃全場」。更準確的解讀是：Clef 在分類、工具呼叫與結構化索引上很強；Jev 則在需要一點通用推理的任務（GPQA、MMLU-Pro、BBH）上領先。 這與它們的主幹和訓練目標相符——Clef 對 Qwen 主幹做後訓練，保留了較多通用推理能力，而 Jev 則在某些決策專屬指標上被拉開領先。挑選時看你自己的任務更接近哪一類。
延遲（毫秒，越低越好）：
| 指標 | Clef | Clef-flash | Jev | Laya |
|---|---|---|---|---|
| 中位數延遲 | 209.3 | 38.8 | 524.1 | 5.8 |
| p95 延遲 | 238.6 | 122.4 | 536.0 | 222.5 |
Laya 在中位數上極快，但在上述品質基準上明顯落後——屬於「快但犧牲準確率」的定位。Clef 系列在品質與延遲曲線上佔據不同位置：Clef 最佳化品質，Clef-flash 最佳化速度。這些數字來自不同的硬體與部署，無法跨列換算——只能把它們當成相對訊號。
工作流評估（來自 TypeSafe Evals 的端到端業務流程）：
| 工作流 | Clef | Clef-flash | Jev |
|---|---|---|---|
| 發票處理 (exact) | 64.7 | 57.1 | 61.8 |
| 客戶服務 (exact) | 76.3 | 77.0 | 76.0 |
| 安全事件 (exact) | 62.9 | 61.7 | 61.7 |
| Agent trace 可觀測性 (primary) | 68.5 | 69.8 | 71.6 |
Cloudflare 的說法是「四項贏三項」。持平而論，差距都是個位數，而且這是 Cloudflare 跑 TypeSafe 自家的評估套件——所以真正採購時，你還是需要自己的資料。
部署與授權：開源真正換到什麼
兩款 Clef 模型都以 Apache-2.0 發布在 Hugging Face 上，附帶標準的分片 safetensors，可讓你在本機執行：
- Transformers（
image-text-to-textpipeline） - vLLM（
vllm serve "Cloudflare/clef"） - SGLang
- Docker Model Runner、llama.cpp / Ollama / LM Studio（量化版本）
檔案結構也很清楚：主幹權重、joint_head.safetensors + joint_head_config.json（joint schema head），以及 joint_schema_model.py（record 編碼、batching 與 systemone wrapper）。Cloudflare 在單張 H200、torch 2.11 與 transformers 5.10.2 上測試。
這裡必須戳破「開源等於免費」的迷思：
- Apache-2.0 免除授權費，但 GPU 還是要付錢。 BF16 下的 27B 對消費級顯卡來說並不輕鬆；Clef-flash 的 9B 實際得多。
- 維運是你的責任。 模型服務、常駐 VRAM、版本升級、安全修補與監控全都是成本。
- 託管版本可免除這些成本：除了 Cloudflare Workers AI，也可直接付費使用 Clef 或 Clef-flash 的託管 API，代價是改用按量計費。
Cloudflare 也強調一個面向企業的重點：預設情況下它不會讀取、儲存或拿你的請求與回應來訓練——除非你選擇加入它的微調產品。自架則輕鬆滿足資料邊界要求。這正好補上了 Jev 比較中留下的缺口——在該比較裡，託管 API 的資料保留必須向廠商確認。
全新的 RL 微調平台
Clef 發布中有一段容易被忽略卻很重要的內容：Cloudflare 推出了強化學習微調服務。
動機來自大量高度垂直的內部分類需求（Trust & Safety 提交審查、客服分流、判斷好機器人與壞機器人）。這些場景累積了多年的標註決策資料。微調會用部分通用效能換取特定領域的更高準確率——而憑藉超過 15 年的網路資料，這正是 Cloudflare 的強項。
技術堆疊值得一提：
- Cloudflare AI Gateway：自動把 AI 流量擷取成資料集
- Workers AI：針對基礎 Clef 模型生成 rollouts
- Cloudflare Containers：用於評分與重放 agent 動作的 RL sandbox
- [New] Trainer：更新微調後的 Clef 權重
- Workers AI + BYO Model：把微調後的模型重新部署回 Workers AI
目前它是以與 Cloudflare 前線部署工程師（FDE）團隊的實作參與形式進行，自助式平台則計畫在之後推出。對已經大量使用 Cloudflare 的團隊來說，這是一條把你的標註資料變成客製決策模型的路——而 Jev 目前沒有公開的對等方案。
建議：談條件，不喊口號
符合這些條件就選 Clef（或 Clef-flash）
- 你的輸入包含圖片或影片，且需要多模態分類。
- 資料不能離開你的邊界，且你需要 Apache-2.0 權重來自架或離線部署。
- 你想要 64k 上下文視窗來處理較長的 state。
- 你想在 Cloudflare 生態系內微調，用你的標註打造客製模型。
- 延遲至關重要，且你能接受準確率取捨：Clef-flash 非常快。
- 想立刻驗證：直接在 defapi 上跑一條 Clef 或 Clef-flash 請求。
符合這些條件就選 Jev
- 你只需要文字決策，且想要零維運的託管 API。
- 你的任務偏向通用推理（GPQA / MMLU-Pro / BBH），而這正是 Jev 目前領先之處。
- 你已經有 Jev 的整合、閾值與校準曲線，而遷移的效益不足以抵銷重新測試的成本。
- 你的團隊沒有 GPU 維運人力，也沒有執行模型服務的計畫。
若兩者都可行，那就
- 用你真實的 state 分布、選項集與評分標準跑 shadow traffic。
- 同時量測正確率、校準、p50/p95 延遲、兜底行為與成本。
- 別把 API 相容當成零遷移——要在邊界樣本上重新驗證閾值。
- 把資料保留、資料落地、SLA 與支援承諾納入採購門檻，而不是依賴公開基準。
常見問題
Clef 真的與 Jev 完全相容嗎？
在 wire protocol 層級，是的：相同的 POST /v1/systemone 請求 body、相同的 answers / usage 回應結構，以及對應的 choice / score / noul 原語。但模型內部的選項上限、信心度公式與校準曲線各不相同，所以舊閾值不能原樣照抄。
Clef 是開源的——我可以在生產環境免費使用嗎？
免費授權不等於零 TCO。27B 需要一張夠力的 GPU，還要加上模型服務、VRAM、監控、升級與安全修補。Clef-flash（9B）或託管版本通常更經濟。
該選 Clef 還是 Clef-flash？
Clef 是精準型模型，在大多數基準上領先；Clef-flash 是延遲型模型，中位數 38.8ms，比 Clef 快約 5 倍，但在 CLINC150 與 ContractNLI 等任務上準確率明顯下滑。熱路徑用 flash，關鍵判斷用 Clef。兩者都已託管，可在 defapi 直接付費體驗：Clef、Clef-flash。
我可以用官方基準來做採購決定嗎？
不行。這些是 Cloudflare 的內部測試，而且 Clef 是在 TypeSafe 自家的評估套件上被比較。用它們來排除明顯不合適的選項沒問題；最終決定需要在你自己的資料上，採用相同的資料集、失敗定義與信心度閾值。
實際上要怎麼使用圖片輸入？
把 images（PIL 圖片）或 videos（幀陣列）加入 record，將選用的 processor 參數放進 media_kwargs，再把 processor 傳給 encode_record。文字與多模態 record 可以混在同一個 batch 裡。
自架 Clef 需要什麼？
一張 H200 等級的 GPU、torch 2.11 + transformers 5.10.2，以及用於圖片/影片的 pillow。Cloudflare 不保證消費級硬體，所以上生產前要先在目標硬體上做 p95 負載測試。
Clef 會取代 Jev 嗎？
未必。兩者在基準上互有勝負，Jev 在通用推理任務上領先，而且它仍是純託管路線。真正改變的是：決策模型這個類別從單一供應商變成一個有開源權重與多模態輸入的競爭場域——這對買方是好事。
下一步
想直接體驗託管路徑，可以付費使用 defapi 上的 Clef（27B 精度型號）或 Clef-flash（9B 速度型號），並可與 Jev API 做 shadow traffic 對照。如果圖片輸入或自架是硬性需求，請讀 Hugging Face 上的 Clef model card 與 Cloudflare 發布文，然後用你自己的資料跑一輪比較。若想先補齊基礎，請看 Jev vs Laya 比較 與 System One 入門。