llm-d 与 NVIDIA Dynamo 性能能力对照总表

Posted on
从推理服务生命周期角度整理 llm-d 与 NVIDIA Dynamo 在性能方向的公开能力。

一、分析口径

本文不做选型判断，也不讨论差异化，只整理 llm-d 与 NVIDIA Dynamo / ai-dynamo 在性能方向已经公开关注和建设的能力。

分析维度按推理服务生命周期展开：

  1. 服务定义与部署；
  2. 服务拉起与模型加载；
  3. 拓扑与多节点准备；
  4. 请求入口；
  5. 请求路由；
  6. KV Cache 感知；
  7. KV Cache 管理；
  8. KV 传输；
  9. Prefill/Decode 分离；
  10. 多阶段推理编排；
  11. 队列与流控；
  12. 延迟预测；
  13. 扩缩容与容量规划；
  14. 多 variant 管理；
  15. Batch / Async 推理；
  16. 多租户与 adapter 性能；
  17. Benchmark / Profiler / 配置搜索；
  18. 长上下文与 Agentic workload；
  19. RL / post-training 性能外延。

二、性能能力总表

生命周期阶段 核心问题域 要解决的问题 llm-d 相关能力 / 项目 Dynamo / NVIDIA 相关能力 / 项目
1. 服务定义与部署 模型服务抽象 如何把模型、runtime、GPU、Gateway、P/D 角色、调度策略声明成可部署服务 llm-d 主项目、InferencePool、llm-d-modelservice、well-lit path guides DynamoGraphDeployment、Dynamo Operator、Helm、CRDs、Dynamo recipes
2. 服务拉起 模型加载与冷启动 大模型权重加载慢，扩容时新副本无法快速进入服务状态 llm-d-fast-model-actuation：sleep/wake、model swapping、快速实例状态切换 ModelExpress：通过 NIXL / NVLink 等路径加速模型权重加载和新副本冷启动
3. 拓扑准备 GPU / 网络拓扑感知 多节点推理、P/D 分离、TP/EP 依赖 NVLink、IB/RDMA、GPU 拓扑和节点亲和性 hermes、llm-d-pd-utils、LWS、DRA、Kubernetes 调度集成 Grove：network topology-aware gang scheduling & autoscaling；Dynamo K8s deployment 集成拓扑感知能力
4. 请求入口 Gateway / Frontend 如何接收 OpenAI-compatible 请求，处理协议、租户上下文、路由元数据 Gateway API、Inference Gateway、llm-d-router Dynamo Frontend、Inference Gateway mode、Dynamo runtime frontend
5. 请求路由 LLM-aware routing 请求应该发到哪个 replica、哪个 pool、哪个阶段的 worker llm-d-router：load-aware、prefix-cache-aware、priority-aware、flow-control routing Dynamo Router / KV Router：基于 worker load、cache hit、runtime metrics 做路由
6. Prefix / KV 感知 KV-cache aware routing 如何让请求尽量命中已有 prefix/KV，减少重复 prefill，降低 TTFT llm-d-kv-cache / KV-cache indexer：维护全局 KV locality，为 Router 提供 cache score KVIndexer、KVPublisher、KV-aware routing、Dynamo Router
7. KV 管理 KV-cache lifecycle / offload KV Cache 超出 GPU HBM 后如何管理、offload、复用、扩大工作集 Advanced KV-cache management、tiered KV offloading、FS backend、GPU/CPU/Disk 层次化缓存 KVBM：GPU → CPU → SSD → remote storage 的 KV block 管理与 offloading
8. KV 传输 KV transfer / 数据移动 P/D 分离后，prefill 产生的 KV 如何低延迟传给 decode worker vLLM / SGLang KV transfer 集成；NIXL / UCCL backend；跨节点 cache coordination 方向 NIXL：面向 GPU/CPU/storage 的低延迟数据传输层；支持 P/D 场景下 KV cache movement
9. P/D 分离 Prefill / Decode disaggregation Prefill 和 Decode 资源特征不同，如何独立部署、独立扩缩、提升 GPU 利用率 P/D disaggregation guides、llm-d-modelservice、coordinator、Router/EPP 分阶段调度 Disaggregated Serving 是 Dynamo 三大核心性能技术之一；支持 prefill / decode worker 分离和组合优化
10. 多阶段推理 Pipeline orchestration 多模态 encode、prefill、decode、streaming、agentic 多轮等阶段如何编排 coordinator：Encode / Prefill / Decode pipeline 编排；通过阶段信息引导路由 Dynamo graph / disaggregated serving pipeline / PrefillRouter
11. 队列与流控 Flow control / backpressure 高并发下如何控制排队、限流、优先级，避免尾延迟失控 llm-d-router：request priority、performance target、flow control；Operational Excellence Dynamo Router / runtime 侧 load-aware routing、request rejection、worker load monitoring
12. 延迟预测 Latency-aware scheduling 如何预测请求在不同 endpoint 上的 TTFT、ITL、总延迟，从而更优路由 llm-d-latency-predictor；predicted-latency based scheduling 方向 Planner / Profiler / performance model；基于 workload profile 与 SLA 做容量和路由相关决策
13. 扩缩容 Autoscaling / capacity planning 多少副本、多少 prefill、多少 decode、如何满足 SLO 并降低成本 llm-d-workload-variant-autoscaler；scale-to-zero；saturation-based scaling；queue depth 与 KV pressure 信号 Planner：SLA-driven autoscaler，基于 profiling、workload、SLO right-size pools
14. 多 variant 管理 Workload variant / serving shape 同一模型可有不同 TP、batch、quantization、P/D 比例、硬件类型，如何选择最优配置 WVA、ModelService、InferencePool、Configuration Explorer Planner、AIConfigurator、Dynamo deployment config、自动生成优化配置
15. Batch / Async 离线推理 / 异步推理 如何利用在线服务空闲容量处理分钟级 SLO 或批量任务 llm-d-batch-gateway、llm-d-async；Batch Processing 主线能力 Dynamo 当前公开性能主线更聚焦 online / disaggregated serving；可通过 Dynamo graph/worker 承载部分批处理形态
16. 多租户与 Adapter LoRA / adapter-aware scheduling 多租户、多 adapter 场景下如何避免重复加载和无效计算 LoRA-aware prefix-cache scheduling；multi-tenant SaaS 场景 benchmark Dynamo 支持多 backend 和多 deployment，但公开性能主线更多围绕 KV、P/D、offload、Planner
17. Benchmark / Profiler 性能验证与复现 如何复现实验、做参数扫描、发现瓶颈、验证 well-lit path llm-d-benchmark、in-guide benchmark、Configuration Explorer、llm-d-inference-sim、llm-d-prism AIPerf、Profiler、AIConfigurator、Dynamo recipes、DynoSim-style modeling
18. 长上下文 Working set / context expansion 长上下文、多轮对话会产生大量 KV，如何避免 HBM 成为硬上限 hierarchical KV offloading、shared filesystem-backed KV tier、扩大有效 working set KVBM + KV offloading：将 KV 移到 host memory、local disk、remote storage，扩大上下文窗口
19. Agentic workload 多轮 / 工具调用 / 状态复用 Agent 多轮请求中，历史上下文不断增长，如何复用 prefix/KV 并降低重复 prefill KV-aware routing、async/batch、未来 semantic caching / pin critical context blocks 方向 Dynamo agentic inference 叙事强调 frontend API、router、KV cache management 三层
20. RL / post-training 性能外延 Rollout serving / weight movement RL 训练中 rollout 生成、权重同步、GPU 空转、sampling 调度如何优化 llm-d-rl、weight-propagation-interface、llm-d-rl-time-slicing、py-inference-scheduler Dynamo roadmap 中有 RL 方向；当前公开主线仍更集中在 serving、P/D、KV、Planner、ModelExpress

