Clef-Flash：Cloudflare 的 9B 決策模型，以及名稱中的 Cloudflare 究竟代表什麼意義

Cloudflare/clef-flash是一個 90 億參數的模型，以機率而非句子來回答問題。你交給它一個狀態——文字、JSON、影像、影片影格——再加上一份最多 64 個具名問題的結構描述，它就會在一次前向傳遞中，為每個允許選項回傳一個分數。沒有任何生成的文字需要解析，也沒有推理軌跡可供閱讀，因為根本沒有文字輸出路徑。它是一對模型當中較小的一半：Cloudflare/clef是與它一同發布的 270 億參數同系列模型，而第三個家族成員Cloudflare/clef-omni，則在 30B 混合專家骨幹上加入音訊輸入。這三個模型全都來自 Cloudflare 本身，而這正是最值得準確弄清楚的事實，因為從搜尋這個模型名稱而來的讀者，通常會帶著兩種假設之一抵達——一種是Cloudflare/clef-flash是他人模型由 Cloudflare 代管的副本，另一種是 Cloudflare 只是代管方——而兩者都錯在同一方向。

Clef-Flash 是什麼，以及它不是什麼

廠商自家那句同時重複出現在 Hugging Face 模型卡與 Workers AI 模型頁面上的一行描述是：它「會把一個狀態，以及一份由具型別問題構成的結構描述，轉化為決策」。這個說法比聽起來更狹隘，而且在進行任何基準測試之前，值得先拆解清楚。

你結構描述中的每個問題都會宣告三種類型的其中一種：

• 新增 — 是/否判斷，會傳回答案為真的機率，並可選擇描述在此問題的脈絡中「是」和「否」代表什麼。

• 選擇 — 一組具名選項集，包含 2 至 255 個項目，會傳回勝出的選項、每個選項的機率，以及一個信心值。

• score —— 一種由 2 至 10 個等級構成的有序評分規準，會回傳可落在等級之間的機率加權等級、將索引對應至說明的圖例、各等級機率，以及信賴度。

一個請求會攜帶 1 到 64 個問題，而答案會以你的問題 ID 為鍵，透過一個 answers 物件回傳。每個問題中的每一個選項都會在同一輪中完成評分，因此一個十二題結構描述的成本並不是十二次呼叫——而是一次。你在另一端拿到的是一個分布，而不是一句話，並由你的程式碼對它設定閾值。

將此與聊天模型相比較的讀者，應該內化兩件事。第一，不存在某種失敗模式，是模型先寫出一段解釋、然後你還得去解析它，因為它根本無法產出散文式文字。第二，而且這點較不令人自在：如果正確答案不在你的選項集裡，Clef-Flash 沒有機制能告訴你。它就只會為你寫下的選項評分。在已公布的請求結構描述中，沒有任何設計會加入「以上皆非」這個分類，除非你自己放進去。

名字中的 Cloudflare：三個角色，一間公司

人們搜尋這個模型時會附上 Cloudflare——cloudflare/clef-flash，以及cloudflare clef flash這種直白的說法。這個前綴值得說清楚，因為它指向三個各自獨立的層，而其中只有一層負責主機代管。

• 訓練它的組織。Clef-Flash 是 Cloudflare 的模型。Cloudflare 的公告文章〈隆重推出 Clef：我們的開源決策模型，以及全新的強化學習微調平台〉於 2026 年 10 月 1 日發布，署名作者為 Michelle Chen、Alex Reneau 與 Kevin Flansburg，文中將它描述為 Cloudflare 訓練的發布版本，並表示這些模型是在內部以開源權重的上游基礎模型「後訓練」而成。這並非 Cloudflare 取得的第三方檢查點。

• Hugging Face 命名空間。權重位於 huggingface.co/Cloudflare/clef-flash。這就是 cloudflare/clef-flash 這個字串會流傳的原因：它是一條儲存庫路徑，形式與任何其他由組織擁有的儲存庫相同。這是這兩個詞最常一起出現的原因，而它並非代管的主張。

• 推論主機，同時也是 Cloudflare。 所提供服務的模型 ID 是 @cf/cloudflare/clef-flash，透過 Workers AI 在 api.cloudflare.com/client/v4/accounts/<account_id>/ai/run/@cf/cloudflare/clef-flash 上執行。因此，要描述的託管安排並不是市集列表中中立意義下的「由 Cloudflare 託管的模型」。而是供應商在自己的平台上提供自己的權重。

