KubeCon China 2026: 同じハードウェアから取り戻した処理能力

上海で開催された KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 は、2 つの論点に沿って進みました。1 つ目はワークロードの移り変わりで、開会の基調講演はそこにアナリストの数字を添えました。AI の計算資源は、いまや学習よりも推論に傾いています。その推論を提供することが Kubernetes の前提としてきた抽象化に無理を強いており、この軋みは会期を通じて繰り返し表面化しました。Deployment は推論レプリカを表現できず、最初のトークンまでの時間 (TTFT) はリクエストレートではありません。2 つ目の論点はエンフォースメントで、1 つ目より下のレイヤーにあり、その行方にほとんど左右されません。HAMi は GPU を分割して各ワークロードを自分の取り分の中に留め、DRA はその割り当て単位を要求し計上する手段を Kubernetes 自身に与えます。ワークロードが学習か推論かは問いません。2 つが交わるのは支出の話です。処理能力を必要としたチームは、ハードウェアを買うのではなく、割り当てる単位を変えることでそれを手に入れていました。

基調講演が示した構図

基調講演は、その移り変わりを数字で示しました。壇上で引用されたアナリストの数字では、AI の計算資源のうち推論が 67%、学習が 33% を占めています。その理由として挙げられたのは規模ではなく頻度でした。学習は散発的に起こりますが、推論はプロンプトのたびに起こり、エージェントのワークロードは推論を大量に必要とします。同じ基調講演は、推論の電力需要が 2030 年までに 93.3 GW に達すると予測しました。あわせて、クラウドネイティブの各要素を AI 時代の対応物に対応づけてもいます。分離のためのコンテナとサンドボックス、マイクロサービスとエージェント、サービスメッシュと MCP のようなエージェント向けプロトコル、宣言的 API と model-as-a-service、そしてイミュータブルインフラと SLA を意識したインフラです。

PyTorch Foundation の基調講演は、最前線を決めるのはいまやチームがどれだけ速く反復できるかだと論じました。モデルを学習させてから提供するという従来の直線的なパイプラインは、本番環境での挙動が重みへと戻っていくループに置き換わっており、その証拠として示されたのが Kimi K3、MiniMax M3、Qwen 3.8 に対する vLLM と SGLang の day-zero 対応でした。基調講演が取り上げた実例は Shopify で、同社はコマース向けエージェントでそのループを毎日回しています。本番環境での失敗が学習データになり、キャリブレーションされたジャッジが軌跡を批評し、修復し、検証します。PyTorch がそれを使って教師ありファインチューニングに続けて強化学習で再学習を行い、更新された重みを vLLM が提供します。同社の GraphQL 評価では、蒸留したモデルが学習例 46,000 件から 61,000 件のあいだのどこかでフロンティアの参照ベースラインを上回りました。見出しの数字である、毎分 2,000 リクエストまでで約 96% という提供コストの削減は、学習を含む実測の総コストではなく、提供コストのモデル上の比較として示されたものです。

HAMi は、この下側のレイヤーが形になりつつあることを示す分かりやすい例です。複数のワークロードが 1 枚の GPU カードを共有でき、それぞれが自分のメモリと計算のクォータを持ちます。スケジューラーの隣ではなく下に位置するオープンな GPU リソースレイヤーとして働き、その上に Volcano、Koordinator、Kueue が乗り、下には KAI Scheduler との統合が置かれます。DRA ドライバーは現在、同じ分割を Kubernetes 自身のクレーム API を通じて表現し、従来の device-plugin による要求と並存するのではなく、それを変換します。プロジェクト自身が、2 つのモードを 1 つのクラスターで同時に動かすべきではないと明言しています。HAMi は初日の 5 つのセッションで名前が挙がり、以下の本番事例のうち 3 つが実際に採用しています。

企業セッションが実際に見せたもの

