編按：本文綜合整理自 Cloudflare 官方部落格、Workers AI 模型頁、SGLang 開源推理框架 與 deeplearning.ai The Batch Issue 363，並加入 Siami 編輯部觀點與數據解讀。
Cloudflare 在 8 月 3 日發布最新工程實錄，公開 Workers AI 如何以自家推理平台量產服務 Moonshot AI 的 Kimi 與 Z.ai 的 GLM 兩款開源大型語言模型。兩者都是參數量龐大、具備長上下文能力的混合專家架構，運行難度集中在 GPU 記憶體而非單純算力。
Cloudflare 的解法是把「讓模型跑得起來」拆成三層：把 KV 快取從 16 位元壓到 8 位元、把模型權重從 8 位元壓到 4 位元、再為共享的實體快取加上完整性標籤檢查。三項技術各自獨立，卻彼此強化，最終目標是在相同準確度下，把更多請求塞進同一張 GPU 的記憶體。所有實驗與量產流量都跑在 SGLang 上，這是一個開源推理服務框架。Cloudflare 表示 SGLang 在市場上提供最佳效能，並與 SGLang 團隊密切合作，把自家改動回饋給上游開源社群。
KV 快取量化：把可用上下文從 68.6 萬拉到 137 萬 token
模型每生成一個 token，會把已經處理過的所有 token 的 attention 鍵值（K 與 V）存在一個稱為 KV 快取的結構裡。對長上下文模型而言，這個快取會迅速膨脹，通常比模型權重更早填滿 GPU 記憶體。預設情況下，快取以 16 位元精度（BF16）儲存。Cloudflare 改用 8 位元浮點數（FP8，e4m3），讓快取體積直接砍半。以 Kimi K2.6 為例，可容納的上下文從約 68.6 萬 token 提升到約 137 萬 token，剛好翻倍。量化並不會讓單一 token 變快——事實上 FP8 attention kernel 每次讀取都要額外做轉換，反而略慢於 BF16。改變的是「同時間能放進多少請求」。下列數據是在分離式 H200 部署上，對 Kimi K2.6 解碼階段的 attention kernel 對比：
| 併發請求數 | BF16 KV 快取 (tok/s) | FP8 KV 快取 (tok/s) |
|---|---|---|
| 1 | 137 | 125 |
| 8 | 731 | 689 |
| 16 | 1,106 | 1,028 |
| 32 | 1,558 | 1,489 |
| 64 | 記憶體不足 | 2,192 |
在任一併發層級，BF16 單 token 速度略快 5% 左右。但 BF16 在 32 個併發請求時就把快取塞滿，無法收第 33 個；FP8 則能跑到 64 併發、達到 2,192 tok/s，比 BF16 峰值高約 41%，每 token 成本低約 30%。Cloudflare 的策略是分離 prefill 與 decode 兩種池：prefill 是運算密集、保留 BF16 以維持高吞吐；decode 是記憶體密集、切到 FP8 把併發量撐高。量化是否影響輸出品質？Cloudflare 跑了完整評測，FP8 與 BF16 在 GSM8K、ARC-Easy、ARC-Challenge、MMLU、MMLU-Pro、內部基準 mcxams、工具呼叫合法性等指標上幾乎無法區分，差距都在 1 個百分點以內。
模型權重壓縮：GLM 5.2 從 705 GB 縮到 421 GB
KV 快取吃掉一部分 GPU 記憶體，模型權重則是另一個主要佔用者。針對 GLM 5.2，Cloudflare 把權重從 8 位元浮點壓到 4 位元整數（INT4），無損模型準確度：checkpoint 從 705 GB 縮到 421 GB，約減少 40%；在 8 路張量平行部署中，每張 GPU 的權重記憶體從約 88 GB 降到 52 GB，同一張卡就能再容納約 118 萬 token 的 KV 快取。量化後的權重對 GLM 5.2 的解碼階段有明顯加速，這背後有一個簡單的物理原因：生成每個 token 都需要把模型權重從 GPU 記憶體串流出來，解碼速度因此受限於記憶體頻寬。資料搬得少，每個 token 自然到得快。這個效果在低併發、單請求延遲敏感時最明顯：
| 併發請求數 | GLM FP8 (tok/s) | GLM INT4 (tok/s) | INT4 增幅 |
|---|---|---|---|
| 1 | 60 | 92 | +55% |
| 8 | 425 | 513 | +21% |
| 16 | 683 | 825 | +21% |
| 32 | 994 | 1,267 | +27% |
| 64 | 1,672 | 1,933 | +16% |
prefill 階段的行為則相反。INT4 權重在乘上前必須先展開回浮點，這個額外步驟讓 prefill 變慢而非變快：GLM 在 FP8 下能維持約 10,160 tok/s 的 prefill 速度，INT4 則降到約 8,660 tok/s。Cloudflare 同樣用分離式設計處理：在 decode 池跑 INT4、在 prefill 池跑 FP8，讓兩端都拿到最佳化結果。模型品質在 Cloudflare 跑的所有基準上，INT4 與 FP8 差距不超過 0.8 個百分點。
共享 KV 快取的完整性檢查：每頁加標籤，錯了就中止請求前兩項技術的副作用一樣：同一張 GPU 的記憶體可以同時容納更多請求。這正是重點，但也意味著數百個請求同時讀寫同一塊實體 KV 快取的不同頁。讓這套機制變快的關鍵——paged attention、continuous batching、快取重用——全都依賴「帳目正確」。在 Cloudflare 的請求量下，即使是十億分之一的錯誤，也會頻繁出現。
Cloudflare 因此為 KV 快取建立完整性檢查層作為防線。原理很直觀：每個實體快取頁在被重新分配時，都會拿到一個會變動的標籤；伺服器記錄每個請求預期使用哪些頁與對應標籤。支援的解碼操作讀取快取前會先比對標籤是否吻合；若不一致，受影響的請求會被中止，而不是把錯誤頁的資料回傳給使用者。這個檢查的成本必須低到能上線才有價值。Cloudflare 在中型量產模型上、2 prefill + 2 decode 配置、8,192 token 輸入與 1,000 token 輸出的條件下測量：
| 併發數 | 吞吐變化 | p95 延遲變化 |
|---|---|---|
| 1 | −0.53% | +0.42% |
| 2 | −0.38% | +0.54% |
| 4 | −0.79% | +0.63% |
| 8 | −0.43% | +0.80% |
吞吐與尾延遲的損失都在 1% 以下，95% 信賴區間上限也接近 1%。之所以便宜，是因為 Cloudflare 把驗證做成獨立的批次檢查，而非融合進 attention kernel——後者會在 GPU 執行緒群組間引入競爭。每個部署可以單獨啟用，預設路徑則使用無操作的 tracker，零測量成本。
為什麼這件事重要推理服務市場的競爭長期被切成兩條線：一條是「模型誰比較強」（基準分數、誰能寫 code），另一條是「硬體誰比較便宜」（GPU 報價、TCO）。Cloudflare 這篇文章把第三條線拉到聚光燈下：同一張 GPU 在維持品質的前提下能服務多少併發請求。
KV 快取量化與權重壓縮都不是 Cloudflare 發明的技術——FP8 attention、INT4 量化在學術界與開源社群已有大量實作。但把這些技術組裝進量產環境、跑在數百萬開發者實際呼叫的 Workers AI 上、並公開具體 benchmark，是少數基礎設施供應商才有的工程紀錄。更重要的是 Cloudflare 與 SGLang 合作回饋上游，這條路徑讓這些優化不只是 Cloudflare 內部資產，而是會逐步出現在其他推理服務商身上。對開源模型生態而言，這篇文章有三層訊息。第一，Kimi K 系列與 GLM 5.x 這類「前線級」（frontier-scale）開源模型，在第三方推理平台上已經能跑出與閉源模型相當的單 token 成本與併發量。第二，分離式 prefill / decode 部署讓「一種精度套用全場景」變成過去式——同一個模型可以為不同負載挑選不同精度。第三，快取完整性檢查代表「paged attention 速度」與「正確性」是同一張考卷的兩面，雲端推理平台不能只優化其中一邊。對開發者與產品團隊而言，Workers AI 上的 Kimi K2.6 與 GLM 5.2 已經是可用選項——它們不必自己買 H200、不必自己寫 SGLang patch，卻能拿到 Cloudflare 量產環境的優化結果。這也意味著，在評估「我的 AI 應用該用哪家推理」時，「API 每 token 多少錢」只是入口；併發量上限、長上下文支援、KV 快取重用率、prefill 首 token 延遲，這些都會直接影響實際體驗與總成本。
數據解讀與質疑幾個值得追問的點。
第一，FP8 KV 快取「41% 峰值提升」是在 64 併發、特定 H200 配置下測得。 不同 GPU（H100、B200、B300）、不同張量平行策略、不同請求長度分佈下，這個數字會顯著波動。Cloudflare 文章本身沒有提供 B300 或 Blackwell 的對照組——他們在「What’s next」段落只提到「正在驗證 NVFP4 權重在 Blackwell 上的效果」，這代表對 NVIDIA 最新架構的完整支援尚未到位。
第二，INT4 權重的品質「與 FP8 差距不超過 0.8 個百分點」是基於 Cloudflare 內部基準。 這不等同於任何使用者的下游任務。對 code generation、長程推理、多輪對話、agentic tool use 等情境，是否仍維持這個差距，需要更多第三方獨立測試。GLM 官方與 Z.ai 也未就 Cloudflare 的量化版本給出獨立評估背書。
第三，「每 token 成本下降 30%」的前提是分離式部署的 decode 階段。 真實應用的成本還要加上 prefill 階段（INT4 比 FP8 慢約 15%）、網路流量、儲存與監控。Cloudflare 沒有公布端到端 TCO 數字，也沒有對照「不分離部署、不量化」的成本基線。
第四，快取完整性檢查的設計假設是「單張 GPU 上的請求彼此隔離」。 一旦跨 GPU 快取共享（例如 tensor parallel 中的 attention all-reduce），這個機制是否能守住正確性邊界，文章沒有展開。
後續觀察重點這篇文章是 Cloudflare 在 8 月「Agents Week」系列的一環，後續值得追蹤的項目：
- NVFP4 權重在 Blackwell（B200、B300）上的實測數字——決定 Cloudflare 是否能在 NVIDIA 最新硬體上維持成本優勢。
- Kimi K3（2.8 兆參數）進入 Workers AI 的時程——目前 Workers AI 上最高是 K2.6，K3 的記憶體佔用是另一個量級。
- GLM 5.3 或更新版本的 INT4 / FP8 benchmark——驗證量化策略是否對新模型同樣有效。
- 快取完整性檢查是否開源——目前看起來是 Cloudflare 內部實作，若回饋到 SGLang 或 vLLAM，將提升整個生態的可靠性。
- 第三方獨立基準重現——Hugging Face、lmsys、AI 評測社群是否採用 Cloudflare 的方法論，會決定這些數字能否擴展到其他推理平台。把 frontier 模型擠進單一 GPU 的記憶體、讓長上下文與高併發共存、又不犧牲準確度——這是 2026 下半年推理工程的主軸。Cloudflare 把這條技術線拉到雲端服務層面公開，下一步看的是 NVIDIA Blackwell 與各家開源新模型能否複製同一套成果。
網友熱門留言 (3)