實際後果是這樣的：模型、授權許可、API 端點與帳單全都歸結到同一家公司，而若讀者原本以為它們之間存在一層獨立的主機代管層，那麼針對這個檢查點，他們並沒有第二家供應商可以依靠。Apache-2.0 的權重是唯一能脫離這種處境的出口，而且它們是真實存在的——詳情見下文。就我們所能找到的任何廠商頁面所述，並非事實的是，Clef-Flash 有透過任何其他推論供應商提供。Cloudflare 自家的資料並未提及任何第三方平台，我們也沒找到任何一家有提供它。

大小、架構與授權

這些數字，無論是來自模型儲存庫本身，還是來自 Cloudflare 的文件，今天讀到的都是：

• 參數 — BF16 下為 9,409,813,744，因此「9B」是向下取整，並非誇大。視覺塔也計入這個總數。

• 主幹 — Qwen3.5-9B，於後訓練期間凍結，包括其視覺編碼器，以標準分片 safetensors 格式儲存。共四個分片，權重總計約 18.8 GB。

• 訓練好的部分——一個「聯合結構頭」（joint schema head），是重 243.5 MB 的小型 Transformer 頭，負責讀取主幹模型的最終隱藏狀態、將證據從該狀態導向每個問題，並聯合為每個問題的每個選項評分。每個允許的選項對應一個 logit；對每個問題做 softmax 即可得到分佈。

• 訓練方法，如 Cloudflare 所述 —— 路由頭與 rank-256 低秩適配器一併在凍結的主幹網路上進行最佳化，並以標籤平滑交叉熵確保結構描述的有效性，搭配旨在進行機率校準的 Brier 損失，再加上一項 Cloudflare 稱為 Reinforcement Learning for Calibrated Decisions 的次要目標。

• 授權——Apache-2.0，以模型卡本身的說法，是「沿用基礎模型」。授權條款並未限制商業使用，且權重並未設有管制：該儲存庫無需申請存取即可下載。

這件事的形態——所有受訓練的部分都位於一個 243 MB 的頭部，鎖接在凍結的 18.8 GB 主幹上——正是我們該認真看待這份架構描述、而非將其當作行銷話術的原因。這個模型不可能學到新的世界知識，因為承載知識的權重從未變動。它學到的是如何把證據導向一項決策。那是一種真實的能力，而且是有界線的能力，而這比任何準確度宣稱都更能解釋本頁後段的基準測試模式。

上下文視窗與輸出上限

這是已經變動的數字；如果你今天要估算提示詞的規模，應該讀取目前的數字，而不是發表時流傳的任何數字。

Cloudflare 的 Workers AI 模型頁面，針對 @cf/cloudflare/clef-flash，於 2026 年 10 月 12 日查閱，指出上下文視窗為 24,576 個 token。10 月 1 日的公告文章說法不同——「我們的模型有 64k 上下文視窗（相較於 Jev 的 32k）」——而 Hugging Face 卡片本身的 encode_record helper 預設為 max_length=16,384。相較之下，27B 的 Workers AI 頁面 clef 給出 65,536 個 token，而 clef-omni 的頁面則給出 64,000。

坦白說：針對這個特定模型，廠商目前文件寫的是 24,576，而發布貼文說的卻是 64k。這是廠商自家兩個來源彼此矛盾，而其中只有一個是開發者實際據以整合的頁面。如果你是衝著那篇公告、按照 64K 的預算來建構提示詞，那麼文件所記載的上限現在大約只有那個數字的三分之一。送出前請先確認。

媒體輸入同樣會計費，並計入同一份預算，而這正是最要命的細節。圖片以 32×32 像素區塊進行 token 化，另加三個標記 token，每張圖片上限為 1,024 個 token；超過約一百萬像素的圖片會被縮小，低於約 65,000 像素的則會被放大。若媒體 token 加上你的提問 token 超出視窗，請求會直接失敗。若未超出，文字 狀態會被截斷以配合剩餘空間——悄悄地從尾端截斷，不會拋出任何錯誤。某天還塞得下的 schema，在文件量龐大的一天就會悄悄遺失部分狀態。

最大輸出量並未公開。Cloudflare 的模型頁面只說明「Clef 模型不對輸出 token 收費」，而回應結構定義帶有一個usage.output_tokens欄位，且未記載上限。這不是能用猜測掩蓋過去的疏漏：非自迴歸評分器並沒有自迴歸模型那種意義下的解碼預算，而供應商也未記載任何限制，因此沒有上限可引用。如果你需要一個數字，該思考的是你的選項數與題目數，而不是輸出的 token 數。

