llm-d 与 NVIDIA Dynamo 可靠性能力对照分析

Posted on
从可靠性视角对照 llm-d 与 NVIDIA Dynamo 在高可用、故障恢复和流量治理方面的能力。

一、分析口径

本文只从可靠性视角整理 llm-d 与 NVIDIA Dynamo / ai-dynamo 生态中公开呈现的能力，不做选型判断，也暂不讨论差异化。

可靠性在大模型推理系统中不仅包括传统的 Pod 重启、健康检查和负载均衡，还包括：

  • Router / Gateway 高可用；
  • Endpoint 健康感知；
  • Worker graceful shutdown；
  • in-flight request 处理；
  • request migration；
  • request cancellation；
  • load shedding；
  • engine process failover；
  • GPU / node 故障恢复；
  • KV cache 在恢复过程中的角色；
  • P/D 分离下的跨阶段恢复；
  • 滚动升级与容量恢复；
  • 基础设施 HA；
  • 故障测试与验证。

为避免混淆，本文将能力状态分为四类：

状态 含义
主线 / 文档化 官方 README、docs、user guide 中明确作为能力说明
Issue / Proposal 公开 issue 或提案，方向明确，但不等同于成熟落地
Experimental / Preview 官方明确标为实验或预览能力
基础依赖 更多依赖 Kubernetes、Gateway、runtime 或底层组件，而不是该项目独立实现

二、可靠性能力总表

