Clef-Flash 是個從不寫出任何詞元的 9B 模型——而 Cloudflare 的部落格文章在權重釋出後將近一天才出現

Cloudflare/clef-flash 是一個擁有 90 億參數的多模態模型，接收一個狀態以及一份由具型別問題構成的結構描述，並為每個允許的答案回傳一個機率。它不會生成文字。不是「它生成文字生成得很糟」——它根本沒有任何文字輸出路徑。它的儲存庫於 2026 年 9 月 30 日 21:15 UTC 在 Hugging Face 上出現，採 Apache-2.0 授權；Cloudflare 介紹它的公告貼文，連同更大的 27B Cloudflare/clef，於隔日 15:34 UTC 發布。大約有十八個小時，開放權重與代管的 Workers AI 端點都公開存在，而廠商對它們隻字未提，而這個先後順序是這次發布中最有趣的事實——對任何正在決定是否要把這個接入管線的人來說，都比任何單一基準測試列更有趣。

兩天後又出現了一道較小的波折。某個第三方執行環境的 clef-flash 函式庫頁面——本文的雷達最初就是在這裡看到這個模型——在其模型表中將它列為「256K 上下文視窗」，卻在幾行之上呈現 Cloudflare 自家的 readme 文字：「64K 上下文視窗：是 Jev 的 32K 視窗所能容納狀態的兩倍」。這兩個數字不可能同時正確，而廠商的說明文件判定以較小的那個為準。這種落差值得一開始就點出來，因為這篇文章裡的其他一切，都取決於同一個問題：哪些數字是廠商給的、哪些是鏡像站給的，以及哪些經過了廠商以外任何人的查核。

實際上線了什麼，以及以什麼順序

該紀錄，在

• 2026 年 9 月 30 日 21:15:35 UTC — Cloudflare/clef，這個 27B 模型，已在 Hugging Face 上建立。

• 2026年9月30日 21:15:36 UTC — Cloudflare/clef-flash 於一秒後建立。兩者皆為 Qwen 基礎模型的微調版本：Clef 來自 Qwen3.8-27B，Clef-Flash 來自 Qwen3.5-9B。

• 2026年10月1日 15:23 UTC —— clef-flash 的儲存庫最後修改時間，大致就是我們所引用的模型卡文字撰寫的時間。

• 2026年10月1日 15:34 UTC ——〈隆重推出 Clef：我們的開源決策模型，以及全新的 RL 微調平台〉一文在 Cloudflare 部落格上線，將兩個模型託管於 Workers AI，並圍繞它們推出一項微調服務。

• 2026 年 10 月 2–3 日 —— 第三方執行環境開始支援這些權重；某個第三方執行環境的函式庫頁面與社群量化版本隨之出現。

所以這不是外洩，不是悄悄發布，也不是一個未經公告、讀者只能把它當成傳聞的檢查點。這是一次 GA 正式發布：有部落格文章、有在 Cloudflare 自家邊緣 GPU 上代管的 API、權重採用 Apache-2.0 授權條款，還附帶一個商業微調平台。唯一真正古怪的地方，是這個儲存庫比公告早了十八小時——長到足以讓模型已經公開，而供應商自家的行銷頁面卻還不存在；短到足以讓 Cloudflare 以外沒有人真正認真地跑過它。

決策模型並非小型語言模型

Cloudflare 文章中的論述框架是：決策模型是一個獨立類別，而架構是支撐這項主張，而非僅是點綴。Clef-Flash 將 Qwen3.5-9B 主幹（包括其視覺編碼器）保持凍結。在其之上有一個小型 transformer head——此次發布版本中權重為 243.5 MB，對比約四個分片主幹檔案、總計達 18.8 GB——它會將來自狀態的證據路由到每個問題，並在一次傳遞中為每個問題的每個選項評分。Cloudflare 稱之為「非自迴歸」（non-autoregressive）：沒有逐 token 生成，沒有中間推理文字，沒有輸出解析。每個允許的選項會得到一個 logit，對每個問題做 softmax，你就得到一個分布。

請求的結構即由此而來。你提供state —— 一個字串，或一個 JSON 物件或陣列 —— 一組選用的圖像或視訊影格，以及一到六十四個具名問題。每個問題會宣告一個 type：noul 用於真／假判斷，回傳為真的機率；choice 用於具名選項集，回傳所選選項以及各選項的機率和一個信心值；或 score 用於有序尺度，回傳以機率加權的等級。準則對 noul 而言是選用的，對其他類型則近乎必要，而文件對一個陷阱異常直白：信心「顯示機率有多集中。它並不是答案正確的機率。」一個回答得很有信心的模型，不一定答得正確，而唯有校準量測才能區分這兩者。

這個區別正是它值得關注的全部理由。如果你曾經請通用模型分類一張客服工單，然後試著解析它的回答，你早就付過這套設計所免除的代價了。Clef-Flash 沒辦法產出「這看起來像帳單問題，大概吧？」這樣的句子，因為它根本無法產出句子。它回傳的是{"choice": "billing", "probabilities": {"billing": 0.981, ...}, "confidence": 0.924}——這個範例直接取自 Cloudflare 自家的文件——再由你的程式碼對它做閾值判斷。

這些數字，以及是誰經手的

下方每一項數據都來自 Cloudflare 的模型卡或該篇部落格文章，而且全部由 Cloudflare 執行。這套測試套件是 Jev Decision Index —— 一個由 TypeSafe 發布的排行榜，而 TypeSafe 正是 Jev 的供應商，也就是 Clef-Flash 所對標的模型 —— 因此這項比較是拿供應商自家產品在競爭對手的指數上受測，並由該供應商親自執行。目前尚無對 Clef-Flash 的獨立評估，本文也不假裝有。

