🔹智能体工作负载正使 KV 缓存成为一个真正的存储问题。 🔹这种流量模式相当特殊。英伟达 Dynamo 团队展示的一次包含 42 次调用的 Claude Cod
- 序号：122
- 星球链接：打开网页
- 附件：图片 0，音频 0，文档 0
- 音频文件：无音频
图片
无图片
正文
🔹智能体工作负载正使 KV 缓存成为一个真正的存储问题。 🔹这种流量模式相当特殊。英伟达 Dynamo 团队展示的一次包含 42 次调用的 Claude Code 会话中，缓存 token 读取量为 891 千，写入量仅为 76 千，读写比为 11.7 倍。 英伟达 CMX 是专为此类 KV 流量构建的 pod 级、通过 Ethernet 连接的闪存层；Dynamo 的 KVBM 则可将 KV 分层存放在 GPU 内存、CPU 内存、磁盘和对象存储中。 🔹这之所以重要，原因很简单：多轮智能体会生成大量可复用状态，系统必须决定轮次之间将这些状态存放在哪里。全部放在靠近 GPU 的位置，成本会迅速攀升；将过多状态移到更远处，又会带来检索问题。 🔹将每段对话的 KV 缓存都保存在 HBM 中，会限制并发量， 每一轮都重新计算完整对话历史，会把 GPU 周期浪费在已经完成的工作上。随着智能体会话变得更长、更持久，服务效率取决于能否保留有用的 KV，并以足够快的速度将其移回 GPU，避免停顿。 🔹这带来了一组新的基础设施决策。系统现在需要决定哪些 KV 块保留在 HBM 中、哪些移入 CPU 内存或闪存，以及能否足够快地取回较旧的 KV 以避免增加延迟，等等。 🔹数据路径在这里变得非常重要，因为 KV 缓存可能让网络拓扑成为服务瓶颈。一旦上下文溢出 GPU 内存，性能就取决于状态从哪里加载、通过哪些链路传输，以及这些链路能否持续向 GPU 提供数据而不造成停顿。带宽配置位置开始与带宽总量同样重要：即使一个集群拥有充足的网络总容量，若 KV 流量集中在错误路径上，表现仍可能不佳。
总体总结
主题正文
- 英伟达 Dynamo 团队展示的一次包含 42 次调用的 Claude Code 会话中，缓存 token 读取量为 891 千，写入量仅为 76 千，读写比为 11.7 倍。
- Dynamo 的 KVBM 则可将 KV 分层存放在 GPU 内存、CPU 内存、磁盘和对象存储中。
- 🔹这之所以重要，原因很简单：多轮智能体会生成大量可复用状态，系统必须决定轮次之间将这些状态存放在哪里。
- 🔹将每段对话的 KV 缓存都保存在 HBM 中，会限制并发量， 每一轮都重新计算完整对话历史，会把 GPU 周期浪费在已经完成的工作上。
- 随着智能体会话变得更长、更持久，服务效率取决于能否保留有用的 KV，并以足够快的速度将其移回 GPU，避免停顿。
- 系统现在需要决定哪些 KV 块保留在 HBM 中、哪些移入 CPU 内存或闪存，以及能否足够快地取回较旧的 KV 以避免增加延迟，等等。
- 一旦上下文溢出 GPU 内存，性能就取决于状态从哪里加载、通过哪些链路传输，以及这些链路能否持续向 GPU 提供数据而不造成停顿。
- 带宽配置位置开始与带宽总量同样重要：即使一个集群拥有充足的网络总容量，若 KV 流量集中在错误路径上，表现仍可能不佳。