如果你的 agent 工作流裡有「看一段音訊判斷要不要轉工單」這類需求，過去的做法大概是串一套 pipeline：先跑語音轉文字，再餵給決策模型。Cloudflare 在 2026 年 10 月 9 日發表的 Clef-omni 把這段流程壓成一次 API 呼叫——模型直接吃 wav、mp3、mp4、webm，搭配文字和圖片，輸出 schema 綁定的決策分數。
一個模型取代一條轉錄 pipeline
Clef-omni 建立在 Qwen3-Omni-30B-A3B-Instruct 的 mixture-of-experts 架構上，但 Cloudflare 只保留了理解骨幹，丟掉文字轉語音的部分。因為 Clef 系列不是 LLM，不做輸出 token 生成，所以省掉轉錄和字幕的成本——媒體直接映射進統一序列，視訊和音訊與視覺幀同步處理。
速度數字值得看一下：純文字決策中位數約 130 ms，圖片約 150 ms，音訊幾百毫秒，一段 21 秒的有聲影片大約 1.5 秒就能完成評分。對需要即時分類的場景來說，這個延遲等級才真的可用。
降價與加速的取捨
Clef-flash 的輸入價格從每百萬 token 0.09 美元降到 0.038 美元，比 TypeSafe 的 Jev 還便宜。但代價是：hosted 版的 context window 從 64k 縮到 24k。Cloudflare 根據使用量資料說明，只有 0.24% 的請求超過 24k 輸入 token，所以做了這個取捨。需要注意兩件事：Hugging Face 上的權重不受影響，自架仍支援 256k；如果你的工作流真的需要長 context，官方建議改用維持 64k 的 Clef。
Clef 本身則變快了，中位數延遲約降到原本的 1.7 到 2 倍。關鍵優化在 serving 層——改用 SGLang 部署，相關改動會進 SGLang 0.5.22。這對自架的人是好消息，因為優化不是綁在 Cloudflare 的內部基礎設施上。
對 builder 的實際意義
這組更新對產品決策的影響主要在兩個地方。第一，模態擴充不再需要架構調整——原本的 Clef 已經支援圖片和影片幀陣列，Clef-omni 把音訊和完整視訊補齊，而且是 Jev-API 相容，理論上換個 model ID 就能試。第二，價格往下壓之後，把「判斷」這件事放進每個工作流環節的門檻變低了，就像 Claude Haiku 5.5 改變 subagent 成本算式的邏輯一樣。
Cloudflare 內部的用法也能當參考：GitHub docs repo 用 Clef 自動偵測並關閉 spam issue、CMS 用它審查 plugin 釣魚、資料外洩防護團隊掃描 PII、威脅情報團隊偵測惡意網域。這些案例的共同點是過去需要小型 ML 團隊訓練分類器，現在變成一次模型呼叫。
看數據時留意基準差異
供應商自己的 benchmark 表值得細看。Clef-omni 在 BFCL 拿 98.2、BANKING77 拿 94.8，但在 When2Call 只有 63.3，低於 Jev 的 80.97；Home appliances 資料集更是只有 69.3，遠低於 Clef-flash 的 97.73。也就是說，omni 版的跨模態能力並沒有全面超越純文字版本——如果你只用文字，原版 Clef 或 Clef-flash 可能還是更好的選擇。
這和之前談過的檢索評測問題是同一件事：單一排行榜不足以指導選型，用 nDCG@10 重寫檢索評測的思路 在這裡同樣適用——先看你的實際工作流落在哪個資料分布，再對照表格選模型。
務實的下一步：把你的真實輸入樣本（包含音訊或影片的話更好）拿去跑一次 Clef-omni 和現有方案的對照，重點看延遲和 exact action 命中率，而不只是公告裡的綜合分數。圖片和音訊如何換算成輸入 token 計價，記得查官方開發者文件確認最新定價。