Clef 決策模型是什麼

讀完這篇，你會知道「決策模型」這個詞指的是哪一種模型，它和分類器、和一次 LLM 呼叫各差在哪裡，Cloudflare 在 2026 年 10 月 1 日釋出的 Clef 與 Clef-flash 主張了什麼、拿什麼數字支持，以及十月九日的第二篇貼文又改了哪些地方。文中的數字全部出自 Cloudflare 自己的兩篇貼文，基準測試也是 Cloudflare 自己跑的，沒有第三方重現，讀的時候請帶著這個前提。

一則客服訊息，程式只要一個分支

先想一個每個後端工程師都遇過的場景。客服系統收到一則使用者訊息，程式需要知道兩件事：這則訊息急不急，該轉給哪個團隊。Cloudflare 的貼文舉的正是這個例子：「you can pass in a customer support message (inputs) and ask if it is urgent and which team should handle it.」輸入是一段自然語言，但程式下一步要的不是一段話，而是一個可以放進 switch 的值：urgent 或不是，billing、security 或 general。

貼文對決策模型的定義很短：「A decision model makes classifications to help agents decide how to act, based on certain probabilities.」接著說明輸出的形狀：模型回傳有型別的答案和機率，「which your code can use to route the ticket, trigger an escalation, or defer to a human.」三個動作值得放在一起看。轉單、升級、交給人，都是程式碼裡的分支，而不是文字內容。決策模型的設計重心，就在於讓模型的輸出直接接得上這些分支。

貼文同時提到，這代表人不見得需要待在 agent 決策的迴圈裡，原文是「a human does not necessarily need to be in the loop for agentic decisions anymore」。這句話用了「necessarily」，是有保留的說法；而前面那三個動作裡就有一個是「defer to a human」，可見這種模型的用法不是把人完全拿掉，而是讓程式知道什麼時候該把案子交出去。這個區別在後面的互動圖裡會看得更清楚。

發布背景也交代一下。貼文開頭說，過去幾週圍繞著決策模型有不少討論，例子是 Typesafe AI 的 Jev System One 模型；Cloudflare 的說法是 Jev 為 AI 領域帶來了一個新的決策模型概念。Clef 與 Clef-flash 是 Cloudflare 自己訓練的兩個決策模型，貼文寫的是「Today, we’re releasing two Cloudflare-trained decision models」，託管在 Workers AI 上，權重以 Apache 2.0 授權放在 Hugging Face，可以自己拿來跑。API 方面，兩者都與 Jev 的 API 相容。

分類器太固定，LLM 太自由

貼文自己承認：「While classifier models have been around for some time」，分類模型不是新東西。那決策模型多出什麼？要回答，先把兩端各自的毛病講清楚。

傳統分類器的標籤集合通常在訓練時就決定了。輸出是機率分佈，這點和決策模型相似，但想加一個新類別，一般做法是補資料、重新訓練。這是一般機器學習的常識，不是 Cloudflare 貼文的原話，這裡只當背景交代。合理的推測是，決策模型想補的正是這一塊：類別（也就是輸出的 schema）在呼叫時才給，而不是在訓練時就固定。貼文的意思大致也是 Jev 這類模型能處理各種輸入，不必為每個新用途另訓一個分類器，但細節我只能照貼文的描述轉述，沒辦法替它背書。

另一端是 LLM。貼文對照時說，LLM 「largely non-deterministic」，大致上是非確定性的；它的好處是開放，什麼都能推理、能呼叫工具。可是當你只想要一個分支值，開放就變成成本：模型寫出一段話，程式要去解析，解析失敗要重試，同一個輸入兩次呼叫可能得到不同措辭。這些是工程上常見的處理負擔，同樣屬於一般經驗，並非出自貼文。

所以決策模型夾在兩者中間。它不像分類器那樣把標籤焊死，也不像 LLM 那樣放任輸出自由。你在呼叫時說明答案可以長什麼樣子，模型只能在這個範圍內選，並附上每個選項的機率。下一節把這個定義拆成三件事，再用一張可以拖動的圖看機率怎麼變成程式的分支。

