Clef：Cloudflare 的 27B 決策模型究竟是什麼

Clef是 Cloudflare 發佈的 270 億參數多模態決策模型。你給它一個狀態——字串、JSON 物件、圖片、影片片段——再加上最多 64 個具型別問題的結構描述，它就會在單次前向傳遞中，為每個問題的每個允許選項回傳機率。整個流程中完全沒有文字生成，也不需要解析輸出：模型為每個允許選項發出一個 logit，你依問題進行 softmax，就完成了。權重採用 Apache-2.0，並存放於 Hugging Face 上的 Cloudflare/clef 儲存庫；Cloudflare 也透過自家的 Workers AI 平台提供此模型。

有兩個日期有助於定位脈絡，但這頁之所以存在，原因與它們都無關。權重於 2026 年 9 月 30 日發布，而 Cloudflare 的公告文章日期為 2026 年 10 月 1 日，這使得 Clef 在本篇撰寫當天已問世十二天——久到稱不上新聞，而這頁也不把它當作新聞處理。它之所以存在，是因為「clef」是人們真的會輸入的查詢詞，而到目前為止，這個部落格上沒有任何內容回應它。發布這件事只是用來推算模型日期的依據；下方這些參考資料才是重點。

尺寸問題，由出版商定案

有兩組參數量並列流傳，而其中只有一組屬於這個模型。

• Clef 是 27B。 Cloudflare 自家的模型頁面將其描述為「一個 27B 多模態決策模型」，而 Hugging Face 的模型卡也在開頭寫道：「Clef 是一個 27B 多模態模型，能將狀態與一份型別化問題的結構描述轉化為決策。」

• 9B 是另一個模型，不是這個模型的另一種尺寸。 9B 檢查點是 Clef Flash，是一個獨立的同系列模型，擁有自己的儲存庫和自己的模型頁面。任何搜尋 9B Clef 的人，其實要找的是 Clef Flash。兩者不能互換，數據也不能混用。

• 還有第三個成員。Clef Omni 於 2026 年 10 月 9 日發表，是一款 30B 的混合專家模型，具備 3B 活躍參數，建構於不同的主幹架構之上。它同樣能讀取音訊。如果你曾看到「30B」與 Clef 相連，那指的是 Clef Omni，而非 Clef。

所以這個頁面上的模型大小是 27B，句點。而這個儲存庫以 BF16 safetensors 格式提供它。已發布的檔案集總共約 55 GB，分散在二十五個檔案中，如果你打算自行託管而不是呼叫它，這才是關鍵數字。

Clef 與 Clef Flash 的關係

Cloudflare 將 Clef 作為一個系列推出，而這個系列結構本身才是重點，並非附帶一提。Clef 與 Clef Flash 共用一套配方：為較大的模型凍結 Qwen3.8-27B 主幹，為較小的模型凍結 Qwen3.5-9B 主幹，保留視覺編碼器，並在其上訓練一個小型聯合結構頭以及低秩適配器。相同的輸出契約，不同的容量，以及截然不同的延遲表現。

這個共用的契約，正是兩個模型值得一起理解的原因：為其中一個撰寫的 schema，就是另一個的 schema，而要切換由哪一個來回答，只需要改動模型識別碼，而不必重寫。這是一場速度與能力之間的取捨，而 Cloudflare 自己 10 月 9 日的文章讓這個取捨更加鮮明：它把 Clef Flash 的託管價格調降到每百萬輸入 token 0.038 美元，同時讓 Clef 維持在每百萬輸入 token 0.24 美元。請注意那篇文章還做了什麼：它把 Clef Flash 的託管上下文視窗縮減到 24,000 個 token，低於先前為它宣傳的 64,000 個，而 Clef 本身則維持在 64,000 個。

架構：一個凍結的骨幹，加上一個評分頭

Clef 並不是一個戴著分類器帽子的語言模型。這項設計值得精確說明，因為它幾乎解釋了這個模型的其他所有特性。

• 主幹 — Qwen3.8-27B，包含其視覺編碼器，沿用並凍結，以一般分片 safetensors 儲存。

• 聯合結構頭 — 一個小型 Transformer 頭，會讀取主幹網路的最終隱藏狀態，將來自該狀態的證據路由到每個問題，並聯合為所有問題的所有選項評分，而不是一次只處理一個問題。

• 訓練 — 秩為 256 的低秩適配器、標籤平滑交叉熵，外加用於校準的 Brier 損失，以及 Cloudflare 的「Reinforcement Learning for Calibrated Decisions」迴圈。

