Clef 與 Qwen3.8-27B：一個骨幹，兩種輸出契約

Clef無法寫出一個句子，而它是由一個能寫句子的模型打造而成。Cloudflare/clef 是一個擁有 270 億參數的多模態決策模型：你交給它一個狀態，以及一份由具型別問題組成的 schema，它就會針對每個允許的選項回傳機率，而不會產出任何一個散文詞元。它底層的主幹是 Qwen3.8-27B，一個開放權重的稠密視覺語言模型，被凍結固定住，並額外接上一個小型頭部。這使得本頁成為少數「模型對模型」頁面之一，其中雙方根本不是競爭對手——它們是一個檢查點及其衍生模型，共享 55 GB 的權重，卻對答案究竟是你讀到的東西，還是你用來計算的東西，抱持不同看法。

兩者的權重都比官方說法更早公開。Cloudflare 於 2026 年 9 月 30 日 21:15 UTC 在 Hugging Face 建立了Cloudflare/clef儲存庫，採用 Apache-2.0 授權，並在隔天下午發布公告文章——〈隆重推出 Clef：我們的開源決策模型，以及全新的 RL 微調平台〉。在大約十八個小時裡，一個 55 GB 的模型可供下載，並在 Cloudflare 自家的邊緣 GPU 上運行，而其供應商卻對此隻字未提。三天之內，它就有了 Ollama 函式庫頁面，需搭配 Ollama 0.35.1，本文正是在該處發現它的，此外還有來自十幾個不同上傳者的 NVFP4、FP8、EXL3、INT8、Q4 和 Q8 版本。

從這個儲存庫可知的內容異常完整，而將其與不可知的部分區分開來是值得的。可知的是：架構、基礎檢查點、授權條款、可運行的參考實作，以及完整的評估矩陣。不可知的是：這些數字能否在非 Cloudflare 的人員重跑後依然成立。下文歸屬於 Clef 的每一項分數，都來自供應商自行執行其託管套件的結果。相對於一個背後已有一個月獨立使用經驗的模型，這種不對稱正是這份比較誠實的主軸，而本文其餘部分要談的，就是它真正造成影響的地方。

這兩個儲存庫，並排

先從下載開始，因為相同之處正是重點。Clef 的 safetensors 總計 54.97 GB，分散於十二個分片。母模型的則為 55.56 GB，分散於十八個分片。Clef 保留了 Qwen3.8-27B 的視覺編碼器——處理器、視覺塔、整個多模態前端——所以並沒有為了縮小體積而移除任何東西。Cloudflare 加入的是一個 256 MB 的聯合 schema 頭：四層、寬度 1,024、十六個頭、4,096 寬的前饋網路、兩個讀取主幹最終隱藏狀態的路由層。訓練配方是凍結的主幹、那個頭，以及秩為 256 的低秩適配器，並以標籤平滑交叉熵處理有效的 schema 答案，搭配 Brier 損失來銳化校準。

然後，分歧完全在於模型被允許輸出什麼。

• 參數 — Clef 27B，由 Qwen/Qwen3.8-27B 後訓練而成。Qwen3.8-27B 為 27B 稠密模型，64 層，5,120 隱藏維度，248,320 個 token 的詞彙表，16 ×（3 × Gated DeltaNet → FF）與 Gated 交錯排列。

• 輸出 —— Clef：每個允許選項一個 logit，逐題做 softmax，完全沒有生成路徑。Qwen3.8-27B：token、工具呼叫，以及預設開啟的推理區塊。

• 題型 — Clef 每次請求接受 1 到 64 個具型別的問題，共三種形式：noul（為真的機率）、choice（2 到 255 個具名選項）、score（2 到 10 個有序等級，回傳一個可落在等級之間的機率加權值）。Qwen3.8-27B 沒有這種契約；你拿到的是散文，解析器得自己寫。

• 授權 —— 兩者皆採用 Apache-2.0，這正是第三方量化能在一個週末內完成的原因。

• 凍結那一半的成本——Clef 的頭部是 256 MB，而主幹是 54.97 GB。幾乎整個下載內容都是父模型。如果你磁碟上已經有 Qwen3.8-27B，那你就是為了取得對如何回答的不同觀點，而再次下載它。

重新定標題的代價，用兩個數字說清楚

Cloudflare 的評估是 Decision Index 0.2.1 測試套件，在內部執行，而且它是一張關於決策模型的表——六個欄位：Clef、Clef-flash、Jev、DiffusionGemma Jev、Kev 9B 和 Laya。Qwen3.8-27B 在其中沒有資料列，而 Clef 在 Artificial Analysis Intelligence Index 上也沒有資料列。因此並沒有共用的計分板，而本文不會憑空發明一個。

