對於剛接觸 AI 部署的工程師來說，最容易產生的誤解是認為跑大語言模型（LLM）只需要買越多 GPU 就好。但實際上，當模型規模達到兆級參數（Trillion parameters）時，瓶頸不在於單純的算力，而是在於記憶體頻寬、資料傳輸延遲以及資源利用率。Cloudflare 最近分享的基礎設施優化方案，正好展示了工業級 LLM 推論（Inference）是如何透過架構設計來突破這些物理限制的。
理解 LLM 推論的兩個階段：Prefill 與 Decode
要理解 Cloudflare 的做法，首先得知道 LLM 處理請求時分為兩個截然不同的階段。
第一個階段是 Prefill（預填充）。當你輸入一段長文字給 AI 時，系統需要一次性處理所有輸入 Token（詞元），並將計算結果存入 KV Cache（鍵值快取，一種用來儲存先前計算結果的記憶體空間，避免重複計算）。這個階段是 Compute-bound（計算密集型），也就是說 CPU/GPU 的算力決定了速度。
第二個階段是 Decode（解碼）。AI 開始一個字一個字地生成回答。每生成一個新字，都要讀取一次 KV Cache。這個階段是 Memory-bound（記憶體頻寬密集型），也就是說 GPU 讀取記憶體的速度比算力更重要。
Cloudflare 採取了一項關鍵技術叫做 Disaggregated Prefill（解耦預填充）。他們將這兩個階段分開在不同的機器上執行。這樣做的好處是，可以針對計算密集和記憶體密集這兩種截然不同的需求，配置最適合的硬體資源，而不會讓兩者在同一台機器上互相爭搶資源，從而提升整體吞吐量。
自研 Infire 引擎：解決多 GPU 協作的痛點
當模型大到單張 GPU 塞不下時（例如 Kimi K2.5 這種需要 560GB 記憶體、至少 8 張 H100 才能載入的模型），就必須使用平行運算。Cloudflare 開發了名為 Infire 的推論引擎，重點優化了兩種平行策略。
首先是 Pipeline Parallelism（流水線平行）。這就像工廠流水線，將模型的不同層分給不同的 GPU。Infire 的目標是達成 Load Balance（負載平衡），防止某些 GPU 在瘋狂運算而其他 GPU 在閒置等待（Starving），確保整體流程順暢。
其次是 Tensor Parallelism（張量平行）。這是在單個運算層級將矩陣運算拆分到多個 GPU 上。這種方式會產生大量的 Cross-GPU Communication（跨 GPU 通訊），也就是 GPU 之間需要頻繁交換數據。Infire 透過優化通訊路徑，極大化降低傳輸延遲。
在實務上，同時結合這兩種平行策略，才能在 Latency（延遲，單個請求的反應速度）與 Throughput（吞吐量，單位時間處理的請求數）之間取得最佳平衡。
記憶體壓縮與極限優化
除了架構設計，記憶體空間的利用率決定了成本。Cloudflare 引入了 Unweight 技術，能將模型權重（Weights）壓縮約 15% 到 22%，且不損失精度。這意味著 GPU 需要搬運的數據量減少，載入速度更快。
透過這些優化，Infire 展現了極高的記憶體效率。例如，原本使用 vLLM（目前主流的開源推論框架）可能連啟動都困難的模型，在 Infire 的優化下，Llama 4 Scout 僅需兩張 H200 GPU 即可運行，並保留足夠的空間給 KV Cache 使用。
為什麼這對工程師很重要
這件事告訴我們，AI 基礎設施正在從簡單的 GPU 堆疊，轉向深層的系統架構優化。傳統的基礎設施是為人類的隨機互動設計的，但 LLM 的工作負載具有高度不可預測性且對資源要求極端。
如果你在設計 AI 服務，不能只關注模型本身的準確率，更要關注推論階段的瓶頸在哪裡。是 Prefill 太慢導致首字延遲（TTFT）過高？還是 Decode 太慢導致生成速度不理想？透過像 Cloudflare 這樣將計算與記憶體需求解耦，以及優化跨設備通訊，才能在生產環境中實現真正的高可用與低延遲。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。