• 輸出 — 每個問題的每個允許選項各有一個 logit。對每個問題做 Softmax 就會得到機率。不會有其他輸出。

聯合評分是讓 Clef 有別於一堆獨立分類器的地方。因為所有問題都在單次傳遞中對同一個隱藏狀態評分，所以問題之間可以互相提供資訊，而整體是非自迴歸的——沒有解碼迴圈，延遲數字正是由此而來。Cloudflare 將這種推論描述為僅預填的傳遞。

背景脈絡、限制，以及輸入的內容

就情境與模態而言，廠商的資料說得很具體；而在它未著墨之處，那份沉默值得記錄下來，而不是粉飾帶過。

• 上下文視窗 — 根據模型頁面，Cloudflare 託管的 Workers AI 端點為 65,536 個 Token。那正是 Cloudflare 發布文章與其歸給 TypeSafe 的 Jev 的 32,000 個 Token 視窗對比時所引用的數字。

• 自架環境的上下文 — Cloudflare 於 10 月 9 日的文章指出，Hugging Face 權重經過訓練，若你自行執行，可支援 256,000 個 token 的視窗。該儲存庫中隨附的編碼器預設為 max_length=16,384，這是預設值而非上限，但如果你使用隨附的載入器，這就是你會得到的結果。

• 最大輸出 — 未公布。沒有可公布的 token 預算：模型會針對每個問題回傳固定的機率向量，因此自然的限制是結構定義（1 至 64 個問題，每個問題有 2 至 26 個選項），而非以 token 計的長度。

• 輸入模態——文字、JSON、圖像與影片。Workers AI 頁面標示支援視覺功能，並接受 PNG、JPEG 或 WebP 圖像，每筆請求最多四張。Clef Omni 則另外加入了音訊；Clef 本身則無。

• 輸出模態——機率。Clef 無法草擬回覆、摘要討論串或產出句子，也不會憑空捏造你未宣告的類別。

• 授權條款 — Apache-2.0，沿用 Qwen3.8-27B 基礎檢查點。Cloudflare 的模型頁面並未在頁面文字中寫明授權名稱，而是連結至授權檔案；該授權檔案本身即為 Apache-2.0。

有一個實作細節被記載為陷阱，值得反覆強調：信心欄位回報的是機率有多集中，而不是答案正確的機率。一個校準良好的模型可能回傳低信心的正確答案，也可能回傳高信心的錯誤答案。

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

這是需要仔細閱讀的部分，因為標題兩半之間的間距很寬。

所有附在 Clef 上的效能數據都來自 Cloudflare。該模型卡發布了一份四十多行的表格，出自其描述為「我們對 Decision Index 0.2.1 套件的內部執行」，而那個排行榜是由 Cloudflare 代管。其下方的 workflow 評估取自 TypeSafe 的公開評估集，但這次執行仍然是 Cloudflare 自己的。截至今日，我找不到針對這兩張表格中任何一張的獨立第三方重現——沒有外部實驗室、沒有中立排行榜，也沒有已發表的重複驗證。請把這些數字視為供應商的最佳情況，而非實測數據。

這些數字背後所呈現的模式，比任何單一數據點都更具資訊量。Clef 最亮眼的結果出現在分類類型的任務上：在 Cloudflare 的測試中，它在 BANKING77 意圖分類上回報 94.2 的 macro-F1，相較於 Jev 的 79.7；而在具備範圍外處理的 CLINC150 上則回報 97.4 的 macro-F1，相較於 89.3。範圍外的那個數字才是營運上真正值得關注的，因為拒絕分類正是路由中最困難的那一半。它同時回報在 BFCL 上達到 98.5 的大小寫完全精確率，以及在 CRUXEval 上達到 86.7。

這些落後之處一致地指向同一方向。在同一張表上，Clef 報告 GPQA Diamond 為 48.0，而 Jev 為 78.3；MMLU-Pro 為 65.9，而 Jev 為 82.7；BBH 為 73.7，而 Jev 為 92.9。這是表中三個最大的差距，而且它們都描述同一個弱點：在模型受訓時所見形態之外的推理。在四項端到端工作流程評估中，這兩個模型足夠接近，因此其排序結果不構成發現。

延遲是唯一一處優勢屬於結構性而非邊際性的地方，因此也是最有可能經得起生產環境考驗的一項。Cloudflare 回報，Clef 的中位數為 209.3 毫秒、p95 為 238.6 毫秒，相較之下 Jev 為 524.1 毫秒與 536.0 毫秒。這樣的排序源自非自迴歸式設計，而非基準測試的偶然特性——但那些絕對毫秒數是在 Cloudflare 自家硬體上測得的，單獨來看意義不大。

