Cloudflare 已經把一台自研的 LLM 推論引擎投入生產,跑在他們整張全球網路上。引擎叫 Infire,底下的架構選擇是 prefill/decode 解耦 —— 把輸入處理和輸出生成分到針對各自最佳化的不同機器上 —— 結果是 Cloudflare 現在能在邊緣託管像 Kimi K2.5(1T+ 參數,磁碟上 ~560GB)這種兆參數級的開放模型,旁邊還跑著 Llama 4 Scout。真正有意思的不是這次發布;而是其中一家最大的 CDN 加入了那個不靠 vLLM、不靠 SGLang、自己跑推論棧跑出規模的小群體。
P/D 拆分是承重的架構選擇。Prefill 受算力限制:處理輸入 prompt,填 KV 快取。Decode 受記憶體頻寬限制:讀 KV 快取,一次發一個 token。把這兩個階段放同一台機器,誰不是瓶頸,誰就在浪費硬體。Infire 把兩階段分到針對各自畫像最佳化的機器上。在此之上,Infire 把流水並行(按模型層在 GPU 間切片)和張量並行(在層內按張量切片)聯動起來,明確目標是防止某一階段的 GPU 在另一階段執行時挨餓。硬體佔用很具體:Kimi K2.5 至少要 8 張 H100(模型本身 ~560GB,剩下的 HBM 給 KV 快取);Llama 4 Scout 在 2 張 H200 上跑得開,還剩下相當多的上下文容量。
第二件東西是 Unweight,Cloudflare 自研的權重壓縮系統,在不損失精度的前提下把模型權重縮 15-22%,減少推論時跨 GPU 的資料搬運量。在兆參數尺度上,權重搬運是一個實打實的成本維度 —— 載入位元組數每少一個百分點,都是真實的瓦數和真實的延遲。再往大看一層:Cloudflare 正在把自己定位成「以通用基礎設施層的方式託管前沿規模開放模型」,跟它託管靜態資源是同一種姿勢。如果 Kimi K2.5 和 Llama 4 Scout 在 Cloudflare 上能拿出可信的冷啟動和 TTFT 數字,那「自己租 H100 叢集 vs 走 Cloudflare」的每 token 成本算式就會改寫。包裝層經濟多了一塊基礎底,「我這 1T 參數模型放哪跑」也就不再是一個採購專案。
如果你基於前沿級開放權重模型出貨、又不想自己營運一池 GPU,Workers AI / Infire 現在所處的競爭位置已經不是一年前那個了 —— 把同一份工作負載在那邊和你當前供應商那邊各跑一遍,看 TTFT 和每 token 成本(尤其是長上下文的編碼代理 trace),那才是有意義的對比。如果你在自家跑推論棧,P/D 解耦這個模式是帶回家的那一份;流水並行 + 張量並行聯動(而不是二選一)是落地時的實作註記。就我目前看到的,Unweight 還沒開源,所以權重壓縮仍是一個 build-or-buy 抉擇。給 vLLM 和 SGLang「保持頂流」的競爭壓力,剛剛變得更具體了。