元鉴 Yuanjian

中文内容

已翻译official company source英文原文2026-06-05

现代 LLM 服务很难调优，因为每一次部署都是一组相互影响的选择所构成的技术栈：模型后端、张量并行形态、prefill/decode 拆分、worker 数量、调度器设置、路由策略、KV cache 行为、自动扩缩容阈值以及拓扑结构。这些选择会跨层相互作用，某个局部改进可能会把瓶颈转移到其他地方。对于更大的模型，即使是一次现实的实验，也可能需要大量 GPU 或节点，之后我们才能知道这个想法是否值得测试。

这正是 DynoSim 的动机：一个 Dynamo twin。

DynoSim 是一种由工作负载驱动的离散事件仿真，用于模拟 NVIDIA Dynamo 服务栈。它在同一条虚拟时间线上结合了实测的引擎前向传播时序、Mocker 调度器核心、Router 和 Planner 行为、KV cache 影响以及工作负载轨迹。目标并不是得到一个纯分析式估计，也不是构建一个逐比特精确的硬件仿真器。目标是在前向传播这一原子级别实现可信的服务仿真，同时扩展到完整的推理栈；对我们而言，这个推理栈是 Dynamo（对许多其他人来说也是如此）。

DynoSim 不仅忠实可靠，作为全栈 Rust 实现，它还快得惊人。在 Apple M4 MacBook Air 上，单线程 Rust 离线回放在 2.41 秒的墙钟时间内，模拟了完整的 23,608 请求 Mooncake 轨迹，配置为八个轮询工作线程以及 512-token 的轨迹块和引擎块。模拟的服务窗口为 60.1 分钟，约比实时快 1,500 倍。

A graph demonstrating the power of DynoSim's simulate-first approach, where thousands of configurations can be screened in simulation before a shortlist is validated on real hardware. — 图 1。DynoSim 将穷举式部署搜索转化为快速的“先模拟后验证”循环，在花费 GPU 时间之前筛选数千个候选方案。

借助 DynoSim，一次扫描可以在现有硬件上为某个工作负载绘制 Pareto 前沿，而 autoresearch 风格的工作流可以为我们的组件提出算法改进：更好的 Router 成本函数、Planner 启发式方法或缓存策略。

架构：将 Dynamo 组合为事件

一个关键的设计选择是组合。DynoSim 不是一个单体模型；它是一组运行在同一模拟时间线上的服务组件。回放工具驱动工作负载到达，单引擎模拟对工作器本地调度和前向传递计时进行建模，多引擎模拟则加入只存在于跨工作器场景中的系统行为：路由、分布式缓存以及 Planner 决策。

An architecture diagram showing DynoSim's components — workload replay, individual engine simulations, Router, Planner, and KVBM — arranged as parallel actors feeding into a single shared discrete-event timeline. — 图 2。DynoSim 在单一离散事件时间线上组合了工作负载回放、引擎模拟、Router、Planner 以及可选的 KVBM 行为。

虚拟时钟上的回放

离散事件模拟（DES）为 DynoSim 提供了一个虚拟时钟和一个事件队列。组件不会按真实时间等待。相反，它们会以建模得到的持续时间来调度未来事件：请求到达、调度器步骤、前向传递、KV 传输、工作器启动或 Planner 操作。运行时会跳转到下一个时间戳，更新系统状态，并让受影响的组件调度更多工作。

一个请求在 twin 中的旅程

负载生成器（例如 Dynamo AIPerf）从跟踪数据或合成工作负载中发出请求。
路由器决定请求应发送到哪里，或者是否应等待。
被选中的引擎调度器将请求批处理到预填充或解码阶段中。
硬件感知的计时，例如由 AI Configurator (AIC) 支持的计时，会估算该次传递的持续时间。
KV 交接、缓存或与卸载相关的事件可能会被调度到同一虚拟时间线上。
解码会生成可见的输出 token。
追踪收集器会记录请求级和系统级指标。