輸入的模態，以及確切回傳的內容

廠商的描述與請求結構描述在輸入端一致，但在某一點上略有分歧，因此以下是差異所在。

• 輸入，依模型卡所示 — 任意形狀的文字、JSON 或結構化資料、影像，以及影片影格陣列。純文字與多模態記錄可在同一批次中混合，媒體參數會透過選用的 media_kwargs 欄位傳遞至處理器。

• 輸入，依 Workers AI 請求結構描述 — 文件記載的參數清單顯示了一個 images 陣列，且沒有影片參數，最多 4 張圖片，每張圖片為 4 MiB 與 1600 萬像素，解碼後總計 8 MiB，而整個要求主體上限為 13 MiB。僅限內嵌位元組：不接受遠端 URL。

• 輸出 — 針對你定義的選項，在 answers 物件中提供機率，並依問題類型採用三種形式之一。不得使用自由格式文字、Markdown 或工具呼叫。

把這個差異理解為託管層面的區別，而不是矛盾。checkpoint 處理的是視訊影格；你透過 HTTP 呼叫的 Workers AI 端點處理的則是圖片。如果視訊是你計畫的一部分，該走的是自架這條路徑。

Cloudflare 聲稱的內容，以及實際測量到的結果

本節的每一項數據都來自 Cloudflare，而且全部都由 Cloudflare 執行。這是本頁最重要的一句話，因此值得具體說明其背後的機制。

基準測試套件是 Decision Index 0.2.1。模型卡將結果描述為「我們的內部執行」，而它連結的公開排行榜託管於 Cloudflare 營運的位址。整篇的對照模型是 TypeSafe 的 Jev，而端到端業務工作流程的數字來自 Typesafe Evals。所以這個比較是：一家供應商在一個以其被比較的競爭對手命名的指數上，衡量自家模型，並自行發布結果。沒有任何對 Clef-Flash 的獨立評估。今日查核：Artificial Analysis 沒有它的模型頁面，而 LMArena 文字排行榜完全沒有列出任何標有 Cloudflare 的模型。當供應商未發布第三方分數時，指出這一點本身就是發現。

掛上這個標籤後，決策導向的結果確實強勁：BFCL 案例精確度 98.8、API-Bank 準確率 93.1、ContractNLI 巨觀 F1 84.3、RouterBench 79.9、FinEntity 97.1，以及家用電器模擬器的案例精確度 97.7——最後一項在同一列上比更大的 27B Clef 高出十四分。一般知識列也站得住腳：MMLU 91.8、ARC-Easy 99.5、ARC-Challenge 98.3、WinoGrande 97.5、HellaSwag 98.6、CLadder 97.7，以及 ForecastBench Brier 10.6，這是該欄中最佳，也正是評判一個會產生機率的模型時該看的那種校準數字。

這些落後數據應該放在同一段，而且它們呈現出一種模式。在 CLINC150 上，於具備 out-of-scope 處理的情況下，Clef-Flash 的 macro-F1 得分為 66.8，而 27B Clef 為 97.4，Jev 為 89.3。在 ANLI 上，它得到 59.1，而 Jev 為 74.8。在 When2Call 上為 65.6，對比 81.0。在 GPQA Diamond 上為 51.0，對比 78.3。在 RAGTruth 上為 35.6，對比 76.5。而在 POP909-CL 這個和弦標註基準上，它回傳 1.6。

範圍外意圖偵測拿到 66.8，旁邊卻是家電控制的 97.7，這並不是一條平滑的能力曲線。它反映的是一個評分器的樣貌：它對自己在後訓練階段所學到的分類型態非常擅長，但在正確答案是「以上皆非」時，要它拒絕分類就弱得多——而尷尬的是，這正是路由層或分流管線最需要的那種判斷。和弦標註上的 1.6，要嘛是格式不相符，要嘛是真正的失敗，而這張模型卡並沒有區分兩者。

工作流程結果（來自 Typesafe Evals）比主要列所呈現的更參差不齊：發票處理精確動作 57.1，對比 Clef 的 64.7 與 Jev 的 61.8；客戶服務精確動作 77.0，領先兩者；安全事件 61.7；代理軌跡可觀測性 69.8。27B 同系列模型在工作流程表中五列贏了三列。

