ServingStudioを公開、シミュレーション・エージェントによる修正・GPU検証をつなぐ推論性能ワークベンチ

ワシントン大学のSyFI Labは9月24日、LLM推論サービスの性能シミュレーション、コード修正、ハードウェア検証を一連のプロセスにまとめたServingStudioを紹介した。エンジニアがモデル、リクエスト分布、GPU構成、性能目標を指定すると、エージェントがベンチマークを作成して設定を探索し、候補となる手法を推論フレームワークに適用する。[公式紹介](https://syfi.cs.washington.edu/blog/2026-09-24-introducing-servingstudio/)

ワークベンチはシミュレーター、エージェント、可視化インターフェースで構成される。シミュレーターは実測したGPUコア時間を使ってサービス性能を予測する。エージェントは予測と実行トレースを比較し、差がカーネル、通信、アイドル時間のどこから生じたかを調べてコードを修正する。修正はまず正しさのチェックを通過させ、最後に実負荷でスループットとレイテンシを測定して、採用するか再検討する。エンジニアリングの観点では、高価なハードウェア実験で探索する範囲を絞るのに役立つが、効果は実測で確認する必要がある。[プロジェクトの説明](https://github.com/SyFI-ServingStudio/ServingStudio)

公開された事例では、SGLangのある細部が明らかになった。起動時に自動チューニングを済ませても、プリフィル用CUDA graph内のMoEカーネルまで調整済みとは限らない。グラフモードでは異なる形状の出力プレースホルダーテンソルを使うため、チューニングキーも異なり、フォールバック戦略に戻る場合がある。この修正ではグラフキャプチャの前に実際の実行経路に沿ってチューニングを追加し、通常の即時実行経路だけが最適化される事態を防ぐ。[修正提案](https://github.com/sgl-project/sglang/pull/38560)

著者らは、4基のB200で4-way tensor parallelを使ってGLM-5.2 NVFP4を実行し、リクエスト240件、同時実行数24、各リクエストの入力4,096トークン、出力8トークンでテストした。ウォームアップ後に3回測定した中央値では、所要時間が44.873秒から42.503秒に短縮し、入力スループットは5.58%増加した。これは入力が長く出力が短い、特定の負荷に対する結果だ。また、2つのテストは同一ホスト上の別々のGPUグループで実施され、グループを入れ替えたテストは行われていない。初回のグラフ経路チューニングには約91秒かかり、キャッシュを再利用して初めて大幅に短縮された。[テスト条件と結果](https://github.com/sgl-project/sglang/pull/38560)

確認時点で、この修正はまだドラフトPRだ。GSM8Kの64問で合計スコアが同じだったとしても、各問の出力が一致したことの証明にはならない。[検証上の制約](https://github.com/sgl-project/sglang/pull/38560) 導入時はモデルとソフトウェアのバージョンを固定し、自分たちの入力長、同時実行数、テールレイテンシで再測定するとよい。このワークベンチはサブモジュールでコンポーネントのバージョンを固定しており、Linuxと複数のビルドツールが必要だ。カーネルのプロファイリングと実際のフレームワークでのテストには、NVIDIA GPUと互換性のあるCUDA環境も必要になる。[導入要件](https://github.com/SyFI-ServingStudio/ServingStudio)

チームは、GPU間、ホストメモリ、リモートストレージをまたぐプレフィックスキャッシュのシミュレーション拡張と、公開カーネル性能データベースの提供も計画している。現時点では、いずれも今後の作業として挙げられている。評価者は、現在の時間データが自分たちのモデル、精度、ハードウェアの組み合わせをカバーしているか確認し、上流レビューの進捗と、異なる負荷での予測誤差を追う必要がある。[今後の計画](https://syfi.cs.washington.edu/blog/2026-09-24-introducing-servingstudio/)