三、按业务流压缩后的问题地图

阶段 1：服务准备

核心问题是如何把一个大模型推理服务声明成平台可理解的对象。

llm-d 侧重点：

  • 通过 InferencePool、ModelService、well-lit path guides，把模型服务、runtime、GPU 资源、Gateway 和调度策略组织起来；
  • 强调 Kubernetes-native 和跨硬件 accelerator 的可复现部署；
  • 通过 benchmark guides 验证部署路径的性能。

Dynamo 侧重点：

  • 通过 Dynamo graph、Operator、CRDs、Helm 和 deployment recipes 定义分布式 inference 服务；
  • 将 disaggregated serving、KV offloading、Planner 等能力纳入统一 deployment 体系；
  • 更强调 datacenter-scale deployment 和 NVIDIA GPU fleet 上的性能闭环。

阶段 2：服务拉起与冷启动

核心问题是大模型权重加载慢，导致扩容、替换、低频模型唤醒成本高。

llm-d 侧重点：

  • llm-d-fast-model-actuation 关注 sleep/wake、model swapping、快速实例切换；
  • 其价值主要体现在弹性伸缩和低频模型服务场景。

Dynamo 侧重点：

  • ModelExpress 关注模型权重加载加速；
  • 通过 NIXL / NVLink 等数据移动能力加快新 replica cold-start；
  • 和 Planner、autoscaling、deployment 形成更强的性能闭环。