核心问题域 要解决的问题 llm-d 相关能力 / 项目 Dynamo / NVIDIA 相关能力 / 项目
控制面 / 入口高可用 Router、Frontend、Gateway 自身不能成为单点，入口组件故障后流量应继续可用 llm-d 以 Gateway API、Envoy、EPP、InferencePool 为基础；Router 作为智能入口，结合 endpoint 状态做请求放置；v0.5 中提到 active-active HA Dynamo 文档提到可启动多个 frontend + router replica，并共享 router state 以提高 fault tolerance；Fault Tolerance 总览也覆盖 system / infrastructure 层
Endpoint 健康感知 Router 需要识别 unhealthy、stale、overloaded worker，避免继续转发请求 llm-d-router 的 EPP 根据 InferencePool 当前状态、load、KV locality、priority 等信号做 placement decision；更多属于 routing / flow-control 基础能力 Dynamo Fault Tolerance 把 Health Checks 放在 Worker 层；整体架构中包含 health checks、discovery liveness、stale endpoint removal
Discovery / Membership 可靠性 Worker 上下线、失联、租约过期后，系统如何更新成员视图，避免 stale endpoint 主要依赖 Kubernetes endpoint、Gateway API、InferencePool / EPP 机制；公开资料中未看到单独 membership fault-tolerance 章节 Dynamo resilience loop 明确包含 discovery liveness、stale endpoint removal、event-path recovery
Graceful Shutdown / Drain 滚动升级、缩容、Pod 终止时，不应继续接收新请求，并尽量让 in-flight 请求完成 llm-d issue #927 提议采用 vLLM --shutdown-timeout，并设置 terminationGracePeriodSeconds 大于 shutdown timeout，以减少升级期间流量中断、允许 in-flight request 完成 Dynamo 有专门 Graceful Shutdown 文档：收到 SIGTERM / SIGINT 后调用 runtime.shutdown()，invalidates endpoints，不再接收新请求，并按配置等待 in-flight requests 完成和清理资源
In-flight Request Completion Worker 退出时，已有请求是等待完成、取消、迁移，还是直接失败 llm-d graceful shutdown issue 的目标是通过 vLLM shutdown timeout 让 in-flight 请求完成；公开主线未看到成熟 request migration / cancellation 策略 Dynamo graceful shutdown 支持 endpoint draining，并根据配置处理 in-flight requests；Fault Tolerance 总览把 graceful shutdown、request migration、request cancellation 作为关键机制
Request Migration / 故障续推 Worker 在生成中故障时，请求能否迁移到其他 worker 并继续输出 公开主线主要是 routing、flow control、HA、resilient transport、graceful shutdown issue；未看到等价于 Dynamo request migration 的文档化能力 Dynamo Request Migration 允许 in-progress requests 在 worker 不可用时迁移到健康 worker，保留 accumulated tokens，并保持 client token flow 连续
Request Cancellation 用户断开连接、请求超时或上游取消后，如何释放 worker 计算资源 公开资料中未看到 llm-d 层的一等 request cancellation 机制；通常依赖 Gateway / runtime 行为 Dynamo Request Cancellation 支持 graceful stop、kill signal、hierarchical cancellation propagation；vLLM backend 文档也说明用户断开连接时请求会跨 worker 自动取消以释放资源
Load Shedding / Request Rejection Worker 或系统过载时，如何拒绝新请求，防止级联故障、OOM 和尾延迟崩溃 llm-d Router 提供 request prioritization 和 advanced flow control；v0.5 也提到 operational rigor、availability requirements，但公开材料更偏调度 / SLO Dynamo Request Rejection / Load Shedding 基于 KV cache utilization、prefill token threshold、worker load monitoring 等阈值，过载时返回 HTTP 503，目标是防止 cascading failures
Priority / Degradation 不同租户或请求优先级不同，故障或过载时如何降级、排队或拒绝 llm-d-router 支持 request prioritization、flow control，并可通过 objective / target 影响 placement Dynamo 文档主要从 load shedding、worker load、HTTP 503、migration / cancellation 角度描述；优先级策略不是其公开 fault-tolerance 叙事核心
Worker Crash Recovery Worker crash、pod restart、runtime 异常后，如何摘流、替换、恢复服务 基础上依赖 K8s restart / endpoint 更新 / Router 重新放置；IRO proposal 面向硬件故障恢复提出 RecoveryRequest 与 EngineAdapter Dynamo Fault Tolerance 明确覆盖 Worker Pod Restart、Worker Crash、Network Partition、GPU Failure 等 failure scenarios；机制包括 health checks、migration、cancellation、load shedding
Engine Process Failover GPU / 节点仍健康，但 backend engine 进程崩溃时，能否快速恢复而非完整重载 IRO proposal 通过 EngineAdapter 抽象 pause / resume、scale down / up、engine status 等操作；更偏硬件 / engine recovery 协调 Shadow Engine Failover 是 Kubernetes 中同节点 engine-process failure 的 active/passive 恢复机制，目标是在 GPU / node 健康、engine 失败时由 standby engine 接管；属于 Experimental / Preview
硬件故障恢复 GPU reset、node reboot、node replacement 等硬件故障如何与推理服务生命周期协同 IRO issue 明确提出 RESET_DEVICE、REBOOT_NODE、REPLACE_NODE 三条恢复轨道，并通过 RecoveryRequest CRD 与 EngineAdapter 协调 engine recovery Dynamo Fault Tolerance failure scenarios 包含 GPU Failure；此外依赖 Kubernetes、Grove、底层 NVIDIA 平台能力和 Shadow Engine Failover 等机制
网络 / 传输韧性 网络拥塞、传输不稳定会导致 P/D KV transfer 或跨节点通信尾延迟波动 llm-d v0.5 提到 UCCL-based transport resilience；UCCL transport backend 用于提升拥塞网络下稳定性 Dynamo 依赖 NIXL 做跨 worker / GPU / CPU / storage 数据移动；Fault Tolerance 还把 NATS resilience、etcd HA 放到基础设施层
KV Cache 在可靠性中的角色 KV 不只是性能缓存；故障时是否能用于恢复、迁移或减少重算 公开主线更偏性能：KV locality、offloading、cache-aware routing；未看到成熟 KV-state recovery 语义 Dynamo load shedding 使用 KV cache utilization 作为 busy threshold；request migration 保留 accumulated tokens，但公开文档未表述为完整 KV block ownership / replica / epoch 级恢复
P/D 分离下的故障处理 Prefill 成功但 decode 失败、KV transfer 失败、decode worker 下线时，如何恢复请求 llm-d 有 P/D disaggregation 与 coordinator，但可靠性公开叙事未单独展开 P/D phase-aware recovery Dynamo request migration、graceful shutdown、request cancellation 覆盖 worker / request 层；vLLM backend 支持 request migration 配置，但 P/D phase-aware recovery 不是公开文档中的单独主题
Rolling Upgrade / ModelService 升级 模型服务升级期间如何尽量不中断用户请求 llm-d #927 明确目标是 graceful ModelService upgrades，配置 vLLM --shutdown-timeout 和 K8s terminationGracePeriodSeconds Dynamo Graceful Shutdown 服务于 Kubernetes pod termination、endpoint invalidation、in-flight wait、clean pod restart
Capacity Restoration / 故障后补容量 Worker 下线或故障后，如何补容量、防止幸存节点过载 llm-d 有 autoscaling、scale-to-zero、flow control；IRO proposal 中 REPLACE_NODE 会 scale down / replace / scale up，但 capacity restoration 没有形成独立文档化闭环 Dynamo Planner 负责容量规划，Fault Tolerance 通过 load shedding 防止过载；但公开 fault tolerance 文档更强调请求 / worker 恢复与拒绝，未把 recovery-aware autoscaling 单独展开
Infrastructure HA etcd、NATS、service discovery、event path 等基础组件故障如何处理 更多依赖 Kubernetes、Gateway、Envoy、KServe 等生态 HA 能力；v0.5 提到 active-active HA Dynamo Fault Tolerance 表中明确 infrastructure 层包括 etcd HA 与 NATS resilience
故障测试 / 验证 可靠性能力是否有测试框架验证，而不是只在文档中描述 llm-d-benchmark 主要关注部署、实验执行、数据采集和 teardown；可靠性 chaos / fault testing 公开主线不突出 Dynamo 有 Fault Tolerance Testing 文档，测试框架支持 request cancellation 等 fault tolerance mechanisms
可靠性文档体系 是否把可靠性作为系统级一等能力组织，而不是散落在 issue / runtime / K8s 配置中 llm-d 可靠性内容较分散：production、resilience、HA、UCCL、graceful shutdown issue、IRO proposal 等分别出现 Dynamo 有独立 Fault Tolerance 章节，并按 Request、Worker、Engine Process、System、Infrastructure 分层组织