重要的是，每个组件决策都会改变未来事件。路由器决策会影响工作节点的队列，Planner 的扩缩容决策会延迟容量，而 KV 移动决策可能会改变解码开始的时间。

重放框架：驱动数字孪生

重放框架将工作负载生成连接到模拟组件，然后再反馈到指标。对于固定轨迹，可以直接根据轨迹调度到达事件。对于反馈驱动的工作负载，例如多轮或智能体流量，该框架可以等待完成后再发出后续请求。轨迹收集器会从模拟时间线中记录吞吐量、TTFT、TPOT、端到端延迟、前缀缓存复用，以及其他请求级或系统级指标。

单引擎模拟：调度器保真度很重要

单个引擎并不只是一个每秒 token 数的估计。调度器决定哪些请求进入每一轮执行，prefill 和 decode 工作如何批处理，以及 KV 压力如何改变进度。DynoSim 保持其后端特定性：vLLM 路径建模了一个具有共享 token 预算和抢占/重计算机制的等待/运行调度器，而 SGLang 路径建模了感知 radix cache 的准入、分块 prefill 预算以及保留前缀的 decode 回撤。

AIConfigurator（AIC）作为引擎侧计时融入这一图景：给定模型、后端、系统、张量并行形状和执行轮次形状，它会估计 prefill 或 decode 工作应花费多长时间。调度器仿真决定每一轮执行包含什么内容；AIC 则估计所选轮次的持续时间。AIC 提供执行轮次速度信息，而 mocker/replay 调度器则建模围绕该轮次的服务行为。

下图展示了为什么该调度器层很重要。AIC 能够为引擎侧性能提供与真实硅硬件高度一致的保真度，尤其是在吞吐量和 token 时间方面。但 TTFT 对请求在高并发下如何等待、批处理、分块以及进入 prefill 非常敏感。

A dual-panel line chart comparing AIC-only estimates against scheduler-aware replay and real hardware measurements for TTFT and throughput across concurrency levels 8 to 64. Scheduler-aware replay tracks hardware measurements more closely t — 图 3. 感知调度器的 replay 缩小了引擎计时估计与硬件测量之间的差距。测试模型为 NVIDIA HGX B200 上的 MiniMax-M2.5 FP8，TP=4，ISL=1K，OSL=1K，并发数从 8 到 64。

多引擎仿真：从工作器到系统

Dynamo 的能力来自于能够基于活跃系统反馈进行在线决策的组件。Router 需要当前缓存状态和解码负载。Planner 需要流量、工作器状态和 SLA 信号。KVBM 需要传输压力、层级容量以及未来缓存可用性。多引擎仿真使用同一个按时间戳排序的事件队列来建模这些反馈循环。每个组件都会观察当前的模拟状态，并将未来的决策或完成事件调度回该队列。

对于下方具体的 Router 和 KVBM 结果，除非另有说明，我们使用相同的基线重放设置：完整的 23,608 请求 Mooncake FAST25 toolagent trace、NVIDIA HGX B200 上的 MiniMax-M2.5 FP8、来自 AIC 的 vLLM 0.14.0 计时、TP=4，以及离线重放。Router 实验组合了八个聚合工作器；KVBM 实验使用一个工作器，并切换 G2 主机内存层级。

下图比较了轮询路由与 KV Router。G2 卸载被禁用，因此差异来自路由和缓存放置：

A multi-panel chart comparing round-robin and KV-aware routing across concurrency levels, showing prefix cache reuse rate, TTFT, TPOT, and TPS/user. KV-aware routing achieves higher reuse and lower TTFT but shows slightly higher TPOT at pea — 图 4。与在并发扫描中采用轮询放置相比，KV 感知路由将前缀复用率从约 0.38 提高到 0.44–0.45，从而降低 TTFT 并提升吞吐量；不过，如 TPOT 和 TPS/user 所反映的那样，在高并发下，缓存亲和放置可能会增加解码压力。