阶段 3：请求进入与路由

核心问题是普通负载均衡无法理解 LLM 请求的计算特征和状态复用机会。

llm-d 侧重点：

  • llm-d-router 是核心控制面；
  • 结合 load、KV locality、priority、performance target 做 endpoint selection；
  • 目标是替代普通 Kubernetes Service / round-robin，形成 LLM-aware scheduling。

Dynamo 侧重点：

  • Dynamo Router / KV Router 结合 worker load、cache hit、runtime metrics；
  • 与 KVBM、NIXL、disaggregated serving 深度联动；
  • 目标是同时优化 compute reuse、TTFT、throughput 和 GPU utilization。

阶段 4：KV Cache 感知与管理

核心问题是 KV Cache 既是性能优化的关键，也是长上下文和多轮对话的主要资源瓶颈。

llm-d 侧重点：

  • llm-d-kv-cache / KV-cache indexer 维护全局 KV locality；
  • 通过 cache-aware routing 减少重复 prefill；
  • v0.5 引入 hierarchical KV offloading，使用 GPU、CPU、filesystem-backed disk tier 扩大 working set；
  • 强调 shared KV tier 可让新节点更快 hydrate cache，减少 warm-up。

Dynamo 侧重点：

  • KVBM 是更完整的 KV block 管理层；
  • 覆盖 GPU、CPU、SSD、remote storage 等多级存储；
  • KV-aware routing、KV offloading 和 disaggregated serving 被官方定义为三大性能技术；
  • NIXL 负责高效 KV cache movement。

阶段 5：P/D 分离与多阶段执行

核心问题是 prefill 和 decode 的资源特征不同，放在同一种 worker 上会导致利用率不佳。

llm-d 侧重点：

  • 支持 P/D disaggregation；
  • 通过 Router/EPP、ModelService、coordinator 等能力组织 prefill/decode worker；
  • coordinator 进一步探索 Encode / Prefill / Decode 多阶段 pipeline 编排。

Dynamo 侧重点：

  • Disaggregated Serving 是核心性能能力；
  • 通过 NIXL 将 prefill worker 生成的 KV 传给 decode worker；
  • 官方强调 P/D、KV-aware routing、KV offloading 三者组合后存在性能叠加效应。

阶段 6：扩缩容与容量规划

核心问题是普通 HPA 不能理解 LLM serving 的 SLO、KV pressure、P/D 比例、variant 和硬件差异。

llm-d 侧重点：

  • WVA 关注 workload variant 层面的 autoscaling；
  • v0.5 增加 scale-to-zero / from-zero；
  • saturation-based scaling 使用 queue depth 和 KV-cache pressure 等信号提前扩容。

Dynamo 侧重点：

  • Planner 是 SLA-driven autoscaler；
  • 基于 profiling、workload prediction、performance model 和 SLO right-size pools；
  • AIConfigurator 用于快速搜索配置并生成 deployment config，减少手工 sweep。

