NVIDIA Dynamo 把 KV cache 當主角——為 Claude Code、Codex 這類 agent 重寫推論棧的真正原因

NVIDIA AI 在 X 上的一條 tweet：「傳統 inference 不是為 agentic coding 設計的。Agent 工具一個 coding session 打數百次 API、context 一直被重算，每個 token 的成本被推高。NVIDIA Dynamo 為 agent 重寫了整個堆疊：KV-aware routing、agent-aware scheduling、multi-tier caching、unified orchestration。結果：更高的 cache 命中、更低延遲、最高 7× throughput。」

「7×」這數字很容易讓人翻白眼當行銷話術。但 Dynamo 不是 vapor——它在 2025 年 3 月就已經開源在 GitHub（ai-dynamo/dynamo），底層是 NVIDIA 多年累積的 Triton inference server 經驗。值得花時間搞懂的，是它在解什麼問題。

Agent 推論為什麼跟 chatbot 不一樣

NVIDIA 開發者部落格〈Full-Stack Optimizations for Agentic Inference with NVIDIA Dynamo〉裡有幾個 Dynamo 團隊自己整理的真實數字（不是 NVIDIA marketing 數字，是引用第三方 case）：

• Stripe 的 agent 一週生成 1,300+ PR
• Ramp 把 30% 已 merge 的 PR 歸功於 agent
• Spotify 一個月有 650+ agent 生成的 PR
• 用 Claude Code 時，第一次 API call 把 conversation prefix 寫進 KV cache 後，之後每一次同一 worker 的呼叫命中率 85–97%
• 4 個 Opus agent 組成的 team，aggregate cache hit rate 達 97.2%
• read/write ratio 高達 11.7×——系統從 cache 讀的 token 是寫進去的近 12 倍

最後一個數字是核心：agent inference 是一種 write-once-read-many（WORM）pattern。System prompt + 累積的對話前綴只算一次，之後每次都從 cache 讀。這跟一般 chatbot 完全不同——chatbot 每個 user 的 context 各自獨立，cache 共享率本來就低；但 agent 在 minutes 到 days 的 session 內，不斷以幾乎一樣的 prefix 打 API。

如果你的 inference server 把每次請求當成獨立事件，就等於每次都重算這個 95%+ 的相同 prefix。這就是 Dynamo 要消除的浪費。

Dynamo 的四個核心元件

從 NVIDIA 官方 architecture 文件整理：

1. KV-aware Smart Router。 Dynamo 把所有 incoming request 雜湊後組成 radix tree，可以即時知道哪個 GPU worker 已經有相關 KV cache。Baseten 在生產環境的測試（Qwen3 480B Coder，~50k token input）顯示，開啟 KV routing 後，TTFT（time to first token）降低 50%、TPOT（time per output token）降低 34%。這是真實 workload 上的可重現數字。

2. Disaggregated Prefill & Decode。 把「讀 prompt」（compute-bound）與「生 token」（latency-bound）拆到不同 GPU。傳統做法兩件事擠在同一顆卡，prefill 一忙 decode 就卡。

3. Dynamic GPU Planner。 根據即時負載，動態調整 prefill / decode GPU 配比。Output 序列短的 workload 會讓 prefill GPU 變瓶頸——這時 Planner 把 decode GPU 拉去做 prefill。

4. KV Block Manager（KVBM）。 把 KV cache 在 GPU memory、CPU memory、storage 三層之間搬移，配合 NIXL（NVIDIA Inference Transfer Library）做 GPU-GPU 加速傳輸。Long context 不再被 GPU memory 限制。

「7× throughput」要怎麼讀

DigitalOcean 在 Dynamo 1.0 上線報導裡寫：「搭配 NVIDIA Blackwell Ultra GPU 時，Dynamo 可以把 inference performance 提升最高 7×。」這個數字有幾個前提：

• 必須是 Blackwell Ultra（不是任何 GPU）
• 必須是 agentic / long-context workload
• 「最高」意味這是 best case，不是平均

Baseten 的真實測試（用的是 Hopper 世代 GPU，不是 Blackwell Ultra）顯示的是 ~1.5–2× 的 latency 改善，不是 7×。Gradient Flow 在獨立評測裡也直接寫：「NVIDIA 宣稱 Dynamo 可以在 Blackwell + DeepSeek-R1 上做到 30× throughput——但這些性能指標目前缺乏獨立第三方驗證。」

7× 是 best case，要打折看；但 1.5–2× 在生產上是真的。

但是

幾個實務上的取捨：

第一，Dynamo 不是 inference engine，是上面一層。 它需要 vLLM、SGLang、TensorRT-LLM 之一當底層引擎。如果你已經跑了一套 vLLM cluster，Dynamo 是疊上去的 orchestrator。如果你還沒選 engine，Dynamo 不會替你選。

第二，SGLang 與 vLLM 已經有 prefix caching。 RunPod 的測試指出，SGLang 用 RadixAttention 在多輪對話下已經能把 throughput 維持在 30–31 tok/s，而 vLLM 會從 22 掉到 16 tok/s。Dynamo 的 KV-aware routing 在「跨 worker」「跨節點」的 scope 上勝出，但在「單一 worker 內」這層，SGLang 自己就做得很好。Dynamo 要打贏 SGLang 的價值，是 multi-node、distributed serving。

第三，open source 但綁 NVIDIA 硬體。 Dynamo 在 GitHub 上是開源的，理論上可以在任何硬體跑。但所有 NVIDIA 的 marketing 數字都綁 Blackwell——買 AMD MI300X 或 Trainium 的人，不會從 Dynamo 拿到一樣的優勢。

第四，llm-d 是另一個選項。 Red Hat 與 vLLM 社群推的 llm-d 也在做類似的事情——distributed inference orchestration。如果你的 stack 已經是 Red Hat / OpenShift，llm-d 比 Dynamo 自然得多。

為什麼這條 tweet 真的重要

不在「7× throughput」這個數字，而在 NVIDIA 終於承認：inference 的瓶頸不是 FLOPs，是 KV cache 怎麼路由。

這個轉變跟同一週 Google 公布 TPU 8i（用 384MB on-chip SRAM 把 KV cache 整個塞進晶片）是同一個訊號：reasoning + agent 的時代，整個推論棧的優化重心從 compute 移到 memory + routing。

對 indie builder 與小團隊：你不會自己跑 Dynamo cluster，但你選的 LLM 服務商（Baseten、Together、DeepInfra、Fireworks、Replicate）背後跑什麼，會直接決定你 agent app 的 cost-per-token。下次比價時值得問一句：「你們 stack 裡 KV cache 怎麼處理？」如果對方答不上來，你就知道要用誰。