有界輸出加上機率：決策模型的最小定義

把貼文的定義拆開，有三個零件。第一個是有界：輸出只能落在你給的 schema 裡。貼文用的字眼是「typed answers」，有型別的答案，所以回傳值不是任意文字。第二個是機率：每個答案都附有信心，而不只是一個標籤。第三個是程式碼握有決定權：模型給出判斷與機率，路由、升級或轉人工是程式依這些值做的事。

機率這個零件，是整個設計能不能用的關鍵。想像模型對一則訊息回答「資安團隊，0.58」。如果只有標籤，你只能照單全收；有了機率，你可以寫「低於 0.8 就交給人」。下面這張圖用四則虛構的訊息示範這個動作：拖動門檻，看哪些訊息自動處理、哪些退回給人。請注意，圖中的訊息和機率都是我為了說明而編的示意值，不是 Cloudflare 的資料。

拖動門檻，看哪幾則訊息會退回給人 · 4 則示意訊息 × 3 個隊伍

信心門檻 0.80

門檻拉到 0.95 時，四則訊息全部退回給人；拉到 0.45 時，連兩個隊伍機率只差 0.02 的第四則也會自動轉走。這就是機率的用途：它讓「要不要自動處理」變成一個你可以調的參數，而不是模型自己拍板。第四則訊息值得多看一眼，帳務 0.44 與資安 0.46 幾乎打平，卻是有人盜刷的急件，這種案子若門檻設得太低，會當成確定的判斷送走。

這張圖背後還有一個前提，要明說：門檻有意義，是因為機率大致可信。模型說 0.9，實際上就該有九成左右的機率是對的。這叫校準（calibration）。第二篇貼文提到 Clef-omni 的訓練用了 Brier score 這類校準相關的損失，並且把產品描述成「Calibrated, schema-bound decisions」，也就是校準過、受 schema 約束的決策。不過貼文沒有給出校準曲線或相關數字，所以 0.8 在 Clef 身上究竟對應多少實際準確率，我們無從得知。這是你要拿自己的資料量的東西。

為什麼不一個 token 一個 token 寫出來

貼文還交代了速度為什麼可能比 LLM 快：「The decision step is non-autoregressive, so there’s no intermediate text to generate token by token」。決策這一步是非自迴歸的，沒有中間文字要一個 token 一個 token 生成。底座方面，貼文說目前用 Qwen 當基礎模型，再針對決策模型的用途做後訓練：「We currently use Qwen as the base model and post-trained it to suit decision model use cases.」

白話的差別是這樣。自迴歸的 LLM 要先寫出答案的文字，每寫一個 token 都得再跑一次模型，寫完之後程式還得解析。決策步驟省掉了「寫出文字」這一段，直接給出各個合法選項的分數。貼文對內部機制的描述很短，細節並沒有展開，所以下面的動畫只是示意，時間軸不代表實際耗時，也不代表 token 數量。

按播放，比較兩條路各自怎麼走到分支 · 2 條泳道

播放 重設

另有幾個細節也和「能不能直接放進系統」有關。Clef 多了視覺編碼器，貼文的說法是「it has a vision encoder so it’s able to take in images and classify visual content」，所以圖片也能當輸入；Jev 只處理文字。Clef 的 context window 是 64k，相對於 Jev 的 32k。隱私方面，貼文寫下的保證是「we don’t read, store, or train on your requests or responses」，也就是 Cloudflare 不讀取、不儲存，也不拿客戶的請求與回應做訓練，選擇微調的客戶另當別論。

Cloudflare 自己怎麼量：網域分類與基準表

貼文裡最貼近實際工作的例子，來自 Cloudflare 自家的 Threat Intelligence 團隊。原文：「we’ve been testing our new Clef model on our Threat Intelligence team」，他們讓 Clef 搭配 Browser Run 去判斷網站網域的類別。結果是：「This classification took our Clef model 2.2s to fetch, render, and classify the website.」對照組是「our fastest general LLM gpt-oss-120b」，在同一條工作流程裡花了 4.7 秒，「and only returned two classifications」，只回了兩個分類。

