DynoSim：パレートフロンティアのシミュレーション

現代の 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 倍高速です。

DynoSim を用いれば、既存ハードウェア上のワークロードに対するパレートフロンティア（Pareto frontier）をマッピングするスウィープが可能となり、また自己研究（autoresearch）スタイルのワークフローによって、コンポーネントへのアルゴリズム変更（より優れた Router コスト関数、Planner ヒューリスティック、またはキャッシュポリシーなど）を提案することもできます。

アーキテクチャ：イベントとしての Dynamo の合成

重要な設計上の選択は「合成」です。DynoSim は単一のモノリシックモデルではなく、同じシミュレーションタイムライン上で動作する一連のサービングコンポーネントで構成されています。リプレイハネスがワークロードの到着を駆動し、シングルエンジンシミュレーションがワーカーローカルのスケジューリングとフォワードパスのタイミングをモデル化し、マルチエンジンシミュレーションはワーカー間でのみ存在するシステム動作（ルーティング、分散キャッシュ、Planner による意思決定）を追加します。

バーチャルクロック上での再生

離散イベントシミュレーション（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 オフロードは無効化されているため、違いはルーティングとキャッシュ配置に起因します：

KVBM は、ローカル HBM、ホストメモリ、SSD、および分散またはリモートキャッシュを含むサービングメモリアーキテクチャ全体にわたって KV ブロックを管理します。ローカル下位階層キャッシュの動作は、タイミングとリソース負荷としてモデル化されることが多く、具体的には G1（GPU メモリ）、G2（ホストメモリ）、転送帯域幅、階層容量、そして最終的に G3（ディスク）が該当します。分散キャッシュではシミュレーションがより興味深いものになります。オフロード、オンボード、リモート読み取り、および配置の決定は、ルーティング、スケジューリング、キューイング、および将来のキャッシュ状態に影響を与えるため、サービングハッチ全体の残りの部分と同じタイムライン上でイベントとして登録する必要があります。

以下の KVBM の例では、G2 ホストメモリ階層が有効化され、32,768 ブロックにサイズ設定された場合にモッカーが予測する結果を示しています：

将来、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 がそれをどのように扱えるかを測定します。

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.