AI 推論基礎設施
Cloudflare 拆分 prefill 與 decode 精度，GLM 5.2 解碼吞吐量最高提高 55%
Cloudflare 以 FP8 KV cache 擴充 Kimi K2.6 的並行容量，並在 GLM 5.2 解碼端改用 INT4 權重。系統同時為共享 KV cache 加入頁面世代標記，防止多租戶請求讀到錯誤快取。
Cloudflare 公開 Workers AI 服務大型稀疏模型的生產配置，核心不是對整條推論管線統一量化，而是依 prefill 與 decode 的瓶頸分別選擇精度。所有實驗均以開源 SGLang 執行，並採用兩階段分離的 H200 部署。
在 Kimi K2.6 上，Cloudflare 將 decode 階段的 KV cache 從 BF16 改為 FP8 e4m3，使可容納的上下文總量由約 68.6 萬增至 137 萬 token。FP8 核心在相同並行度下其實稍慢，例如單請求由每秒 137 降至 125 token；真正收益來自記憶體容量。BF16 在超過 32 個並行請求後記憶體不足，FP8 則能維持 64 個請求及每秒 2,192 token，較 BF16 的峰值吞吐量高約 41%，每 token 成本據稱下降約 30%。
GLM 5.2 的權重則由 FP8 壓成 INT4，checkpoint 從 705 GB 降至 421 GB；八路張量平行時，每張 GPU 的權重占用由約 88 GB 降至 52 GB。由於 decode 受記憶體頻寬限制，單請求吞吐量從每秒 60 升至 92 token；但需要先解壓權重的 prefill 反而由每秒 10,160 降至 8,660 token。因此 Cloudflare 只在 decode 使用 INT4，prefill 仍保留 FP8。
更高密度也放大共享快取的隔離風險。新機制替每個實體 KV 頁面配置隨重新分配而改變的標記，decode 前核對請求預期的頁面與標記，不一致便中止請求。官方測得吞吐與 p95 延遲負擔均低於 1%。不過品質結論主要來自 Cloudflare 自選基準，部分還是內部測試；工程團隊仍應以自身長上下文、工具呼叫及多租戶壓力測試驗證量化誤差與隔離行為。