這組對照要小心讀。2.2 對 4.7 是同一條工作流程的兩次結果，貼文沒有說跑了幾次、是不是取中位數；而且 gpt-oss-120b 只回了兩個分類，輸出量和 Clef 並不相同，所以它不是一場嚴格的同條件比較。合理的推測是，這個例子的用意在展示延遲與輸出結構的取捨，而不是一個可以外推的倍率。還有一件事容易漏看：2.2 秒包含抓取與渲染網頁，模型本身只佔其中一段，貼文沒有拆出來。

接下來是基準測試。貼文的主張是「Clef is currently the leader when evaluated against the Jev Decision Index」，並說他們把其中對決策重要的評測挑出來列表：「We shortlisted some evaluations below that are important for decision-making as defined by the Jev Decision Index」。要記得兩件事：表格是 Cloudflare 精選過的子集，指數的名稱帶著 Jev，我在貼文裡沒有讀到由誰維護它的說明，更沒有第三方重現。下表只列 Clef、Clef-flash、Jev 與 DiffusionGemma Jev 四欄，原表另有 Kev 9B 與 Laya 兩欄，這兩欄在十列裡都沒有拿到最高分，所以不列入。

Jev Decision Index 精選評測（Cloudflare 自行發表）

評測	Clef	Clef-flash	Jev	DiffusionGemma Jev
BFCL · case exact	98.47	98.76	95.75	96.52
ToolRet · nDCG@10	69.19	66.43	65.28	61.21
API-Bank · accuracy	91.93	93.11	88.19	83.66
Home appliances · case exact	82.95	97.73	52.27	42.05
When2Call · accuracy	72.37	65.58	80.97	75.44
BANKING77 · macro-F1	94.20	90.93	79.74	74.28
CLINC150+OOS · macro-F1	97.43	66.77	89.27	83.49
BRIGHT · nDCG@10	45.91	39.26	47.52	42.94
Amazon ESCI · macro-F1	57.48	57.39	55.21	53.37
PhishNChips · accuracy	79.60	75.05	62.55	85.35

我自己數了一遍：十列裡，Clef 或 Clef-flash 拿下七列，Jev 拿下 When2Call 與 BRIGHT 兩列，DiffusionGemma Jev 拿下 PhishNChips 一列。從表格看，其他模型在個別評測上會勝過 Clef，PhishNChips 就是例子；貼文本身只說 Clef 在這些評測裡表現有競爭力。這和「領先」的說法並不衝突，卻提醒你領先不代表每個任務都贏。

表裡有幾個數字比總分更值得看。CLINC150+OOS 這一列，Clef 是 97.43，Clef-flash 掉到 66.77，差了三十分以上；Home appliances 反過來，Clef-flash 的 97.73 高於 Clef 的 82.95。小模型不能當成大模型的縮水版，各任務的強弱會互換。貼文自己的說法是，較大的 Clef 是「more powerful precision model」，偏重精準；Clef-flash 是較小的那一個，選哪個得看你的任務。

關於這些評測在量什麼，下面一段是我對這些公開資料集的一般認識，不是貼文的說明。BFCL 與 API-Bank 一類偏重函式或 API 呼叫的正確性，ToolRet 看的是從一堆工具裡檢索出對的那個，BANKING77 與 CLINC150+OOS 是意圖分類（CLINC 的 OOS 指的是超出範圍的輸入），Amazon ESCI 是商品搜尋相關性。把它們放在一起，涵蓋的是「該選哪個工具、哪個類別、哪個結果」的選擇題，和決策模型的定位吻合。至於 Home appliances 與 PhishNChips，我沒有可靠的出處，不替它們下定義。

Typesafe 自己的評測套件是另一組證據。貼文說「our Clef models fared well, beating Jev in 3 out of 4 areas」。四個工作流程分別是 invoice processing、customer service、security incidents 與 agent trace observability；Clef 在發票處理拿 64.7（Jev 61.8），資安事件拿 62.9（Jev 61.7）；客服場景是 Clef 的 76.3、Clef-flash 的 77，對 Jev 的 76.0；唯一輸的是 agent trace observability，Jev 71.6，Clef 68.5，Clef-flash 69.8。差距多半只有一兩分，貼文沒有給信賴區間或重複實驗的變異，所以「3 比 1」的說法宜當成方向，不要當成顯著性結論。