阶段 7：性能验证与配置搜索

核心问题是分布式推理系统参数空间巨大，如果没有 benchmark/profiler，很难证明优化有效。

llm-d 侧重点：

  • llm-d-benchmark 和 in-guide benchmark 支持 well-lit path 性能复现；
  • Configuration Explorer 支持参数 sweep 和 memory-safe 配置探索；
  • llm-d-inference-sim 用于无 GPU 或轻量环境下模拟推理行为。

Dynamo 侧重点：

  • AIPerf 用于 benchmark；
  • Profiler 和 AIConfigurator 用于性能建模与配置推荐；
  • Dynamo 将配置搜索、deployment config、Planner 串成更自动化的性能工程链路。

四、一级问题域总结

如果抽象掉项目名，llm-d 和 Dynamo 在性能方向共同关注的问题可以归纳为以下 10 类。

一级问题域 关注点 llm-d 表现 Dynamo 表现
服务抽象 如何描述大模型服务、worker pool、variant、P/D role InferencePool、ModelService、well-lit path Dynamo graph、CRD、Operator、deployment recipes
请求调度 如何把请求放到最合适的 worker Router/EPP、load-aware、KV-aware、priority Router / KV Router、worker metrics、cache hit
KV 感知 如何利用已有 prefix/KV 降低 prefill KV-cache indexer、cache locality score KVIndexer、KVPublisher、KV-aware routing
KV 管理 如何扩大 KV 工作集并避免 HBM 限制 hierarchical KV offloading、FS backend KVBM、GPU/CPU/SSD/remote storage
KV 传输 P/D 分离时如何移动 KV NIXL / UCCL backend、runtime KV transfer 集成 NIXL、non-blocking KV movement
P/D 分离 prefill/decode 如何独立部署和扩缩 P/D guides、ModelService、coordinator Disaggregated Serving、PrefillRouter、NIXL
冷启动 新副本如何快速可用 FMA：sleep/wake、model swapping ModelExpress：权重加载和 replica cold-start 加速
扩缩容 如何以 SLO/成本/资源为目标调容量 WVA、scale-to-zero、KV pressure scaling Planner、SLA-driven autoscaling、AIConfigurator
性能工程 如何复现、调参、benchmark llm-d-benchmark、sim、prism、Configuration Explorer AIPerf、Profiler、AIConfigurator
高级 workload Batch、Agentic、RL rollout 如何进入平台 Batch Gateway、Async、llm-d-rl、WPI Agentic inference、Dynamo graph，RL 方向在 roadmap 中

五、初步结论

从性能视角看，llm-d 和 Dynamo 关注的问题高度重叠，但系统组织方式不同。

llm-d 更强调：

  • Kubernetes-native；
  • Gateway / EPP / InferencePool；
  • 跨硬件 accelerator；
  • well-lit path；
  • 通过 Router + KV locality + WVA 形成开放推理控制面；
  • 通过 incubation 扩展到 batch、RL、model actuation、multi-stage coordinator。

Dynamo 更强调：

  • datacenter-scale distributed inference runtime；
  • Disaggregated Serving；
  • KVBM；
  • NIXL；
  • ModelExpress；
  • Planner；
  • AIConfigurator / Profiler；
  • NVIDIA GPU fleet 上的数据移动、缓存管理、配置搜索和 SLA autoscaling 闭环。

如果只从性能主线抽象，两者都在围绕同一个核心目标展开：

通过请求调度、KV 状态复用、P/D 分离、KV offloading、低延迟数据移动、冷启动加速、SLO-aware autoscaling 和可复现性能工程，提高大模型推理系统的 TTFT、ITL、throughput、GPU 利用率和单位成本效率。

因此，后续分析不应先问“哪个项目更好”，而应继续拆解：

  1. 它们如何建模请求；
  2. 它们如何建模 KV 状态；
  3. 它们如何建模 worker / variant / topology；
  4. 它们如何把 routing、KV、P/D、autoscaling 串成闭环；
  5. 它们哪些能力已经进入主线，哪些仍在 incubation / roadmap / experimental 阶段。