NVIDIA Dynamo

第二批 PR 改变了归属关系的表示方式，这才是底层更难的问题。每个缓存 block 都需要归属到依赖它的请求上，才能做到"仍在使用时不释放、所有人用完后不再钉住"。当成千上万个并发会话共享彼此重叠的 prefix 时，这套记账本身的开销就变得可观。

Dynamo 从共享 block 链，转向 arena 级别的归属计数，最终采用按后端划分的 request lease，每一步都把被跟踪的单位变粗。lease 设计让 vLLM 后端的 AgentX 回放耗时降低 23.71%、SGLang 降低 22.02%，同时降低了峰值内存——这说明问题出在此前的表示方式上，而不是流量本身。

后续的 router profiling 又消除了一批形态相同的开销：某个周期性扫描或全量重算之所以此前可以接受，只是因为活跃状态一直很小。分桶式过期清理取代了正比于全部被跟踪对象的扫描，让高churn 的 AgentX 吞吐量提升 13.7%。仅处理增量的后缀清理只处理发生变化的部分，在同一时间窗口内多吸收约 28 倍的写入与删除事件。压缩 prompt 路径把前端 CPU 占用降低 35.3%，并显著改善尾部首 token 时间——这很重要，因为该负载的 prompt 既长又高度重复。过载状态现在也改为增量跟踪而非重新计算。

有一项路由改动是有意的取舍，而非纯粹的收益：Dynamo 现在可以把进行中的 decode 请求计入路由评分，于是一个已经承担长时间 decode 的 worker，会显得比其队列深度所暗示的更"贵"。在其报告的调参点上，这改善了 AgentX 延迟中位数，代价是少量吞吐量——只有当请求会长时间占用 worker 时，这种权衡才会显现出来。

接下来优化的是请求平面，因为智能体 trace 并不是"一个请求、一个响应"。它会发出大量内容高度雷同的相关请求，并把每个 token 作为独立帧流式返回，因此序列化与拷贝是按轮次、按 token 付出的，而不是只付一次。改用 MessagePack 请求负载在其 AgentX 测试中把吞吐量提高 8.1%、平均首 token 时间降低 9.7%；直接的 Python 转码则彻底去掉了该路径上的中间值树。

随后是一系列"去掉一次拷贝"而非"把某步做快"的改动：不再拷贝 MessagePack 事件负载、不再拷贝收到的 ZeroMQ 帧、不再为每个 token 承担完整的 token 间延迟指标开销；chat 流式热路径也因同样理由被缩短。单看这些都平淡无奇，但乘上每个并发会话的每个流式 token，它们决定了前端每秒能承载多少请求。

高并发 profiling 随后发现了一批与搬运数据毫无关系的开销。静态日志过滤器移除了一处共享的 span matcher 锁——这是竞争点问题而非流量问题——使报告中的前端吞吐量从每秒 932 个请求提升到 1,133 个。更简单的位置式 radix 分桶在 32 worker 的运行中把 mocker 的峰值内存降低了 5.51 GiB。

还有一个仍为 open 的改动，把 detokenization 指标改为每个响应汇总一次，而不是在每个流式分块上更新累计计数器，在其对照诊断 profile 中把前端 CPU 时间大约减半。这是该类问题最清楚的例子：单次调用的埋点很便宜，但按每个 token 调用一次就变得难以承受。