Ollama、GKE の GPU 共有、vCluster を使って、費用対効果の高い AI を実現する
Abdel Sghiouar
Senior Cloud Developer Advocate
Saiyam Pathak
DevRel, vCluster
※この投稿は米国時間 2026 年 3 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。
組織が AI ワークロードをスケールすると、主に 2 つの課題が浮上します。1 つは、使用率の低い GPU に費用がかさむということ、もう 1 つは、複数チームの分離環境を管理運用するのが複雑であるということです。経験則として、GPU 全体を 1 つの Pod に割り当てるのは非効率です。また一方で、チームごとに個別のクラスタを管理すると、運用上の負担が大きくなるという問題があります。
この投稿では、Google Kubernetes Engine（GKE）の GPU タイム シェアリングと、マルチ テナンシー用の vCluster を組み合わせて、この両方の問題を解決する方法を紹介します。具体的には、分離した複数の仮想環境に Ollama をデプロイしてオープンモデル（Mistral など）を提供し、これらの環境で 1 つの物理的な GPU インフラストラクチャを共有します。
アーキテクチャ: 共有ハードウェア上の仮想クラスタ
このアーキテクチャでは、GKE Autopilot を活用して物理インフラストラクチャを抽象化しています。ワークロードをデプロイすると、Autopilot が GPU やドライバなどの必要なハードウェアをオンデマンドでプロビジョニングしてくれるため、ノードの管理は不要です。
これにより複数のチームがそれぞれ分離された環境内で、API、Ollama インスタンスや、場合によっては異なるモデルを使用しながら、これらをすべて費用対効果の高い同じ共有 GPU ノードで実行することが可能となります。たとえば、チーム A（法務調査など）とチーム B（カスタマー サポートなど）が、GPU リソースを共有しながら、別々の環境で作業できます。
vCluster では、既存の Kubernetes クラスタ上に仮想 Kubernetes クラスタを作成できます。vCluster はさまざまなテナンシー モードをサポートしています。たとえば、この図に示されている共有ノードモデルでは、各仮想クラスタが独自の分離したコントロール プレーンを取得しながら、基盤となるワーカーノードを共有しています。個々の仮想クラスタには、そのクラスタへのフルアクセスを持つ管理者がアクセスでき、他のチームとの干渉は発生しません。このモデルでは、ホストクラスタ機能も適宜利用できるほか、各仮想クラスタ内に独自のコントローラや CRD をデプロイできます。
vCluster では、次のいずれかのテナンシー モードを使用できます。
-
共有ノード: このモードでは、複数の仮想クラスタが同じ物理 Kubernetes ノードでワークロードを実行できます。この構成は、リソース使用率の最大化が最優先のシナリオに最適です。特に、社内の開発環境、CI / CD パイプラインや、コスト重視のユースケースに適しています。
-
プライベート ノード: このモードでは、ホストクラスタのワーカーノードを共有せず、個々の vCluster にそれぞれワーカーノードを追加します。これらのプライベート ノードはその vCluster のワーカーノードとして機能し、同じホストクラスタ内の他の vCluster には共有されません。
-
自動ノード: ノードとリソースの要件に基づいて、ワーカーノードを自動的にプロビジョニングして追加するように vCluster を構成します。自動ノードを使用するには、vCluster Platform をインストールし、それに vCluster を接続する必要があります。
-
スタンドアロン: これは、コントロール プレーンとノードに関してアーキテクチャが異なるモードです。スタンドアロン モードでは、ホストクラスタは不要です。他の Kubernetes ディストリビューションと同様、vCluster はノードに直接デプロイされます。スタンドアロンの vCluster は、ベアメタル ノードや VM など、あらゆるタイプのノードで実行できます。コントロール プレーンやワーカーノードの共有ホストクラスタがないため、ワークロードを最も厳格に分離できます。
デプロイ
デプロイ手順に沿って進めるには、次のものがインストールされていることを確認してください。
ステップ 1: GKE Autopilot クラスタを設定して作成する
GKE Standard とは異なり、ノード数を計算したり、ノードプールを手動で構成したりする必要はありません。自動的にクラスタが作成されて、認証情報が取得されます。
-
環境変数を設定し、GKE Autopilot クラスタを作成します。
export PROJECT_ID=YOUR_PROJECT_ID
export REGION=YOUR_REGION_ID
# GKE Autopilot クラスタを作成する
gcloud container clusters create-auto vcluster-gpu-sharing \
-
--region=$REGION --project $PROJECT_ID -
YOUR_PROJECT_IDとYOUR_REGION_IDは、使用する Google Cloud プロジェクトとリージョンに置き換えます。 -
ローカルの kubectl を構成するために、認証情報を取得します。
gcloud container clusters get-credentials vcluster-gpu-sharing \
-
--region $REGION --project $PROJECT_ID
ステップ 2: 仮想クラスタ（vCluster）を作成する
Autopilot クラスタを実行すると、テナントに対して分離環境を作成できるようになります。ここでは、demo1 と demo2 の 2 つの vCluster を作成します。構成には vcluster.yaml マニフェスト ファイルが必要です。
GKE Autopilot を使用する場合、最初の vCluster の作成には数分かかることがあります。これは、独自のコントロール プレーンの Pod が稼働するのを待機するためです。Autopilot はこの新しいワークロードに対して基盤となるノードを動的にプロビジョニングするため、インフラストラクチャが初期化されるまで少々遅延が発生します。
注: vCluster を別の vCluster 内に作成しようとしているというエラー警告が表示された場合は、[no] を選択して、正しいホスト コンテキストに切り替えてください。
ステップ 3: Ollama を仮想クラスタにデプロイする
まず、Ollama のデプロイ マニフェストを作成します。このマニフェストによって Ollama をデプロイし、Kubernetes Service を使用してポート 11434 で公開します。
-
Ollama の デプロイ マニフェストを作成します。このマニフェストによって Ollama をデプロイし、Kubernetes Service を使用してポート 11434 で公開します。GPU タイム シェアリングを使用するノードを選択します。
# Ollama のデプロイ マニフェストを作成する
cat <<EOF > ollama.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: ollama
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: ollama
template:
metadata:
labels:
app: ollama
spec:
nodeSelector:
# GPU タイム シェアリングを使用するノードを選択する。
# 基盤の GPU を一定数のコンテナで共有することを
# 許可するノードを選択する。
# Nvidia L4 GPU を搭載したノードを選択する。
cloud.google.com/gke-gpu-sharing-strategy: "time-sharing"
cloud.google.com/gke-max-shared-clients-per-gpu: "5"
cloud.google.com/gke-accelerator: nvidia-l4
containers:
- name: ollama
image: ollama/ollama:latest
ports:
- containerPort: 11434
resources:
limits:
nvidia.com/gpu: 1
---
apiVersion: v1
kind: Service
metadata:
name: ollama
namespace: default
spec:
selector:
app: ollama
ports:
- port: 11434
targetPort: 11434
type: ClusterIP
-
EOF -
vCluster がアクティブになったら、コンテキストを切り替えて demo1 内で作業します。
# 仮想クラスタ demo1 に接続する
-
vcluster connect demo1 -n demo1 -
仮想環境に Ollama をデプロイします。
# デプロイ マニフェストを適用する
-
kubectl apply -f ollama.yaml -
仮想クラスタ内にいても、GPU をリクエストする Pod を作成すると、このリクエストはホストに同期されます。GKE Autopilot はこのリクエストを検出し、ワークロードを実行するノードに必要な GPU ハードウェアを自動的にアタッチします。
ステップ 4: モデルの pull とテスト
-
サーバーが実行されたら、仮想クラスタのコンテキスト内で、モデルの pull とテストを実行します。
# Pod 内で pull コマンドを実行する
-
kubectl exec -it <pod-name> -- ollama pull mistral -
API を検証します。
# Ollama サービスをポート転送する
kubectl port-forward svc/ollama 8080:11434
# 新しいウィンドウでチャット リクエストを送信する
curl -s http://localhost:8080/api/chat \
-H "Content-Type: application/json" \
-
-d '{ "model": "mistral", "stream": false, "messages": [ {"role": "user", "content": "Explain GKE Autopilot"} ] }' | jq -r '.message.content'
ステップ 5: Ollama を vCluster demo2 にデプロイする
同じ手順を繰り返して、Ollama をデプロイし、モデルを 2 つ目の仮想クラスタに pull します。
基盤となるインフラストラクチャを検証する
それでは、ホストクラスタのコンテキストに戻って、何が起こっているかを確認しましょう。
-
プロビジョニングされたノードの数と、Ollama Pod が実行されている場所を確認します。
# 利用可能なコンテキストを一覧表示する
kubectx
# ホストクラスタのコンテキストに切り替える
kubectx gke_$PROJECT_ID_$REGION_vcluster-gpu-sharing
# ノードを一覧表示する
-
Kubectl nodes -
2 つのノードが表示されるはずです。1 つは vCluster コンポーネントを実行しています。もう 1 つは、L4 GPU を使用して Ollama インスタンスを実行しています。出力は次のようになります（ノード名は異なります）。
# kubectl get nodes の出力
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
gk3-vcluster-gpu-sharing-nap-1w88cyly-895203e4-xbqk Ready <none> 7h8m v1.33.5-gke.2072000
-
gk3-vcluster-gpu-sharing-pool-2-0a984fed-7mff Ready <none> 4d v1.33.5-gke.2072000 -
Ollama Pod が実行されている場所を確認します。
# Ollama Pod を実行しているノードを確認する
kubectl get pods -n demo1 -o wide
-
kubectl get pods -n demo2 -o wide -
両方の Ollama Pod が同じノードで実行されていることに注目してください。このノードは GKE Autopilot によってプロビジョニングされ、L4 GPU と GPU 共有を使用するように構成されています。
まとめ
この例では、GKE Autopilot を使用することで、GPU ノードプールやタイム シェアリングを手動で構成せずに済んでいます。Autopilot によってリソースが動的に提供される一方で、vCluster によって、チーム A の法務調査データとチーム B のカスタマー サポートの bot が完全に分離されています。この実装方法により、AI ワークロードのスケーリングにおいて堅牢でメンテナンスの少ないプラットフォームを実現できます。
- シニア クラウド デベロッパー アドボケイト、Abdel Sghiouar
- vCluster デベロッパーリレーションズ、 Saiyam Pathak
