标签: #vLLM 에서 Dynamo 로

← 全部文章

• 将相同的请求发送给 Dynamo，实测轮询和感知 KV 路由

  我们按照第 1 篇中测试请求的相同顺序，再次将其发送给了 Dynamo。如果将前端设置为轮询（Round-Robin），其命中率与 Service 背后的 vLLM 相同。仅通过 Dynamo 并不会使缓存复苏。开启感知 KV 路由后，在 6 个 Worker 上，请求级别的命中率分别从：7 种前缀的 56% 上升到 83%、12 种前缀的 32% 上升到 68%、24 种前缀的 18% 上升到 43%；并发数为 16 时的 TTFT

  2026-11-13 · 16 分钟阅读 #NVIDIA Dynamo#vLLM#KV 인지 라우팅#접두 캐시#KV 캐시

• 如果将 prefill 和 decode 拆分，在小模型和慢网络下测量分离式服务

  我们在 Kubernetes 中不使用 Grove 部署了 Dynamo 的分离式服务，并发送了与第 3 篇相同的请求。在同一台服务器中分为两个 prefill Worker 和两个 decode Worker 时，首个 Token 时间的中位数从 34~106ms 增加到 286~896ms，吞吐量减少了 37~48%。这是因为即使是命中文档的请求，也必须将 272MB 的 KV 转移到 decode Worker。在服务器之间（1G

  2026-11-13 · 12 分钟阅读 #NVIDIA Dynamo#vLLM#분리 서빙#prefill decode#NIXL

• 安装 Dynamo 运营商前必读：Webhook 范围、两种安装方式、载入清单

  要在 Kubernetes 上部署 Dynamo 1.6.2，必须先安装运营商。通过绘制 Chart 可以发现，默认（全局）方式会创建 12 个 ClusterRole 和 8 个 Webhook，其中一个会拦截集群中所有 Pod 的创建。收窄 Webhook 的参数被 Chart 拒绝了，唯一的出路——命名空间限制方式——单独使用时会漏掉 CRD、转换 Webhook 地址和证书。将运营商和工作负载的命名空间分开后，运营商在约 2 分

  2026-11-13 · 15 分钟阅读 #NVIDIA Dynamo#쿠버네티스 오퍼레이터#승인 웹훅#Helm#폐쇄망

• 在 vLLM 后方部署多台实例时，前缀缓存的命中率究竟如何？

  如果将多个 vLLM Pod 通过一个 Kubernetes Service 绑定在一起，请求会被随机分发到任意一个 Pod。由于前缀缓存是每个 Pod 各自独立维护的，当具有相同前缀的请求被发往不同的 Pod 时，系统就必须从头开始重新计算。在使用 0.6B 模型以及分别测试 6 个和 3 个 Worker 的情况下，我们发现当存在 2 种前缀时，请求的缓存命中率高达 95%~98%；但当增至 7 种时降至 52%~60%，12 种时

  2026-11-13 · 11 分钟阅读 #NVIDIA Dynamo#vLLM#접두 캐시#KV 캐시#쿠버네티스