第11章 — プラットフォームとオーケストレーション層

LLM Primer VI: AIシステムのスケーリング を章ごとに紹介していくウォークスルー、第11回。プラットフォームの選択はフィーチャーの問題ではなく、どの運用モデルがチームの既存運用文化に合うかのフィット問題だと論じる章です。

なぜこの章があるのか

エンジンはGPU上のモデルを包み、トークンを生む。それが完全な仕事の記述です。本番が「ロードバランサーの背後に2レプリカ」「1エンドポイントの下に2つの異なるエンジン」「embed→retrieve→rerank→generateを1つの論理呼び出しとして走らせるパイプライン」「1テナントが他を飢えさせるのを止めるクォータシステム」「キュー深度が上がるにつれレプリカを足すオートスケーラー」を必要とした瞬間、エンジンは答えを使い果たします。第11章は2026年にその仕事を支配する4つのプラットフォーム — Ray Serve、KServe、BentoML、Triton Inference Server — を歩き、それらの選択がフィーチャー問題ではなくチームの運用文化のフィット問題だと論じます。

11.1 Ray ServeはPythonファースト、KServeはKubernetesファースト

Ray Serveは、「モデルパイプラインの構成、スケール、配備のためにPythonを離れる必要がなければサービングフレームワークはどう見えるか?」から出発するプラットフォームです。答えはアクターとしてデコレートされたPythonクラスを、Python関数呼び出しで配線し、Rayランタイムがレプリケーション、配置、オートスケーリングを行う、というもの。デプロイメントは互いのメソッドを呼び合ってパイプラインに構成される。パイプラインはPython、可観測性はPython、運用物語はPython。同じクラスタで訓練のためにすでにRayが走っているときに自然な選択です。KServeは反対の出発点から立ち上がる。Kubernetesファースト、ベンダー中立、宣言的。KServeの InferenceService は重みがどこにあるか、どのランタイムが提供するか、オートスケーリングがどう振る舞うかをキャプチャするCRDです。プラットフォームはKnativeでゼロへのスケール、Istioでトラフィックルーティングを行うポッドを配線し、安定したHTTPエンドポイントを公開する。トレードは表現力 — KServeでのパイプライン構成はRay Serveよりよりyaml駆動 — と、ポータビリティ・標準化。

11.2 BentoMLはパッケージ化する、Tritonは異種モデルをバッチ化する

BentoMLは3つ目のスタンスを取ります。プラットフォームの主な仕事はモデル+コード+依存を単一の首尾一貫したアーティファクト — Bento — にし、そのアーティファクトをどこにでも(Kubernetes、Lambda、Cloud Run、素のVM)一命令で配備することだ、と。汎用アプリケーションにおけるDockerイメージが、モデルサービング層で担うのと同じ役割です。書き味はFastAPI形状のPython。配備物語はアーティファクトファーストの動き。ベストフィットは小さな運用フットプリントと、「Pythonクラス」から「どこでも走るデプロイ済みエンドポイント」への最速パスを求めるチーム。Triton Inference Serverは歴史的にNVIDIA整合サービングを支配してきたエンタープライズ級の動的バッチャー。TensorFlow、PyTorch、ONNX、TensorRT、TensorRT-LLM、Pythonバックエンドを並列にホストし、動的バッチャーを非LLMワークロード(レコメンダー、分類器、埋め込み器)に適用し、TensorRT-LLMバックエンド下のLLMには連続バッチングスケジューラを使う。ベストフィットは異種ワークロード、あるいはNVIDIAスタックに深く関与するチーム。

11.3 4つの選択は運用文化のフィットで分割される

4つのプラットフォームは綺麗に分割されます。中心的重力がPythonとRay → Ray Serve。Kubernetes、宣言的マニフェスト、マルチクラウド可搬性、マルチテナント分離 → KServe。小さな運用フットプリント、クラスからエンドポイントへの最速パス → BentoML。異種ワークロードまたはNVIDIAファースト店 → Triton。組織レベルでは相互排他ではありません。大きな組織で一般的なパターンは、最高ボリュームの本番LLMにTriton、複数のモデル呼び出しを構成するRAGとエージェントパイプラインにRay Serve、マルチテナンシーを強制する傘としてKServe、開発者環境の中にBentoML。選ぶ際の有用な演習は、チームが絶対必要な運用属性を3つと絶対なくてもよいものを3つ挙げ、そのリストに対してプラットフォームを順位付けすること。「全てをサポートする」プラットフォームには抵抗する。各プラットフォームは自身のコアを良く、周辺を悪くサポートし、コアが必須項目と重なるものが、チームが運用を楽しめるものです。

第11章が敷いたもの

エンジンとプラットフォームの境界は、レプリケーションの単位が「1つのGPUノード上の1つのモデルを所有する1つのポッド」であるときは綺麗です。第1章の事実 — プリフィルとデコードは矛盾するワークロード — を守る瞬間、綺麗でなくなる。第12章はそれらを別々のGPUプールに分割し、KVキャッシュをプール間でネットワークファブリック上で運び、その分割をKubernetesのプリミティブ — LeaderWorkerSet、GroveのPodCliqueSet、KAI Schedulerのトポロジー認識 — で表現します。プラットフォーム層こそが分割を運用可能にし、プラットフォーム層こそが分割を表現可能にする理由です。

次回 — 第12章: 分離型サービングとKubernetes。 プリフィルとデコードを別のポッドに分け、その分割を表現するKubernetesのプリミティブ。