延遲正是這款模型名副其實之處，而同樣的但書也適用。中位數請求延遲為 38.8 毫秒，p95 為 122.4 毫秒，由 Cloudflare 在 Cloudflare 基礎設施上測得；相較之下，27B Clef 為 209.3 / 238.6。來自廠商自家硬體的絕對毫秒數，既不構成任何事物的上限，也不構成任何事物的下限；真正的主張在於排序，而這個排序——大約比自家體型更大的同門型號快五倍——正是架構兌現其說法的證明。

讀者實際上怎麼稱呼它

存在兩條路徑，而它們確實是截然不同的承諾。

託管路由。在 Workers AI 上呼叫它，使用 @cf/cloudflare/clef-flash，可從 Worker 內透過 env.AI.run() 綁定，或使用 bearer token 透過 REST 在 Cloudflare API 端點呼叫。必填欄位為 model、state 與 questions；model 選擇器必須符合模式 ^\s*(clef|clef-flash)\s*$，這是在同一個端點上區分 27B 與 9B 變體的方式。Workers AI 模型頁面和 Workers AI 定價頁面上的定價為 每百萬個輸入 token $0.038，其中媒體會以相同費率轉換為輸入 token，且輸出 token 不收費。

自行架設的路線。權重採用 Apache-2.0 且不受閘控，因此你可以自行執行。這份 model card 記載了一條參考路徑：在單張 H200 上使用 torch 2.11 與 transformers 5.10.2，並以 pillow 處理影像與視訊輸入，同時指向 SGLang cookbook 以取得 H200、B200 與 B300 的啟動指令。以這種方式提供服務時，模型會在 /v1/systemone。

那條路徑並非偶然，因為這正是這個模型值得理解、而不只是拿來使用的原因。用卡片上的話來說，Clef-Flash「與 Jev 和 SystemOne 完全相容」：它接受 Jev/SystemOne 請求主體，並回傳相同的回應主體——model、answers 以問題 ID 為鍵，usage。這種相容性是刻意設計的，因此後來對儲存庫的一次提交還明確加上了 systemone 進入點。如果你的管線已經以那種形式向決策模型提問，那麼替換成這個模型只需要改一個模型字串和一個 URL，而不是一次遷移。這是切換成本實實在在的降低，也是這裡唯一的一項架構事實，會改變讀者能做什麼。

一則路由說明，以事實而非推銷來說明：OrcaRouter 並不提供 Cloudflare/clef-flash。我們今天查了我們的即時型錄，它並不在那裡，而本頁任何內容都不應被解讀為聲稱我們有提供它。我們的型錄確實有收錄的，是 Clef-Flash 當初設計要能無縫替代的模型——TypeSafe 的 Jev 1.13 就在我們的型錄上，其定價表顯示每百萬輸入 token 為 $0.042（本頁的快速資訊徽章將其四捨五入為 $0.04），具備 65K token 上下文，以及相同的 POST /v1/systemone 端點類型。由於兩者使用同一種傳輸格式，在它們之間切換只是變更設定而非重寫，這正是為什麼要讓兩者都能透過同一把金鑰存取，而不是讓架構綁定在最先推出的那個模型上。OrcaRouter 以 供應商標價原樣傳遞、不加價的方式運作，因此任一供應商調價，我們這邊當天就會同步生效。

還有什麼仍然開放？

三件事，依它們會改變局面的順序排列。

Cloudflare 以外的人必須同時重現 CLINC150 的 out-of-scope 與 home-appliance 儲存格，因為兩者指向相反的方向，而公開的執行結果對兩者都沒有提供機制。如果 66.8 在獨立測試下仍成立，那會是關於 Clef-Flash 在實際運作上最重要的事實，而它並不在公告的優勢清單中。

上下文視窗需要供應商提供一個統一後的數字。現在，模型自己的說明文件頁面寫的是 24,576 個 token，發布文章說的是 64k，而隨附的編碼輔助工具則預設為 16,384。任何在為正式環境提示詞估算大小的人，都只能在供應商的三種說法中選擇相信哪一個。

而且這個類別需要與生產規模的真實工作負載接觸。Cloudflare 的說法是，決策模型位於熱路徑上——他們文章中的一個網域分類範例顯示，Clef 在同一項工作上以 2.2 秒回傳判定結果，相較之下，通用型模型則需 4.7 秒。這是一項針對特定工作流程、具體且可測試的主張，而它將由實際運行它的人來定奪，而不是由一張表格來決定。