最後是延遲。貼文說：「Across the 43 eval benchmarks that we ran, our Clef models beat the decision models on latency」，但有個例外，「except for Laya which is very fast but trades off quality in the benchmarks above」。下圖把表中的中位延遲與 p95 畫在對數軸上。

圖裡有個容易讓中位數遮住的細節。Laya 的中位延遲只有 5.8 ms，是全表最快，但它的 p95 是 222.5 ms，比 Clef-flash 的 122.4 ms 還高。對要在請求路徑上同步呼叫的服務，尾端延遲往往比中位數更要緊；單看中位數會高估 Laya 的優勢。另一個觀察是，Clef 的 p95（238.6）緊貼著中位數（209.3），分佈很窄，這對要做容量規劃的人是好消息，不過這只是一組基準測試下的數字，換成你的輸入長度不一定成立。

第二篇貼文：更快、更便宜，也能聽、能看

十月九日，Cloudflare 發了第二篇貼文，講三件事：Clef 變快、Clef-flash 變便宜、新增了 Clef-omni。下面的卡片把三個模型並排，數字全來自這篇貼文。

Clef-flash

價格（每百萬輸入 token）

$0.09 降到 $0.038

託管 context window

64k 降到 24k

權重訓練長度

256k，Hugging Face 上的權重未動

貼文給的理由

只有 0.24% 的請求超過 24k 輸入 token

Clef

價格（每百萬輸入 token）

$0.24，維持不變

中位延遲，約 800 token

262 ms 到 152 ms（1.7 倍）

中位延遲，約 3,400 token

616 ms 到 305 ms（2.0 倍）

中位延遲，約 16,000 token

2,721 ms 到 1,635 ms（1.7 倍）

Clef-omni

價格（每百萬輸入 token）

$0.15，新推出

輸入

文字、圖片、音訊（wav 或 mp3）、影片（mp4 或 webm）

中位延遲

純文字約 130 ms，圖片約 150 ms

21 秒有聲影片

約 1.5 秒評分完成

先看 Clef-flash。價格從每百萬輸入 token 0.09 美元降到 0.038 美元，貼文說這讓它「now cheaper than Jev」。代價寫在 context window：託管版從先前宣稱的 64k 縮到 24k，理由是「only 0.24% of requests exceed 24k input tokens」，依 Cloudflare 的用量資料，只有 0.24% 的請求超過這個長度。這句話有一個隱含的前提：用量資料來自 Cloudflare 現有的客戶，如果你的輸入偏長，比方整份合約或長篇對話，你就落在那 0.24% 裡，24k 對你就是硬性上限。貼文另外說，Hugging Face 上的權重沒有改動，訓練時支援 256k，自行部署的人不受託管版限制。

再看 Clef。價格維持 0.24 美元，變快來自託管端的優化。貼文說其中一項是改用 SGLang 來服務模型，並且提到相關的 pull request 預計進入 SGLang 0.5.22。三個輸入長度的中位延遲都下降：約 800 token 從 262 ms 到 152 ms，約 3,400 token 從 616 ms 到 305 ms，約 16,000 token 從 2,721 ms 到 1,635 ms，倍率分別是 1.7、2.0 與 1.7。p95 的下降幅度不一樣，約 16,000 token 那一列從 3,250 ms 降到 1,805 ms，約 800 token 那一列卻只從 438 ms 降到 351 ms。如果你在乎尾端，要看的是 p95 那一欄。

