Agent Development Kit（ADK）とセルフホスト LLM を使用して GKE にエージェント AI アプリケーションをデプロイする

Autopilot Standard

このチュートリアルでは、Google Kubernetes Engine（GKE）を使用してコンテナ化されたエージェント AI/ML アプリケーションをデプロイして管理する方法について説明します。Google Agent Development Kit（ADK）と、vLLM によってサービングされる Llama 3.1 などのセルフホスト型大規模言語モデル（LLM）を組み合わせることで、モデルスタックを完全に制御しながら、AI エージェントを効率的かつ大規模に運用できます。このチュートリアルでは、GPU アクセラレーションを備えた GKE Autopilot クラスタで、Python ベースのエージェントを開発から本番環境へのデプロイまで行うエンドツーエンドのプロセスについて説明します。

このチュートリアルは、エージェント AI/ML アプリケーションのサービングに Kubernetes コンテナ オーケストレーション機能を使用することに関心がある ML エンジニア、デベロッパー、クラウド アーキテクトを対象としています。 Google Cloudのコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

注: このチュートリアルのアプローチでは、LLM を実行するために GPU ハードウェアを備えた GKE クラスタをプロビジョニングする必要があります。これは、モデル推論が Google のマネージド インフラストラクチャによって処理される Vertex AI のアプローチとは異なります。Vertex AI のアプローチの詳細については、ADK と Vertex AI を使用して GKE にエージェント AI アプリケーションをデプロイするをご覧ください。

始める前に、次の内容を理解しておいてください。

• GKE
• Docker を使用したコンテナ化

背景

このセクションでは、このチュートリアルで使用されている重要なテクノロジーについて説明します。

Agent Development Kit（ADK）

Agent Development Kit（ADK）は、AI エージェントの開発とデプロイ用に設計された、柔軟性の高いモジュラー フレームワークです。ADK は Gemini と Google エコシステム向けに最適化されていますが、特定のモデルやデプロイを使用する必要はなく、他のフレームワークとの互換性を考慮して構築されています。ADK は、エージェント開発をソフトウェア開発のように感じられるように設計されており、デベロッパーが基本的なタスクから複雑なワークフローまで、さまざまなエージェント アーキテクチャを簡単に作成、デプロイ、オーケストレーションできるようにします。

詳細については、ADK のドキュメントをご覧ください。

GKE マネージド Kubernetes サービス

Google Cloud には、AI/ML ワークロードのデプロイと管理に適した GKE など、さまざまなサービスが用意されています。GKE は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を簡素化するマネージド Kubernetes サービスです。GKE は、LLM のコンピューティング需要を処理するために必要なインフラストラクチャ（スケーラブルなリソース、分散コンピューティング、効率的なネットワーキングなど）を提供します。

Kubernetes の主なコンセプトについて詳しくは、Kubernetes の学習を開始するをご覧ください。GKE の詳細と、GKE が Kubernetes のスケーリング、自動化、管理にどのように役立つかについては、GKE の概要をご覧ください。

vLLM

vLLM は、GPU のサービング スループットを向上できる、高度に最適化されたオープンソースの LLM サービング フレームワークであり、次のような機能を備えています。

• PagedAttention による Transformer の実装の最適化
• サービング スループットを全体的に向上させる連続的なバッチ処理
• 複数の GPU でのテンソル並列処理と分散サービング。

詳細については、vLLM のドキュメントをご覧ください。

目標

このチュートリアルでは、次の方法を説明します。

1. Google Cloud 環境を設定します。
2. GPU 対応の GKE クラスタをプロビジョニングします。
3. vLLM 推論サーバーを使用して Llama 3.1 モデルをデプロイします。
4. ADK ベースのエージェントのコンテナ イメージをビルドします。
5. エージェントを GKE クラスタにデプロイし、セルフホスト LLM に接続します。
6. デプロイしたエージェントをテストします。

アーキテクチャ

このチュートリアルでは、GKE にエージェント AI アプリケーションをデプロイするためのスケーラブルなアーキテクチャについて説明します。ADK エージェント アプリケーションは標準 CPU ノードプールで実行され、セルフホスト LLM（vLLM の Llama 3.1）は GPU 対応ノードプールで実行されます。どちらも同じ GKE クラスタ内にあります。このアーキテクチャでは、エージェントのアプリケーション ロジックが LLM 推論ワークロードから分離されるため、各コンポーネントを個別にスケーリングして管理できます。