KVBM 管理服务内存层次结构中的 KV 块：本地 HBM、主机内存、SSD，以及分布式或远程缓存。本地较低层级缓存的行为通常可以建模为时序和资源压力：G1（GPU 内存）、G2（主机内存）、传输带宽、层级容量，以及最终的 G3（磁盘）。分布式缓存是仿真变得更有意思的地方。卸载、载入、远程读取和放置决策会影响路由、调度、排队以及未来的缓存状态，因此需要将它们作为事件登记在与服务测试框架其余部分相同的时间线上。

下面的 KVBM 示例展示了在启用 G2 主机内存层级并将其大小设为 32,768 个块时，mocker 的预测结果：

A Pareto curve plotting mean TTFT against throughput with G2 host-memory tier enabled versus disabled, showing the G2-enabled curve shifted up and to the left. A callout highlights the c=32 point where TTFT improves by 19.3%. — 图 5。启用 KVBM G2 主机内存层级可通过复用原本需要重建的 KV 块来减少预填充重计算，在整个扫描范围内降低 TTFT，并将吞吐量—交互性帕累托曲线向上移动；其中在 c=32 时收益最大，平均 TTFT 改善了 19.3%。

未来，Replay 还可以驱动针对真实分布式缓存目标的 NIXL（NVIDIA Inference tranXfer Library）读写。这些测量结果会校准传输成本、放置行为和竞争情况，然后反馈到分布式缓存模型中。

使用 DynoSim 进行优化和发现

一旦 DynoSim 能够通过组合组件运行工作负载，重放就会成为优化和发现的评分函数：提出一种布局或策略，运行工作负载，收集指标，并将结果与目标或假设进行比较。

通过 Replay 进行系统化优化

如今，优化器会针对部署旋钮使用一种粗糙但实用的块坐标下降方法：选择一种 TP 形状，为该 TP 形状选择一种 worker 拆分，然后选择路由器设置。这种方法之所以有效，是因为当前的搜索空间仍然较小，并且局部足够平滑，使得粗粒度的坐标搜索能够找到有用的候选项。随着搜索空间扩大，同一套回放评分循环可以连接到更丰富的黑盒优化器，例如 Hyperopt 风格的贝叶斯搜索、遗传算法或 Vizier。

更有意思的是，回放循环并不限于结构化旋钮。按照 Karpathy 的 autoresearch 风格，一个智能体式框架可以提出一项非平凡的代码变更，重新构建 Dynamo，重新运行同一条 trace，并且只保留那些能改进目标的变更。这会把回放转变为一个有界的研究循环，用于探索路由器成本函数、Planner 启发式方法以及那些难以表示为小型参数网格的缓存策略。

发现示例：超越当前优化器

同一个仿真循环不仅可以用于配置搜索，也可以用于研究。有些实验会调优已暴露的参数。另一些实验则会改变算法本身。

这里我们将深入发现示例聚焦于 Planner。自动扩缩容适合 DynoSim 有两个原因。首先，其有趣的行为是宏观层面的：它源于数分钟的流量、延迟的 worker 启动、容量波动，以及扩缩容决策、队列和路由之间的反馈——这些都不是小型单元测试能够真实检验的。其次，以另一种方式评估它——在完整的 Kubernetes 环境中——每次策略变更的成本都很高，无论是 GPU 小时还是工程师时间。DynoSim 让我们能够在搭建完整环境之前积极扫描这些影响：比较静态与动态设置，调优 Planner 参数，并量化 worker 启动时间的重要性，从而在决定更快启动、预测性扩缩容或预热容量是否值得工程投入之前获得依据。

下面三个实验复用了上文介绍的 Mooncake FAST25 toolagent trace，但将模拟的引擎配置切换为 H200-SXM 上 TP=2 的 Qwen3-32B。

实验 1 设置权衡：我们比较静态部署与使用 Planner 的动态部署，其中使用聚合引擎。我们扫描静态副本数（无 Planner；具有不同数量引擎副本的固定部署），并叠加一次 Planner 运行，将 SLA 设置为 TTFT=1500 ms 和 ITL=50 ms。

