Clef-Flash 對比 Qwen3-8B：38 毫秒對上人人早已在跑的 8B

許多團隊會把一項具體、不起眼的工作交給 Qwen3-8B：讀這張工單、這行日誌、這份表單，然後告訴我它屬於我的四個分類桶中的哪一個。這是一項披著對話外衣的分類任務，而 Qwen3-8B 做得夠好，好到沒有人費心去替換它。2026 年 9 月 30 日，Cloudflare 發布了 Cloudflare/clef-flash的權重，這是一個 9B 模型，專門用來做那項工作，別無其他；而有趣的問題不是它是否比 Qwen3-8B 更聰明。而是你目前從 8B 通用模型得到的東西，究竟是否值得用生成的 token 來付費。

Clef-Flash 以結構而非基準來回答那個問題。它接收一個狀態以及一份最多包含 64 個具型別問題的結構描述，並在單次非自迴歸傳遞中為每個允許的選項回傳一個 logit——沒有中間文字、沒有解析，除了機率之外沒有輸出。Cloudflare 為它測得的中位請求延遲為 38.8 毫秒，相較之下，與其進行基準比較的 TypeSafe 決策模型 Jev 約為 500 毫秒。Qwen3-8B 不在那張表裡，因為 Qwen3-8B 不玩那個遊戲：它寫出一個答案，而你閱讀它。

這組配對之所以值得做完整比較，而不只是一頁規格列，在於這兩個模型完全沒有共用的基準測試。流通中的每一個 Clef-Flash 數字，都是由 Cloudflare 在一個競爭對手發布的指標上產生的，而 Cloudflare 以外沒有人重現過其中任何一項。Qwen3-8B 背後有三個世代的獨立使用經驗，還有一份你可以爭論的公開紀錄。該決定你是否要進行替換的，是這種不對稱，而不是延遲差距。

兩份輸出合約，而非兩種尺寸

這裡的參數量相近到只會分散注意力——Clef-Flash 是 9B，Qwen3-8B 是 8.2B，其中 6.95B 屬於非嵌入部分。真正關鍵的差異在於每個模型被允許輸出什麼。

Qwen3-8B 是一個因果語言模型。給它一張支援工單，它就會產生 token，而且預設會先產生一個推理區塊，因為除非你把它關掉，否則思考模式是開啟的。它可以分類、解釋、升級、草擬回覆，或告訴你你的分類體系缺少某個案例——全都出自同一組權重，不需要任何結構描述。它的模型卡標示有 36 層、32 個查詢頭對 8 個 KV 頭的群組查詢注意力、100 多種語言，以及原生 32,768 個 token 的上下文長度，並可透過 YaRN 擴展到 131,072。它是大多數團隊會求助的模型，因為它是什麼都能做的模型。

Clef-Flash 是一項後訓練成果，而非對話夥伴。Cloudflare 凍結了 Qwen3.5-9B 主幹——包括其視覺編碼器——並在其上訓練了一個聯合 schema 頭：243.5 MB 的頭部權重，對上四個分片主幹檔案，合計約 18.8 GB。這個頭會讀取主幹的最終隱藏狀態，將來自該狀態的證據路由到每個問題，並將所有問題的所有選項一併評分。限制本身就是特色。Cloudflare 限制它只能輸出機率，這就是為什麼基礎模型會出現在其血統中，卻從不出現在其輸出裡。

注意這是誰的譜系。Clef-Flash 源自 Qwen3.5-9B，也就是 Qwen3-8B 所屬的 Qwen3 系列之後的下一個世代。所以，這不是 9B 衍生模型通常會有的那種「對自身基礎模型進行微調」的故事——而是同一棵家族樹中的另一個分支，為了不同的合約而重新訓練。

同一份工作，兩種執行方式

兩個模型都能路由支援工單。它們的失敗方式不同，而這些失敗模式正是遷移的代價。

使用 Qwen3-8B 時，工作重點在於提示詞與解析器。你描述自己的類別，要求模型回傳其中一類，然後還要處理模型回覆「這看起來像帳務，不過也可能是技術問題」的情況——這是對真實模糊性的真實回答，但你的下游程式碼無法處理。該模型卡自身的指引明確指出，進行效率相關工作時應停用思考模式，而貪婪解碼會降低輸出品質，而且當思考模式開啟時，你不應在多輪對話歷史中把推理區塊繼續往後帶。這些指示中的每一項，都是通用模型逼你做出的決定。

有了 Clef-Flash，工作轉移到結構定義（schema）上。針對 choice 題目，每道你得宣告二到二十六個選項，或是在二到二十六個等級之間的 score 題目，而你會拿回被選中的選項、每個選項各自的機率，以及一個信心值。這份契約裡有三個細節，比標題上那個延遲數字更有價值。第一，信心不等於正確——Cloudflare 的文件直白地說，它衡量的是機率有多集中，而不是答案正確的機率。第二，平手時依你宣告的選項順序決定，所以如果兩個選項真的重疊，你已經靠著清單排序默默做了決定。第三，也是最咬人的一點：除非你自己寫了一個進去，否則沒有「以上皆非」。決策模型只會為它拿到的選項評分；一張關於隱私請求的工單，若被交到帳務、技術與業務的結構定義手上，回來的會是這三者中「最不壞」的那一個，而不是拒答。

