第13章 — オートスケーリングとコールドスタート対策
LLM Primer VI: AIシステムのスケーリング を章ごとに紹介していくウォークスルー、第13回。標準のKubernetesオートスケーラーがLLMトラフィック下で障害を出す理由と、KEDA、Knative、CRIUがどう修正を構成するかを説明する章です。
なぜこの章があるのか
チャットアシスタントは1日の中で30倍のピーク対トラフを揺れます。開発者ツールは週末にゼロに落ち、消費者プロダクトは太平洋から欧州の波に乗る。ピーク基準で用意すればトラフで金を無駄にし、トラフ基準で用意すればピークでリクエストを落とす。オートスケーリングはデプロイをトラフィックに歩調を合わせて保ち、コールドスタート対策はオートスケーリング — 特にゼロへのスケール — をユーザーに気づかれないほど速くする。第13章は標準のKubernetes HPAがなぜLLMに間違ったスケーラーか、KEDAが代わりに何の信号でスケールするか、Knativeがどうゼロへのスケールを表現するか、そして60〜180秒のコールドスタートを1桁秒に圧縮するには何が必要かを説明します。
13.1 HPAはLLMトラフィックに4つの特定の方法で失敗する
既定のHPAはCPUかGPU利用率でスケールします。LLMには4つの点で失敗する。第一に、GPU利用率は間違った信号 — nvidia-smi は 何らかの カーネルが走っている時間の割合を報告するもので、バッチがよくパックされているか、リクエストが前進しているかは報告しない。1つのデコードの背後に8つの長いプリフィルがキューされた95パーセント利用のサーバーは過負荷。健全な連続バッチを持つ60パーセント利用のサーバーは大丈夫。第二に、LLMのリクエスト持続時間(数秒から数十秒)はHPAの制御ループ(15秒)に対して長く、スケーリングは負荷を1リクエスト寿命分遅らせる。第三に、容量の単位はポッドではない。分離配備はクリークでスケールし、HPAはクリークを理解しない。第四に、コールドスタート。新しいポッドは60〜180秒後にオンラインになり、それをトリガーしたスパイクは既に艦隊を過負荷にしているか、タイムアウトとして自己排出している。典型的な失敗モードはトラフィック倍化中の2分停止、それに続くスケールダウンで次のスパイクに対して不足配備で残ること。
13.2 KEDAはキュー深度、TTFT、KV占有率でスケールする
KEDAは外部指標を望みレプリカ数に変換する1つ以上のスケーラーに対象ワークロードを束ねる ScaledObject CRDでHPAを拡張します。LLMサービングには3つの信号が重要。キュー深度は最も直接的で、エンジンの待機リクエスト数はサービング能力に対する到着仕事量の余剰。vLLMは vllm:num_requests_waiting として公開する。最初のトークンまでの時間 — 具体的にはスライディングウィンドウ上のp95かp99 — はユーザーが見える劣化をキャプチャし、キュー深度が取り逃す非対称な過負荷(プリフィル飽和だがデコードは大丈夫、あるいはその逆)を捕まえる。KVキャッシュ占有率は先読み。占有率が80パーセントを超えたら、既存のものがプリエンプトや拒否を始める前に新しいレプリカがオンラインになるべき。本番のScaledObjectは通常3つ全てを合成し、最も攻撃的なものが勝つ。Knative Servingがゼロへのスケールをその上に載せます。小さな起動閾値未満の全ポッドが除去され、着信リクエストはポッドを要求時に起動するアクティベーターが保持する。これはコールドスタートが速いときにのみ経済的です。
13.3 CRIUは90秒のコールドスタートを3〜6秒に圧縮する
70Bのコールドスタートはイメージプル(10〜60秒)、Python初期化(2〜5秒)、重みロード(60〜120秒)、CUDAコンテキスト初期化(5〜15秒)、CUDAグラフキャプチャ(10〜30秒)、KVウォームアップ(2〜10秒)に分解される — 合計90〜250秒。CRIU(Checkpoint/Restore In Userspace)は完全に温まったプロセス — 重みロード、CUDAコンテキスト立ち上げ、グラフキャプチャ、KVプール確保、ヘルスチェック通過 — をスナップショットし、後にディスクから秒単位で復元します。NVIDIAの cuda-checkpoint ユーティリティ(2024)はCRIUを拡張してGPU状態を扱う。デバイスメモリプール、CUDAコンテキスト、キャッシュされたPTX、キャプチャされたグラフ。ウォームvLLMスナップショットはローカルNVMeから3〜6秒で復元される。DaemonSetがチェックポイントを各ノードのNVMeに事前ステージするので、Knativeはネットワークから取りに行くのではなくローカルファイルから復元できる。イメージストリーミング(プル完了前にプル開始)と遅延重みロードと組み合わせると、5秒未満のコールドスタートが本番で達成可能 — ユーザー向けアプリケーションでゼロへのスケールが経済的に守れる数字です。
第13章が敷いたもの
第1章から第13章までLLMサービングの物理スタック — ハードウェア、エンジン、プラットフォーム、分離、スケーリング — を歩きました。残りの本はお金に転じます。第14章はなぜトークンが課金単位か、なぜ出力が入力より2〜5倍高いか、そして見えない推論トークンがどう請求書に載るかを説明します。第15章はセルフホストとAPIプロバイダーの損益分岐算術、加えて多くのチームが甘く見るプラットフォームエンジニアリングの行を歩きます。第16章は効いてくるコスト削減の打ち手のカタログです。
次回 — 第14章: トークン経済とAPI価格。 請求書がなぜこの形なのか、そして誰も見ていないときにメーターがどう回るか。
