DynoSim：パレートフロンティアのシミュレーション
NVIDIA は、LLM サービング設定の複雑な最適化を可能にする高速離散イベントシミュレータ「DynoSim」を発表し、実機テスト前に数千通りの構成を瞬時に評価する手法を確立した。
キーポイント
LLM サービング設定の複雑性への対応
モデルバックエンドからスケジューリング、KV キャッシュ動作まで多層的なパラメータが相互干渉するため、従来の実機実験ではボトルネックの特定や最適化に多大なリソースと時間がかかる課題を指摘。
NVIDIA Dynamo の忠実なシミュレータ「DynoSim」
エンジン順次処理タイミング、ワークロードトレース、スケジューラ・ルータの振る舞いを統合した仮想タイムライン上で動作する、原子レベルで忠実かつ高速な離散イベントシミュレーションツール。
驚異的なシミュレーション速度の実現
Rust による実装により、Apple M4 MacBook Air 上で 23,608 リクエストのトレースを 2.41 秒で完了させ、実際の 60 分間のインフェレンス時間を約 1,500 倍の速度で再現可能。
シミュレーションファーストによる最適化アプローチ
数千通りの構成をシミュレーションでスクリーニングし、有望な候補のみを実機で検証する「Pareto Frontier（パレートフロンティア）」探索手法を提案。
シミュレーション先行アプローチ
DynoSim は、数千もの設定候補をまずシミュレーション上でスクリーニングし、その後で実機検証を行う「シミュレートして検証する」ループを採用しています。
GPU 時間の最適化
この手法により、膨大な探索空間から有望な候補を絞り込むことで、高価な GPU リソースを実機テストに集中させることが可能になります。
Pareto フロンティアのシミュレーションとアルゴリズム改善
DynoSim を用いて既存ハードウェア上のワークロードに対する Pareto フロンティアをマッピングできるほか、自動研究スタイルのワークフローでルーターのコスト関数やキャッシュポリシーなどのアルゴリズム変更を提案可能である。
影響分析・編集コメントを表示
影響分析
この発表は、LLM の本番環境導入におけるチューニングコストとリスクを劇的に低減する可能性を秘めています。特に大規模モデルや複雑なアーキテクチャ構成において、実機テスト前の広範なパラメータ空間探索を可能にすることで、開発サイクルの短縮とリソース効率の向上に直結します。業界全体として、シミュレーション駆動設計がインフラ最適化の標準的なプラクティスへと進化することを示唆しています。
編集コメント
LLM の本番環境設定は、パラメータの組み合わせが指数関数的に増大する難問ですが、このシミュレータ技術はその解決策として極めて有望です。実機テスト前に仮想空間で最適解を絞り込む手法は、今後 AI インフラ設計のデファクトスタンダードになるでしょう。
現代の LLM サービングは調整が困難です。なぜなら、各デプロイメントはモデルバックエンド、テンソル並列形状、プリフェッチ/デコード分割、ワーカー数、スケジューラー設定、ルーティングポリシー、KV キャッシュ動作、自動スケーリング閾値、トポロジーなど、相互作用する選択のスタックだからです。これらの選択は層を超えて相互に影響し合い、ある部分での局所的な改善がボトルネックを別の場所にシフトさせる可能性があります。大規模モデルの場合、アイデアがテストに値するかどうかを知る前に、1 つの実用的な実験でも多くの GPU やノードが必要になることがあります。
それが DynoSim の動機です：Dynamo の双子です。
DynoSim は、NVIDIA Dynamo サービングスタックのワークロード駆動型離散イベントシミュレーションです。計測されたエンジン順方向パスのタイミング、モッカースケジューラーコア、Router（ルーター）、Planner（プランナー）の動作、KV キャッシュの影響、およびワークロードトレースを 1 つの仮想タイムライン上で統合します。目的は純粋な解析的推定でも、ビット単位で正確なハードウェアエミュレータでもありません。目的は、順方向パスという原子レベルでの忠実なサービングシミュレーションを実現し、それを Dynamo（および多くの他の人々にとっても）であるような完全な推論スタックまで拡張することです。
DynoSim は忠実であるだけでなく、フルスタックの Rust 実装として驚異的な速度を誇ります。Apple M4 MacBook Air において、シングルスレッドの Rust オフラインリプレイは、8 つのラウンドロビンワーカーと 512 トークンのトレースおよびエンジンブロックを持つ完全な 23,608 リクエストの Mooncake トレースを、壁時計で 2.41 秒でシミュレーションしました。シミュレートされたサービングウィンドウは 60.1 分であり、実時間と比較して約 1,500 倍高速です。
image*図 1. DynoSim は、膨大なデプロイメント検索を「シミュレーションして検証する」高速なループに変換し、GPU 時間を費やす前に数千の候補をスクリーニングします*
DynoSim を用いれば、既存ハードウェア上のワークロードに対するパレートフロンティア（Pareto frontier）をマッピングするスウィープが可能となり、また自己研究（autoresearch）スタイルのワークフローによって、コンポーネントへのアルゴリズム変更（より優れた Router コスト関数、Planner ヒューリスティック、またはキャッシュポリシーなど）を提案することもできます。
アーキテクチャ：イベントとしての Dynamo の合成
重要な設計上の選択は「合成」です。DynoSim は単一のモノリシックモデルではなく、同じシミュレーションタイムライン上で動作する一連のサービングコンポーネントで構成されています。リプレイハネスがワークロードの到着を駆動し、シングルエンジンシミュレーションがワーカーローカルのスケジューリングとフォワードパスのタイミングをモデル化し、マルチエンジンシミュレーションはワーカー間でのみ存在するシステム動作（ルーティング、分散キャッシュ、Planner による意思決定）を追加します。
image*図 2. DynoSim は、ワークロード再生、エンジンシミュレーション、Router（ルーター）、Planner（プランナー）、およびオプションの KVBM 動作を単一の離散イベントタイムライン上で構成します。*
バーチャルクロック上での再生
離散イベントシミュレーション（Discrete-event simulation: DES）は、DynoSim にバーチャルクロックとイベントキューを提供します。コンポーネントは実時間では待機しません。代わりに、モデル化された継続時間を伴う将来のイベントをスケジュールします：リクエストの到着、スケジューラのステップ、フォワードパス、KV（Key-Value）転送、ワーカーの起動、あるいは Planner のアクションなどです。ランタイムは次のタイムスタンプへジャンプし、システム状態を更新して、影響を受けるコンポーネントにさらなる作業をスケジュールさせます。
ツイン内を通過するリクエストの旅路
- Dynamo AIPerf などのロードジェネレーターが、トレーサまたは合成ワークロードからリクエストを発行します。
- Router（ルーター）は、リクエストがどこへ向かうべきか、あるいは待機すべきかを決定します。
- 選択されたエンジンスケジューラは、リクエストをプリフェッチパスまたはデコードパスにバッチ処理します。
- AI Configurator (AIC) に基づくタイミングなどのハードウェアインフォームドなタイミングが、そのパスの継続時間を推定します。
- KV のハンドオフ、キャッシュ、あるいはオフロードに関連するイベントも、同じバーチャルタイムライン上にスケジュールされる可能性があります。
- デコードにより、可視化された出力トークンが生成されます。
- トレースコレクターは、リクエストレベルおよびシステムレベルのメトリクスを記録します。
重要な点は、各コンポーネントの意思決定が将来の事象を変化させることです。ルーターの意思決定はワーカーのキューに影響し、Planner のスケーリング意思決定はキャパシティの遅延を引き起こし、KV 移動の意思決定はデコード開始のタイミングを変更します。
Replay harness: Driving the twin
Replay ハーネスは、ワークロード生成をシミュレートされたコンポーネントに接続し、そこからメトリクスへと戻します。固定トレースの場合、到着はトレースから直接スケジューリングできます。マルチターンやエージェント型トラフィックなどのフィードバック駆動型ワークロードの場合、ハーネスは完了を待ってからフォローアップリクエストを発行できます。トレースコレクターは、シミュレーションされたタイムラインからのスループット、TTFT（Time To First Token）、TPOT（Time Per Output Token）、エンドツーエンドレイテンシ、プレフィックスキャッシュの再利用率、およびその他のリクエストレベルまたはシステムレベルのメトリクスを記録します。
Single engine simulation: Scheduler fidelity matters
単一エンジンシミュレーションは、単なる秒間あたりのトークン数の推計ではありません。スケジューラーは、どのリクエストが各パスに入るか、プリフェッチとデコード作業がどのようにバッチ処理されるか、そして KV（Key-Value）圧力が進行にどう影響するかを決定します。DynoSim はこのバックエンド固有の挙動を維持します：vLLM パスは、共有トークン予算を持つ待機/実行中のスケジューラーとプリエンプション/再計算をモデル化し、SGLang パスは radix-cache 対応のアドミッション、チャンク化されたプリフェッチ予算、およびプレフィックス保存型のデコード撤回をモデル化します。
AIConfigurator (AIC) は、この図景においてエンジン側のタイミング推定として機能します。モデル、バックエンド、システム、テンソル並列形状、およびパス形状が与えられた場合、プリフェッチまたはデコード作業に要する時間を AIC が見積もります。スケジューラシミュレーションは各パスに含まれる内容を決定し、AIC はその選択されたパスの所要時間を推定します。AIC はパス速度を通知し、一方、モッカー/リプレイスケジューラはパス周辺のサービス動作をモデル化します。
以下の図は、なぜこのスケジューラ層が重要であるかを示しています。AIC はスループットやトークン時間といったエンジン側の性能について、実機シリコンに対して高い忠実度を提供しますが、TTFT（Time To First Token）は、高同時実行下でのリクエストの待ち方、バッチ処理、チャンク化、およびプリフェッチへの流入方法に敏感です。
image*図 3. スケジューラ認識型リプレイは、エンジンタイミング推定とハードウェア測定値との間のギャップを埋めます。テストに使用されたモデルは 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 トレース、NVIDIA HGX B200 上の MiniMax-M2.5 FP8、AIC からの vLLM 0.14.0 のタイミング測定、TP=4、およびオフラインリプレイです。Router 実験では 8 つの集約されたワーカーを構成し、KVBM 実験では 1 つのワーカーを使用し、G2 ホストメモリティアを切り替えます。
以下の図は、ラウンドロビンルーティングと KV Router を比較しています。G2 オフロードは無効化されているため、違いはルーティングとキャッシュ配置に起因します：
image*図 4. KV 認識型ルーティングは、並行処理スウィープ全体を通じてラウンドロビン配置と比較して TTFT（Time To First Token）を削減しスループットを向上させる一方、キャッシュアファイン配置では高並行時に TPOT（Token Per Output Time）やユーザーあたりの TPS（Tokens Per Second）に反映されるようにデコード負荷が増加する可能性があります。これはプレフィックスの再利用率を約 0.38 から 0.44-0.45 に改善します。*
KVBM は、ローカル HBM、ホストメモリ、SSD、および分散またはリモートキャッシュを含むサービングメモリアーキテクチャ全体にわたって KV ブロックを管理します。ローカル下位階層キャッシュの動作は、タイミングとリソース負荷としてモデル化されることが多く、具体的には G1（GPU メモリ）、G2（ホストメモリ）、転送帯域幅、階層容量、そして最終的に G3（ディスク）が該当します。分散キャッシュではシミュレーションがより興味深いものになります。オフロード、オンボード、リモート読み取り、および配置の決定は、ルーティング、スケジューリング、キューイング、および将来のキャッシュ状態に影響を与えるため、サービングハッチ全体の残りの部分と同じタイムライン上でイベントとして登録する必要があります。
以下の KVBM の例では、G2 ホストメモリ階層が有効化され、32,768 ブロックにサイズ設定された場合にモッカーが予測する結果を示しています：
image*図 5. KVBM の G2 ホストメモリ階層を有効化することで、本来再構築されるはずの KV ブロックを再利用しプレフィルの再計算を削減します。これによりスウィープ全体で TTFT が低下し、スループットと対話性のパレート曲線が上方へシフトします。最大の効果は c=32 で、平均 TTFT が 19.3% 改善されます。*
将来、Replay は NIXL (NVIDIA Inference tranXfer Library) に対する読み書きを、実際の分散キャッシュターゲットに対して実行することも可能になります。これらの測定値は転送コスト、配置動作、競合状態を較正し、その後分散キャッシュモデルにフィードバックされます。
DynoSim を用いた最適化と発見
DynoSim が構成されたコンポーネントを通じてワークロードを実行できるようになれば、Replay は最適化と発見の両方に対するスコアリング関数として機能します。レイアウトまたはポリシーを提案し、ワークロードを実行してメトリクスを収集し、その結果を目的や仮説と比較するのです。
Replay を通じた体系的な最適化
現在のオプティマイザは、デプロイメントの調整項目に対して粗雑だが実用的なブロック座標降下法を使用しています。具体的には、TP（Tensor Parallelism）の形状を選択し、その TP 形状に対するワーカー分割を選択し、その後ルーター設定を選択します。これは現在探索空間がまだ小さく、粗い座標探索でも有用な候補を見つけられるほど局所的に滑らかであるため機能しています。探索空間が大きくなるにつれて、同じ Replay スコアリングループを、Hyperopt 型のベイズ検索や遺伝的アルゴリズム、Vizier のようなより高度なブラックボックスオプティマイザに接続することが可能になります。
さらに興味深いことに、リプレイループは構造化されたノブに限定されません。Karpathy の自己研究のスタイルに従い、エージェント型ハーンが非自明なコード変更を提案し、Dynamo を再構築し、同じトレースを再実行し、目的関数を改善する変更のみを保持することができます。これにより、リプレイは、小さなパラメータグリッドとして表現するのが awkward なルーターコスト関数、Planner ヒューリスティック、キャッシュポリシーに対する有界な研究ループへと変換されます。
発見の例：現在の最適化器を超えて
同じシミュレーションループは、構成検索だけでなく研究にも使用できます。いくつかの実験では露出されたパラメータを調整し、他の実験ではアルゴリズム自体を変更します。
ここでは、Planner に焦点を当てた詳細な発見の例を取り上げます。Autoscaling が DynoSim に適合する理由は 2 つあります。第一に、興味深い振る舞いは*マクロ*レベルで生じます。これは数分間のトラフィック、遅延するワーカー起動、キャパシティの入れ替わり、スケール決定とキューおよびルーティングとのフィードバックから現れるものであり、これらを小さな単体テストが忠実に実行できるものではありません。第二に、これを逆方向、つまり完全な Kubernetes 環境で評価することは、ポリシー変更ごとに GPU 時間とエンジニアの時間の両面で高コストとなります。DynoSim を用いれば、完全な環境を構築する前にこれらの影響を積極的にスweep できます：静的設定と動的設定の比較、Planner パラメータの調整、そしてより高速な起動、予測的スケールリング、またはプリウォームされたキャパシティがエンジニアリングコストに見合うかどうかを決定する前に、ワーカー起動時間がどれほど重要かを定量化することができます。
以下の 3 つの実験では、前述の Mooncake FAST25 toolagent trace を再利用しつつ、シミュレーションエンジンプロファイルを H200-SXM 上で TP=2 の Qwen3-32B に切り替えます。
実験 1: セットアップのトレードオフ: 静的デプロイと、集約されたエンジンを用いたプランナー付きの動的デプロイを比較します。静的なレプリカ数（プランナーなし；異なる数のエンジンレプリカを持つ固定デプロイ）をスweep し、SLA を TTFT=1500 ms、ITL=50 ms に設定したプランナー実行 1 つを重ねて表示します。
image*図 6. SLA ターゲット型プランナーは、静的デプロイよりも優れたコストとレイテンシの運用点を見つけます。
プランナー付きの動的デプロイは、はるかに優れたコスト・レイテンシ点を達成します。その p90 TTFT と ITL はどの静的デプロイよりも大幅に低く、かつ同時に使用される GPU 時間も少なくて済みます。
実験 2: スケーリング間隔: エンジンの起動を瞬時に行う設定で、スケーリング間隔を 1 秒から 300 秒までスweep し、トラフィック変化への迅速な対応と頻繁すぎるスケーリングの間のトレードオフを確認します。
image*図 7. 負荷調整は、応答性とスケーリングによる振動（churn）のバランスにおいて、おおよそ 5〜10 秒付近で最も効果的です。
P90 TTFT は 1〜10 秒の間隔でもほぼ一定ですが、スケーリングイベントは 1,529 から 233 に急激に減少します。約 30 秒を超えると、Planner がバーストに対して反応し遅くなります。GPU 使用時間はスウィープ全体で概ね安定しているため、非常に短い間隔でも GPU 時間のコストが大幅に増えるわけではありませんが、不要なスケーリングの振動を引き起こします。最適な範囲は約 5〜10 秒です。
実験 3: コールドスタート時間: 実際のクラスターでは、容量を追加するには時間がかかり、新しいエンジンポッドがトラフィックを処理できるようになるまでに数秒から数分かかります。シミュレーションではこの遅延をモデル化し、Planner がそれをどのように扱えるかを測定します。
image*Figure 8. Startup delay produces an SLA cliff once new capacity arrives too late to absorb bursts.*
TP=2 の Qwen3-32B において、Planner はコールドスタート時間が約 180 秒に達するまで SLA を満たしますが、約 200 秒になるとパフォーマンスが急激に低下し、300 秒にはシステムがトラフィックバーストの後れを取り戻せず、p90 TTFT が 242 秒に達します。これは、最適なパフォーマンスを得るためにはコールドスタート時間を 200 秒未満に最適化する必要があることを示唆しています。
これら 3 つの実験は、設計空間を低コストで探索できる方法を説明するものです。
シミュレーションを内部ループとして
目的は、実際のクラスターでの検証を置き換えることではありません。その検証をより焦点を絞って行うことです。
Figure 9. DynoSim makes simulation the inner loop for deployment tuning: sweep broadly, shortlist Pareto candidates, verify on the cluster, then calibrate from telemetry.
原文を表示
Modern LLM serving is hard to tune because each deployment is a stack of interacting choices: model backend, tensor-parallel shape, prefill/decode split, worker counts, scheduler settings, routing policy, KV cache behavior, autoscaling thresholds, and topology. Those choices interact across layers, and a local improvement can shift the bottleneck somewhere else. For larger models, even one realistic experiment can require many GPUs or nodes before we learn whether the idea was worth testing.
That is the motivation for DynoSim: a Dynamo twin.
DynoSim is a workload-driven discrete-event simulation of the NVIDIA Dynamo serving stack. It combines measured engine forward-pass timing, Mocker scheduler cores, Router, and Planner behavior, KV cache effects and workload traces on one virtual timeline. The goal is not a purely analytical estimate and not a bit-exact hardware emulator. The goal is a faithful serving simulation at the atomic level of forward passes, while extending up to the full inference stack, which for us is Dynamo (and for many others as well).
Not only is DynoSim faithful, it is also blazingly fast as a full-stack Rust implementation. On an Apple M4 MacBook Air, the single-threaded Rust offline replay simulated the full 23,608-request Mooncake trace with eight round-robin workers and 512-token trace and engine blocks in 2.41 seconds of wall time. The simulated serving window was 60.1 minutes, about 1,500x faster than real time.
With DynoSim a sweep can map the Pareto frontier for a workload on existing hardware, while an autoresearch-style workflow can propose algorithmic changes to our components: a better Router cost function, Planner heuristic, or cache policy.
Architecture: Composing Dynamo as events
A key design choice is composition. DynoSim is not one monolithic model; it is a set of serving components that run on the same simulated timeline. A replay harness drives workload arrivals, single-engine simulations model worker-local scheduling and forward-pass timing, and multi-engine simulations add the system behaviors that only exist across workers: routing, distributed caching, and Planner decisions.
Replay on a virtual clock
Discrete-event simulation, or DES, gives DynoSim a virtual clock and an event queue. Components do not wait in real time. Instead, they schedule future events with modeled durations: a request arrival, a scheduler step, a forward pass, a KV transfer, a worker startup, or a Planner action. The runtime jumps to the next timestamp, updates system state, and lets the affected components schedule more work.
A request’s journey through the twin
- A load generator, such as Dynamo AIPerf, emits a request from a trace or synthetic workload.
- The router decides where the request should go, or whether it should wait.
- The selected engine scheduler batches the request into a prefill or decode pass.
- Hardware-informed timing, such as timing backed by AI Configurator (AIC), estimates the duration of that pass.
- KV handoff, cache, or offload-related events may be scheduled on the same virtual timeline.
- Decode produces visible output tokens.
- The trace collector records request-level and system-level metrics.
The important part is that every component decision changes future events. A router decision affects the worker’s queue, a Planner scaling decision delays capacity, and a KV movement decision can change when decode begins.
Replay harness: Driving the twin
The replay harness connects workload generation to the simulated components and then back to metrics. For fixed traces, arrivals can be scheduled directly from the trace. For feedback-driven workloads, such as multi-turn or agentic traffic, the harness can wait for completions before issuing follow-up requests. The trace collector records throughput, TTFT, TPOT, end-to-end latency, prefix cache reuse, and other request-level or system-level metrics from the simulated timeline.
Single engine simulation: Scheduler fidelity matters
A single engine is not just a tokens-per-second estimate. The scheduler decides which requests enter each pass, how prefill and decode work are batched, and how KV pressure changes progress. DynoSim keeps that backend-specific: the vLLM path models a waiting/running scheduler with shared token budget and preemption/recompute, while the SGLang path models radix-cache-aware admission, chunked-prefill budgets, and prefix-preserving decode retraction.
AIConfigurator (AIC) fits into this picture as engine-side timing: given the model, backend, system, tensor-parallel shape, and pass shape, it estimates how long prefill or decode work should take. The scheduler simulation decides what each pass contains; AIC estimates the duration of that chosen pass. AIC informs pass speed, while the mocker/replay scheduler models the serving behavior around the pass.
The figure below shows why that scheduler layer matters. AIC gives strong fidelity to real silicon for engine-side performance, especially for throughput and token time. But TTFT is sensitive to how requests wait, batch, chunk, and enter prefill under high concurrency.
Multi engine simulation: From workers to systems
The power of Dynamo comes from components that make online decisions from active system feedback. A Router needs the current cache state and decode load. The Planner needs traffic, worker state, and SLA signals. KVBM needs transfer pressure, tier capacity, and future cache availability. Multi-engine simulation models those feedback loops with the same timestamp-ordered event queue. Each component observes the current simulated state and schedules future decisions or completions back into that queue.
For the concrete Router and KVBM results below, we use the same baseline replay setup unless noted otherwise: the full 23,608-request Mooncake FAST25 toolagent trace, MiniMax-M2.5 FP8 on NVIDIA HGX B200, vLLM 0.14.0 timing from AIC, TP=4, and offline replay. The Router experiment composes eight aggregated workers; the KVBM experiment uses one worker and toggles the G2 host-memory tier.
The figure below compares round-robin routing with the KV Router. G2 offload is disabled, so the difference comes from routing and cache placement:
KVBM manages KV blocks across the serving memory hierarchy: local HBM, host memory, SSD, and distributed or remote cache. Local lower-tier cache behavior can often be modeled as timing and resource pressure: G1 (GPU memory), G2 (host memory), transfer bandwidth, tier capacity, and eventually G3 (disk). Distributed cache is where the simulation becomes more interesting. Offload, onboard, remote read, and placement decisions affect routing, scheduling, queueing, and future cache state, so they need to be registered as events on the same timeline as the rest of the serving harness.
The KVBM example below shows what the mocker predicts when the G2 host-memory tier is enabled and sized at 32,768 blocks:
In the future, Replay can also drive NIXL (NVIDIA Inference tranXfer Library) reads and writes against a real distributed cache target. Those measurements calibrate transfer cost, placement behavior, and contention, then feed back into the distributed cache model.
Optimization and discovery with DynoSim
Once DynoSim can run a workload through composed components, replay becomes a scoring function for both optimization and discovery: propose a layout or policy, run the workload, collect metrics, and compare the result against the objective or hypothesis.
Systematic optimization via Replay
The optimizer today uses a crude but practical block-coordinate descent over the deployment knobs: choose a TP shape, choose a worker split for that TP shape, then choose the router setting. That works because the current search space is still small and locally smooth enough for coarse coordinate search to find useful candidates. As the search space grows, the same replay scoring loop can be connected to richer black-box optimizers such as Hyperopt-style Bayesian search, genetic algorithms, or Vizier.
More interestingly, the replay loop is not limited to structured knobs. In the style of Karpathy’s autoresearch, an agentic harness can propose a nontrivial code change, rebuild Dynamo, rerun the same trace, and keep only changes that improve the objective. That turns replay into a bounded research loop for router cost functions, Planner heuristics, and cache policies that are awkward to express as a small parameter grid.
Discovery examples Beyond the current optimizer
The same simulation loop can be used for research, not just configuration search. Some experiments tune exposed parameters. Others change the algorithm itself.
Here we focus the in-depth discovery example on the Planner. Autoscaling fits DynoSim for two reasons. First, the interesting behavior is *macro*: it emerges from minutes of traffic, delayed worker startup, capacity churn, and feedback between scale decisions, queues, and routing — none of which a small unit test can exercise faithfully. Second, evaluating it the other way — in a full Kubernetes setup — is expensive per policy change, both in GPU-hours and in engineer time. DynoSim lets us aggressively sweep those effects before standing up the full environment: compare static vs dynamic setups, tune Planner parameters, and quantify how much worker startup time matters before deciding whether faster startup, predictive scaling, or pre-warmed capacity is worth the engineering.
The three experiments below reuse the Mooncake FAST25 toolagent trace introduced above, but switch the simulated engine profile to Qwen3-32B at TP=2 on H200-SXM.
Experiment 1 setup tradeoffs: We compare static deployments and dynamic deployment with planner using aggregated engines. We sweep static replica counts (no planner; fixed deployments with different number of engine replicas) and overlay one planner run setting SLA to TTFT=1500 ms and ITL=50 ms.
The dynamic deployment with planner reaches a much better cost-latency point: its p90 TTFT and ITL are far lower than any static deployments while using less GPU-hours at the same time.
Experiment 2 scaling interval: We sweep the scaling interval from 1 second to 300 seconds, with engine startup set to instant, to see the tradeoff between reacting quickly to traffic changes and scaling too often.
P90 TTFT stays about the same from 1-10 second intervals, but scaling events drop sharply from 1,529 to 233. After about 30 seconds, the Planner reacts too slowly to bursts. GPU-hours stay roughly steady across the sweep, so very short intervals do not cost much more GPU time, but they do cause unnecessary scaling churn. The best range is around 5-10 seconds.
Experiment 3 cold-start time: On a real cluster, adding capacity takes time because a new engine pod needs seconds to minutes before it can serve traffic. In the simulation, we model that delay and measure how well the Planner handles it.
For Qwen3-32B at TP=2, the Planner meets the SLA until startup delay reaches about 180 seconds. Around 200 seconds, performance drops sharply, and by 300 seconds the system is stuck behind the traffic burst, with p90 TTFT reaching 242 seconds. This suggests users should optimize cold start time to stay below 200 seconds for best performance.
These three experiments illustrate how the design space can be explored cheaply.
Simulation as the inner loop
The goal is not to replace real-cluster validation. The goal is to make that validation more focused.
<img src="https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simulation-the-inner-loop-for-deployment-tuning.webp" decoding="async" width="2476" height="1066" data-wp-class--hide="state.isContentHidden" data-wp-class--show="state.isContentVisible" data-wp-init="callbacks.setButtonStyles" data-wp-on--click="actions.showLightbox" data-wp-on--load="callbacks.setButtonStyles" data-wp-on-window--resize="callbacks.setButtonStyles" data-src="https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simulation-the-inner-loop-for-deployment-tuning.webp" alt="Figure 9. DynoSim makes simulation the inner loop for deployment tuning: sweep broadly, shortlist Pareto candidates, verify on the cluster, then calibrate from telemetry." data-srcset="https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simulation-the-inner-loop-for-deployment-tuning.webp 2476w, https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simulation-the-inner-loop-for-deployment-tuning-179x77.png 179w, https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simulation-the-inner-loop-for-deployment-tuning-300x129.png 300w, https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simulation-the-inner-loop-for-deployment-tuning-768x331.png 768w, https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simulation-the-inner-loop-for-deployment-tuning-625x269.png 625w, https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simulation-the-inner-loop-for-deployment-tuning-1536x661.png 1536w, https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-9.-DynoSim-makes-simul
関連記事
KV キャッシュの局所性：LLM サービングコストにおける見えない変数
GPU の割り当て次第でスループットやレイテンシが変動する KV キャッシュの局所性が、再計算コストに直結し、ロードバランサーの設計変更が必要となる。
LLM サービングにおける CPU と GPU の分離の必要性：SMG の事例
Shepherd Model Gateway（SMG）は、大規模な大規模言語モデル（LLM）展開向けの高パフォーマンスなモデルルーティングゲートウェイです。同ツールは、ワーカーライフサイクル管理を一元化し、HTTP/gRPC/OpenAI 互換バックエンド間でトラフィックを分散させます。また、履歴保存や MCP ツール、プライバシー重視のワークフローに対する企業レベルの制御を提供します。
世界を動かす物理AI — Qasar Younis & Peter Ludwig、Applied Intuition
Qasar Younis氏とPeter Ludwig氏は、自律走行や安全重要機械向けOSなど10年間の経験から、物理AIの重要性を説明する。