モデルの起動待ち時間を2.38倍短縮──SGLangが「CUDAグラフのキャプチャ中にチェックポイントを読み込む」設計に変えた

大規模言語モデルの推論エンジンとして使われるSGLangは、v0.5.18（2026年8月22日公開）のリリースノートに「710 PRs from 212 contributors」と記載された大型リリースだ。その中の1つが、サーバー起動時にかかる時間を大幅に縮める「Overlapped checkpoint staging（重ね合わせ式のチェックポイント読み込み）」だ。実装したのはPR #32017で、2026年8月13日にマージされている。

3行まとめ

1. SGLang v0.5.18は、PR #32017（2026-08-13マージ、16ファイル・+2020/-79行）で、モデルの重みをストレージから読み込む処理とCUDAグラフのキャプチャを並行させる--startup-weight-load-mode overlapをオプトインで追加した。
2. PR本文のベンチマーク（Qwen3-32B・BF16・H100・ローカルNVMe）によれば、素の逐次起動84.83秒に対しoverlap込みで35.60秒(TP1、2.38倍)まで短縮するが、TP2では78.60秒→45.16秒(1.74倍)にとどまり、TP1ほどの倍率は出ていない。
3. 既存の「プリフェッチ付き逐次処理」との比較(overlapの純粋な追加効果)では、TP1で8.6%・TP2で11.7%の短縮にとどまり、リリースノートが謳う2.38倍という数字の大半はoverlapではなくプリフェッチ自体の効果だと、PR本文自身が明記している。

何を並行させたのか

公式リリースノートの説明はこうだ。

"Overlapped checkpoint staging at startup: Checkpoint pages now stage from storage while CUDA graphs capture. Qwen3-32B on H100 starts 8.6-11.7% faster than serial with prefetch, and 2.38x faster (35.6s vs 84.8s) than the plain default. Opt in with --startup-weight-load-mode overlap"

（起動時の重ね合わせ式チェックポイント読み込み：チェックポイントのページが、CUDAグラフのキャプチャと並行してストレージから読み込まれるようになった。H100上のQwen3-32Bは、プリフェッチ付きの逐次処理より8.6〜11.7%速く、素の既定設定より2.38倍（35.6秒 対 84.8秒）速く起動する。--startup-weight-load-mode overlapで有効化する）

サーバーを起動する際、推論エンジンは大きく分けて2つの作業をこなす必要がある。1つは、モデルの重み（チェックポイント）をディスク（あるいはネットワークストレージ）からGPUメモリに読み込むこと。もう1つは、推論を高速化するためにCUDAグラフ（GPU上の計算グラフをあらかじめ記録・最適化しておく仕組み）をキャプチャすることだ。これまでは、この2つが順番に（逐次的に）実行されていたとみられる。今回の変更は、この2つを同時並行で進めることで、起動全体にかかる時間を圧縮する。

数字の内訳：2種類の比較が示されている

リリースノートが示す性能数値は、比較対象が2段階に分かれている点に注意が必要だ。PR #32017の本文には、Qwen3-32B（BF16）をH100上で動かし、ローカルNVMeストレージ・TP1/TP2構成でA/B/Cの3パターンをラテン方格順で3回ずつ計測した詳細な表が掲載されている。

PR本文は「A→Cの削減の大部分は協調的なチェックポイント・プリフェッチによるもので、B→Cこそが新しい起動順序（overlap）に起因する主結果だ」と明記している。B→Cだけを見ると、TP1で8.6%（3.34秒、1.09倍）・TP2で11.7%（5.96秒、1.13倍）の短縮にとどまる。つまりリリースノートが強調する「2.38倍」という数字は、素の既定設定と比べた場合の話であり、そのうち大半はすでに存在する「プリフェッチ」機能の効果で、overlap自体が純粋に上乗せする効果は1割前後、という内訳になる。

また、TP1では2.38倍だった短縮効果が、TP2では1.74倍に縮小している点も見逃せない。PR本文は「これらの計測はTPサイズに対する単調なスケーリングを立証するものではない」「TP1とTP2は別々のノードで別々に計測されている」と釘を刺しており、TPランクが増えるほど改善率が上がるとは主張していない。参考として、TP1でプリフェッチのスレッド数をTP2と同じ計8スレッドに揃えて計測すると、B→Cの短縮は43.25秒→36.71秒（15.1%、1.18倍）になったとも報告されている。

使うには明示的なオプション指定が必要

この機能はデフォルトでは有効になっておらず、--startup-weight-load-mode overlapという起動オプションを明示的に指定する必要がある。「Opt in with」という表現から、既定の起動フローを変えずに、必要な場合だけ選択的に有効化できる設計であることが分かる。

3段階のロールアウト計画と、現時点でのサポート範囲

PR本文によれば、これは3段階に分けたロールアウト計画のうち「PR 1」にあたる。今回のPRで対応するのは、既定のDefaultModelLoaderによるCUDAグラフキャプチャ、mmapを有効にしたauto/safetensors形式での読み込み、Llama・Qwen2・Qwen3系のネイティブなdenseな生成モデル、FP16/BF16精度、TP1/TP2構成、単一の主要チェックポイントソースに限定されており、対応範囲外の構成では黙って挙動を変えるのではなく明示的にエラーを出す設計になっている、とPR本文に明記されている。今後の計画としては、「PR 2」でサポート対象の拡大・起動フェーズのタイミング計測やCI/ベンチマークの充実、「PR 3」でautoポリシーの導入とデフォルト化を予定している、とPR本文には書かれている（いずれも本記事執筆時点でマージ済みかどうかは確認していない）。