三、按可靠性层次归纳

1. 流量级可靠性

这一层解决的是：

不要把请求继续打到坏节点或过载节点。

能力 llm-d Dynamo
健康感知 Router / EPP 基于 InferencePool 状态和实时信号做 placement Health Checks、Discovery Liveness、stale endpoint removal
负载保护 Router 支持 prioritization 和 advanced flow control Request Rejection / Load Shedding，基于 KV utilization、prefill token 等阈值返回 503
入口 HA v0.5 提到 active-active HA 多 frontend + router replica，共享 router state

初步判断：

  • 两边都有流量级可靠性能力；
  • Dynamo 的 fault-tolerance 文档化更完整；
  • llm-d 更像是把这些能力分散在 Router、HA、transport、K8s integration 中。

2. Worker 生命周期可靠性

这一层解决的是：

Pod 升级、缩容、退出、crash 时，系统如何优雅处理。

能力 llm-d Dynamo
Graceful shutdown issue #927：计划采用 vLLM --shutdown-timeout，配合 terminationGracePeriodSeconds 专门文档：SIGTERM / SIGINT → endpoint invalidation → 等待 in-flight → cleanup
Rolling upgrade 通过 graceful ModelService upgrade issue 推进 Graceful shutdown 明确覆盖 Kubernetes pod termination 和 clean restart
Worker crash 依赖 K8s + Router/EPP + IRO proposal Fault Tolerance 明确覆盖 worker crash、pod restart、network partition、GPU failure

初步判断：

  • Dynamo 已经做成用户指南；
  • llm-d 正在通过 issue / proposal 补齐；
  • llm-d 当前更依赖 Kubernetes 与 runtime 的基础语义。

3. 请求级可靠性

这一层解决的是：

请求已经在生成中，故障或取消时怎么办。

能力 llm-d Dynamo
Request migration 未看到成熟主线能力 已有 Request Migration：保留 accumulated tokens，迁移到健康 worker 继续生成
Request cancellation 未看到独立主线能力 已有 Request Cancellation：支持层级取消传播，用户断连时跨 worker 取消
In-flight handling 主要通过 graceful shutdown issue 依赖 vLLM shutdown timeout Fault Tolerance 明确把 migration、cancellation、graceful shutdown 组合起来处理

初步判断：

  • Dynamo 在请求级可靠性上更系统；
  • 需要注意 Dynamo request migration 公开语义主要是 accumulated-token continuation；
  • 这不应直接等同于完整 KV-state 接管。

4. Engine / 硬件恢复

这一层解决的是：

engine process、GPU、node 发生故障时如何恢复服务能力。

能力 llm-d Dynamo
Engine process failover IRO proposal 通过 EngineAdapter 抽象 pause / resume、scale down / up Shadow Engine Failover，作为 Engine Process 层机制，被列入 Fault Tolerance
GPU reset / node reboot / node replacement IRO proposal 明确 RESET_DEVICE、REBOOT_NODE、REPLACE_NODE 三条恢复轨道 Fault Tolerance failure scenarios 包含 GPU Failure；Shadow Engine Failover 覆盖同节点 engine-process failure
硬件恢复编排 IRO 通过 RecoveryRequest CRD 与 infrastructure recovery controller 协同 依赖 Dynamo + Kubernetes + NVIDIA 平台能力

