Dynamo：Token 工厂的调度系统从 Prefill、Decode 到 KV Cache，Agent 时代为什么正在重写内存、存储与网络的价值

AI 推理调度正在从“谁空闲”升级到“谁已经知道这件事”

一座最先进的 AI Factory 即使拥有充足 GPU，也可能因为超长 Prompt、重复 Prefill、KV Cache 搬运、节点等待和上下文错配而浪费昂贵 Compute。Dynamo 的意义不是替代 TensorRT-LLM、vLLM 或 SGLang，而是在这些 inference engine 之上优化整个分布式系统：把 Prefill 与 Decode 拆开、把请求路由到拥有可复用 KV Cache 的 worker，并把上下文跨 GPU、内存和存储层调度。

一次 LLM 推理，实际上先“读资料”，再“逐字写答案”

大型语言模型收到请求后，并不是从第一个输出 Token 开始就一直做同一种计算。最重要的两个阶段是 Prefill 与 Decode。

NVIDIA Dynamo 官方文档将两者的 scaling pressure 分开：Prefill 主要受输入长度、Prompt reuse 和 context size 影响；Decode 更受并发、输出长度和 active KV memory 影响。这正是 P/D 分离有可能提高效率的原因。

KV Cache：不是“又一个缓存”，而是模型当前任务已经做过的计算

Transformer 在生成新 Token 时，需要参考前文。若每生成一个 Token 都重新处理此前全部上下文，重复计算会迅速膨胀。KV Cache 保存此前 Attention 中已经算出的 Key 与 Value，使后续 Decode 可以直接读取这些状态。

更适合投资研究的理解是：模型权重像长期能力与知识；KV Cache 像执行当前任务时已经形成的工作记忆。因此，当同一长前缀、多轮会话或 Agent 任务继续推进时，KV Cache 的复用价值并不等同于“少读几次 SSD”，而是“少做一遍昂贵的 GPU Prefill”。

Dynamo 优化的不是单颗 GPU，而是“模型周围的整套系统”

NVIDIA 对 Dynamo 的定位很清楚：inference engine 优化 GPU forward pass，Dynamo 则优化系统周围的分布式 serving。当前框架可与 vLLM、SGLang、TensorRT-LLM 配合，并支持 Kubernetes、Slurm 和本地部署；官方文档还列出 NVIDIA / AMD GPU 与 Intel XPU 支持，因此不能简单把 Dynamo 等同于“另一个 NVIDIA-only CUDA 锁定层”。

① Prefill / Decode Disaggregation：把两种工序拆开

在 aggregated serving 中，同一 worker 同时做 Prefill 与 Decode。若一个超长 Prompt 突然进入，重 Prefill 可能占据资源并干扰正在持续生成的请求。Dynamo 的 disaggregated serving 把两阶段放进独立 worker pools，使其可以分别选择并行度、部署位置和扩容比例。

② KV-Aware Routing：不是只看负载，而是看缓存重叠

Dynamo 的 PrefillRouter 可以综合 cache overlap score + worker load 选择 Prefill worker。传统负载均衡只问“谁更空”；Context-Aware 调度还会问“谁已经拥有这个请求的大量可复用前缀”。这改变了推理调度的优化目标。

③ xPyD：Prefill 与 Decode 的比例可以动态变化

Dynamo 支持运行时增加或移除 Prefill / Decode worker，使系统能够针对不同 workload 重新配置 x 个 Prefill、y 个 Decode 的比例。长上下文爆发时，Prefill capacity 可以上调；长输出、高并发时，Decode pool 可以成为主要扩容对象。

当“工作记忆”需要搬家，网络就变成推理生产线的一部分

Prefill 和 Decode 分开后，Prefill worker 生成的 KV Cache 必须传到 Decode worker。Dynamo 使用 NIXL 将 KV Cache 从 Prefill engine 的 VRAM 直接传到 Decode engine 的 VRAM；官方文档强调传输可以 non-blocking，使 GPU 在 KV 搬运期间继续为其他请求执行 forward pass。