不過，雙方都經歷過的基準測試只有一項，而差距之大，足以讓它成為這次發布中最與決策相關的數字。在 GPQA Diamond——研究所程度的科學選擇題——上，Cloudflare 測得 Clef 為 48.0。母模型在90.5（Artificial Analysis 的測試框架），而89.2（廠商自家的模型卡）。這是常識方面四十分的斷崖，而且並不神祕：Clef 的作答方式是為交給它的一組固定選項評分，而常識型選擇題與「把這張工單分流」之間的距離，已是同一組權重所能被指向的最遠端。請把這項比較視為具指示性、而非受控的——兩套測試框架、兩個實驗室，既不屬於廠商，也不屬於追蹤機構。但方向無庸置疑，而這就是這份合約的代價。

同樣的模式也出現在 Clef 其餘的通用型測試項目上。MMLU-Pro 65.9、BBH 73.7；CLINC150 在含範圍外處理的情況下，27B 拿下 97.4，Jev 則是 89.3——最後這一格是罕見的例外，這個衍生模型在此徹底擊敗較舊的決策模型，而這點很重要，因為拒絕分類正是路由中最難的那一半。Clef 強的地方，恰恰就是一個自家訓練的分類器該強的地方：BANKING77 意圖宏觀 F1 達 94.2、BFCL 案例完全符合率 98.5、API-Bank 91.9。它弱的地方，一個來自競爭實驗室的純文字決策模型——TypeSafe 的 Jev——在 GPQA Diamond 上領先它三十分，收費則是 每百萬輸入詞元 $0.042，而且就列在我們自家的價目表上，這倒是個有用的提醒：「27B」本身並不構成任何論據。

上層所保留的，正是決策索引從不過問的一切。在它自己的卡片上，以及在我們目錄中來自 AA 的資料列裡，記載著：Terminal-Bench 2.1 為 73.0、SWE-bench Pro 61.7、LiveCodeBench v6 90.3、OSWorld-Verified 84.3、DeepSWE 1.1 為 42.2、AA Coding 68.1（在 138 個取樣模型中排名第 35）。這些項目都沒有 Clef 的資料列，因為 Clef 無法嘗試它們。它沒有工具呼叫路徑，沒有長時程規劃，也沒有辦法輸出修補程式。

一個決定要付出什麼代價，以及為什麼輸出行就是全部的論據

Workers AI 模型頁面只列出 Clef 的一個單價：每百萬輸入 token 為 $0.24。頁面上沒有輸出計價行，原因就在回應裡。Ollama 自己文件中的範例——一張支援工單被路由到三個問題——回傳的內容是 "usage": {"input_tokens": 1204, "output_tokens": 3}。三個問題只用了三個輸出 token。Cloudflare 是否對這三個 token 收費幾乎無關緊要：一項決策的輸出成本不是費率，而是問題的數量。

把這拿來對照母模型在我們自家型錄上的價目表，也就是每百萬輸入 token 為 $0.33，每百萬輸出為 $2.40，並具有 262,144 個 token 的上下文視窗。相同的 1,204-token 狀態，相同的單一路由決策：

• Clef — 1,204 個輸入 token 以每百萬 $0.24 計算，約為 每次決策 $0.00029，而每百萬次決策約為 $289。當答案變得更難時，這個數字幾乎不會變動，只有在狀態變得更長時才會改變。

• 在停用思考模式的情況下，Qwen3.8-27B 的相同狀態輸入成本約為 $0.00040，再加上約十個輸出 token，每百萬個 $2.40。算起來大約是 $0.00042，也就是每百萬個 $421。Clef 大約便宜 1.5 倍，而這並不是任何人在說的故事。

• Qwen3.8-27B 在思考功能維持開啟的情況下——這也是此檢查點的預設狀態。如果模型花費 400 個詞元去推理一封密碼重設郵件該歸入四個分類桶中的哪一個，那又是 $0.00096，而該決策的結果會落在接近 $0.0014，也就是每百萬次 $1,357。那 400 個詞元是假設，而非實測值，而倍數會隨之呈線性變動。

所以，定價論點的老實版本比乍看之下更狹窄。面對關閉思考模式運作的通用型模型，Clef 在成本上以約 1.5 倍勝出——這是真實差距，但並不具變革性。面對處於預設配置的同一個模型，差距則是冗長程度的函數；而冗長程度正是語言模型所具備、以評分器評估選項的設計完全沒有的東西。這就是結構性主張：Clef 的成本受狀態長度所限，而父模型的成本則受父模型決定要說多少所限。

唯一不接近的數字

Cloudflare 報告 Clef 的中位請求延遲為 209.3 毫秒，p95 為 238.6 毫秒，這是在其測試中的 43 項基準測試上、於自家邊緣 GPU 上測得的。Cloudflare 以外的任何人都尚未重現此結果，而該供應商的基礎設施正是這個數字之所以如此低的原因——此模型就是設計來與呼叫方位於同一網路上。