China Merchants Bank は、この問題にもっとも素朴な形で向き合っていました。アクセラレーターのプールは 1 つ、安定した容量を求める学習ワークロードと素早い伸縮を求める推論ワークロードがあり、その両方が同じカードを取り合っている、という状況です。アクセラレーターを買い増すのではなく、同社は両方を 1 つの共通基盤の上でスケジュールすることにしました。学習はアドミッションとクォータのために Kueue を通って入り、推論は vLLM または SGLang で動き、Prometheus のメトリクスに対して KEDA でスケールします。その下には、配置のための HAMi を伴う Kubernetes スケジューラーと、データセット・チェックポイント・キャッシュされた重みのための Fluid があります。潮の満ち引きのような挙動が肝心なところです。推論の需要が上がると KEDA がスケールアウトし、学習ジョブは自らチェックポイントを取ってカードを解放し、需要が下がれば再開します。同社の報告では、アクセラレーターの平均計算利用率は 35% から 60% 超へ、入力と出力を合わせた 100 万トークンあたりの推論コストは 60% 超の低下、マルチテナントでの学習密度は 5 倍、Fluid にキャッシュされた重みからの Qwen3-14B のロードは 2 秒未満でした。これらは、TTFT 5 秒以下・TPOT 50 ミリ秒以下という本番環境の目標に対する数字です。同社自身のまとめの一文は、価値は単一のコンポーネントではなくレイヤーをまたいだ協調から生まれる、というものでした。プラットフォームを買うのではなく自前で組み上げることのコストについても同様に率直で、終わりのない結合作業と互換性テストがそれにあたります。この取り組みは会期中に CNCF の End User Case Study Contest を受賞しました。

CamScanner を手がける Intsig は、同じ問題にフリート規模で直面していました。自社構築とマルチクラウドを合わせた 1 万枚規模のカード群が、1,000 を超えるオンライン推論サービスと 1,000 を超えるオフライン学習ジョブを並行して抱え、学習側は 24 時間を通して 90% を超える利用率で回っていました。制約は配置ではなく待ち時間、つまりカードの順番を待つ人でした。同社が効果を認めた実践は、まず分割し、負荷の重い処理と大規模モデルにはカード 1 枚をまるごと確保すること、半端な断片を撒き散らすのではなく部分的に使われた GPU を埋める binpack 配置、高負荷のワークロード同士が同じカードを共有しないようにするアフィニティの組み合わせ、監視のループ、そしてエラスティックなスケーリングです。これらを合わせて、GPU 利用率 50% 向上、全体コスト 30% 削減、推論性能の劣化は 10% 未満に抑制、という結果が挙げられています。

Viettel の説明がもっとも率直でした。このベトナムの通信事業者は、世代の異なる約 2,500 基の GPU をチームごとの割り当ての裏に抱えており、最上位のカード 1 枚で単一の推論サービスをフル負荷で動かしても、利用率はおよそ 10% にとどまっていました。同社の診断は、制約はこれまで一度もハードウェアではなく、割り当ての単位だった、というものです。その見立ての上に組んだ 4 層のスタックは、OpenStack Ironic と Nova でベアメタルをプロビジョニングし、Kubernetes に HAMi の分割と KEDA を加えてオーケストレーションし、vLLM、SGLang、KServe、llm-d で提供し、Envoy AI Gateway でトークンを計量します。チームはいまやサーバーを何週間も待つ代わりに、数分で API キーと OpenAI 互換のエンドポイントを受け取れます。本番のカード 1 枚で、同じワークロード・同じサービスレベルのまま、利用率は 13% から 59% に上がりました。同社はこれを原因として示し、そこから導かれるものを別に並べています。カード 1 枚あたりの処理量は 3.5 倍で、これは計測したワークロードにおいて同じスループットを得るのに必要な GPU が 71% 少ないという同じ結果の言い換えです。1 ワットあたりの処理量 2.1 倍は、それとは別に挙げられた数字です。

