DynoSim、LLM serving実験を1,500倍速いsimulation loopへ

LLM serving最適化の難しさは、モデル性能だけではない。現実のGPU clusterで構成を一つずつ試すコストが重い。NVIDIAのDynoSimは、この問題をsimulate-firstの流れに変える。tensor-parallel shape、prefill/decode split、worker数、routing policy、KV cache、autoscalingを、本番clusterに載せる前にworkload trace上で絞り込む。

DynoSimはNVIDIA Dynamo serving stackのworkload-driven discrete-event simulationである。Router、Planner、scheduler、KV cache behavior、workload traceを一つのvirtual timelineに置き、request arrival、forward pass、KV transfer、worker startupといったイベントを時間順に進める。NVIDIAによれば、Apple M4 MacBook Air上のsingle-threaded Rust offline replayで、Mooncake trace 23,608 requestを2.41秒でsimulateした。対象のserving windowは60.1分で、real timeより約1,500倍速い。

この速度が効くのは、inference tuningが連動したsystems problemだからだ。routingを変えるとdecode pressureが増えることがあり、cache policyはTTFTを下げてもthroughput curveを動かす。cold-start delayがautoscalingの利点を消す場合もある。DynoSimは数千のdeployment候補を安くふるいにかけ、Pareto候補だけを実機で検証することを狙う。NVIDIAはMiniMax-M2.5 FP8 on HGX B200の実験で、KV-aware routingがprefix reuseを約0.38から0.44〜0.45へ上げ、round-robinよりTTFTを下げたと示した。

cache tierとautoscalingも対象だ。KVBM G2 host-memory tierを有効にするとprefill recomputeが減り、concurrency 32でmean TTFTが19.3%改善した。Qwen3-32B at TP=2 on H200-SXMを使ったPlanner実験では、dynamic deploymentがstatic deploymentより低いp90 latencyと低いGPU-hoursの組み合わせを見つけた。scaling intervalは5〜10秒付近が、反応速度とscaling churnのバランス点になった。

agent trafficが増えるほど、この種のsimulationは重要になる。multi-turn request、burst、prompt長のばらつき、cache reuseの変化は、小さなunit testでは説明しきれない。DynoSimがproduction traceを継続的にreplayし、より良いconfigurationを推薦する内側のloopになれば、LLM servingは一度決めた設定を維持する運用から、trafficに合わせて更新し続ける運用へ近づく。