A scatter plot of GPU-hours versus p90 latency (TTFT and ITL), with points for each static replica count and a single point for the SLA-targeted Planner. The Planner point sits in the lower-left corner, achieving lower latency at lower cost — 图 6。以 SLA 为目标的 Planner 找到了比静态部署更优的成本-延迟运行点。

采用规划器的动态部署达到了更优的成本-延迟平衡点：其 p90 TTFT 和 ITL 远低于任何静态部署，同时使用的 GPU 小时数更少。

实验 2 扩缩容间隔：我们将扩缩容间隔从 1 秒扫描到 300 秒，并将引擎启动设置为即时，以观察快速响应流量变化与过于频繁扩缩容之间的权衡。

A dual-axis line chart sweeping scaling interval from 1 to 300 seconds, showing p90 TTFT remaining flat between 1–10 seconds then rising steeply, while scaling event count drops sharply from ~1,500 at 1 second to ~230 at 10 seconds, with a — 图 7。负载调整在约 5-10 秒时效果最佳，兼顾响应速度和扩缩容抖动。

从 1-10 秒的间隔内，P90 TTFT 基本保持不变，但扩缩容事件从 1,529 次大幅下降到 233 次。约 30 秒之后，Planner 对突发流量的反应过慢。GPU 小时数在整个扫描范围内大致保持稳定，因此非常短的间隔不会消耗更多 GPU 时间，但会导致不必要的扩缩容抖动。最佳范围约为 5-10 秒。

实验 3 冷启动时间：在真实集群中，增加容量需要时间，因为新的引擎 pod 需要数秒到数分钟才能开始处理流量。在仿真中，我们对该延迟进行建模，并衡量 Planner 对其的处理效果。

A line chart of p90 TTFT against cold-start delay in seconds, showing a flat region below ~180 seconds followed by a sharp cliff, reaching 242 seconds of p90 TTFT at 300-second startup delay. — 图 8。启动延迟会在新容量到达过晚、无法吸收突发流量时导致 SLA 断崖式下降。

对于 TP=2 的 Qwen3-32B，Planner 在启动延迟达到约 180 秒之前都能满足 SLA。到约 200 秒时，性能急剧下降；到 300 秒时，系统被困在流量突发之后，p90 TTFT 达到 242 秒。这表明，用户应将冷启动时间优化到 200 秒以下，以获得最佳性能。

这三个实验说明了如何以低成本探索设计空间。

将仿真作为内循环

目标并不是取代真实集群验证。目标是让该验证更加聚焦。

Figure 9. DynoSim makes simulation the inner loop for deployment tuning: sweep broadly, shortlist Pareto candidates, verify on the cluster, then calibrate from telemetry. — 图 9. DynoSim 将仿真作为部署调优的内循环：广泛扫描，筛选 Pareto 候选方案，在集群上验证，然后基于遥测数据进行校准。

仿真成为设计探索的内循环。真实集群仍然是用于验证的外循环。在这两个循环之间，Dynamo 可以将服务算法作为一个系统来测试：调度器行为、路由策略、Planner 控制、KV/缓存移动、工作负载形态，以及测得的引擎时序。

展望未来，我们还计划在生产环境中闭合这一循环。一个构建在 DynoSim 之上的智能扫掠算法将定期针对最近记录的生产流量运行，在当前工作负载分布下搜索配置空间，并在发现显著更优的部署时推荐（或直接应用）重新配置。由于流量形态会在数小时和数天内发生漂移——不同的提示词组合、ISL/OSL 分布或突发模式——上周合适的 TP 形态、prefill/decode 拆分、路由器策略和 Planner 设置，今天可能已不再是最优。由 DynoSim 驱动的持续扫掠可使在线部署持续跟踪当前最优状态，而不是依赖一次性的上线决策。

Mocker 轨迹重放
Profiler 指南
Router 指南
规划器指南
KVBM 指南

DynoSim：模拟帕累托前沿