最後這一點是兩面刃，而這正是這項比較最誠實的核心。Qwen3-8B 會告訴你，你的分類體系有問題。Clef-Flash 不會，而在管線中，這是一種真正的退步——那種你一個月後才在錯誤路由的佇列裡發現的問題。這項取捨是以真實的延遲與真實的確定性，換取一個能浮現你沒想到要問的問題的模型。

數字說了什麼，又沒說什麼

Clef-Flash 的已發佈結果來自 Cloudflare 執行 Jev Decision Index 0.2.1 套件，而同一輪執行也為該廠商的部落格文章提供了依據。表現強勁的項目值得精確說明：BFCL 案例完全吻合 98.8，API-Bank 準確率 93.1，家用電器模擬器 97.7，ContractNLI 巨觀 F1 84.3，RouterBench 精選品質 79.9。在 TypeSafe 自家評估套件中的四個端到端業務工作流程上，Clef-Flash 在客戶服務以 77.0 勝過 Jev 的 76.0 以及較大的 27B Clef 的 76.3，但在發票處理以 57.1 敗給 Jev 的 61.8 與 Clef 的 64.7。

弱的儲存格與強的儲存格一樣具有資訊量。包含超出範圍（out-of-scope）處理的 CLINC150，讓 Clef-Flash 的 macro-F1 為 66.8，而 27B Clef 為 97.4，Jev 為 89.3——在正是測試模型是否知道何時該棄權的基準形狀上，出現了三十點的斷崖。When2Call 為 65.6，對比 Jev 的 81.0。GPQA Diamond 為 51.0，對比 78.3。POP909-CL 落在 1.6，這個數字模型卡並未解釋。

現在來看那些表格不會告訴你的部分：Qwen3-8B 在任何一張表中都沒有對應的列。兩個模型都沒有在對方的基準測試上被評分過。Clef-Flash 自家的 MMLU 分數 91.8 與 GSM8K 分數 67.3，是透過其型別化決策測試框架產生的，而那並不是 Qwen 回報其數字時所用的測試框架；把兩者拿來比較，會是把範疇錯誤包裝成比較。因此，誠實的立場是：並不存在共用的計分板，而本文也不會憑空發明一個。真正存在的是：供應商在自家基礎設施上測到的延遲差距、本質上不同的成本結構，以及一批除了 Cloudflare 之外沒有人重現過的 Decision Index 儲存格。

{{1}}一個決定{{/1}}{{2}}要付出什麼代價{{/2}}

Cloudflare 的 Workers AI 說明文件將 Clef-Flash 列為每百萬個輸入 token $0.09，而輸出則不收費，因為實際上根本沒有輸出——文件中的計算範例在一個包含三個問題的請求中，只傳回三個輸出 token。因此，針對一張 1,500 個 token 的工單做出路由決策，輸入成本約為 $0.000135，之後就沒有可量測的成本。每天執行一百萬次這類作業，你每天大約花費 $135，而且當工單變得更複雜時，這個數字不會變動，只有當工單變長時才會變。

自迴歸模型沒有對等的上限。那一百萬個決策中的每一個也都會對生成的 token 計費，而且如果思考模式是開啟的——對 Qwen3-8B 而言預設正是如此——模型可能會在回答之前先花上數百個 token，推理一封密碼重設郵件屬於四個類別中的哪一個。用 enable_thinking=False 或 /no_think 標籤關閉思考，是任何以該模型為基礎的分類提示詞中影響力最大的一行，而且很容易漏掉。這個比較不是「便宜模型對上昂貴模型」，而是固定的純輸入價格，對上一個會隨模型決定要說多少而變動的價格。

背景，來自三個廠商介面的三個數字

Clef-Flash 的可用上下文取決於你閱讀的是哪個 Cloudflare 介面。Workers AI 模型頁面記載了 65,536 個 token 的上下文視窗。已發布的 config.json宣告 max_position_embeddings 為 262,144，供文字塔使用。該模型卡自身的編碼輔助函式預設為 max_length=16,384，並可透過 max_state_tokens 來另行限制狀態。某個宣稱支援 256K 的第三方執行階段清單讀取的是設定值，而不是服務限制——這化解了該差異，而不是讓它成為一個謎團，但對任何呼叫代管端點的人來說，實際數字是 65,536。

