智慧體需要由大型語言模型驅動。幾週前，我們宣布 Workers AI 正式進入戰場，開始代管 Moonshot 的 Kimi K2.5 等大型開源模型。自那時起，我們已將 Kimi K2.5 的速度提升 3 倍，並且還有更多模型正在陸續新增中。這些模型已成為本週我們推出的眾多智慧產品、框架和工具的骨幹。
代管 AI 模型是一個有趣的挑戰：它需要在軟體與極其昂貴的硬體之間取得微妙的平衡。在 Cloudflare，我們擅長透過巧妙的軟體工程，從硬體中榨取每一分效率。本文將深入探討我們如何為運行超大語言模型奠定基礎。
如同我們在上一篇 Kimi K2.5 部落格文章中所提到的，我們使用了多種硬體設定，以便為模型提供最佳的服務。許多硬體設定取決於使用者傳送給模型的輸入與輸出大小。舉例來說，如果您使用模型來寫同人小說，您可能會給它幾個簡短的提示詞（輸入詞元），同時要求它產生好幾頁的內容（輸出詞元）。
反之，如果您執行的是摘要任務，您可能會傳送數十萬個輸入詞元，但只產生寥寥數千個輸出詞元的簡短摘要。面對這些相反的使用情境，您必須做出選擇：您要將模型設定調校為加快輸入詞元的處理速度，還是加快輸出詞元的產生速度？
當我們在 Workers AI 上推出大型語言模型時，我們知道大多數的使用情境都是為了智慧體。對於智慧體，您會傳送大量的輸入詞元。整個流程始於一段冗長的系統提示詞，其中包含了所有可用的工具以及各類 MCP。隨著使用者發出首個提示，模型的脈絡就會隨之不斷擴充。使用者後續發出的每一個新提示，實際上都是向模型傳送了一次新的請求；而該請求所包含的資料，囊括了此前所有的對話歷史——所有先前使用者的提示詞、助理的回應、產生的程式碼等等。對 Workers AI 而言，這代表我們必須專注在兩件事上：快速的輸入詞元處理和快速的工具呼叫。
我們用來提升效能與效率的一種硬體設定，是「分離式預先填充」(disaggregated prefill)。處理 LLM 請求有兩個階段：預先填充 (prefill) 會處理輸入詞元並填入 KV 快取；解碼 (decode) 則會產生輸出詞元。預先填充階段通常受限於運算能力，而解碼階段則通常受限於記憶體頻寬。這意味著每個階段所使用的 GPU 資源不同，而且由於預先填充一定在解碼之前執行，這兩個階段會互相阻塞。最終結果就是，如果在單一機器上同時執行預先填充與解碼，我們就無法有效率地運用所有 GPU 效能。
透過預先填充/解碼分離，我們為每個階段分別執行獨立的推斷伺服器。首先，請求會先傳送到預先填充階段，該階段會執行預先填充並將其儲存在自己的 KV 快取中。然後，同一個請求會被傳送到解碼伺服器，同時附帶如何將 KV 快取從預先填充伺服器傳輸過來的資訊，然後開始解碼。這有許多優點，因為它允許伺服器針對自身扮演的角色獨立調校，可以根據輸入或輸出流量較多的情況進行擴展，甚至可以在異構硬體上執行。
這種架構需要相對複雜的負載平衡器才能實現。除了上述路由請求之外，它還必須改寫解碼伺服器的回應（包括串流 SSE），使其包含來自預先填充伺服器的資訊（例如已快取的詞元）。更複雜的是，不同的推斷伺服器需要不同的資訊來啟動 KV 快取傳輸。我們對此進行了擴充，實作了詞元感知負載平衡 (token-aware load balancing)：系統中有一組預先填充端點與一組解碼端點，負載平衡器會估算每個端點正在處理中的預先填充或解碼詞元數量，並嘗試均勻分佈此負載。
在我們的公開模型發佈後，輸入/輸出模式再次發生劇烈變化。我們花時間分析了新的使用模式，然後調整了設定以符合客戶的用例。
下圖展示了在將流量切換至全新的 PD 架構之後，「首個詞元回應時間」(Time to First Token) 指標的 90 分位值下降了，同時，我們的請求總量增加了，但使用的 GPU 資源量不變。我們觀察到長尾延遲的波動性有顯著改善。
同樣地，單詞元時間的 90 分位值從約 100 毫秒（波動較大）降至 20-30 毫秒，詞元間延遲實現了三倍的改善。
由於智慧體用例通常有較長的脈絡，我們最佳化了提示快取效率，以避免在每一輪都重新計算輸入張量 (input tensors)。我們利用一個名為 x-session-affinity 的標頭，幫助請求路由到先前已計算輸入張量的正確區域。我們在最初關於在 Workers AI 上推出大型 LLM 的部落格文章中曾提到這一點。我們將工作階段親和性標頭添加到熱門的智慧體框架中（如 OpenCode），並觀察到總輸送量有顯著提升。使用者端提示快取的微小差異，累積起來可能導致執行模型所需的額外 GPU 數量成倍增加。雖然我們內部有 KV 感知路由，但我們也依賴用戶端傳送 x-session-affinity 標頭來明確啟用提示快取。我們透過提供快取詞元的折扣價格來激勵使用此標頭。我們強烈建議使用者利用提示快取，以獲得更快的推斷速度和更低的成本。
我們與內部用量最大的使用者合作，以採用這個標頭。結果是，在尖峰時段，輸入詞元快取命中率從 60% 提高到 80%。這顯著增加了我們可以處理的請求輸送量，同時為 OpenCode 或 AI 程式碼審查等互動式或時間敏感的工作階段提供更好的效能。
由於我們現在提供更大的模型，一個執行個體可能橫跨多個 GPU。這意味著我們必須找到一種有效的方式在 GPU 之間共用 KV 快取。KV 快取是儲存所有來自預先填充階段輸入張量（一個工作階段中提示詞的結果）的地方，最初存在於 GPU 的 VRAM 中。每個 GPU 都有固定的 VRAM 大小，但如果您的模型執行個體需要多個 GPU，就需要一種方法讓 KV 快取能夠跨 GPU 存在並相互通訊。為了在 Kimi 上實現這一點，我們利用了 Moonshot AI 的 Mooncake Transfer Engine 和 Mooncake Store。
Mooncake 的 Transfer Engine 是一個高效能資料傳輸框架。它支援不同的遠端直接記憶體存取 (RDMA) 通訊協定，如 NVLink 和 NVMe over Fabric，從而實現無需 CPU 介入的直接記憶體到記憶體資料傳輸。它提高了跨多個 GPU 機器傳輸資料的速度，這對於模型的多 GPU 和多節點設定尤其重要。
當與 LMCache 或 SGLang HiCache 搭配使用時，快取可以在叢集中的所有節點間共用，讓一個預先填充節點能夠辨識並重複使用來自先前請求（原本是在其他節點上進行預先填充）的快取。這消除了叢集內工作階段感知路由的需求，並使我們能夠更均勻地進行負載平衡。Mooncake Store 還允許我們將快取擴展到 GPU VRAM 之外，並利用 NVMe 儲存。這延長了工作階段保持在快取中的時間，提高了我們的快取命中率，使我們能夠處理更多流量並為使用者提供更好的效能。
LLM 的工作原理是根據序列中先前的詞元來預測下一個詞元。在單純的實作中，模型只會預測接下來的 n 個詞元，但我們實際上可以讓它在模型的單次前向傳遞中預測下 n+1、n+2... 個詞元。這項流行的技術稱為推測解碼，我們在先前一篇關於 Workers AI 的文章中曾討論過。
透過推測解碼，我們利用一個較小的 LLM（草稿模型）來產生幾個候選詞元，讓目標模型從中選擇。然後目標模型只需要在單次前向傳遞中，從一小群候選詞元中選出一個。驗證這些詞元的速度比使用較大的目標模型來產生詞元更快，計算成本也更低。然而，由於最終仍由目標模型決定接受或拒絕草稿詞元，所以品質仍然能維持。
在智慧體的使用情境中，推測解碼真正發揮了作用，因為模型需要產生大量的工具呼叫與結構化輸出。工具呼叫在很大程度上是可預測的——您知道它會有一個名稱、描述，而且被包裝在一個 JSON 信封中。
為了在 Kimi K2.5 上做到這一點，我們利用了 NVIDIA 的 EAGLE-3（用於提升語言模型效率的推測演算法）草稿模型。調整推測解碼的參數，使其包含要產生的未來詞元數量。因此，我們能夠在加速每秒詞元輸送量的同時，實現高品質的推斷。
正如我們在 2025 年「生日週」期間所宣布的，Cloudflare 擁有一個名為 Infire 的專有推斷引擎，能讓機器學習模型執行得更快。Infire 是一個用 Rust 編寫的推斷引擎，專為應對我們分散式全球網路在推斷方面面臨的獨特挑戰而設計。我們已擴展 Infire 以支援這類我們計劃執行的新大型語言模型，這意味著我們必須構建一些新功能來使其全面運作。
像 Kimi K2.5 這樣的大型語言模型擁有超過 1 兆個參數，大約是 560GB 的模型權重。一個典型的 H100 約有 80GB 的 VRAM，而模型權重需要載入至 GPU 記憶體中才能執行。這意味著，像 Kimi K2.5 這樣的模型至少需要 8 個 H100 GPU 才能將模型載入記憶體並執行——這還不包括 KV 快取（包含您的脈絡視窗）所需的額外 VRAM。
因此，自從我們最初推出 Infire 以來，我們就必須增加對多 GPU 的支援，讓推斷引擎能夠以管線平行 (pipeline-parallel) 或張量平行 (tensor-parallel) 模式（同時也支援專家平行 (expert-parallelism)）跨多個 GPU 執行。
對於管線平行，Infire 會嘗試適當地平衡管線中所有階段的負載，以防止某個階段的 GPU 閒置等待，而其他階段卻仍在執行。另一方面，對於張量平行，Infire 會最佳化以減少跨 GPU 的通訊，使其盡可能快速。對大多數模型而言，同時運用管線平行與張量平行，可以在輸送量與延遲之間取得最佳的平衡。
雖然 Infire 原本就已經比 vLLM 具有更低的 GPU 記憶體開銷，我們還是進一步最佳化了 Infire，縮減了像是啟用值 (activation) 等內部狀態所需的記憶體。目前，Infire 僅需兩個 H200 GPU 就能執行 Llama 4 Scout，並剩下超過 56 GiB 的空間留給 KV 快取，足以處理超過 120 萬個詞元。Infire 也能在 8 個 H100 GPU（沒錯，就是 H100）上執行 Kimi K2.5，並仍有超過 30 GiB 可用於 KV 快取。在上述兩個案例中，若是使用 vLLM，您可能連啟動模型都會有困難。
在加入多 GPU 支援的過程中，我們發現了更多可以改善啟動時間的機會。即使是像 Kimi K2.5 這樣最大的模型，Infire 也能在 20 秒內開始服務請求。載入時間僅受限於磁碟機速度。
投資於我們專有的推斷引擎，使我們能夠最大化硬體的效能：在不受限制的系統上，每秒詞元輸送量提升高達 20%，同時也使我們能夠使用較低階的硬體來執行最新的模型，而這在以前是完全不可行的。
機器學習領域每週都有新技術、研究和模型問世。我們正在持續最佳化我們的技術堆疊，以便在高效運行 GPU 的同時，為客戶提供高品質、高效能的推斷服務。如果您覺得這些挑戰很有趣——我們正在招聘！