值得留意的是，對於已經在本部落格讀過 Clef 基準測試表的人來說：服務層的數據在 10 月 9 日有變動。Cloudflare 將 Clef 的服務層改用 SGLang，並將這項工作貢獻到上游，回報在約 800 個輸入 token 時中位數加速 1.7×，在約 3,400 個 token 時則為 2.0×。這些是服務層的變更，不是新的權重，模型本身並未改變。如果你引用的是 10 月 9 日之前的延遲數據，那就已經過時了。

呼叫 Clef，並正確處理與 Cloudflare 的關係

它有兩種執行方式，而兩者都不神秘。

第一個是 Cloudflare 自家的端點。Clef 由 Workers AI 提供服務，那是 Cloudflare 自家的推論平台，每百萬個輸入 token 收費 0.24 美元，輸出 token 不收費——這是因為根本沒有輸出 token。媒體輸入會轉換成 token，並以相同的輸入費率計費。這是發布者自行託管自家模型，而這就是這段關係的全部：把這個模型名稱與 Cloudflare 配對的搜尋結果，並不是指向某個恰好加入它的第三方主機。Cloudflare 打造了它。

第二個是你自己的硬體。權重以 Apache-2.0 授權放在 Hugging Face 上，因此允許自行託管，無需商業洽談。Cloudflare 自家的測試是在單一 H200 上使用 torch 2.11 和 transformers 5.10.2，而影像與視訊輸入則需要 pillow。如果你曾讀到 Clef 也能在 SGLang 上執行，就 10 月 9 日的服務變更而言，這是正確的；上游工作預定在 SGLang 0.5.22 中發佈。

這套 API 的形態刻意不追求新奇。Clef 的請求與回應主體與 TypeSafe 的 SystemOne 格式相容，因此，一條已經接上該形態決策模型的管線，只要改一個 URL 和一個模型字串，就能把流量指向 Clef。這是個貨真價實的轉換成本論點，而且是雙向成立的——這才是誠實的解讀方式：正因為介面相同，採用 Clef 很便宜，放棄它也同樣便宜。對決策端點已經在生產環境運行的團隊來說，明智的做法是拿自己的實際流量同時跑兩者，而不是直接遷移。如果你透過 OrcaRouter 路由，TypeSafe 的 Jev 1.13 是我們型錄上架的一個模型，因此現有方案與你自架的任何模型之間的 A/B 測試，只需一組金鑰而非兩份合約——200 多個模型，供應商定價原樣傳遞、不按 token 加價，以及為你處理好容錯移轉。

這一頁不會告訴你的一件事，就是 Clef 是否能透過我們取得。Cloudflare 將它發佈在 Workers AI 和 Hugging Face 上，而我尚未查證是否能經由我們自家的模型清單取得，所以沒有什麼可宣稱的。

還有什麼尚未解決？

對 Clef 而言，最有用的一件事，就是由外部對 Decision Index 進行複製。這套測試套件是公開的，且 Cloudflare 將這些評估描述為可重現，因此第三方執行與否，就是廠商表格與事實之間的差別。在這種結果出現之前，對 Clef 已公布概況的誠實總結是：它是一個非常強大的受限分類器，採用快速、非自迴歸的設計；而作為通用推理器，則明顯弱於它被拿來做基準比較的模型。

有三件具體的事會改變這個判讀。對 BANKING77 與 CLINC150 範圍外數字的中立重現，因為比現有方案高出 30 個百分點的差距，要麼就是全部真相，要麼就是假象。在真實併發下的一個 p95 數值，因為在單一 H200 上測得的 209 毫秒中位數，並不能說明負載下的熱路徑。以及一個微調後的 Clef，能在基礎模型從未受訓的任務上勝過基礎模型；這正是 Cloudflare 的 RL 微調平台旨在產出、卻尚未以客戶成果證明的事。

在那之前，讀者所能憑靠的是這個東西的輪廓：27B 參數、一個帶有視覺功能的凍結 Qwen3.8-27B 骨幹、一個聯合頭部、65,000 個詞元的託管上下文，輸入文字、JSON、圖像與影片，輸出機率，Apache-2.0。這足以判斷該架構是否契合你的問題。它還無法回答的問題是，廠商自家的評分板對這個模型的評價是否正確，而 Cloudflare 以外沒有人查核過。