さらに有益だったのは、やるべきでない場面についての説明でした。共有は、リクエストのサイズが上流で制限されていてカードの 10% ほどから先へ動かない予測サービスでは 3.3 倍の効果を返しました。一方、エンジンがすでに continuous batching を行っているモデルでは 1.6 倍遅くなり、計算律速の学習では総計 0.77 倍となり、分離のためだけに意味がある、という結果でした。同社の但し書きは、これらの数字はあくまで自分たちのものだ、というものです。他所にも通用するのはワークロードの形のほうで、エンジンがすでにカードを忙しくさせているなら、共有はそれを分けるだけです。

Alibaba は同じトレードオフを、カードではなくクラスターのレイヤーで選びました。Qwen は Karmada のフェデレーションをまたいで提供されており、そこで示されたマイグレーションプランはオンラインのユニットを 1 つずつ移していきます。各ラウンドは 5 分の安定待ち時間を置き、ユニットを移す前に移行先で容量を確保し、失敗したラウンドを巻き戻せるよう元のスロットを保持し続けます。リバランサーは、スポット容量がクラスター間を移るのに合わせてバッチ推論を割り振り直します。同社の報告では、割り当て率はおよそ 15% 向上、スポット GPU の利用率はおよそ 30% 向上、これまで何日もかかっていたクラスター間の移行は数分で完了しています。

レプリカはグループになった

推論のレプリカ 1 つが必ずしも Pod 1 つではなくなっており、それがこれらのワークロードのスケジューリングを難しくしています。DaoCloud と Huawei Cloud が担当した LeaderWorkerSet (LWS) のメンテナーセッションは、モデルサイズの表を提示しました。Kimi K3 が 2.8 兆パラメータ、DeepSeek V4 Pro が 1.6 兆、GLM 5.3 が約 7,500 億です。この規模のモデルの重みはもはや 1 ノードの HBM を超える、というのがセッションの論点で、そのためレプリカ 1 つが複数マシンにまたがる Pod のグループになります。Deployment も StatefulSet も、リーダーとそのワーカーをその複製単位として表現できません。それを提供するのが LWS で、レプリカ数にグループサイズを掛けた構成、注入されるリーダーのアドレス、そして 1 つの Pod が落ちたときに既定でグループ全体を作り直す再起動ポリシーを備えます。DisaggregatedSet はその上に位置し、1 つのサービス定義から、それぞれがすべてのロールを含むスライスを生み出します。子となる各 LWS はスライス・リビジョン・ロールで名前が付けられるため、ロールアウトの途中で新しい prefill が古い decode と話し続けることがありません。その下で起こる破綻の仕方ははっきりしています。これらの Pod を個別にスケジュールすると、GPU のスロットがすべてリーダーで埋まり、どのレプリカも ready にならないという事態が起こり得ます。Volcano は LWS のグループを PodGroup にすることでこれに答えており、グループは 1 つの単位としてまとめて受け入れられるか、まったく受け入れられないかのどちらかになります。scheduler-plugins の coscheduler も同じ方式を取り、YuniKorn は自前のタスクグループで同じ結果に到達します。

Huawei は同じ構造をコンシューマー向けアシスタントに持ち込みました。同社の Celia アシスタントを支える推論プレーンは 3 段の入れ子になっています。ModelServing がサービンググループを保持し、各グループがロールを保持するため、マルチモーダルモデルは vit、prompt、decode の各ロールをそれぞれ異なる Pod 構成で、一定の比率を保ちながら動かせます。Gang ポリシーは Volcano の PodGroup にコンパイルされ、トポロジーポリシーは prefill と decode を同じラックに固定し、比率制約は各ロールが自分のメトリクスでスケールするあいだ prefill と decode の比を 1 から 3 のあいだに保ちます。押さえておく価値のある細部はエビクション保護でした。バリデーティング Webhook が、Kubernetes 標準の PodDisruptionBudget の手前で論理ユニットごとに確認し、単一のグループがそのロールの唯一のインスタンスを抱えている場合、運用者が介入するか容量を追加するまでエビクションは拒否されます。NPU 利用率は 30.1% から 40.7% へ、NPU リソースの運用自動化率は 63% から 87% へ動きました。Huawei のものではなく Volcano コミュニティのプロジェクトである Kthena ルーターは、llm-d の KV キャッシュを考慮したルーティングと 7 つの構成で比較され、負けた分も示されています。2 つはすべての指標でベースラインを下回り、2 つは TTFT でのみ負け、上位 3 つは 6 項目すべてで改善し、もっとも良いものはリクエストスループット 25.1% 向上、TTFT 23.8% 低減に達しました。