初步判断：

  • llm-d 在硬件故障恢复方向有明确 proposal；
  • Dynamo 已有更完整的 fault-tolerance 叙事，并有 experimental / preview 的 Shadow Engine Failover；
  • 两者都在把 engine / hardware failure 从普通 Pod 重启提升为平台级恢复问题。

5. 状态级可靠性

这一层解决的是：

KV、token、sequence state 这些推理状态能否参与恢复。

状态 llm-d Dynamo
Token state 未看到主线 request migration 语义 Request Migration 保留 accumulated tokens
KV state 公开材料主要用于性能：KV locality、offloading、cache-aware routing KV utilization 用于 load shedding；KVBM 偏性能管理；公开 migration 未表述为 KV block 级恢复
Sequence state 未看到成熟公开能力 Request migration 有 partial generation state，但更像 token-level continuation

初步判断：

  • Dynamo 已经有请求级迁移能力；
  • 但公开资料不应解读为完整 KV-state-aware recovery；
  • llm-d 公开主线也没有把 KV 状态恢复做成成熟可靠性能力；
  • 状态级可靠性是目前两者公开材料中都需要谨慎表述的部分。

四、事实底图总结

从可靠性角度看，两大系统的公开侧重点不同。

llm-d

llm-d 的可靠性能力存在，但整体较分散，主要体现在：

  • Router / EPP 的 endpoint 状态感知；
  • request prioritization；
  • advanced flow control；
  • active-active HA；
  • UCCL-based transport resilience；
  • graceful shutdown / graceful ModelService upgrade issue；
  • Inference Resilience Operator proposal；
  • Kubernetes / Gateway / runtime 基础可靠性能力。

可以概括为：

1
2
3
llm-d：
  可靠性能力存在，但更分散在 Router、HA、transport、graceful shutdown issue、IRO proposal 中；
  公开主线仍主要围绕性能、调度、KV、P/D、autoscaling 和 production hardening。

Dynamo / NVIDIA

Dynamo 的可靠性体系更显性，已经有独立 Fault Tolerance 文档，并按层次组织：

  • Request；
  • Worker；
  • Engine Process；
  • System；
  • Infrastructure。

公开覆盖的能力包括：

  • request migration；
  • request cancellation；
  • graceful shutdown；
  • request rejection / load shedding；
  • health checks；
  • stale endpoint removal；
  • shadow engine failover；
  • etcd HA；
  • NATS resilience；
  • fault tolerance testing。

可以概括为：

1
2
3
4
Dynamo：
  可靠性已经是一等文档主题；
  覆盖流量级、请求级、worker 生命周期、engine process 和基础设施层；
  但公开资料中仍需区分 token-level request migration 与完整 KV-state-level recovery。

五、当前可确认的边界

为了保证汇报真实可靠，建议在材料中避免以下表述：

1
2
错误表述：
  llm-d 和 Dynamo 主要关注性能，没有做可靠性。

更稳妥的表述是：

1
2
3
4
5
更准确表述：
  llm-d 和 Dynamo 都已经开始覆盖生产级可靠性能力。
  Dynamo 尤其将 Fault Tolerance 作为一等文档主题，覆盖 request migration、request cancellation、graceful shutdown、load shedding、health checks 和 engine-process failover 等能力。
  llm-d 的可靠性能力则更分散，主要体现在 Router/EPP flow control、active-active HA、transport resilience、graceful shutdown issue 和 IRO 硬件故障恢复 proposal 中。
  两者公开材料中都需要谨慎区分请求级恢复与完整 KV-state-level recovery。

六、后续继续分析的问题

如果后续要进一步深入，可以继续按以下问题核对：

  1. Dynamo request migration 是否只是 token-level continuation，还是支持真正的 KV / sequence state migration；
  2. Dynamo Shadow Engine Failover 是否能覆盖 in-flight request，还是主要覆盖 model weights / engine process；
  3. llm-d IRO proposal 是否进入实现阶段，是否已有 controller / CRD / EngineAdapter 实现；
  4. llm-d graceful shutdown issue 是否合入主线，ModelService Helm chart 是否已支持相关配置；
  5. llm-d active-active HA 覆盖的是 Router / control-plane HA，还是包括请求状态级 HA；
  6. 两者是否有 P/D phase-aware recovery 的明确状态机；
  7. 两者是否把 recovery-aware autoscaling 与 fault tolerance 联动起来；
  8. 两者是否有针对 fault injection / chaos testing 的 benchmark 或 e2e 测试体系。