對母公司而言，我們能做得比供應商提供的數字更好，因為這是我們的路由之一。在截至 2026 年 10 月 2 日的七天窗口內，OrcaRouter 自家的 playground 測得 Qwen3.8-27B 的 p50 為 1,929 毫秒，且在該窗口的 1.363 億個 token 流量中，輸出速度為每秒 235.8 個 token。每日序列才是有意思的部分：p95 在七天中的六天恰好落在 10,000 毫秒，這讀起來像上限而非測量值，而 p50 則依當天不同在 1,751 毫秒與 4,296 毫秒之間擺盪。把中位數視為大約是 Clef 的九倍，並把尾部視為不具資訊性，直到有人公布真正的分布為止。

那個差距不是調校上的差異，而且它不會縮小。只做預填充的一趟，加上平行評分頭，一次掃描就能完成；自迴歸模型則要等到沒東西可說時才會結束。Clef 的廠商絕對數字值得照慣例打個折扣，但這個排序是架構本身的特性，不是 Cloudflare 硬體的特性。

對其中一個而言，上下文會以三種方式被引用。

這兩個模型都接受文字、JSON、圖片和影片。它們的視窗並不相同，而且其中一個會因為你閱讀的地方不同，而被引述得不一致。

• Clef，託管版 — 65,536 個 token，根據 Workers AI 模型頁面與公告文章。這是約束 API 呼叫者的數字，而 Cloud 自己的表述則是比較性的：是 Jev 的 32K 視窗所持有狀態的兩倍。

• Clef，在磁碟上——已發佈的 config.json 宣告 max_position_embeddings 為 262,144，因為凍結的骨幹是父模型的，且仍帶有父模型的位置上限。隨附的 encode_record 輔助函式預設為 max_length=16,384，並有 max_state_tokens 可用來分別限制狀態。這三個數字都沒有錯；它們回答的是不同問題，而一個宣稱 256K 的執行階段清單讀取的是設定，不是端點。

• Qwen3.8-27B — 原生支援 262,144，若搭配正確的服務配置可擴展至 1,000,000，這點依廠商的規格卡與我們的型錄列所述。至少是託管 Clef 視窗的四倍。

實際後果比這個比例所暗示的還要小。Clef 消耗的是一個狀態——一張票、一張發票、一個——而不是一段對話，而且它的賣點之一是，你可以交給它一份大型扁平化酬載，並針對它提出六十四個問題，而不必為每個問題再次支付該酬載的成本。父層需要這個視窗，因為它必須保存歷史紀錄、工具結果以及自身的推理。需求不同，上限就不同。

兩者都看到相同的像素

視覺編碼器是繼承而來的，因此這並非一個模型是多模態、另一個不是的情況。Clef 每次請求最多接受四張圖片，為 base64 編碼的 PNG、JPEG 或 WebP，並由承載內容中的每個問題共用；影片影格則可以影格陣列的形式加入——模型卡中的收據範例會詢問總額是否清晰可辨的是非題，這就是該設計的縮影。Qwen3.8-27B 是原生視覺語言模型，在廠商的模型卡上，OmniDocBench 1.5 為 91.1、RealWorldQA 為 85.9、CharXiv 為 78.8。

不同之處在於你拿回來的是什麼。Clef 會給你逐欄位的判斷，並附上機率，也就是關於一份文件的具型別答案。父層則會給你一份文件描述，接著由你自行解析。對一大類文件工作來說——檢查這份表單、找出這個條款、這個總額是否高於門檻——具型別答案就是整項工作，而描述則是你先付出成本取得、隨後就丟棄的額外負擔。

界線實際上落在哪裡

• 選擇 Clef——答案可以事先列舉，而你寧願不寫解析器。路由、分診、閘控、政策檢查、文件欄位擷取。封閉集合，每個問題有 2 到 255 個選項，最多可將 64 個問題一起計分。

• 採用 Clef —— 這項決策位於熱路徑中，而 209 毫秒對比 1,929 毫秒會改變管線能做到的事。這是轉換的最強烈單一理由，而且是延遲上的理由，不是準確度上的理由。

• 採用 Clef——你追求的是確定性。你未宣告的選項不可能回來，因為沒有會產生它的生成步驟。

• 保留 Qwen3.8-27B——答案不是從清單中挑一個：摘要、起草、推理一個全新問題、撰寫程式碼、在長遠時間跨度中操作工具。Clef 這些全都做不到，而且它不會告訴你。