技術的な仕組みとしては、既存の逐次フロー「実重みの読み込み・後処理→ランタイム初期化とCUDAグラフキャプチャ」を、「GPUストレージ確保とsafetensorsシャードの解決→capture-safeな重みの初期化→チェックポイントのプリフェッチ開始(ストレージからOSページキャッシュへのステージング、これがCUDAグラフキャプチャと並行して走る)→メモリプール・attentionバックエンドの初期化とCUDAグラフキャプチャ→実重みの読み込みと後処理(既存のストレージ内でその場に反映)→CUDA同期・ストレージの同一性検証→配信開始」という順序に組み替えたものだと説明されている。キャプチャ済みグラフが参照するテンソルの実体（オブジェクトの同一性・データポインタ・shape・stride・dtype・device・storage offset）が、実重みのコミット後も変わらないことを検証する仕組みも組み込まれているという。PRの変更規模は16ファイル・追加2,020行・削除79行で、著者はyh0903氏。

GitHub APIで変更ファイル一覧を個別に取得すると、この16ファイルの内訳と、追加2,020行・削除79行という合計値を、ファイルごとの数字を積み上げて確認できた。新規追加された最大のファイルは、新しいコアモジュールpython/sglang/srt/model_executor/model_runner_components/startup_weight_load.py（591行の新規追加）で、これが今回の並行処理ロジックの本体にあたる。テスト側の追加も大きく、test/registered/unit/model_executor/model_runner_components/test_startup_weight_load.pyが732行の新規追加、test/registered/model_loading/test_startup_weight_load.pyが69行の新規追加となっている。既存ファイルではpython/sglang/srt/model_loader/loader.py（+180/-16）とpython/sglang/srt/model_loader/weight_utils.py（+104/-18）の変更量が大きい。

v0.5.18タグの時点でのソースコード本体（startup_weight_load.py）を実際に取得して確認すると、PR本文が説明していた「テンソルの実体が変わっていないことを検証する仕組み」は、コード上にdata_ptr・shape・stride・dtype・device・storage_offsetという6つのフィールドを持つデータクラスとして実装されており、この6項目を比較することで整合性を検証している。記事本文で「オブジェクトの同一性・データポインタ・shape・stride・dtype・device・storage offset」と説明した内容は、この実装と一致することを確認した。

なぜ起動時間が重要なのか

推論サーバーの起動時間は、モデルを使い始めるまでの初回の待ち時間だけでなく、オートスケーリング環境（負荷に応じてサーバーインスタンスを増減させる運用）では、新しいインスタンスが実際にリクエストを処理できるようになるまでのリードタイムに直結する。35.6秒と84.8秒という差は、1回だけなら誤差の範囲に思えるかもしれないが、日常的にインスタンスの起動・停止を繰り返す運用では、積み重なるコストになる。

同じリリースに含まれる他の起動時間関連の変更

v0.5.18のリリースノートには、起動関連の別の変更として「One compiled-kernel cache directory」も同じセクション付近に記載されている。

"One compiled-kernel cache directory: Triton, FlashInfer, Inductor, DeepGEMM, and CUDA driver caches all move under SGLANG_CACHE_DIR. The first launch after upgrading recompiles once; see Breaking Changes"

（コンパイル済みカーネルのキャッシュディレクトリを1つに統合：Triton・FlashInfer・Inductor・DeepGEMM・CUDAドライバのキャッシュが、すべてSGLANG_CACHE_DIR配下に移動する。アップグレード後の最初の起動は1回だけ再コンパイルが走る）

起動時間の最適化と、キャッシュ管理の整理が同じリリースにまとまっているあたり、v0.5.18が「運用時の待ち時間」全般にフォーカスしたリリースだったことがうかがえる。

起動待ちのストレスから見えてくる規模感

筆者は自分でSGLangを使ったサーバー運用を行っているわけではないが、ローカルLLM環境を構築する際に、モデルの読み込み待ち時間の長さにストレスを感じた経験は何度もある。今回の変更が扱っているのは、そのローカル環境よりさらに大規模な、本番運用でのオートスケーリングを前提にした最適化だ。「起動が速くなる」という一見地味な改善が、実際には推論エンジンの内部で「ディスクI/OとGPU計算グラフの構築という、性質の異なる2つの重い処理をどう並行させるか」という設計判断の積み重ねであることが、この1行の説明からも読み取れる。

他モデル・他GPUでの実測値は示されていなかった

Qwen3-32B・H100という組み合わせ以外のモデル・GPUでの実測値は、今回確認したリリースノート本文にもPR #32017の本文にも記載がなかった。またこの機能がモデルサイズに対してどうスケールするか（より大きなモデルでも同程度の高速化率が出るか）についても、確認した範囲では言及がない。PR本文自身が「TP1・TP2は別々のノードで計測されており、TPランクが増えるほど改善率が上がるとは言えない」「3回の反復では統計的な確度を厳密に立証する意図はない」と明記しており、この記事もその留保をそのまま引き継いでいる。TP2・NFS(ネットワークストレージ)での再計測は、共有ストレージの競合により安定した平均が取れず性能主張から除外されたとPR本文にあり、ローカルNVMe以外のストレージでの数字は本記事の範囲では確認できていない。PR本文と変更ファイル一覧はGitHub APIで取得して読み、コア実装ファイルstartup_weight_load.pyの本体もGitHub raw経由で取得して整合性検証ロジックの実装を確認した。ただし、追加された2つのテストファイル（新規732行・69行）の中身、既存ファイルへの変更差分そのもの（diffのハンク単位の内容）までは、この記事では開いていない。SGLangを自分の環境で動かしてこの機能を検証したわけでもない。

関連記事

• ローカルLLMとは何か──自分のPCでAIを動かす仕組み・利点・始め方を解説
• LLMベンチマークの読み方──MMLU・HumanEval・Arenaの注意点【2026年版】