在大语言模型推理服务化的工程实践中，一个长期被低估的痛点是资源利用率的波动性。与模型训练可以接受批处理带来的吞吐量优先不同，推理服务必须在低延迟与高吞吐之间找到平衡点。传统的推理部署往往采用静态分区策略 —— 将固定数量的 GPU 分配给 Prefill 阶段，固定数量分配给 Decode 阶段。这种看似简洁的架构在面对真实流量时却暴露出严重的效率问题：当长 prompt 请求激增时，Prefill GPU 过载导致首 token 时间（TTFT）飙升，而 Decode GPU 处于闲置状态；反之，当大量短请求涌入时，Decode 阶段成为瓶颈，而 Prefill 资源被浪费。NVIDIA Dynamo 作为数据中心级别的分布式推理框架，其核心设计理念正是通过动态调度与智能路由来彻底解决这一结构性矛盾。
动态调度架构：从被动响应到主动预测
Dynamo 的动态调度系统由三个核心组件构成：事件平面（Event Plane）、Planner 规划器以及可弹性伸缩的工作节点。事件平面负责实时捕获系统中发生的各类信号，包括请求到达速率、输入序列长度分布、输出 token 生成速率、GPU 利用率曲线以及 KV 缓存命中率等关键指标。这些信号通过 NATS 或 Kubernetes 原生机制进行广播，确保所有调度决策组件能够基于一致的实时视图进行判断。Planner 是整个调度系统的决策大脑，它内置了多种调度策略模板，包括基于延迟敏感的 SLA 策略、基于吞吐量的批量策略，以及针对推理工作负载专门优化的混合策略。当事件平面报告的指标超过预设阈值时，Planner 会在不中断服务的前提下触发工作节点的扩缩容操作。
具体到扩缩容的触发机制，Dynamo 采用了一种双轨阈值系统。对于 Prefill 工作节点，核心监控指标是输入序列长度（ISL）与请求到达速率的乘积，当这个复合指标超过当前算力的某个百分比时（例如 85%），系统会启动 Prefill 节点的扩容流程。反之，当指标持续低于安全水位线（如 30%）超过一个观察窗口期时，Planner 会触发缩容以释放资源。Decode 工作节点的监控逻辑类似，但关注的重点是输出序列长度（OSL）与 token 生成速率的乘积，即系统的实际生成吞吐量。这种区分 Prefill 与 Decode 监控焦点的设计，体现了 Dynamo 对推理工作流本质特征的深刻理解 ——Prefill 是计算密集型瓶颈，Decode 是内存带宽与延迟敏感型瓶颈，两者的优化维度天然不同。
KV 感知路由：超越负载均衡的智能分发
传统的请求路由策略通常基于简单的轮询、最少连接数或随机分发算法。这些策略在无状态服务中表现良好，但在 LLM 推理场景下却存在根本性的缺陷：它们完全忽视了 KV 缓存的存在价值。当一个请求被路由到错误的节点时，该请求在之前交互中已经计算并缓存的 Key-Value 向量会被丢弃，系统不得不为相同的上下文前缀重新执行完整的 Prefill 计算。这种重复计算不仅浪费了宝贵的 GPU 算力，还显著增加了 TTFT，因为 Prefill 阶段的计算量与输入序列长度成正比。
Dynamo 的 Smart Router 引入了一种截然不同的路由范式：优先将请求发送到 KV 缓存命中率最高的节点。这一策略的实现依赖于全局 radix 树注册表（Global Radix Tree Registry），该数据结构维护了所有活跃 KV 缓存在分布式系统中的位置映射关系。每当一个请求到达时，Router 会提取其输入序列的前缀，计算该前缀在全局注册表中的缓存分布，然后选择缓存率最高且负载可接受的节点作为目标。如果存在多个缓存率相近的候选节点，系统会进一步根据当前的负载情况进行负载均衡，以避免出现部分节点过热而另一部分节点空闲的极端情况。
从性能数据来看，KV 感知路由带来了显著的实际收益。在 NVIDIA 官方使用 R1 Distilled Llama 70B 模型进行的 100,000 条真实请求测试中，相比随机路由策略，KV 感知路由实现了 3 倍的 TTFT 提升以及 2 倍的平均请求延迟下降。这一收益在重载场景下尤为明显，因为此时 KV 缓存的复用价值被放大 —— 更多的请求意味着缓存命中的概率更高，而每一次命中都意味着一次完整 Prefill 计算的节省。
多层级 KV 缓存管理：突破 GPU 内存边界
KV 缓存的容量是分布式推理系统扩展性的硬性约束。即使是 70B 参数的模型，其 KV 缓存在处理长上下文时也可能轻易耗尽单卡 80GB HBM 的容量。Dynamo 的 KV Block Manager（KVBM）提供了一套多层级缓存管理方案，允许系统将部分 KV 缓存卸载到更低成本、更高容量的存储层级，包括主机 DDR 内存、本地 NVMe SSD，甚至是网络附加存储（NAS）或对象存储服务。
KVBM 的设计核心在于智能的缓存放置与驱逐策略。当 GPU 内存接近饱和时，系统会根据 KV 块的使用频率、预计下次访问时间以及缓存大小综合计算每个块的驱逐优先级。热点 KV 块会被保留在 GPU HBM 中，温数据可以降级到 DDR 内存，冷数据则进一步下沉到 NVMe 或远程存储。更重要的是，Dynamo 在缓存层级之间实现了高效的传输协议 NIXL（NVIDIA Inference tranXfer Library），能够在 Prefill 节点与 Decode 节点之间快速传递 KV 缓存，同时在缓存卸载与加载过程中保持极低的延迟开销。
实测数据显示，KVBM 的多层级缓存机制能够带来 2.2 倍到 12 倍的 TTFT 提升，具体收益取决于请求到达速率（QPS）的高低。在低 QPS 场景下，由于缓存失效的概率较低，KVBM 的优势主要体现在能够处理更长的上下文而不触发显存溢出；在高 QPS 场景下，缓存复用的收益被放大，配合 NIXL 的高速传输，整体延迟改善更为显著。
实战配置参数与监控要点
在生产环境中部署 Dynamo 时，有几个关键参数需要仔细调优。首先是 Planner 的扩缩容阈值配置，建议将扩容阈值设置在 75% 到 85% 之间，缩容阈值设置在 25% 到 35% 之间，并配置适当的观察窗口期（如 30 秒到 60 秒）以避免震荡。其次是 KV 缓存的驱逐策略选择，对于内存敏感型部署可以采用 LRU（最近最少使用）策略，对于工作负载具有明显周期性的场景可以考虑 LFU（最不经常使用）策略以更好地保留热点缓存。
监控层面建议重点关注以下指标：全局 KV 缓存命中率（目标值应高于 60%）、Prefill 与 Decode 阶段的 GPU 利用率差距（理想状态下应保持在 15% 以内）、请求的 TTFT 分布（P99 延迟不应超过 SLA 目标的 1.5 倍）、以及事件平面的信号延迟（确保 Planner 能够基于近实时的数据做出决策）。这些指标可以通过 Dynamo 自带的 Prometheus 端点进行采集，并配合 Grafana 可视化面板进行实时观察。
从架构选型的角度来看，Dynamo 特别适合以下场景：日均请求量波动大且难以预测的在线服务、需要处理长上下文（超过 32K token）的应用、对 TTFT 和延迟有严格 SLA 要求的交互式 AI 产品，以及需要在有限 GPU 资源下最大化服务吞吐量的成本敏感型部署。对于流量相对平稳且规模较小的场景，使用传统的静态分区部署可能更为简单；但当系统扩展到多节点、跨机架甚至跨数据中心的规模时，Dynamo 的动态调度优势将变得不可替代。
资料来源：本文核心架构设计与性能数据来源于 NVIDIA Dynamo 官方文档（docs.nvidia.com/dynamo/latest/design_docs/architecture.html）与 GitHub 开源仓库（github.com/ai-dynamo/dynamo）。