図 1: GKE にエージェント AI をデプロイするためのスケーラブルなアーキテクチャ。

このアーキテクチャには 2 つのコア コンポーネントがあり、それぞれ独自の GKE Deployment にあります。

• ADK エージェント アプリケーション: エージェントのカスタムビルドのビジネス ロジックとツール（get_weather など）がコンテナ イメージにあります。イメージは標準の CPU ノードプールで実行され、内部 Kubernetes サービスを使用して LLM と通信します。

• セルフホスト LLM（vLLM 上の Llama 3.1）: Llama 3.1 モデルは、GPU 対応のノードプール上の専用 vLLM サーバーで実行されます。このデプロイでは、コンテナの起動時に Hugging Face から指定されたモデルをダウンロードして提供するように構成されたパブリック コンテナ イメージ（vllm/vllm-openai:v0.8.5）を使用します。エージェントは、vllm-llama3-service Kubernetes サービスによって公開された REST API を介してこのサーバーと通信します。

ADK エージェントと vLLM デプロイは、同じ GKE クラスタで実行されます。単一クラスタ内のこのコロケーションにより、ネットワーキング、管理、デプロイが簡素化され、アプリケーションのコンポーネントに専用のハードウェアを割り当てることができます。

費用

このチュートリアルでは、課金対象である次の Google Cloudコンポーネントを使用します。

• GKE
• Artifact Registry
• Cloud Build

各サービスの料金を確認して、発生する可能性のある費用を把握します。

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the required APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the required APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

