@NVIDIAAI：傳統推論無法應對Agentic程式開發需求，NVIDIA Dynamo透過全棧優化實現高達7倍吞吐量。 NVIDIA Dynamo針對Agentic程式開…

傳統推論無法應對Agentic程式開發需求，NVIDIA Dynamo透過全棧優化實現高達7倍吞吐量。 NVIDIA Dynamo針對Agentic程式開發重建推論堆疊，解決傳統系統在數百次API呼叫下的KV快取瓶頸，實現更高快取命中率、更低延遲與高達7倍吞吐量提升。 實際應用數據 編碼Agent已大規模產生生產程式碼： Stripe的Agent每週產生超過1,300個PR。 Ramp將30%的合併PR歸功於Agent。 Spotify每月報告超過650個Agent產生的PR。 工具如「Claude Code」與「Codex」單次程式開發會話中進行數百次API呼叫，每次攜帶完整對話歷史，造成嚴重KV快取壓力。以「Claude Code」為例，第一個API呼叫寫入對話前綴至KV快取後，後續呼叫命中率達85-97%；Agent團隊（或swarm）跨4個Opus成員聚合命中率達97.2%，讀寫比11.7倍，呈現寫一次讀多次（WORM）存取模式。最大化跨worker的快取重用率、保持KV區塊溫熱且可路由，是Agentic推論的核心優化目標。 關鍵術語定義 文章一致使用三個術語： harness：驅動工作流程的Agent框架（如「Claude Code」、「Codex」、「OpenClaw」、「OpenCode」等）。 Orchestrator：Dynamo的路由、排程與快取管理層。 Runtime：執行模型並擁有KV快取管理器的推論引擎（如SGLang、vLLM、TRT-LLM）。 Layer 1：前端API優化 Dynamo在前端支援多協議，讓單一部署相容各種harness。 多協議支援 Agent harness日益採用v1/responses與v1/messages取代v1/chat/completions，以處理交錯思考與工具呼叫等新模式。v1/chat/completions將訊息內容視為平面字串、工具呼叫作為獨立欄位（如GLM與MiniMax在後端託管時處理交錯思考的差異）；v1/responses與v1/messages則使用類型化內容區塊，讓單一助理回合包含思考、工具呼叫與文字等獨立物件。這讓orchestrator辨識區塊邊界、執行提示優化，並依區塊類型套用不同快取與排程政策。Dynamo透過共通內部表示服務三種端點，讓單一部署成為任一harness的推論後端。NVIDIA團隊內部部署Dynamo運行「GLM-5」與「MiniMax2.5」，驅動「Codex」與「Claude Code」harness，並基準測試後端實現，目標與封閉源推論的快取重用效能平齊，將於數週內分享完整報告與優化配方。 日零工具呼叫支援 Dynamo投資多個開源模型的工具呼叫與推理解析日零支援，若模型未支援，可開issue或使用tool-call-parser-generator skill以任一harness產生解析器。 Agent提示：harness與orchestrator介面 傳統推論伺服器僅見匿名token化請求，忽略harness的全球脈絡，如哪些Agent阻塞於工具呼叫、哪些剛生成、會話剩餘回合數，或當前呼叫是快速查詢或長合成。程式開發Agent使用者等待最終結果而非單token串流，讓orchestrator可重排序與優先化跨Agent請求而不影響使用者體驗；會話持續數分鐘至數天，包含長工具呼叫暫停。這讓Dynamo的agent hints擴充實現橋接：harness可跨三種API端點附加結構化提示，讓路由器與runtime進行Agent感知排程與快取決策。此為v1 API，正與社群共同設計，歡迎harness開發團隊提供回饋。 Layer 2：路由器機制 編碼Agent遵循順序模式：長prefill、工具呼叫、前綴延伸、重複；多Agent harness則跨平行子Agent扇出短獨立脈絡。預設round-robin路由忽略快取局部性、請求優先級與會話結構，Dynamo路由器以三機制彌補：KV感知放置、優先排程與可延伸路由策略。 KV感知放置 無快取感知路由下，對話第2回合落在相同worker機率僅1/N，每次miss需完整前綴重計算，成效能瓶頸與使用者高成本。Dynamo路由器維護全球索引，記錄各worker的KV快取區塊；每請求查詢索引計算per-worker重疊分數，選擇最小化快取miss與解碼負載組合成本的worker。此成本函數可調，且可建置自訂Agent感知路由策略。「Flash Indexer」文章詳述六迭代達170M ops/s（行星規模KV路由）。 優先排程 優先級為單一使用者介面排程旋鈕，高值表示「更重要」。Dynamo在路由器與引擎層均利用： 路由器：啟用--router-queue-threshold時，高優先請求提前入列。 引擎：標準化後端特定極性，轉發用於佇列排序、預奪與KV快取驅逐。 入列請求使用BinaryHeap，依有效到達時間排序；高優先讓請求「提早到達」，置於低優先前。僅當所有worker超負載門檻時入列，否則直達worker選擇；容量釋放時優先排空高優先項目。引擎如SGLang可利用優先基底radix快取驅逐，低優先區塊先遭記憶體壓力淘汰。 Layer 3：KV快取管理 Agentic工作負載產生重用價值迥異的區塊——每回合重用的系統提示、永不重用的推理token——但預設LRU視所有區塊相同。2-30秒工具呼叫暫停可能淘汰整個前綴，迫使恢復時完整重計算。快取需理解區塊價值、支援跨worker共享，並尊重Agent生命週期邊界。 均勻驅逐問題 LRU僅看最近性，高流量下2-30秒工具呼叫等待可能讓Agent區塊老化，恢復時需重計算前綴。解決之道為提供orchestrator API，控制保留哪些區塊、在何處存活、多久。 KV快取作為共享資源 目前KV快取為各worker本地短暫資源，Agent的~32K token系統提示與工具定義在每個服務請求的worker獨立計算；主Agent生成4子Agent時，若工具定義重疊且落在不同worker，共享前綴重複計算4次。「Claude Code」團隊會話分析顯示：成員平均79.4%快取命中率，對比主Agent探索子Agent的91.3%（5.0x vs. 11.7x讀寫比），差距幾乎全由各成員首次呼叫cold-start寫入造成。目標讓高價值KV區塊全叢集可用：cold start寫一次，全worker隨時讀取。 SGLang的HiCache與Dynamo的KV Block Manager（KVBM）建構4階記憶體階層： 區塊遵循write-through路徑：worker計算KV前綴後，從GPU流至CPU至磁碟；全球登錄以序列hash去重。註冊後區塊不可變，全worker可定址儲存階層。 這解決子Agent cold-start：主Agent計算工具定義與系統提示寫入共享儲存；子Agent 1生成於不同worker時，路由器查「Flash Indexer」找到區塊，worker經NIXL（RDMA讀）載入而非重算；子Agent 2同。4次冗餘prefill變1次計算+3次載入。同機制解決disaggregated prefill-decode一致性：prefill worker計算KV經NIXL傳decode worker；decode產生新KV；下回合prefill需原前綴+turn 1 token（僅存decode），共享儲存讓decode寫新區塊，任prefill下回合取用。 預取機制 多階儲存解決共享與持久，但區塊僅請求命中worker後抵達GPU。Agentic系統缺預取：harness用歷史計時預測工具呼叫回歸，知曉所需區塊與時機。Dynamo建構預取hook，讓harness訊號「提前從儲存拉GPU所需區塊」。結合保留API（下述），harness獲全生命週期控制：釘住防驅逐、設優先控驅逐順序、預取主動載入。 選擇性快取保留 全球可用解決共享，但不解驅逐。SGLang與vLLM支援優先基底驅逐（harness指派數值，低優先先淘汰）；TRT-LLM更進階TokenRangeRetentionConfig（Dynamo團隊成員@jthomson04設計實作），允許單請求內per-region控制。 請求攜0或多指令；無指令區塊走預設LRU（O(1)，零開銷）。驅逐分二結構：未優先LRU空閒清單與註解區塊優先佇列。harness可表達「系統提示區塊最後淘汰（優先100）；對話脈絡存活30秒工具呼叫（持續45s）；解碼token先走（優先1）」，引擎無需懂原因。 Anthropic的prompt caching標記前綴可快取；Dynamo的cachecontrol API帶相同語意至自託管推論。請求含cachecontrol: { type: "ephemeral", ttl: "1h" }，路由器釘住worker radix tree中匹配前綴節點於TTL，防L2儲存驅逐。 下一步連結保留至分散快取：目前保留限單worker本地；區塊釘worker A但下請求路由worker B，釘跟不上。延伸至HiCache/KVBM共享階，harness一次釘住跨worker存活：優先與TTL元資料隨write-through路徑旅行…