单节点内可以走 NVLink / CUDA IPC；跨节点则需要 InfiniBand、UCX、RDMA 或 RoCE 等高速路径。于是一个新的系统权衡出现：分离 Prefill / Decode 可以减少资源错配，但会增加 Context Movement。只有网络足够快，拆分带来的收益才不会被 KV 迁移成本吞掉。

这意味着推理架构越强调 disaggregation、共享 KV 与多层缓存，Networking、NIC/DPU 和光互联的价值就越不能只用“训练集群带宽”解释。

为什么 Agent 把 KV Cache 从技术细节放大成基础设施问题

普通 Chatbot 的一次会话可能 Prompt 短、轮次少、任务结束快；Agent 则可能读取几十个文件、搜索、调用数据库、执行代码、再读取工具结果，并持续几十轮甚至更久。于是 Context Length、Turns、Concurrent Agents 与 Runtime 同时上升。

因此，Agent 经济并不只意味着“更多 Token 需求”。它还意味着每个 Token 背后的上下文管理成本发生变化。推理基础设施开始需要像操作系统管理进程和内存一样管理 Agent 的工作记忆。

CMX：HBM 与传统 Storage 之间，出现一个专为 Context 设计的新层

NVIDIA CMX（Context Memory Storage，上下文记忆存储平台）被官方定义为面向 long-context、multi-turn 与 agentic inference 的 AI-native context tier。它由 BlueField-4 驱动，使用 NVMe SSD、DOCA Memos 与 Spectrum-X Ethernet，把 GPU memory 向外扩展为 pod-level shared context tier，并专门针对 ephemeral KV Cache 优化。

NVIDIA 的 CMX 页面还明确把 Dynamo 放进同一体系：Dynamo 负责在 serving 层把请求路由到 KV Cache 所在位置，CMX 则提供 pod 级 Context Tier。两者合在一起，目标是让“已经计算过的状态”能够被发现、搬运和复用。

存储价值的新维度：不只是“我保存了多少 GB”，而是“我替 GPU 少算了多少”

传统存储价值常被压缩成容量、IOPS、带宽和 $/GB。KV Cache 让另一个经济变量变得重要：如果一个长 Prompt 的 Prefill 已经消耗大量 GPU 时间，而 Context Tier 能让后续请求复用这部分状态，存储保存的就不仅是数据，而是可避免的未来计算。

这并不意味着 NAND 的每个字节都会获得“GPU 估值”。真正决定价值的是：KV Cache 是否重复使用、命中率多高、上下文保留多久、网络搬运成本多少、存储延迟是否足够低，以及被避免的 Prefill 本身有多昂贵。

从 HBM 到 NAND、DPU 与光互联：受益逻辑不再只是“数据更多”

因此，存储投资逻辑需要从“AI 产生更多数据，所以 SSD 用量增加”升级为：哪些介质和系统真正进入推理关键路径，并通过 avoided compute 改善 Tokens/$TCO？这也是 CMX 相比传统冷存储更值得研究的地方。

真正应该观察的不是 Cache 容量，而是从命中率一路传导到 ROIC

这一链条不能跳步。Cache Hit Rate 很高但网络搬运太慢，可能不改善 TTFT；GPU utilization 上升但 Token realized price 下跌，也未必提高 Revenue/MW。最终仍要回到经济产出，而不是只看技术 benchmark。

什么情况下，Dynamo / Context Memory 的投资价值会被高估

Token 工厂的竞争，正在从“算得快”进入“少重算、少等待、会记忆”

Physical CUDA 把 AI Factory 的优化边界从 GPU 延伸到网络、电力、冷却和资本；Dynamo 则把视线推进到工厂内部运行时。这里的核心资源不再只有 Compute，还有 Context——哪些状态已经被计算、存在哪里、是否值得搬、何时复用。

主要来源与证据边界

相关研究

AI Factory生产函数系列③｜Physical CUDA — 从设施、电力和资本层理解 NVIDIA 如何定义 AI Factory。

AI记忆体大迁徙｜从 HBM 到 CMX，NAND 进入 GPU 上下文层 — Context Memory 的存储产业链背景。

AI Cloud 四层经济模型：从 1MW 到 Token，再到利润池 — 把运行时效率继续接回 Revenue/MW 与 ROIC。