Qwen3-8B 的數字是它自己的，而且一年半來一直如此：原生 32,768，搭配 YaRN 為 131,072，設定預設值為 40,960，其中保留 32,768 給輸出、8,192 給提示詞。所以，如果原始視窗是你的決定性因素，這個小型自迴歸模型可以擴展到大約是託管式決策模型文件所記載的兩倍——而決策模型所需的視窗卻少得多，因為你傳送的是狀態，而不是對話。

誰應該交換，而誰不應該

• Swap — 你有固定的分類體系、三到 26 個目的地，以及一個支援佇列、一個分流步驟，或一個代理閘門；在這些情境裡，38.8 毫秒中位數與 122.4 毫秒 p95 相對於半秒的生成時間，會改變你的管線能做到的事。

• Swap — 你目前正在從 8B 模型解析散文，並處理那個每五十個就有一個、不符合你格式的答案。對已宣告選項的分布能完全移除那個失敗類別。

• 不要替換——答案集並非事先已知，或者你需要模型告訴你它不知道。Clef-Flash 沒有棄權路徑，除非你將它建入準則中；而它已發表的最弱儲存格，正是超出範圍的案例。

• 請勿更換——當工作負載是推理、從未受約束文件中擷取、摘要，或程式碼時。Clef-Flash 無法寫出一個句子，因此任何預期要有句子的下游，都保留 Qwen3-8B。

• 先別切換——你需要由供應商以外的人來核對這些數字。目前沒有針對 Clef-Flash 的獨立評估，而產生其分數的評測套件，是由它所擊敗的模型的供應商所發布的。

它們各自要去哪裡

兩者都是 Apache-2.0，所以都任你自行託管，但佔用空間差距不小。bf16 的 Qwen3-8B 約 16 GB，量化版本則小得多——Ollama 模型庫上的 Q4 版本為 5.2 GB，其中qwen3:8b列出 3,870 萬次下載與 40K 的上下文視窗。Clef-Flash 則需要完整的 18.8 GB 主幹，外加 243.5 MB 的頭部，且其 Ollama 模型庫頁面在釋出後幾天內就上線，有一個 11 GB 的量化標籤，分享次數仍只有數百；Ollama 的表格顯示的是設定檔中的 256K，而非端點實際的 65,536。這個下載比例並不是對任一模型的評斷——一個頁面已上線十八個月，另一個才大約一天——但它公允地呈現了兩者各自背後累積了多少實際運作歷史。

如果你想要託管版本，Cloudflare 會在 Workers AI 上以文中所述每百萬 $0.09 的價格運行 Clef-Flash，權重也可從 Hub 下載。這兩個模型都會與 Ollama 的 /v1/systemone 端點溝通（Clef-Flash 適用，需 Ollama 0.35.1 或更新版本），而 Qwen3 則走標準的 generate 路徑——因此替換只是用戶端的變更，而非架構上的變更。

這兩個模型目前都不在我們的路由之列：OrcaRouter 的公開目錄對 clef-flash 與 Qwen3-8B 一視同仁地回傳 404，因此這裡的任何內容都不應被解讀為我們對可用性的聲明。路由層真正改變的，是整條流程中負責生成的那一半。如果某個決策模型最終成為你 agent 的把關者，那麼依據該決策採取行動的模型仍然必須觸及得到，而這正是以一組 API 金鑰取用 200 多個模型的單一 API能佔有一席之地的原因——供應商定價以 0% 加價原樣傳遞，因此廠商一降價，這裡當天就會反映；再加上自動容錯移轉，讓單一供應商的一個糟糕午後不會弄垮你才剛重建好的路徑。Qwen 系列也已經向前演進了：Qwen3.8-27B 在這裡可路由，每百萬個 token 輸入 $0.40、輸出 $4.21，並具備 262,144 個 token 的上下文視窗；它是與 Qwen3-8B 不同的模型，並非其替代品，但它是同一家族往上一個世代的產品。

什麼會改變這個讀數？

三件事，依序。

一次針對範圍外單元格的獨立執行。Clef-Flash 在 appliance simulation 上拿到 97.7、在 CLINC150+OOS 上拿到 66.8，這兩者之間的落差並不是在描述一個能力平滑、全面勝任的分類器；而是在描述一個在訓練時所見形狀內很強、但當正確答案是「以上皆非」時就變弱的模型。如果這在別人的測試框架下也成立，那就是關於這個模型最重要的運作事實，而它並不在任何人的亮點清單上。

來自 Cloudflare 邊緣外部的實測延遲數據。38.8 毫秒的中位數令人印象深刻，而且它是由廠商在廠商掌控的基礎設施上，針對託管於邊緣的模型所測得。與 Jev 相較的排序大概很穩健；該存疑的則是絕對數字。

以及一個共用的基準測試。在有人以相同標籤、在同一個分類任務上為 Clef-Flash 和一個小型開源 LLM 評分之前，兩者之間的選擇取決於輸出契約、價格結構，以及你願意依據哪一方的證據來行動。這三點在今天足以決定許多管線的走向——但它們不是準確度比較，而本文也不會假裝它們是。