AI・生成AIGoogleがRed Hat・IBMと育てた推論基盤「llm-d 1.0」は何を解決するのか。500人超が加わったオープンソースの中身を確かめる
AIエージェントの急増で限界を迎えた推論サーバーに、オープンソースの新しい答え——500人超のコミュニティが作った枠組みを一次資料で確かめた
まず初めに
AIエージェントが増えた結果、サーバーの中はまるで渋滞する高速道路だ。同じ計算を何度もやり直し、メモリは重複データで埋まり、一つのわがままな処理が他の全員を待たせる。そこに現れたのが、交通整理の専門家「llm-d」というわけだ。しかも面白いのは、ライバル同士のはずのGoogleとRed Hat・IBMが手を組んで作ったという点。普段は別々の道を走っている会社が、渋滞だけは一緒に解消しようとする——需要が大きすぎる時だけ、業界は仲良くなれるものらしい。
※個人の感想です
何が起きているのか
Google(著者:AI・コンピューティング基盤担当VP兼GMのMark Lohmeyer氏、プロダクトマネージャーのSean Horgan氏)は2026年10月20日、PyTorch Conferenceにおいて、AIの推論(学習済みのAIモデルに入力を与えて結果を出力させる処理)を、複数のサーバーにまたがって分散処理するためのオープンソースソフトウェア「llm-d 1.0」を発表しました。llm-dは、Googleが Red Hat・IBMなどと共同で立ち上げたプロジェクトで、Cloud Native Computing Foundation(CNCF、Kubernetesなどを管理する非営利団体)のSandboxプロジェクトとして、25以上の組織から500人超の開発者が参加しているとされています。AIモデルを実際に動かす「PyTorch」系のコミュニティ(vLLM・SGLangといった推論エンジン)と、分散システムを本番環境で動かす「Kubernetes」系のコミュニティを結びつけるプロジェクトだと説明されています。
Googleによれば、1年前のAI利用は「1回の質問に1回の回答」を返すチャット形式が中心でしたが、現在は複数の処理やツールを組み合わせて動く「AIエージェント」や、AIの学習手法の一つである強化学習(RL)の試行が増えており、これらは長い前提文脈を共有しながら、ツールをまたいで処理が広がり、利用がバーストする(短時間に集中する)という特徴があります。1台のサーバーや、単純にリクエストを振り分けるだけの仕組み(ラウンドロビン型の負荷分散)でこれを処理すると、同じ入力内容の計算を複数のサーバーがそれぞれやり直してしまったり、計算用メモリ(アクセラレータメモリ)が重複したデータで埋まったり、一つの処理の集中(バースト)が他の利用者の応答を止めてしまったりする問題が起きるとされています。PyTorch Conferenceの基調講演では、Google Kubernetes Engine(GKE)上で1,000体のAIエージェントが、vLLM・SGLangという推論エンジンとTPU・GPUが混在する環境に対して、1つのllm-dの受付口(エンドポイント)にアクセスする実演が行われたと説明されています。
llm-d 1.0が新たに加えた機能として、優先度や公平性を踏まえて処理を振り分ける「マルチテナントQoS」、複数のクラウド・ハードウェアで検証済みの安定したAPI基盤、システムを止めずに更新できる「ルーターの高可用性」と「ゼロダウンタイム更新」、AIエージェントの一連のやり取り(セッション)を意識した振り分け機能、そしてGoogle製のAIチップ「TPU」向けに、PyTorchのモデルをそのまま動かせる「TorchTPU」との連携強化が挙げられています。公開されている性能検証では、GoogleのAIチップ「Ironwood(TPU 7世代)」を使ったコーディング向けのAIエージェント処理で、最初の応答が返るまでの時間(TTFT)の中央値が85%以上短縮され、全体の処理能力(スループット)が2.4倍になったとされています(2026年10月時点の検証)。また、GoogleのAIサービス「Geminiプラットフォーム」(旧Vertex AI)の実運用では、繰り返し使う処理結果を再利用できる割合(プレフィックスキャッシュのヒット率)が35%から70%へ向上し、コーディング用AIエージェントの最初の応答時間が35%以上短縮されたと報告されています。導入企業の例として、Snap社はキャッシュ再利用率を75〜80%まで高めたとコメントし、AI企業のMistralは、優先度に応じて処理を割り振る仕組みを使い、料金プランごとの応答速度の基準(SLO)を守るために活用しているとコメントしています。
なぜ重要なのか
この発表が重要な理由は、AIの使われ方が「チャット」から「AIエージェント」中心に移り変わる中で、その裏側を支える基盤技術そのものが、特定の1社が独占する仕組みではなく、オープンソースとして共同開発される形で整備されつつある、という点です。llm-dは、GoogleのクラウドだけでなくKubernetesが動く環境であれば利用できるよう設計されており、特定のクラウド事業者に縛られずにAIエージェントの基盤を構築したい企業にとっての選択肢になります。
もう一つの重要な点は、競合関係にあるはずの企業同士が、AI基盤の土台部分では協力していることです。Googleが主導し、Red Hat・IBMが共同で立ち上げ、MistralのようなAIモデル開発企業も開発に参加しています。AIモデルそのものの開発競争とは別に、それを動かすための基盤技術では協力関係を築く、という業界の構図が見えてくる発表です。
私たちへの影響
今回の発表で直接の対応が必要になるのは、自社でAIモデルを運用し、推論基盤を自前で構築・管理している企業の開発者・運用担当者です。発表によれば、llm-dはKubernetesの標準的な部品(Gateway API・Prometheusなど)の上に構築されており、既存のvLLMなどの推論エンジンの前段に段階的に導入できるとされています。
一般の消費者が直接何かの対応を取る必要はありません。ただし、普段利用しているAIチャットサービスやAIエージェント機能が「応答が速くなった」「混雑時にも安定して使えるようになった」と感じる場面があれば、こうした裏側の基盤技術の改善が一因になっている可能性があります。
初心者が知っておくべきこと
推論とは、学習済みのAIモデルに実際の入力(質問や指示)を与えて、結果(回答)を出力させる処理のことです。AIモデルを新しく学習させる「学習」とは区別される工程で、私たちが普段チャットAIを使うときに裏側で行われているのは、基本的にこの推論処理です。
「オープンソース」とは、ソフトウェアの設計図(ソースコード)を公開し、誰でも自由に使ったり、改良に参加したりできるようにする開発の形式のことです。llm-dのように、複数の企業・組織が共同でオープンソースのプロジェクトを育てることで、特定の1社に依存せずに技術を発展させていく、という進め方が業界では一般的に行われています。
IT Postの見方——基盤の共有は、誰の負担を減らすのか
IT Postは、AIエージェントの普及によって生じる基盤側の課題を、特定企業の独占技術ではなくオープンソースとして解決しようとする今回の動きは、長期的には多くの企業にとって有益だと考えます。特に、Googleのクラウドを使っていない企業や、自前のデータセンターでAIを運用する企業にとっても、同じ基盤技術の恩恵を受けられる可能性がある点は評価できる部分です。
一方で、IT Postでは、現時点でllm-dの改善効果を具体的な数字で示しているのは、Snap・Mistral・ZenteiQといった、相応の技術力と規模を持つ企業である点には留意が必要だと考えます。分散推論基盤の構築・運用には専門的な知識と計算資源が必要であり、中小規模の開発者・企業がこの技術の恩恵をどこまで実感できるかは、今回の発表だけでは見えてきません。オープンソースであることは参入のハードルを下げる一歩ですが、実際に使いこなせるかどうかは別の課題として残る、とIT Postは考えます。
※個人の感想です
今後どうなりそうか
発表では、llm-dの開発チームが、ベンチマーク結果を比較できるダッシュボード「Prism」や、GitHub上でのコミュニティ参加を呼びかけています。今後、どの程度の企業・組織がllm-dを採用し、Google以外のクラウド事業者やオンプレミス環境でどこまで普及するのかは、発表時点では明らかになっていません。IT Postでは、この分散推論基盤がAIエージェントの普及とともにどこまで業界標準になっていくか、あらためて確認していきます。