隨著AI智能體
能力的不斷提升，它們對推理基礎設施提出了新的要求。與傳統聊天機器人不同，編程助手等智能體系統需要反覆處理大量上下文，在多次交互中重複利用資訊，並調用並行子智能體，從而產生不可預測的活動激增。這類工作負載的主要特點是讀取和管理上下文，而非生成文本，這給延遲、內存、吞吐量和成本都帶來了挑戰。
llm-d項目由IBM研究院、紅帽和谷歌牽頭，並有其他行業領導者共同參與，該項目推出了一個開源框架，旨在幫助大規模服務大語言模型，應對這些新型AI工作負載帶來的挑戰。llm-d正在滿足企業AI領域出現的一項需求：隨著每Token成本不斷上升，以及保護專有數據的需求日益增長，企業越來越希望在自有基礎設施上部署開放模型。目前，llm-d框架已證明其有能力處理當今的智能體流量。
在近期一次使用基準工作負載的演示中，llm-d項目展示了其開源推理平台能夠在H200 GPU上高效地為智能體工作負載服務大型混合專家模型。許多機構都面臨同樣的挑戰：如何在現有GPU集群上擴展智能體工作負載。此次演示的目標是證明，這在企業和雲端GPU集群中常見的H100加速器上同樣可以實現。
團隊使用llm-d，在544塊英偉達H100 GPU上部署了GLM-5.2，這是一個約7530億參數的開放權重混合專家模型（約390億活躍參數）。選擇該模型是為了展示當前平台運營商可能部署的實際場景。在具有數百個並發智能體會話、高上下文重用率的工作負載測試中（代表生產環境的流量模式），該部署在智能體基準測試中峰值實現了每分鐘超過660萬個輸出Token，可同時支持最多3000個並發編程智能體，且零搶占。
按當前雲端租賃價格計算，使用llm-d在H100上自託管GLM-5.2的單Token成本比同等商用API定價低5至10倍，在智能體工作負載常見的輸入密集型流量模式中，節省幅度最大。IBM研究院傑出工程師、llm-d維護者Carlos Costa表示："我們希望證明，一個自託管的開放權重模型可以在長上下文智能體工作負載下，以具有競爭力的交互吞吐量運行真實的智能體工作負載，而且使用的是大多數機構已經擁有的GPU。llm-d已經證明它能夠大規模處理這類工作負載。我們希望在常見的上一代GPU集群上，針對這種規模的模型縮小差距，而這正是我們此次所展示的內容。"
理解智能體流量
在此前的研究中，來自219個真實Claude Code會話的數據表明，為智能體工作負載提供服務需要與傳統聊天機器人推理不同的方法。編程智能體大部分時間都用於反覆讀取和處理大量上下文，而生成長回復所占的時間相對較少。這些上下文通常包含整個軟體代碼庫——是一項重複且繁重的工作。研究中的請求中位數攜帶約19.5萬個Token，但僅生成317個Token，這意味著計算挑戰主要集中在處理輸入上下文，而非生成文本。
基於此次演示，llm-d團隊總結出智能體工作負載的三個特徵：極長的上下文、對早期輪次資訊的大量重用，以及來自子智能體的並行活動突發。分析發現，相同資訊會被反覆處理：96%的主智能體請求逐字重用了先前請求至少90%的輸入內容。相比之下，高效系統應緩存並重用之前的計算結果，而非從頭重新計算。研究還表明，超過一半的請求是以並發子智能體任務組的形式到達的，且沒有提前通知，這會造成工作負載的突然激增，服務系統必須在不犧牲響應能力的前提下應對這種情況。
llm-d如何提供幫助
llm-d結合了六項能力，以減少重複的上下文處理、在負載下保持緩存重用，並獨立擴展預填充和解碼容量。
由於智能體服務中的大量計算都用於重新處理系統已經處理過的上下文，前綴感知路由會將每個請求定向到已保存其緩存上下文的伺服器，使系統重用先前的計算結果，而非從頭開始。在CyberGym智能體基準測試中，從優化的近似路由切換到精確前綴匹配後，吞吐量提升了79%，首Token生成時間降低了67%。分層鍵值（KV）緩存管理將工作緩存擴展到CPU內存，使有用的前綴在GPU內存壓力下得以保留，而非被清除後重新計算。當最佳緩存匹配位於另一台伺服器上時，點對點（P2P）KV緩存共享會從該對等節點直接獲取，而非在本地重新計算前綴。這些能力共同作用，減少了首Token生成時間，並通過避免重複的預填充工作來保留GPU容量，即便請求在伺服器之間遷移時也是如此。
一個7530億參數的模型無法容納於單台伺服器。llm-d通過採用數據並行注意力機制的廣域專家並行來解決這一問題，該方法將模型分布到多個節點上，同時避免了張量並行方式在GLM-5.2多頭潛在注意力機制下所需的KV緩存複製。隨後，預填充/解碼分離將上下文處理與Token生成拆分為獨立的資源池，各自針對其工作負載進行調優，並根據需求進行擴展。兩個資源池通過英偉達的NIXL零拷貝傳輸庫進行通信，在整個基準測試過程中未出現任何傳輸失敗。這使運營商能夠將模型部署到現有的H100節點集群中，並根據工作負載需求的變化，獨立擴展上下文處理和Token生成能力。
最後，多Token預測（MTP）在每次前向傳播中生成多個輸出Token，顯著提升了高並發下的輸出吞吐量。由於MTP建立在其他優化措施之上，其收益會不斷疊加。
Costa表示："llm-d不僅僅是一堆功能的集合，而是關於所有這些功能在生產環境中協同工作，運行在任何機構都能夠部署的基礎設施之上。這就是它們整合在一起時的效果。"
大規模服務已就緒
團隊在544塊H100 GPU上以分離拓撲結構部署了GLM-5.2，分別設置了獨立的預填充組和解碼組。該部署支持一項滿足關鍵業務需求的內部工作負載，涉及數百至數千個並發智能體，處理具有高上下文重用率的長上下文多輪任務。該系統專為處理持續的大規模生產流量而構建。
為了確定系統的極限並在受控條件下驗證每項能力，團隊在內部工作負載的同時運行了結構化基準測試。每項基準測試都使用全新的前綴和種子，以防止先前的緩存狀態影響結果。
AutomationBench通過將並發編程智能體數量從2000個擴展到3000個來測試原始並發能力。在2500個智能體這一舒適運行點上，該部署維持了每分鐘7612個請求，峰值輸入吞吐量為每分鐘1.3489億個Token，峰值輸出為每分鐘605萬個Token，且全程零搶占。在3000個智能體時，輸出達到每分鐘660萬個Token，隨後接近系統的服務極限，但未出現搶占或故障。
另外，CyberGym評估了長上下文智能體完成任務的能力：400個並發智能體，每個智能體在10輪交互中處理37.6萬字符的上下文。在完整路由方案下，全部400個智能體軌跡在248秒內完成，速率為每分鐘967.7個請求，首Token生成時間的第90百分位為17.59秒，隊列等待時間的第90百分位僅為1.11秒。本地前綴命中率達到73.18%，高於近似路由下的44.46%。
AgentX測試了128個並發智能體在約15分鐘內處理約19.5萬Token上下文的交互吞吐量。該基準測試完成了7251個請求，速率為每秒7.7個請求，首Token生成時間的第90百分位為5.77秒。測試過程中，168個請求觸發了對另一工作節點上可重用KV緩存塊的P2P查找。
在這些結果背後，分離式數據平面處理了全部工作負載。NIXL完成了620萬次KV緩存傳輸，平均每次傳輸2.71 GiB，在集群第90百分位維持約580 Gb/s的傳輸速率，且零傳輸失敗。每個成功請求對應近一次傳輸的比例表明，幾乎所有流量都經過了分離的預填充/解碼流水線。CPU層緩存吸收了2.53 PiB的提示塊儲存，並向GPU恢復了2.16 PiB，平均每次恢復耗時79.6毫秒。所有基準測試均以零服務錯誤完成。
在測得的緩存分解數據中，該技術棧從緩存中提供了85.2%的輸入Token，將未緩存的預填充比例降低至14.8%，為新上下文和生成任務留出了更多GPU容量。
紅帽團隊成員、推理工程高級首席機器學習工程師Maroon Ayoub表示："我們追求的不是單一的峰值吞吐量數字。我們想了解這種規模的開放模型能否支撐起定義智能體系統特徵的長上下文、重用和突發流量。在不出現搶占的情況下服務數千個並發智能體，為運營商提供了一條從基準測試結果通往生產部署的可靠路徑。"
這對平台運營商意味著什麼
llm-d等技術使已經擁有GPU基礎設施的機構也能夠觸及前沿級開放模型服務能力。以往要以具有競爭力的吞吐量服務這種規模的模型，往往需要更新一代的硬體或完全託管的API端點。這次演示表明，只要擁有合適的軟體技術棧，廣泛部署的H100基礎設施同樣能夠交付出色的結果，為擁有大規模H100集群的運營商提供了一條無需等待下一代加速器、即可自託管服務長上下文智能體工作負載的路徑。
Costa表示："擁有大規模H100集群的運營商看到這些數據後，會發現在自有基礎設施上服務前沿規模模型是一條可行的路徑。智能體推理是一個系統性問題。收益來自於避免冗餘工作、路由至正確的緩存、獨立擴展預填充和解碼能力，而不僅僅是原始的GPU吞吐量。"
IBM研究院高級技術人員Nili Guy表示："這些結果並非H100基礎設施能夠交付性能的上限。它們為我們提供了一個堅實的基準，開放服務技術棧的每一次改進都會拓展同一集群所能支撐的能力上限。這正是llm-d的機遇所在：軟體層面的改進能夠不斷放大運營商現有硬體的價值。"
團隊將繼續以開放的方式推進llm-d的發展，將大規模內部部署中積累的經驗應用於解決社區中的實際痛點。深入理解這些系統在持續智能體流量下的運行表現，將指引項目下一步的建設方向。
llm-d是一個開源項目，也是雲原生計算基金會（CNCF）沙箱項目，由IBM研究院、紅帽、谷歌以及不斷壯大的貢獻者和採用者社區共同參與建設。該項目提供部署指南、經過驗證的配置方案以及多平台支持。欲了解詳情，請訪問llm-d.ai。
Q&A
Q1：llm-d是什麼？它主要用來做什麼？
A：llm-d是由IBM研究院、紅帽和谷歌等共同推動的開源推理框架，用於大規模部署和服務大語言模型，特別適合處理AI智能體這類需要頻繁讀取和重用大量上下文的複雜工作負載。
Q2：使用llm-d部署GLM-5.2模型能節省多少成本？
A：按當前雲端租賃價格計算，使用llm-d在H100 GPU上自託管GLM-5.2的單Token成本比同等商用API定價低5至10倍，在智能體工作負載常見的輸入密集型流量場景中節省幅度最大。
Q3：llm-d通過哪些技術手段提升了智能體工作負載的處理效率？
A：llm-d結合了六項關鍵能力，包括前綴感知路由、分層KV緩存管理、點對點緩存共享、廣域專家並行、預填充/解碼分離以及多Token預測，共同減少重複計算、保持緩存重用，並支持獨立擴展處理能力。