• 保留 Qwen3.8-27B —— 你需要這個模型說出「這些都不是」。決策模型只會為它被賦予的選項評分。給它一套帳務／技術／業務的分類架構，再加上一個隱私請求，它會回傳三者中最不糟的那一個，而不是拒絕回答。母模型則會浮現你壓根没想到要問的問題。

• 保留 Qwen3.8-27B —— 適合上下文或長文件工作。在百萬 token 擴充之前，是託管視窗的四倍。

把那份清單讀成一條管線，而不是一個判決，因為它本來就是這樣。這個架構讓這層關係變得字面上成立：Clef 就是母體的前填充階段，只是在末端接上不同的答案機制。合理的設計會把 Clef 放在前面——決定路線、優先順序、升級旗標——並讓 Qwen3.8-27B 留在它後面，根據這個決定採取行動。這兩者是恰好共用一次下載的互補關係。

它們各自要去哪裡

Clef 託管於 Cloudflare 的 Workers AI，價格如上方所示為每百萬筆輸入 $0.24，而 Apache-2.0 授權的權重則可由你在本機自行執行。Ollama 函式庫的收錄是最新的管道：ollama pull clef需要 Ollama 0.35.1 或更新版本，因為此模型是透過 /v1/systemone 端點來溝通，那是 Ollama 為決策模型新增的端點。要看標籤，別只看標題——預設與 clef:27b 標籤是 18 GB，那是 55 GB 模型的四位元版本；clef:27b-q8_0 是 30 GB，clef:27b-nvfp4 是 18 GB，clef:27b-mxfp8 是 31 GB，而 clef:27b-mlx-bf16 是完整 55 GB 的 Apple 晶片版本。TypeSafe 自家的 Python SDK 只要指向本機 Ollama 並提供任意 API 金鑰就能與其溝通，而執行環境會忽略該金鑰。有一個在正式環境中會造成麻煩的注意事項：confidence 衡量的是機率有多集中，而不是答案正確的機率，且平手時會依你宣告的選項順序來決定。

母模型是目前比較容易以 API 形式提供的那一個。Qwen3.8-27B 可在 OrcaRouter 上路由，採用上文使用的每百萬 token $0.33 與 $2.40 費率，並具備 262,144-token 視窗，而且它是可透過單一 OpenAI 相容金鑰存取的 200 多個模型之一。由於供應商定價以 0% 加成直接轉嫁，這項比較中任一方的廠商降價，在生效當天就會即時反映在我們的路由上。

Clef 本身並不是我們的路由之一——我們的公開目錄不會為它回傳任何項目，而此處的任何內容都不應被解讀為我們對其可用性的聲明。我們確實有提供的是能讓這套決策模式在沒有 Cloudflare 帳戶的情況下也能觸及的模型：TypeSafe 的 Jev 1.13 是一條已列出的路由，每百萬個輸入權杖收費 $0.042，具備 65,536 個權杖的上下文，在同一段七天期間內測得 p50 為 148 毫秒，且它採用完全相同的 POST /v1/systemone 請求格式。由於 Clef 刻意與 Jev API 相容，針對其中任一個建置的管線距離另一個只差一次設定變更——而這正是路由層存在的目的：讓這件事變得免費。 讓兩者都保持可達，用你自己的標籤來衡量，並讓勝出者成為一個資料點，而不是一項架構上的承諾。如果某個決策模型最終成為代理的把關者，實際依據該決策行動的模型仍必須可達，而那一半已經在同一把金鑰底下。

什麼會改變這個讀數？

三件事，依它們會讓它變動的幅度由小到大排列。

第三方需要重跑 Decision Index。這個測試套件是公開的，而 Cloudflare 將這些評估描述為可重現，所以這是做得到的——而 CLINC150 的超出範圍欄位是最值得關注的一項，因為 27B 的 97.4 究竟是在最難的那一半路由上真的優於 Jev 的 89.3，還是自家打造測試框架下的人為產物。目前 Cloudflare 以外的人還不知道。

有人得讓 Clef 和 Qwen3.8-27B 在同一項分類任務上、用相同標籤接受評分。唯有這樣的比較，才能判定對封閉集判定而言，重新設置輸出頭究竟是品質取捨還是品質升級；而兩家廠商都沒有動機去做這件事。在那之前，四十個百分點的 GPQA 落差仍是關於究竟移除了什麼的最佳現有證據，但它也是關於錯誤任務的證據。

而且 Clef 的延遲需要在併發情況下達到 p95。209 毫秒的中位數是由供應商在其掌控的硬體上測得的，而這個模型的整個賣點正是它位於熱路徑中。相對於自迴歸父模型的排序是架構性的，並且會持續成立。絕對毫秒數才是那個不該信任的數字，而整個商業論證所依賴的正是這個數字。

Qwen3.8-27B 是透過單一 OpenAI 相容金鑰即可存取的 200 多個模型之一——Qwen3.8-27B。