• Make sure that you have the following role or roles on the project: roles/container.admin, roles/iam.serviceAccountAdmin, roles/artifactregistry.admin, roles/cloudbuild.builds.editor, roles/resourcemanager.projectIamAdmin

  Check for the roles

  1. In the Google Cloud console, go to the IAM page.

     Go to IAM
  2. Select the project.

  3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

  4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

  Grant the roles

  1. In the Google Cloud console, go to the IAM page.

     IAM に移動
  2. プロジェクトを選択します。
  3. [ アクセスを許可] をクリックします。

  4. [新しいプリンシパル] フィールドに、ユーザー ID を入力します。 これは通常、Google アカウントのメールアドレスです。

  5. [ロールを選択] リストでロールを選択します。
  6. 追加のロールを付与するには、 [別のロールを追加] をクリックして各ロールを追加します。
  7. [保存] をクリックします。
  8. Hugging Face から読み取りアクセス トークンを取得して、Llama モデルをダウンロードします。また、Llama 3.1 モデルへのアクセス権もリクエストする必要があります。

  環境を準備する

  このチュートリアルでは、Cloud Shell を使用して Google Cloudでホストされているリソースを管理します。Cloud Shell には、kubectl、terraform、Google Cloud CLI など、このチュートリアルに必要なソフトウェアがプリインストールされています。

  Cloud Shell を使用して環境を設定するには、次の操作を行います。

  1. Google Cloud コンソールで Cloud Shell セッションを起動し、 [Cloud Shell をアクティブにする] をクリックします。このアクションにより、 Google Cloud コンソール ペインでセッションが起動します。

  2. デフォルトの環境変数を設定します。

     gcloud config set project PROJECT_ID
     export GOOGLE_CLOUD_REGION=REGION
     export PROJECT_ID=PROJECT_ID
     

     次の値を置き換えます。

     • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
     • REGION: GKE クラスタ、Artifact Registry、その他のリージョン リソースをプロビジョニングする Google Cloud リージョン（us-east4 など）。L4 GPU と G2 マシンタイプ インスタンスをサポートするリージョンを指定してください。リージョンの可用性を確認するには、Compute Engine ドキュメントの GPU のリージョンとゾーンをご覧ください。

  サンプル プロジェクトのクローンを作成する

  1. Cloud Shell ターミナルから、チュートリアルのサンプルコード リポジトリのクローンを作成します。

     git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples.git
     

  2. チュートリアル ディレクトリに移動します。

     cd kubernetes-engine-samples/ai-ml/adk-vllm
     

  Google Cloud リソースを作成して構成する

  エージェントをデプロイするには、まず必要な Google Cloudリソースをプロビジョニングする必要があります。GKE クラスタと Artifact Registry リポジトリは、gcloud CLI または Terraform を使用して作成できます。

  gcloud

  このセクションでは、GKE クラスタと Artifact Registry を設定する gcloud CLI コマンドについて説明します。

  1. GKE クラスタを作成する: コンテナ化されたエージェント アプリケーションは、GKE Autopilot クラスタまたは GKE Standard クラスタにデプロイできます。フルマネージドの Kubernetes エクスペリエンスを実現するには、Autopilot クラスタを使用します。ワークロードに最適な GKE の運用モードを選択するには、GKE の運用モードについてをご覧ください。

     Autopilot

     Cloud Shell で、次のコマンドを実行します。

     gcloud container clusters create-auto CLUSTER_NAME \
         --location=$GOOGLE_CLOUD_REGION
     

     CLUSTER_NAME を GKE クラスタの名前に置き換えます。

     Autopilot では、GKE はワークロードのリソース リクエストに基づいてノードを自動的にプロビジョニングします。LLM に必要な GPU は、nodeSelector を使用して deploy-llm.yaml マニフェストでリクエストされます。

     nodeSelector リクエストを nvidia-l4 GPU に追加する手順は次のとおりです。

     1. エディタで kubernetes-engine-samples/ai-ml/adk-vllm/deploy-llm/deploy-llm.yaml を開きます。

     2. spec.template.spec の下に次の nodeSelector を追加します。

        nodeSelector:
        cloud.google.com/gke-accelerator: nvidia-l4
        

     標準

     1. Cloud Shell で、次のコマンドを実行して Standard クラスタを作成します。

        gcloud container clusters create CLUSTER_NAME \
            --location=$GOOGLE_CLOUD_REGION
        

        CLUSTER_NAME は、GKE クラスタの名前に置き換えます。

     2. 次のコマンドを実行して、クラスタの GPU 対応のノードプールを作成します。

        gcloud container node-pools create gpu-node-pool \
            --cluster=CLUSTER_NAME \
            --location=$GOOGLE_CLOUD_REGION \
            --machine-type=g2-standard-8 \
            --accelerator=type=nvidia-l4,count=1 \
            --enable-gvnic
        

        deploy-llm.yaml ファイルは、G2 マシンシリーズで使用可能な nvidia-l4 GPU を指定します。このマシンタイプの詳細については、Compute Engine ドキュメントの GPU マシンタイプをご覧ください。

  2. Artifact Registry リポジトリを作成する: エージェントの Docker コンテナ イメージを安全に保存して管理するための Artifact Registry リポジトリを作成します。

     gcloud artifacts repositories create REPO_NAME \
         --repository-format=docker \
         --location=$GOOGLE_CLOUD_REGION
     

     REPO_NAME は、使用する Artifact Registry リポジトリの名前（adk-repo など）に置き換えます。

  3. リポジトリの URL を取得する: リポジトリの完全パスを確認するには、次のコマンドを実行します。この形式は、エージェント イメージをビルドするときに Docker イメージにタグを付けるために使用します。

     gcloud artifacts repositories describe REPO_NAME \
         --location $GOOGLE_CLOUD_REGION
     

  Terraform

  このセクションでは、サンプル リポジトリに含まれている Terraform 構成を使用して Google Cloud リソースを自動的にプロビジョニングする方法について説明します。

  1. Terraform ディレクトリに移動します: \terraform ディレクトリには、GKE クラスタとその他の必要なリソースを作成するために必要なすべての構成ファイルが含まれています。

     cd terraform
     

  2. Terraform 変数ファイルを作成する: 提供された変数ファイル（example_vars.tfvars）の例をコピーして、独自の vars.tfvars ファイルを作成します。

     cp example_vars.tfvars vars.tfvars
     

     エディタで vars.tfvars ファイルを開き、プレースホルダ値を特定の構成に置き換えます。少なくとも、PROJECT_ID は Google Cloud プロジェクト ID に、CLUSTER_NAME は GKE クラスタの名前に置き換える必要があります。

  3. Terraform を初期化する: Google Cloudに必要なプロバイダ プラグインをダウンロードするには、このコマンドを実行します。

     terraform init
     

  4. 実行プランを確認する: このコマンドは、Terraform が行うインフラストラクチャの変更を示します。

     terraform plan -var-file=vars.tfvars
     

  5. 構成を適用する: Google Cloud プロジェクトにリソースを作成するには、Terraform プランを実行します。メッセージが表示されたら、yes で確定します。

     terraform apply -var-file=vars.tfvars
     

  これらのコマンドを実行すると、Terraform は GKE クラスタと Artifact Registry リポジトリをプロビジョニングし、Workload Identity Federation for GKE を含む必要な IAM ロールとサービス アカウントを構成します。

  Terraform の使用方法の詳細については、Terraform を使用して GKE リソースをプロビジョニングするをご覧ください。

  クラスタと通信を行うように kubectl を構成します。

  クラスタと通信するように kubectl を構成するには、次のコマンドを実行します。

  gcloud container clusters get-credentials CLUSTER_NAME \
      --location=${GOOGLE_CLOUD_REGION}
  

  CLUSTER_NAME を GKE クラスタの名前に置き換えます。

  エージェント イメージをビルドする

  gcloud CLI または Terraform を使用してインフラストラクチャを作成したら、次の手順に沿ってエージェント アプリケーションをビルドします。

  1. Cloud Build に必要な IAM ロールを付与する: Cloud Build サービスには、エージェントのコンテナ イメージを Artifact Registry に push する権限が必要です。Cloud Build で使用される Compute Engine のデフォルト サービス アカウントに roles/artifactregistry.writer ロールを付与します。

     1. Compute Engine のデフォルト サービス アカウントのメールアドレスを作成します。

        export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
        export COMPUTE_SA_EMAIL=${PROJECT_NUMBER}[e-mail]
        

     2. サービス アカウントに roles/artifactregistry.writer ロールを付与します。

        gcloud projects add-iam-policy-binding $PROJECT_ID \
            --member=serviceAccount:${COMPUTE_SA_EMAIL} \
            --role=roles/artifactregistry.writer
        

  2. エージェント コンテナ イメージをビルドして push する: プロジェクトのルート ディレクトリ（adk/llama/vllm）から、次のコマンドを実行して Docker イメージをビルドし、Artifact Registry に push します。

     export IMAGE_URL="${GOOGLE_CLOUD_REGION}-docker.pkg.dev/${PROJECT_ID}/REPO_NAME/adk-agent:latest"
     gcloud builds submit --tag $IMAGE_URL
     

  3. イメージが push されたことを確認する: ビルドプロセスが正常に完了したら、リポジトリ内のイメージを一覧表示して、エージェントのコンテナ イメージが Artifact Registry に push されたことを確認します。

     gcloud artifacts docker images list ${GOOGLE_CLOUD_REGION}-docker.pkg.dev/${PROJECT_ID}/REPO_NAME
     

     push して latest としてタグ付けしたイメージが一覧表示された出力が表示されます。

  モデルをデプロイする

  GKE クラスタを設定してエージェント イメージをビルドしたら、次のステップはセルフホストの Llama 3.1 モデルをクラスタにデプロイすることです。これを行うには、Hugging Face からモデルを pull し、クラスタ内で内部的に提供する事前構成済みの vLLM 推論サーバーをデプロイします。

  1. Hugging Face の認証情報用の Kubernetes Secret を作成する: GKE クラスタがゲート付きの Llama 3.1 モデルをダウンロードできるようにするには、Hugging Face トークンを Kubernetes Secret として指定する必要があります。deploy-llm.yaml マニフェストは、認証にこのシークレットを使用するように構成されています。

     kubectl create secret generic hf-secret \
         --from-literal=hf-token-secret=HUGGING_FACE_TOKEN
     

     HUGGING_FACE_TOKEN は、実際のトークンに置き換えます。

  2. マニフェストを表示する: プロジェクトのルート ディレクトリ（adk/llama/vllm）から、モデルの Deployment マニフェストを含む /deploy-llm ディレクトリに移動します。

     cd deploy-llm
     

  3. マニフェストを適用する: 次のコマンドを実行して、deploy-llm.yaml マニフェストをクラスタに適用します。

     kubectl apply -f deploy-llm.yaml
     

     このコマンドは、次の 3 つの Kubernetes リソースを作成します。

     • meta-llama/Llama-3.1-8B-Instruct モデルを使用するように構成された vLLM サーバーを実行する Deployment。
     • 内部クラスタ IP アドレスで vLLM サーバーを公開し、ADK エージェントが通信できるようにする vllm-llama3-service という名前の Service。
     • Llama 3.1 モデルに必要な Jinja チャット テンプレートを含む ConfigMap。

  4. モデルのデプロイを確認する: vLLM サーバーは、Hugging Face からモデルファイルを pull します。この処理には数分かかることがあります。Pod のステータスをモニタリングして、準備ができていることを確認できます。

     1. Deployment が利用可能になるまで待ちます。

        kubectl wait --for=condition=available --timeout=600s deployment/vllm-llama3-deployment
        

     2. 実行中の Pod のログを表示して、サーバーが正常に起動したことを確認します。

        export LLM_POD=$(kubectl get pods -l app=vllm-llama3 -o jsonpath='{.items[0].metadata.name}')
        kubectl logs -f $LLM_POD
        

        次の例のようなログ出力が表示されたら、デプロイの準備が完了しています。これは、LLM サーバーが起動し、API ルートが使用可能になったことを示しています。

        INFO 07-16 14:15:16 api_server.py:129] Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
        

     3. モデルサーバーにリクエストを直接送信して、LLM の準備が整っていることを確認します。これを行うには、新しい Cloud Shell ターミナルを開き、次のコマンドを実行して vllm-llama3-service をローカルマシンに転送します。

        kubectl port-forward service/vllm-llama3-service 8000:8000
        

     4. 別のターミナルで、curl を使用してモデルの API エンドポイントにサンプル リクエストを送信します。次に例を示します。

        curl -X POST http://localhost:8000/v1/completions \
          -H "Content-Type: application/json" \
          -d '{
            "model": "meta-llama/Llama-3.1-8B-Instruct",
            "prompt": "Hello!",
            "max_tokens": 10
          }'
        

        コマンドが成功の JSON レスポンスを返したら、LLM の準備は完了です。これで、ターミナル ウィンドウに戻って Ctrl+C を押してポート転送プロセスを終了し、エージェントのデプロイに進むことができます。

  エージェント アプリケーションをデプロイする

  次のステップは、ADK ベースのエージェント アプリケーションをデプロイすることです。

  1. /deploy-agent ディレクトリに移動します: プロジェクトのルート ディレクトリ（adk/llama/vllm）から、エージェントのソースコードとデプロイ マニフェストを含む /deploy-agent ディレクトリに移動します。

     cd ../deploy-agent
     

  2. エージェントのデプロイ マニフェストを更新します。

     1. サンプル deploy-agent.yaml マニフェスト ファイルには、コンテナ イメージの URL にプロジェクト ID のプレースホルダが含まれています。プレースホルダは、 Google Cloud プロジェクト ID に置き換える必要があります。

        image: us-central1-docker.pkg.dev/PROJECT_ID/adk-repo/adk-agent:latest
        

        この置換をインプレースで実行するには、次のコマンドを実行します。

        sed -i "s/<PROJECT_ID>/$PROJECT_ID/g" deploy-agent.yaml
        

     2. readinessProbe パスが /dev-ui ではなく / に設定されていることを確認します。この置換をインプレースで実行するには、次のコマンドを実行します。

        sed -i "s|path: /dev-ui/|path: /|g" deploy-agent.yaml
        

  3. マニフェストを適用する: 次のコマンドを実行して、deploy-agent.yaml マニフェストをクラスタに適用します。

     kubectl apply -f deploy-agent.yaml
     

     このコマンドは、次の 2 つの Kubernetes リソースを作成します。

     • カスタムビルドのエージェント コンテナ イメージを実行する adk-agent という名前の Deployment。
     • エージェント アプリケーションを公開してテスト用にアクセスできるようにする、NodePort タイプの adk-agent という名前の Service。

  4. エージェントのデプロイを確認する: Pod のステータスを確認して、正しく実行されていることを確認します。

     1. Deployment が利用可能になるまで待ちます。

        kubectl wait --for=condition=available --timeout=300s deployment/adk-agent
        

     2. 実行中のエージェント Pod のログを表示します。

        export AGENT_POD=$(kubectl get pods -l app=adk-agent -o jsonpath='{.items[0].metadata.name}')
        kubectl logs -f $AGENT_POD
        

  次のようなログ出力が表示され、Uvicorn サーバーが実行されてリクエストを受け入れる準備ができていることを示す場合、デプロイは成功しています。

  INFO:     Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)
  

  デプロイしたエージェントをテストする

  vLLM サーバーとエージェント アプリケーションの両方を正常にデプロイしたら、エージェントのウェブ UI を操作してエンドツーエンドの機能をテストできます。

  注: このチュートリアルでは、LLM を使用してプロンプトに基づいて呼び出すツールを決定しますが、ツール自体はライブ API ではなく、わかりやすくするためにハードコードされたモックデータを使用します。エージェントの get_weather ツールは、リアルタイムの外部サービスではなく、「paris」、「ottawa」、「tokyo」の事前定義された辞書から天気情報を取得します。

  1. エージェントのサービスをローカルマシンに転送する: adk-agent サービスは NodePort タイプですが、Cloud Shell 環境からアクセスする最も直接的な方法は kubectl port-forward コマンドを使用することです。次のコマンドを実行して、エージェントの Pod への安全なトンネルを作成します。

     kubectl port-forward $AGENT_POD 8001:8001
     

  2. エージェントのウェブ UI にアクセスする: Cloud Shell で、[ウェブでプレビュー] ボタンをクリックし、[ポート 8001 でプレビュー] を選択します。新しいブラウザタブが開き、エージェントのチャット インターフェースが表示されます。

  3. エージェントと対話する: エージェントの get_weather ツールを呼び出す質問をします。次に例を示します。

     What's the weather like in Tokyo?
     

     エージェントはまず LLM を呼び出してインテントを理解し、get_weather ツールを使用する必要があるかどうかを判断します。次に、「Tokyo」をパラメータとしてツールを実行します。最後に、ツールの出力を使用してレスポンスを生成します。次のようなレスポンスが表示されます。

       The weather in Tokyo is 25°C and sunny.
     

  4. （省略可）ログでツール呼び出しを確認する: 各 Pod のログを表示することで、エージェントと LLM のやり取りやツールの実行を確認できます。

     1. エージェント Pod のログ: 新しいターミナルで、adk-agent Pod のログを表示します。ツール呼び出しとその結果が表示されます。

        kubectl logs -f $AGENT_POD
        

        出力には、ツールが呼び出され、結果が処理されていることが示されます。

     2. LLM Pod ログ: vllm-llama3-deployment Pod のログを表示して、エージェントからの受信リクエストを確認します。

        kubectl logs -f $LLM_POD
        

        ログには、エージェントが LLM に送信したプロンプトの全文が表示されます。これには、システム メッセージ、クエリ、get_weather ツールの定義が含まれます。

  テストが完了したら、ターミナル ウィンドウに戻って Ctrl+C を押して、port-forward プロセスを終了できます。

  クリーンアップ

  このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

  デプロイされたリソースを削除する

  このチュートリアルで作成したリソースについて Google Cloud アカウントに課金されないようにするには、次のコマンドを実行します。

  gcloud

  gcloud CLI を使用してリソースを作成した場合は、次のコマンドを実行して GKE クラスタと Artifact Registry リポジトリを削除し、サービス アカウントの権限を元の状態に戻します。

  gcloud container clusters delete CLUSTER_NAME \
      --location=$GOOGLE_CLOUD_REGION
  
  gcloud artifacts repositories delete REPO_NAME \
      --location=$GOOGLE_CLOUD_REGION
  
  gcloud projects remove-iam-policy-binding $PROJECT_ID \
      --member=serviceAccount:${COMPUTE_SA_EMAIL} \
      --role=roles/artifactregistry.writer
  

  Terraform

  Terraform を使用してインフラストラクチャをプロビジョニングした場合は、/terraform ディレクトリ内で 1 つのコマンドを実行して、すべてのリソースを破棄できます。

  1. プロジェクトのルート ディレクトリ（adk/llama/vllm）から /terraform ディレクトリに移動します。

     cd terraform
     

  2. このコマンドを実行して、Terraform 構成ファイルで定義されているすべてのリソースを削除します。

     terraform destroy
     

  次のステップ

  • Horizontal Pod Autoscaler（HPA）を構成して、エージェントのリソースをオンデマンドで自動的に調整する方法について説明します。
  • Google Cloudで実行されているウェブ アプリケーション用に Identity-Aware Proxy（IAP）を構成し、エージェントの UI へのアクセスに対する一元的な認可を提供する方法について説明します。
  • Cloud Logging と Cloud Monitoring を使用して、GKE クラスタ内のエージェントのパフォーマンスと健全性に関する分析情報を取得する方法を学習します。
  • GKE AI Labs で、GKE を使用してエージェント AI イニシアチブを加速するのに役立つ試験運用版のサンプルを確認する。