Clef-omni 是這次新增的成員，權重同樣開放在 Hugging Face。貼文寫它建立在 Qwen3-Omni-30B-A3B-Instruct 這個混合專家（MoE）基礎上，「where the model was already capable of processing text, imagery, audio, and video directly within a single pipeline」。它讓一次 API 呼叫能同時接收文字、圖片、音訊與影片，貼文的說法是「Calibrated, schema-bound decisions now seamlessly handle text, images, audio, and synchronized video in a single API call」。延遲方面，貼文給的是純文字約 130 ms、圖片約 150 ms、音訊「a few hundred milliseconds」，21 秒有聲影片約 1.5 秒。價格是每百萬輸入 token 0.15 美元。貼文只給了 Clef-omni 的中位數，沒有列 p95。

Clef-omni 並不全面勝過 Clef。貼文的說法是各項基準「strong performance」，同時表格顯示 Clef-omni 在若干任務上落後 Clef：以 Typesafe 的發票處理為例，Clef-omni 的 exact-actions 分數是 60.2，Clef 是 64.7；反過來，BANKING77 的 macro-F1 上，Clef-omni 是 94.8，高於 Clef 的 94.20。這兩列只說明各任務的強弱會互換，不能直接推出多模態必然犧牲品質；如果你的輸入只有文字，該用哪一個，要拿自己的資料來驗證。

貼文還列了 Cloudflare 內部的使用場景：公開的 GitHub 文件庫用 Clef 偵測並關閉垃圾 issue，內容管理系統 EmDash 用它審查外掛庫中的釣魚內容，資料外洩防護團隊用它掃描政府證件之類的個資。這幾個都是「輸入是一段內容，輸出是一個要不要處理的分支」的工作，符合第一節所說的使用形狀。要提醒的是，這些場景在貼文裡只是簡述，沒有附上準確率或誤判率，所以它們證明的是「有人在用」，並不證明「好用到什麼程度」。

什麼時候該換，什麼要自己量

如果你的系統裡已經有一段「呼叫 LLM、解析文字、再分支」的程式，決策模型值得評估。理由有三個，都能從貼文推出：輸出是有型別、有機率的值，可以直接接門檻與人工審核；沒有中間文字要生成，貼文宣稱延遲較低；API 與 Jev 相容，而且 Clef 又經由 AI Gateway 提供，貼文說換模型「as simple as changing the model ID」，試用的切換成本很低。這三點裡，第三點最容易驗證，因為貼文說只要換模型 ID；實際要花多少時間，貼文沒有講，要看你自己的系統。

換之前，有幾件事要自己量，貼文沒辦法替你回答。第一，校準：用你自己的資料畫出機率與實際準確率的關係，才能決定門檻設在哪。第二，你的任務是否落在 Clef 的強項裡；從基準表看，同一個模型在不同評測上的名次差很多，Clef-flash 在 CLINC150+OOS 的落差尤其大。第三，輸入長度是否超過託管版的上限，Clef-flash 的 24k 是硬限制。第四，延遲要看 p95，而且要在你的輸入長度下量，貼文的延遲表是單一基準設定下的結果。

貼文最後談到的是強化學習微調。Cloudflare 提供的是一項服務：「We are offering a service to help customers fine-tune Clef to suit their workloads with our hands-on FDE team.」也就是由駐點工程師（FDE）協助客戶針對自己的工作負載微調 Clef，現階段偏人工服務，之後預計做成自助平台。貼文也先把代價講了：「When you fine-tune a model, you may give up some general purpose performance」，微調可能犧牲一些通用能力，換取特定領域的準確度。他們自己也承認「We’re still early here」，這個產品還在早期。

還有一個沒回答的問題：決策模型的邊界在哪。貼文把它定位成「幫 agent 決定怎麼行動」的分類，換句話說，它處理的是選擇題。需要產生內容、需要多步推理的任務，仍然是 LLM 的地盤。合理的推測是，實際系統會把兩者並用：決策模型站在前面，決定這一步走哪條路、要不要交給人，LLM 在選中的分支裡做開放式的工作。這個分工是我的推論，貼文沒有直接這樣寫。

Mental model：決策模型把「接下來走哪條路」縮成一個有型別、帶機率的小答案，由你的程式碼用門檻決定自動處理還是交給人；它能不能用，取決於那些機率準不準，而這件事只有你的資料說得準。