在決策專屬的基準測試上，Clef-Flash 的強勁表現確實值得與行銷話術分開來看：BFCL 案例精確度 98.8、API-Bank 93.1、家用電器模擬 97.7、ContractNLI 巨觀 F1 84.3、RouterBench 79.9。它在 BFCL（98.8 對 98.5）、API-Bank（93.1 對 91.9）以及家用電器測試套件（97.7 對 83.0）上都擊敗了規模更大的 27B Clef——最後一項領先十四個百分點，這是整張表中最令人意外的一格，也是 Cloudflare 以外沒有人查核過的一格。

這些損失同樣真實，也該放在同一段裡。在帶有範圍外處理的 CLINC150 上，clef-flash 拿下 66.8 的 macro-F1，對比 27B 的 97.4 與 Jev 的 89.3——在帶有「other」分類桶的意圖偵測上出現三十點的斷崖落差，而這正是路由層最常看到的請求樣態。在 ANLI 上它得到 59.1，Jev 則是 74.8；在 When2Call 上 65.6，Jev 為 81.0；在 GPQA Diamond 上 51.0，Jev 為 78.3。而在 POP909-CL 這個和弦標註基準上，它拿到 1.6——這個數字不是資料格式不相容，就是貨真價實的失敗，而卡片上並未說明是哪一種。

延遲表正是這款模型名副其實之處。中位數請求延遲為 38.8 毫秒，p95 為 122.4 毫秒，相較之下，27B Clef 為 209.3 / 238.6，Jev 為 524.1 / 536.0。Cloudflare 是在自家基礎設施上進行測量，因此請把這些絕對毫秒數視為你在其他地方可能看到的上限，但排序——flash 版本比自家更大的同系列型號快約五倍半，在中位數上比 Jev 快十三倍——正說明這項設計確實如宣傳般運作。

各列表唯一有分歧的那個數字

上下文視窗是會讓人吃苦頭的數字，因為它就是被抄錯的那一個。Cloudflare 的 Workers AI 文件針對 @cf/cloudflare/clef-flash 記載的上下文視窗為 65,536 個權杖。那篇部落格文章說「我們的模型有 64k 上下文視窗（相較於 Jev 的 32k）」。模型卡自己的編碼輔助工具預設為 max_length=16,384 個權杖。另一方面，某個第三方執行環境的函式庫清單則在其表格中宣稱支援 256K。

三個廠商來源都一致認為大約是 64K，而一份第三方列表則說那是這個數字的四倍。如果你憑著某個函式庫頁面，把提示詞大小估在 256K 的預算之下，你會在發出請求時才知道實情。誠實的解讀是：文件記載的上限為 65,536 個 token，但要注意，Cloudflare 自家的發行說明從未將模型卡的 16,384-token 預設值與此對照——這是預設值，不是限制，但如果你照原樣使用隨附的載入器，它會默默影響你會傳送多少狀態。

你可以在哪裡呼叫它，以及不能在哪裡呼叫它

Clef-Flash 目前還不是 OrcaRouter 上提供的路由之一。我們的目錄查詢它會回傳 404，因此本文任何內容都不應被解讀為我們對其可用性的聲明——如果你想現在就用，Cloudflare 已在 Workers AI 上託管它，每百萬個輸入 token 收費 0.09 美元，而 Apache-2.0 授權的權重則可供你自行在本機執行。

對這篇文章真正要討論的那項決策而言，這意味著：一個只能透過單一供應商平台才能觸及的評分器，其延遲與可用性都會連同準確度一起由你繼承。具有路由途徑的託管替代方案是 TypeSafe 的 Jev 1.13，它在 OrcaRouter 上每百萬輸入 token 收費 $0.042，上下文長度為 65,536 個 token，而 Cloudflare 刻意選擇它作為基準對照模型，因為兩者彼此 API 相容。Clef-Flash 採用相同的/v1/systemone請求格式，因此兩者可以在一層薄轉接器之後互換。能透過同一把金鑰觸及這兩者，且供應商定價按原價轉嫁、不加收任何費用，這正是應該讓這項比較持續保持活躍、而不是把架構押在剛好最先推出哪個模型上的理由。

什麼會改變這個讀數？

三件事，按它們能多大程度改變局面來排列。

Cloudflare 以外的人需要重現 CLINC150+OOS 與 home-appliance 這兩個儲存格，因為它們指向相反方向，而模型卡對兩者都沒有提供任何機制。在範圍外意圖偵測上拿到 66.8，緊接著在家電控制上拿到 97.7，並不是一條平順的能力曲線；這暗示這個模型非常擅長其訓練分布中的分類樣態，卻在正確答案是「以上皆非」時，明顯較弱於拒絕進行分類。如果這在獨立測試下成立，那就是關於 clef-flash 最重要的營運事實，而它並不在重點摘要區段裡。

64K 與 256K 的清單差異需要有個來源來更正，因為它目前正從某個鏡像向外擴散，進入人們真正會閱讀的地方。廠商文件通常不是你得引用來在針對 runtime 卡片的爭論中勝出的東西，而這正是一個確實如此的小案例。

而這個類別必須經得起真實工作負載的考驗。Cloudflare 自己的說法是，決策模型就位於代理的熱路徑上——在他們的 Threat Intelligence 範例中，抓取、渲染與分類一個網站要兩秒，而他們最快的通用 LLM 做同一件事要 4.7 秒。這是一個關於真實且具體工作流程的真實且具體主張，而這類主張是由實際運行它的人來定論，而不是靠一張表格。