来源： NVIDIA | Eli（Dynamo首席架构师） | 日期未提供 分类： NVIDIA 原文发表： 未提供 纪要生成： 2026-03-09
本次分享嘉宾Eli是NVIDIA Dynamo项目的首席架构师。本次分享聚焦Dynamo端到端架构设计思路，回应大模型推理服务平衡吞吐量与交互延迟的核心痛点，覆盖从预部署配置、集群调度、请求路由到故障容错的全链路实现逻辑，为大模型推理大规模落地提供完整方案参考。
本节重点 - 推理系统需平衡交互延迟与吞吐量的帕累托最优，不存在通用适配方案 - 需适配流量动态变化，支持KV缓存感知调度 - 内置原生容错能力应对网络故障、OOM、过载等突发场景
详细精要
聚合与解离部署模式各自适用于帕累托曲线的不同区间，Dynamo同时支持两类模式，最大化部署灵活性
系统需适配流量动态变化：架构设计支持动态调整配置与调度策略，匹配实时流量特征
支持KV缓存感知路由，优先将请求调度到已有对应缓存的节点，降低重复计算开销
原生容错是核心设计目标：容错能力从架构设计初期内置，而非后期补充
💬 精华片段（中文）
"So as we look at Dynamo, we need to be able to support not only disaggregated serving, but also aggregated serving. Right. And some some areas of the curve aggregated serving will be better than disaggregated. So it's not really a one size fits all."
本节重点 - AI Configurator可通过仿真快速生成初始部署配置，无需GPU - 输入包含模型、硬件、SLA要求等参数，输出并行策略、worker配比等完整配置 - 比在线profiling效率更高，可搭配在线profiling使用
详细精要
输出结果既可以直接导入Dynamo使用，也可以作为独立配置文件供其他系统使用
输入输出覆盖全链路部署需求：参数覆盖所有核心部署维度，输出直接可用
输出内容包含TP（张量并行）配置、并行策略、预填充/解码worker配比，同时明确推荐采用聚合或解离部署模式
与在线profiling形成互补：大幅缩短配置选型周期，降低调优成本
💬 精华片段（中文）
你可以在任意环境运行这个工具，因为它不需要GPU，完全基于仿真实现，能够快速给出准确的配置结果。
"The idea here is that this allows you to basically do offline configuration for your performance, choosing your particular latency targets and offline be able to quickly determine what is a good starting point. So this will tell you exactly what TP settings to give, what parallelism strategies, also how to match pre-fill and decode workers. And the idea is that you can do it, you can run it anywhere, because it doesn't really require GPU, just because it's done through simulation."
本节重点 - Dynamo控制平面完全适配K8s生态，降低落地门槛 - 自研Grove调度器支持拓扑感知，预填充/解码worker可独立扩缩 - 采用K8s原生endpoint slice实现服务发现，无需额外组件
详细精要
选择K8s原生设计的核心原因是K8s已经成为大模型推理大规模部署的事实标准
Grove调度器实现更灵活的弹性扩缩：兼顾拓扑亲和性与扩缩容灵活性
具备拓扑感知能力，可要求预填充、解码worker处于同一网络域，同时支持两类worker独立扩缩，兼顾性能与灵活性
服务发现复用K8s原生能力：兼容K8s与非K8s部署场景
💬 精华片段（中文）
我们采用标准的K8s技术实现服务发现，用户无需在集群中部署额外服务即可接入，大幅降低了落地门槛。
"So the information is shared between everything during discovery. And again, the main thing to mention is that we're using standard Kubernetes techniques for this. So it makes it easier for people to adopt without needing any additional services within their cluster."
本节重点 - Planner组件基于推理专属指标自动扩缩容，兼容标准HPA方案 - Model Express实现模型快速加载，降低扩缩容冷启动开销 - 支持集群内模型缓存、GPU间直接内存传输两种加速加载方式
详细精要
基于K8s标准扩缩容资源实现，可兼容HPA（水平Pod扩缩容）、Keda等通用扩缩容方案，支持用户自定义扩缩容逻辑
Model Express降低模型加载冷启动开销：从多个维度优化模型加载速度
💬 精华片段（中文）
如果首token延迟开始上升，我们可以增加预填充worker的数量；如果token间延迟成为瓶颈，我们则可以增加解码worker的数量。
"So if your time to first token is starting to increase, we can increase the number of prefill workers. If the intertoken latency is really the challenge, then we can increase the number of decode workers."
本节重点 - 前端与路由基于Rust开发，兼容OpenAI、vLLM等标准接口 - 预填充、解码worker独立优化，支持vLLM、TensorRT-LLM、SGLang等多推理引擎 - Nixle高性能传输库作为KV缓存与数据传输底座，支持多介质低延迟传输
详细精要
兼容OpenAI标准接口与vLLM服务接口，内置分词能力，降低用户适配成本
worker分层设计兼顾性能与灵活性：不同阶段worker独立优化，支持多推理引擎
worker内核基于Rust实现，推理引擎层抽象统一，适配vLLM、TensorRT-LLM、SGLang等主流引擎，KV事件、扩缩容等逻辑统一处理
Nixle与KV感知路由提升缓存利用率：最大化KV缓存复用率，降低计算开销
💬 精华片段（中文）
路由会维护一个全局索引，记录KV缓存在所有worker上的分布情况，这个索引的信息直接来自worker上报的KV事件，所以完全精确，不需要近似判断缓存是否存在。
"So when blocks are stored or evicted from particular workers, the router keeps track of that and contains a global index for the way the KV cache is distributed across the worker. We call this precise thing because it really gets events directly from the worker so it doesn't have to approximate whether something's in the cache or not."
本节重点 - 实现请求级容错，支持请求执行过程中迁移、随时取消、过载前置拒绝 - 所有状态最终一致性，多路由副本状态同步，单副本故障不影响服务 - 迭代快速重启技术，通过进程checkpoint恢复、影子内存等方式降低故障恢复时间
详细精要
支持全链路请求取消，任意环节触发取消后后续所有阶段都终止执行，避免资源浪费；集群过载时可前置拒绝请求，避免级联故障
状态最终一致性保障组件高可用：有状态组件多副本同步，无单点故障
单路由副本故障后，其余副本可直接接管所有流量，无状态不一致问题
快速恢复技术降低故障停机时间：多维度优化故障恢复速度
💬 精华片段（中文）
我们现在投入大量精力研发的方向之一是利用Model Express和其他技术实现快速重启，尽可能降低故障后的恢复时间。
"One of the other pieces that we're spending a lot of time on now is using model express and other technologies to do fast restart. So again, we talked about low latency GPU to GP way transfer. We're also looking at different ways to do checkpoint and restore of complete processes to really reduce that cold start and warm start time."
| 术语 | 解释 |
|---|---|
| Dynamo（NVIDIA） | 本集指NVIDIA推出的端到端大模型推理服务系统，覆盖部署、调度、路由、容错全链路 |
| AI Configurator | Dynamo配套的离线配置仿真工具，可快速生成推理部署最优配置 |
| TP（Tensor Parallelism） | 张量并行，一种大模型分布式推理并行策略，将模型参数拆分到多个GPU上计算 |
| K8s（Kubernetes） | 开源容器编排系统，是当前大规模云服务部署的事实标准 |
| CRD（Custom Resource Definition） | 自定义资源定义，K8s提供的扩展能力，用户可自定义资源类型 |
| Grove | Dynamo自研的K8s调度器，支持拓扑感知与细粒度扩缩容 |
| HPA（Horizontal Pod Autoscaler） | K8s原生水平Pod扩缩容组件 |
| KV Cache | 键值缓存，大模型推理中存储已计算的token注意力键值对，避免重复计算，降低延迟 |
| Prefill Worker | 预填充worker，大模型推理中负责处理用户输入prompt预计算阶段的工作节点 |
| Decode Worker | 解码worker，大模型推理中负责逐token生成输出序列阶段的工作节点 |
| Nixle | Dynamo内置的高性能多介质传输库，支持CPU、GPU、存储间的低延迟数据传输 |
| Rust | 高性能、内存安全的系统级编程语言，本集中用于开发Dynamo的路由、worker内核等核心组件 |
| OpenAI Compatible Interface | 兼容OpenAI标准的API接口，用户无需修改适配OpenAI的代码即可切换到Dynamo服务 |
| vLLM | 主流开源大模型推理服务框架，支持PagedAttention等内存优化技术 |
| TensorRT-LLM（TRT-LLM） | NVIDIA推出的大模型推理加速引擎，针对NVIDIA GPU做了深度优化 |
| SGLang | 主流开源大模型推理服务框架，支持快速结构输出等特性 |
| SLA（Service Level Agreement） | 服务等级协议，本集中指推理服务的延迟、可用性等服务承诺 |