第12章 — 分離型サービングとKubernetes

公開日: 2026-05-04 最終更新日: 2026-07-07 バージョン: 1
第12章 — 分離型サービングとKubernetes

第12章 — 分離型サービングとKubernetes

LLM Primer VI: AIシステムのスケーリング を章ごとに紹介していくウォークスルー、第12回。ついにプリフィルとデコードを別々のGPUプールに分割し、ポッドをインターコネクトの正しい側に留めるKubernetesのプリミティブを示す章です。


なぜこの章があるのか

第11章はエンジンとプラットフォームの間に綺麗な線を引きました — エンジン自身がプリフィルとデコードは矛盾するワークロードだと指摘するまで。プリフィルは演算律速、デコードはメモリ帯域律速。両者を同じGPUで走らせることは、1つのハードウェアに矛盾する2つのことを上手くやらせようとすることで、結果両方に中途半端になる。分離型サービングは両者を別のGPUプールに分割し、KVキャッシュをプール間で運び、各プールを自分のワークロード用にチューニングする。代償は運用の複雑さで、Kubernetesのプリミティブ、ポッドのトポロジー、KVトラフィックを運ぶネットワークファブリックで支払う。第12章はその複雑さの形 — コンポーネント、転送経路、そしてそれを表現するCRD(LeaderWorkerSet、GroveのPodCliqueSet、KAI Scheduler) — を歩きます。

ひとことで言うと: 分離は1つの中途半端なGPUプールを2つのよくチューニングされたプールに変える — 代償として、通常系列あたり数GBのKVキャッシュを、厳格なTTFT予算内でNVLinkかInfiniBand上で運ぶ。

12.1 プリフィルとデコードは違うチップと違うクロックを望む

同じH100上で、長いプリフィルは真にピークFLOPsの60〜80パーセントに達し得るし、デコードステップはFLOPsの5〜15パーセントを使いつつHBM帯域の70〜90パーセントを飽和させます。連続バッチング下で交互に走らせるのは動く妥協ですが2つ漏れる。プリフィルの演算パスは、キューされたデコードが流したい同じHBMバスを叩き、トークン間時間が膨張する。カードは単一の動作点でも走る。プリフィル向けにチューニングするとデコードは帯域絞り、デコード向けにチューニングするとプリフィルは演算絞り。プロンプトはRAGとエージェントが本番トラフィックを取って以降、数百から数千トークンに伸び、交互のコストも一緒に育ちました。分離は各局面に自身のプールを与えます。プリフィルワーカーは生FLOPsのカード(H100 SXM、B200)で走らせられる。デコードワーカーは容量と帯域のカード(H200、MI300X)で走らせられる。各プールは自身のワークロードに合わせてサイズ調整される — 長コンテキスト・短出力のトラフィックはより多くのプリフィルが要り、チャットトラフィックはより多くのデコードが要る。

12.2 形は4つのコンポーネントとKV転送経路

動く分離配備は4つのコンポーネントを持ちます。プリフィルワーカーはリクエストを受け、プリフィルを計算し、最初のトークンを吐き、KVキャッシュを転送用にステージする。デコードワーカーは着信KVキャッシュとメタデータを受け、それを自身のページ化アテンションプールにインストールし、実行中の生成に対して連続バッチングを走らせる。KVキャッシュルーター — 制御プレーン — は各デコードワーカーの空きKV容量、バッチ充填、ネットワークローカリティのビューを保持し、各プリフィルの出力を転送コスト最小化と負荷分散のために割り当てる。フロントエンドゲートウェイはユーザーのHTTP接続を終端し、プリフィルワーカーから最初のトークンをストリーム、その後透過的にデコードワーカーから残りをストリームに切り替える。決定的な制約はKV転送。70B GQAの4,096トークン系列は1.5〜2 GB。ユーザーが見ているのと同じ50〜100 msのTTFT予算内で、プリフィルノードからデコードノードへ動かなければならない。ノード内900 GB/sのNVLinkとノード間400 Gb/sのInfiniBandが数字を成立させます — もしポッドがファブリックの正しい側に着地すれば。

12.3 LeaderWorkerSet、Grove、KAIがトポロジーを表現する

Kubernetesは元々「これら2種類のポッドが1つの論理レプリカ」を表現するプリミティブを持ちませんでした。LeaderWorkerSet(2024年に上流に追加)はリーダー(たとえばプリフィル)とワーカー(たとえばデコード)を持つマルチポッドレプリカを表現し、コントローラーがグループを1つのスケジューリング単位として保つ。NVIDIA GroveのPodCliqueSet(2025年、NVIDIA AI Enterpriseの一部)は、型付きクリーク(プリフィル、デコード、ルーター)それぞれに独自のテンプレートとサイズ、加えてクリーク間の関係を記述するクリークトポロジー記述でさらに一般化する。Groveはクリーク内・クリーク間のローカリティ制約と共に集合全体をスケジューラに提出する。どちらのCRDもそれ単独では十分ではなく、両者ともクラスタの物理トポロジーを知るスケジューラを必要とします。標準のKubernetesスケジューラは知りません。KAI Scheduler(2024年にRun:aiからオープンソース化)は nvidia-smi topo --matrix とInfiniBandサブネットマネージャが生成するトポロジーグラフを消費し、候補配置をそれに対してスコア付けする。Groveのクリークが nvlinkDomain: required を要求すると、KAIは配置を単一のNVLink一貫ドメイン(HGXベースボードの1つのNVSwitch上の8 GPU)に制限する。クリーク間トポロジーが sameInfiniBandIsland と言うと、KAIはクリークをKV往復が100 μs未満に留まる1つのリーフスイッチグループ内に留める。

覚えておきたいこと: トポロジー認識スケジューリングなしの分離は、分離しないより悪い。KV転送が間違ったスイッチをまたぐと、TTFT予算はネットワークジッターに消え、運用者は分割の複雑さを引き受けたのにスループットを掴めない。

第12章が敷いたもの

第12章は配備に静的な絵を与えました。ある瞬間、固定数のクリークが走ってトラフィックを捌く。実トラフィックは静的ではありません。チャットアシスタントは1日の中で30倍のピーク対トラフを揺れ、開発者ツールは週末にゼロに落ち、消費者プロダクトは太陽を追う。第13章はオートスケーリング物語を歩きます。なぜ標準のHPAはLLMサービングに間違ったスケーラーか、KEDAは代わりに何の信号でスケールするか、Knativeがゼロへのスケールをどう表現するか、そして60〜180秒のコールドスタートをユーザー向けアプリケーションが吸収できる何かに圧縮するには何が必要か。


次回 — 第13章: オートスケーリングとコールドスタート対策 KEDA、Knative、CRIU、CUDAグラフキャッシュ、NVMe — ゼロへのスケールを実ユーザーと共存させるスタック。

全体像を押さえたい方へ: 書籍版にはLlama-70B分離配備のためのLeaderWorkerSetとGroveのYAML、KAIトポロジー設定ブロック、Pythonのルーター決定関数、4コンポーネントを横断するエンドツーエンドリクエストトレース、そしてマルチモデル・マルチテナントのクリークノートが収録されています。Amazonで『LLM Primer VI』を見る →

下田 昌平
下田 昌平
開発と設計を担当。1994年からプログラミングを始め、今もなお最新技術への探究心を持ち続けています。