AI の話ではなかったレイヤー

Samsung SDS は同じ問いを物理レイヤーに持ち込みました。同社はヘテロジニアスなベアメタルと VM のインフラをサービスとして 17 のクラウドデータセンターから提供し、40 か国で事業を展開していますが、新しい製品はそのたびに同じアンダーレイクラスターへ着地し続けていました。コストになっていたのはオブジェクトの数ではなく、結合でした。1 つのノードが Multus と Calico と OVN を同時に動かし、CSI ドライバーが 2 つ、コンテナランタイムが 2 つ載り、分離は Namespace 止まりという状態です。Kubernetes とドライバーのバージョンは一緒に動くため、1 回のバージョン更新が全面的な再検証を意味し、あるワークロードのデータプレーン障害が他のワークロードを道連れにしました。同社の答えは、アンダーレイを目的別のクラスターに分割し、数多く運用するコストを Cluster API で引き受けることでした。目的別クラスターのコントロールプレーンは、etcd も含めて共有のコントロールクラスター上に Pod として動き、互いに経路のない 2 つのオーバーレイネットワークのあいだを Konnectivity が API サーバーのトラフィックのトンネルでつなぎます。バージョンと CNI はクラスターごとに選べるようになります。この構成が会期中の他のセッションとつながるのは、それが何を可能にするかという点です。ノードの構成が宣言的であるため、1 回のコミットで空いているクラスターから混んでいるクラスターへノードが移ります。同社が示したユースケースは日次のサイクルで、業務時間帯は GPU を推論へ、夜間は学習へ寄せるというものでした。そこに添えられた経済の説明は率直で、遊んでいるノードは代金を払ったのに何も稼がないハードウェアであり、利用率こそが利益率だ、というものです。

持ち帰る価値のあるテーマ

実際に手を動かす価値があるのは 4 つです。1 つ目は、買い増す前に本番負荷のもとでカード 1 枚が実際に何を出せているかを測ること。壇上のチームのうち 3 社はおよそ 10% から 35% のあたりから始めており、そのうちもっとも明確に語った 1 社は、何も買い足さずにそこを抜け出しています。2 つ目は、予算より先に割り当ての単位を変えること。HAMi によるカードの分割でも、LeaderWorkerSet によるリーダーとワーカーのグループでも、サービンググループ内のロールでも、クラスター間を移るノードでも構いません。3 つ目は、共有を前提にせず試すこと。Viettel の 3 つの結果、つまりカードを埋めきれないワークロードでの 3.3 倍、すでに埋められるワークロードでの 1.6 倍の悪化、計算律速の学習での総計 0.77 倍は、同じ問いを 3 つの形のワークロードに投げかけたものであり、答えを決めるのはエンジンがすでにカードを忙しくさせているかどうかです。4 つ目は、推論がすでに複数ノードにまたがっているなら、後から付け足すのではなく、いまグループ単位のワークロード API と Gang スケジューリングへ移ること。prefill と decode の分離は、DisaggregatedSet と Huawei の ModelServing において、LeaderWorkerSet が与えるものの上に、それ自体が 1 つの API 面になっているからです。上海で効いたレバーは割り当てだけではなく、キャッシュ、圧縮、ルーティングもそれぞれ大きな成果を生んでいましたが、繰り返し現れたのは割り当てであり、そのすべての下にある資源はアクセラレーターの時間です。