Lab 3: Vom Prototyp zur Produktion – ADK-Agent mit GPU in Cloud Run bereitstellen

1. Einführung

Übersicht

In diesem Lab stellen Sie einen produktionsreifen ADK-Agenten (Agent Development Kit) mit einem GPU-beschleunigten Gemma-Backend bereit. Der Schwerpunkt liegt auf kritischen Bereitstellungsmustern: Einrichten von GPU-fähigen Cloud Run-Diensten, Einbinden von Modell-Back-Ends in ADK-Agents und Beobachten des Autoscaling-Verhaltens unter Last.

Aufgaben

In diesem Lab konzentrieren Sie sich auf die kritischen Aspekte der Produktionsbereitstellung:

  1. Gemma mit GPU in Cloud Run bereitstellen – Hochleistungsfähiges Gemma-Modell-Backend einrichten
  2. Gemma-Bereitstellung in einen ADK-Agenten einbinden – Agenten mit dem GPU-beschleunigten Modell verbinden
  3. Mit der ADK-Weboberfläche testen: Prüfen Sie, ob Ihr Conversational Agent richtig funktioniert.
  4. Lasttests durchführen: Beobachten Sie, wie beide Cloud Run-Instanzen unter Last automatisch skaliert werden.

Der Schwerpunkt liegt auf Mustern für die Produktionsbereitstellung und nicht auf der Entwicklung umfangreicher Agents.

Lerninhalte

  • GPU-beschleunigte Gemma-Modelle für die Produktion in Cloud Run bereitstellen
  • Externe Modellbereitstellungen in ADK-Agents einbinden
  • Produktionsreife KI-Agent-Bereitstellungen konfigurieren und testen
  • Autoscaling-Verhalten von Cloud Run bei Last verstehen
  • Beobachten, wie mehrere Cloud Run-Instanzen bei Trafficspitzen zusammenarbeiten
  • Lasttests zur Validierung von Leistung und Autoscaling durchführen

2. Projekt einrichten

  1. Wenn Sie noch kein Google-Konto haben, müssen Sie ein Google-Konto erstellen.
    • Verwenden Sie stattdessen ein privates Konto. Bei Arbeitskonten und Konten von Bildungseinrichtungen kann es Einschränkungen geben, die verhindern, dass Sie die für dieses Lab erforderlichen APIs aktivieren.
  2. Melden Sie sich in der Google Cloud Console an.
  3. Aktivieren Sie die Abrechnung in der Cloud Console.
    • Die Kosten für Cloud-Ressourcen für dieses Lab sollten weniger als 1 $betragen.
    • Sie können die Schritte am Ende dieses Labs ausführen, um Ressourcen zu löschen und so weitere Kosten zu vermeiden.
    • Neuen Nutzern steht die kostenlose Testversion mit einem Guthaben von 300$ zur Verfügung.
  4. Erstellen Sie ein neues Projekt oder wählen Sie ein vorhandenes Projekt aus.

3. Cloud Shell-Editor öffnen

  1. Klicken Sie auf diesen Link, um direkt zum Cloud Shell-Editor zu gelangen.
  2. Wenn Sie heute an irgendeinem Punkt zur Autorisierung aufgefordert werden, klicken Sie auf Autorisieren, um fortzufahren. Klicken Sie, um Cloud Shell zu autorisieren.
  3. Wenn das Terminal nicht unten auf dem Bildschirm angezeigt wird, öffnen Sie es:
    • Klicken Sie auf Ansehen.
    • Klicken Sie auf TerminalNeues Terminal im Cloud Shell-Editor öffnen.
  4. Legen Sie im Terminal Ihr Projekt mit diesem Befehl fest:
    • Format:
      gcloud config set project [PROJECT_ID]
    • Beispiel:
      gcloud config set project lab-project-id-example
    • Wenn Sie sich nicht an Ihre Projekt-ID erinnern können:
      • Sie können alle Ihre Projekt-IDs mit folgendem Befehl auflisten:
        gcloud projects list | awk '/PROJECT_ID/{print $2}'
      Projekt-ID im Cloud Shell Editor-Terminal festlegen
  5. Es sollte folgende Meldung angezeigt werden:
    Updated property [core/project].
    Wenn Sie WARNING sehen und Do you want to continue (Y/n)? gefragt werden, haben Sie die Projekt-ID wahrscheinlich falsch eingegeben. Drücken Sie n, dann Enter und versuchen Sie, den Befehl gcloud config set project noch einmal auszuführen.

4. APIs aktivieren und Standardregion festlegen

Bevor wir Cloud Run-Dienste mit GPU-Unterstützung bereitstellen können, müssen wir die erforderlichen Google Cloud-APIs aktivieren und die Projekteinstellungen konfigurieren.

  1. Aktivieren Sie die APIs im Terminal:
gcloud services enable \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  aiplatform.googleapis.com

Wenn Sie zur Autorisierung aufgefordert werden, klicken Sie auf Autorisieren, um fortzufahren. Klicken Sie, um Cloud Shell zu autorisieren.

Es kann einige Minuten dauern, bis dieser Befehl ausgeführt wird. Wenn die Ausführung erfolgreich war, erhalten Sie eine Meldung, die ungefähr so aussieht:

Operation "operations/acf.p2-73d90d00-47ee-447a-b600" finished successfully.
  1. Legen Sie Ihre standardmäßige Cloud Run-Region fest.
gcloud config set run/region europe-west1

5. Python-Projekt vorbereiten

Richten wir den Startcode ein, der die grundlegende Struktur für unseren Gemma-Backend- und ADK-Agent-Dienst enthält.

  1. Klonen Sie das Starter-Repository:
    cd ~
git clone https://github.com/amitkmaraj/accelerate-ai-lab3-starter.git
cd accelerate-ai-lab3-starter
  2. Sehen Sie sich die Projektstruktur an:
    ls -R
    Sie sollten die folgende Startstruktur sehen:
    accelerate-ai-lab3-starter/
├── README.md                    # Project overview
├── ollama-backend/              # Ollama backend (separate deployment)
│   └── Dockerfile               # Backend container (🚧 to implement)
└── adk-agent/                   # ADK agent (separate deployment)
    ├── pyproject.toml           # Python dependencies (✅ completed)
    ├── server.py                # FastAPI server (🚧 to implement)
    ├── Dockerfile               # Container config (🚧 to implement)
    ├── load_test.py             # Load testing (🚧 to implement)
    └── production_agent/        # Agent implementation
        ├── __init__.py         # Package init (✅ completed)
        └── agent.py            # Agent logic (🚧 to implement)

6. Überblick über die Architektur

Bevor wir mit der Implementierung beginnen, sehen wir uns die Architektur mit zwei Diensten an:

Lab 3: Architektur mit zwei Diensten

Wichtige Erkenntnis: Während des Lasttests werden beide Dienste unabhängig voneinander skaliert. Das GPU-Back-End (Engpassdienst) wird für die Inferenzlast auf 1–3 Instanzen skaliert, während der ADK-Agent für die Verarbeitung von Anfragen bei 1 Instanz bleibt.

7. Gemma-Backend in Cloud Run mit GPU bereitstellen

Lab 3: Gemma-Dienst

Der erste wichtige Schritt ist die Bereitstellung eines GPU-beschleunigten Gemma-Modells, das als Gehirn für Ihren ADK-Agenten dient. Ein entkoppeltes, bereitgestelltes LLM kann in Architekturen von Vorteil sein, in denen Sie ein separates, feinabgestimmtes Modell oder eine isolierte Skalierung benötigen.

  1. Wechseln Sie zum Ollama-Backend-Verzeichnis:
    cd ollama-backend
  2. Öffnen Sie das Ollama-Dockerfile und implementieren Sie es:
    cloudshell edit Dockerfile
    Ersetzen Sie den TODO-Kommentar durch:
    FROM ollama/ollama:latest

# Listen on all interfaces, port 8080
ENV OLLAMA_HOST 0.0.0.0:8080

# Store model weight files in /models
ENV OLLAMA_MODELS /models

# Reduce logging verbosity
ENV OLLAMA_DEBUG false

# Never unload model weights from the GPU
ENV OLLAMA_KEEP_ALIVE -1

# Store the model weights in the container image
ENV MODEL gemma3:270m
RUN ollama serve & sleep 5 && ollama pull $MODEL

# Start Ollama
ENTRYPOINT ["ollama", "serve"]
    🔧 Was passiert hier?
    • Verwendet das offizielle Ollama-Image als Grundlage
    • Legt OLLAMA_HOST fest, um Verbindungen von jeder IP-Adresse zu akzeptieren.
    • Port 8080 wird freigegeben.
  3. Gemma-Backend mit GPU-Unterstützung bereitstellen:
gcloud run deploy ollama-gemma3-270m-gpu \
  --source . \
  --region europe-west1 \
  --concurrency 4 \
  --cpu 8 \
  --set-env-vars OLLAMA_NUM_PARALLEL=4 \
  --gpu 1 \
  --gpu-type nvidia-l4 \
  --max-instances 3 \
  --memory 16Gi \
  --allow-unauthenticated \
  --no-cpu-throttling \
  --no-gpu-zonal-redundancy \
  --timeout 600 \
  --labels dev-tutorial=codelab-agent-gpu

Wenn Sie die Meldung „Deploying from source requires an Artifact Registry Docker repository to store built containers. Wenn Sie die Meldung „Ein Repository mit dem Namen [cloud-run-source-deploy] in der Region [europe-west1] wird erstellt.“ sehen, fahren Sie fort.

⚙️ Schlüsselkonfiguration

  • GPU: NVIDIA L4 wurde aufgrund des hervorragenden Preis-Leistungs-Verhältnisses für Inferenzarbeitslasten ausgewählt. Die L4 bietet 24 GB GPU-Arbeitsspeicher und optimierte Tensor-Operationen und eignet sich daher ideal für Modelle mit 270 Millionen Parametern wie Gemma.
  • Arbeitsspeicher: 16 GB Arbeitsspeicher für das Laden von Modellen, CUDA-Vorgänge und die Arbeitsspeicherverwaltung von Ollama
  • CPU: 8 Kerne für die optimale Verarbeitung von E/A und Vorverarbeitungsaufgaben
  • Gleichzeitigkeit: 4 Anfragen pro Instanz sorgen für ein ausgewogenes Verhältnis zwischen Durchsatz und GPU-Arbeitsspeichernutzung.
  • Zeitlimit: 600 Sekunden für das erste Laden des Modells und den Containerstart

💰 Kosten: GPU-Instanzen sind deutlich teurer als reine CPU-Instanzen (ca. 2–4$pro Stunde im Vergleich zu ca. 0,10$pro Stunde). Die Einstellung --max-instances 1 trägt dazu bei, die Kosten zu kontrollieren, indem eine unnötige Skalierung von GPU-Instanzen verhindert wird.

  1. Warten Sie, bis die Bereitstellung abgeschlossen ist, und notieren Sie sich die Dienst-URL:
    export OLLAMA_URL=$(gcloud run services describe ollama-gemma3-270m-gpu \
    --region=europe-west1 \
    --format='value(status.url)')

echo "🎉 Gemma backend deployed at: $OLLAMA_URL"

8. ADK-Agent-Integration implementieren

Erstellen wir nun einen minimalen ADK-Agenten, der eine Verbindung zu Ihrem bereitgestellten Gemma-Backend herstellt.

  1. Rufen Sie das ADK-Agent-Verzeichnis auf:
    cd ../adk-agent
  2. Öffnen und implementieren Sie die Agent-Konfiguration:
    cloudshell edit production_agent/agent.py
    Ersetzen Sie alle TODO-Kommentare durch diese minimale Implementierung:
    import os
from pathlib import Path

from dotenv import load_dotenv
from google.adk.agents import Agent
from google.adk.models.lite_llm import LiteLlm
import google.auth

# Load environment variables
root_dir = Path(__file__).parent.parent
dotenv_path = root_dir / ".env"
load_dotenv(dotenv_path=dotenv_path)

# Configure Google Cloud
try:
    _, project_id = google.auth.default()
    os.environ.setdefault("GOOGLE_CLOUD_PROJECT", project_id)
except Exception:
    pass

os.environ.setdefault("GOOGLE_CLOUD_LOCATION", "europe-west1")

# Configure model connection
gemma_model_name = os.getenv("GEMMA_MODEL_NAME", "gemma3:270m")

# Production Gemma Agent - GPU-accelerated conversational assistant
gemma_agent = Agent(
   model=LiteLlm(model=f"ollama_chat/{gemma_model_name}"),
   name="gemma_agent",
   description="A production-ready conversational assistant powered by GPU-accelerated Gemma.",
   instruction="""You are 'Gem', a friendly, knowledgeable, and enthusiastic zoo tour guide.
   Your main goal is to make a zoo visit more fun and educational for guests by answering their questions.

   You can provide general information and interesting facts about different animal species, such as:
   - Their natural habitats and diet. 🌲🍓
   - Typical lifespan and behaviors.
   - Conservation status and unique characteristics.

   IMPORTANT: You do NOT have access to any tools. This means you cannot look up real-time, specific information about THIS zoo. You cannot provide:
   - The names or ages of specific animals currently at the zoo.
   - The exact location or enclosure for an animal.
   - The daily schedule for feedings or shows.

   Always answer based on your general knowledge about the animal kingdom. Keep your tone cheerful, engaging, and welcoming for visitors of all ages. 🦁✨""",
   tools=[],  # Gemma focuses on conversational capabilities
)

# Set as root agent
root_agent = gemma_agent
    🔧 Was passiert hier?
    • Verbindung zu Ihrem bereitgestellten Gemma-Backend über LiteLLM
    • Erstellt einen einfachen Konversations-Agent
    • Google Cloud-Integration konfigurieren
  3. FastAPI-Server öffnen und implementieren:
    cloudshell edit server.py
    Ersetzen Sie alle TODO-Kommentare durch:
    import os
from dotenv import load_dotenv
from fastapi import FastAPI
from google.adk.cli.fast_api import get_fast_api_app

# Load environment variables
load_dotenv()

AGENT_DIR = os.path.dirname(os.path.abspath(__file__))
app_args = {"agents_dir": AGENT_DIR, "web": True}

# Create FastAPI app with ADK integration
app: FastAPI = get_fast_api_app(**app_args)

# Update app metadata
app.title = "Production ADK Agent - Lab 3"
app.description = "Gemma agent with GPU-accelerated backend"
app.version = "1.0.0"

@app.get("/health")
def health_check():
    return {"status": "healthy", "service": "production-adk-agent"}

@app.get("/")
def root():
    return {
        "service": "Production ADK Agent - Lab 3",
        "description": "GPU-accelerated Gemma agent",
        "docs": "/docs",
        "health": "/health"
    }

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8080, log_level="info")
    🔧 Was passiert hier?
    • Erstellt einen FastAPI-Server mit ADK-Integration
    • Aktiviert die Weboberfläche für Tests
    • Stellt Endpunkte für Systemdiagnosen bereit
  4. Öffnen Sie das Dockerfile und implementieren Sie es:
    cloudshell edit Dockerfile
    Ersetzen Sie alle TODO-Kommentare durch:
    FROM python:3.13-slim

# Copy uv from the official image
COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv

# Install system dependencies
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

# Set working directory
WORKDIR /app

# Copy all files
COPY . .

# Install Python dependencies
RUN uv sync

# Expose port
EXPOSE 8080

# Run the application
CMD ["uv", "run", "uvicorn", "server:app", "--host", "0.0.0.0", "--port", "8080"]
    Erläuterung der Technologieauswahl:
    • uv: Moderner Python-Paketmanager, der 10- bis 100-mal schneller als pip ist. Es wird ein globaler Cache und parallele Downloads verwendet, wodurch sich die Container-Build-Zeiten erheblich verkürzen.
    • Python 3.13-slim: Aktuelle Python-Version mit minimalen Systemabhängigkeiten, wodurch die Containergröße und die Angriffsfläche reduziert werden
    • Build mit mehreren Phasen: Durch das Kopieren von uv aus dem offiziellen Image wird sichergestellt, dass wir die neueste optimierte Binärdatei erhalten.

9. Umgebung konfigurieren und Agent bereitstellen

Als Nächstes konfigurieren wir den ADK-Agent, damit er eine Verbindung zu Ihrem bereitgestellten Gemma-Backend herstellt, und stellen ihn als Cloud Run-Dienst bereit. Dazu müssen Sie Umgebungsvariablen einrichten und den Agent mit der richtigen Konfiguration bereitstellen.

  1. Umgebungskonfiguration einrichten:
    cat << EOF > .env
GOOGLE_CLOUD_PROJECT=$(gcloud config get-value project)
GOOGLE_CLOUD_LOCATION=europe-west1
GEMMA_MODEL_NAME=gemma3:270m
OLLAMA_API_BASE=$OLLAMA_URL
EOF

Umgebungsvariablen in Cloud Run

Umgebungsvariablen sind Schlüssel/Wert-Paare, mit denen Ihre Anwendung zur Laufzeit konfiguriert wird. Sie sind besonders nützlich für:

  • API-Endpunkte und Dienst-URLs (z. B. unser Ollama-Backend)
  • Konfiguration, die sich zwischen Umgebungen (Entwicklung, Staging, Produktion) ändert
  • Vertrauliche Daten, die nicht fest codiert werden sollten

ADK-Agent bereitstellen:

export PROJECT_ID=$(gcloud config get-value project)

gcloud run deploy production-adk-agent \
   --source . \
   --region europe-west1 \
   --allow-unauthenticated \
   --memory 4Gi \
   --cpu 2 \
   --max-instances 1 \
   --concurrency 10 \
   --timeout 300 \
   --set-env-vars GOOGLE_CLOUD_PROJECT=$PROJECT_ID \
   --set-env-vars GOOGLE_CLOUD_LOCATION=europe-west1 \
   --set-env-vars GEMMA_MODEL_NAME=gemma3:270m \
   --set-env-vars OLLAMA_API_BASE=$OLLAMA_URL \
   --labels dev-tutorial=codelab-agent-gpu

⚙️ Schlüsselkonfiguration:

  • Autoscaling: Auf 1 Instanz festgelegt (einfache Anfragenbearbeitung)
  • Gleichzeitigkeit: 10 Anfragen pro Instanz
  • Arbeitsspeicher: 4 GB für den ADK-Agent
  • Umgebung: Stellt eine Verbindung zu Ihrem Gemma-Backend her.

🔒 Sicherheitshinweis: In diesem Lab wird der Einfachheit halber --allow-unauthenticated verwendet. In der Produktion sollten Sie die richtige Authentifizierung mit folgenden Methoden implementieren:

  • Dienst-zu-Dienst-Authentifizierung mit Dienstkonten in Cloud Run
  • IAM-Richtlinien (Identity and Access Management)
  • API-Schlüssel oder OAuth für externen Zugriff
  • gcloud run services add-iam-policy-binding zur Zugriffssteuerung verwenden

Rufen Sie die Dienst-URL Ihres Agents ab:

export AGENT_URL=$(gcloud run services describe production-adk-agent \
    --region=europe-west1 \
    --format='value(status.url)')

echo "🎉 ADK Agent deployed at: $AGENT_URL"

✅ Best Practices für Umgebungsvariablen basierend auf der Dokumentation zu Umgebungsvariablen in Cloud Run:

  1. Reservierte Variablen vermeiden: Legen Sie PORT (wird automatisch von Cloud Run festgelegt) oder Variablen, die mit X_GOOGLE_ beginnen, nicht fest.
  2. Aussagekräftige Namen verwenden: Setzen Sie ein Präfix vor Ihre Variablen, um Konflikte zu vermeiden (z.B. GEMMA_MODEL_NAME statt MODEL)
  3. Kommas maskieren: Wenn Ihre Werte Kommas enthalten, verwenden Sie ein anderes Trennzeichen: --set-env-vars "^@^KEY1=value1,value2@KEY2=..."
  4. Aktualisieren im Vergleich zu Ersetzen: Mit --update-env-vars können Sie bestimmte Variablen hinzufügen oder ändern, ohne andere zu beeinträchtigen.

Variablen in Cloud Run festlegen:

  • Aus Datei: gcloud run deploy SERVICE_NAME --env-vars-file .env --labels dev-tutorial codelab-adk (lädt mehrere Variablen aus einer Datei)
  • Mehrere Flags: Wiederholen Sie --set-env-vars für komplexe Werte, die nicht durch Kommas getrennt werden können.

10. Mit der ADK-Weboberfläche testen

Nachdem beide Dienste bereitgestellt wurden, müssen Sie prüfen, ob Ihr ADK-Agent erfolgreich mit dem GPU-beschleunigten Gemma-Backend kommunizieren und auf Nutzeranfragen reagieren kann.

  1. Testen Sie den Endpunkt für die Systemdiagnose:
    curl $AGENT_URL/health
    Sie sollten Folgendes sehen:
    { "status": "healthy", "service": "production-adk-agent" }
  2. Interagieren Sie mit Ihrem Agent, indem Sie die URL für Ihr production-adk-agent in einen neuen Browsertab eingeben. Sie sollten die ADK-Weboberfläche sehen.
  3. Testen Sie Ihren Agent mit diesen Beispielunterhaltungen:
    • „Wovon ernähren sich Rote Pandas in der Wildnis?“
    • „Kannst du mir einen interessanten Fakt über Schneeleoparden erzählen?“
    • „Warum sind Pfeilgiftfrösche so bunt?“
    • „Wo finde ich das neue Babykänguru im Zoo?“
    👀 Was du beobachten solltest:
    • Der Agent antwortet mit Ihrem bereitgestellten Gemma-Modell. Sie können dies überprüfen, indem Sie die Logs für Ihren bereitgestellten Gemma-Dienst ansehen. Das machen wir im nächsten Abschnitt.
    • Antworten werden vom GPU-beschleunigten Backend generiert
    • Die Weboberfläche bietet eine übersichtliche Chat-Umgebung.

Lab 3: ADK-Tests

11. Lasttests implementieren und ausführen

Lab 3: Lasttests

Um zu verstehen, wie Ihre Produktionsbereitstellung mit dem tatsächlichen Traffic umgeht, führen wir umfassende Lasttests durch, die das automatische Skalieren sowohl des ADK-Agents als auch der GPU-Backend-Dienste auslösen.

  1. Öffnen und implementieren Sie das Lasttestskript:
    cloudshell edit load_test.py
    Ersetzen Sie den TODO-Kommentar durch:
    import random
import uuid
from locust import HttpUser, task, between

class ProductionAgentUser(HttpUser):
    """Load test user for the Production ADK Agent."""

    wait_time = between(1, 3)  # Faster requests to trigger scaling

    def on_start(self):
        """Set up user session when starting."""
        self.user_id = f"user_{uuid.uuid4()}"
        self.session_id = f"session_{uuid.uuid4()}"

        # Create session for the Gemma agent using proper ADK API format
        session_data = {"state": {"user_type": "load_test_user"}}

        self.client.post(
            f"/apps/production_agent/users/{self.user_id}/sessions/{self.session_id}",
            headers={"Content-Type": "application/json"},
            json=session_data,
        )

    @task(4)
    def test_conversations(self):
        """Test conversational capabilities - high frequency to trigger scaling."""
        topics = [
            "What do red pandas typically eat in the wild?",
            "Can you tell me an interesting fact about snow leopards?",
            "Why are poison dart frogs so brightly colored?",
            "Where can I find the new baby kangaroo in the zoo?",
            "What is the name of your oldest gorilla?",
            "What time is the penguin feeding today?"
        ]

        # Use proper ADK API format for sending messages
        message_data = {
            "app_name": "production_agent",
            "user_id": self.user_id,
            "session_id": self.session_id,
            "new_message": {
                "role": "user",
                "parts": [{
                    "text": random.choice(topics)
                }]
            }
        }

        self.client.post(
            "/run",
            headers={"Content-Type": "application/json"},
            json=message_data,
        )

    @task(1)
    def health_check(self):
        """Test the health endpoint."""
        self.client.get("/health")
    🔧 Was passiert hier?
    • Sitzungserstellung: Das richtige ADK-API-Format wird mit POST an /apps/production_agent/users/{user_id}/sessions/{session_id} verwendet. Nachdem Sie session_id und user_id erstellt haben, können Sie eine Anfrage an den Agent senden.
    • Nachrichtenformat: Entspricht der ADK-Spezifikation mit app_name, user_id, session_id und strukturiertem new_message-Objekt
    • Conversation Endpoint: Verwendet den /run-Endpunkt, um alle Ereignisse gleichzeitig zu erfassen (empfohlen für Lasttests)
    • Realistic Load (Realistische Last): Erstellt eine Unterhaltungslast mit kürzeren Wartezeiten, um das Autoscaling auszulösen.
    📚 Weitere Informationen zu ADK-API-Endpunkten und Testmustern finden Sie im ADK-Testleitfaden.
  2. Installieren Sie die Abhängigkeiten:
    uv sync
pip install locust
  3. Locust ist ein Open-Source-Tool für Lasttests, das auf Python basiert und für Leistungs- und Lasttests von Webanwendungen und anderen Systemen entwickelt wurde. Das Hauptmerkmal ist, dass Testszenarien und Nutzerverhalten mit Standard-Python-Code definiert werden. Das bietet im Vergleich zu Tools, die auf grafischen Benutzeroberflächen oder domänenspezifischen Sprachen basieren, eine hohe Flexibilität und Ausdruckskraft. Wir verwenden Locust, um den Nutzertraffic für unsere Dienste zu simulieren.Führen Sie den Lasttest aus.
    # Run a load test to trigger autoscaling
locust -f load_test.py \
   -H $AGENT_URL \
   --headless \
   -t 50s \
   -u 3 \
   -r 1
    Ändern Sie die Parameter im Test und beobachten Sie die Ausgabe. Sie sehen, dass ollama-gemma3-270m-gpu auf 2–3 Instanzen ansteigt. Die📊 Parameter für den Belastungstest
    • Dauer: 50 Sekunden
    • Nutzer: 3 gleichzeitige Nutzer
    • Spawn-Rate: 1 Nutzer pro Sekunde
    • Ziel: Autoscaling für beide Dienste auslösen

12. Autoscaling-Verhalten beobachten

Während der Lasttest ausgeführt wird, können Sie die automatische Skalierung von Cloud Run in Aktion beobachten. Hier sehen Sie die wichtigsten architektonischen Vorteile der Trennung des ADK-Agents vom GPU-Backend.

Beobachten Sie während des Lasttests, wie die beiden Cloud Run-Dienste in der Console skaliert werden.

  1. Öffnen Sie die Cloud Console und rufen Sie
      auf.
    • „Cloud Run“ → „production-adk-agent“ → „Messwerte“
    • „Cloud Run“ → „ollama-gemma3-270m-gpu“ → „Messwerte“

👀 Worauf Sie achten sollten:

🤖 ADK-Agent-Dienst:

  • Sollte bei steigendem Traffic bei 1 Instanz bleiben
  • Spitzen bei CPU- und Arbeitsspeichernutzung bei hohem Traffic
  • Effiziente Verwaltung von Sitzungen und Anfragenrouting

🎮 Gemma Backend Service (Engpass):

  • Skaliert je nach Bedarf für die Inferenz von 1 bis 3 Instanzen
  • Die GPU-Auslastung steigt unter Last deutlich an.
  • Dieser Dienst wird aufgrund der GPU-intensiven Modellinferenz zum Engpass.
  • Die Zeiten für den Modellrückschluss bleiben aufgrund der GPU-Beschleunigung konstant.

💡 Wichtige Statistiken:

  • Das GPU-Backend ist der Engpass und wird aggressiver skaliert (1–3 Instanzen).
  • Der ADK-Agent bleibt konsistent
  • Beide Dienste werden unabhängig voneinander auf Grundlage ihrer individuellen Lasteigenschaften skaliert.
  • Mit Autoscaling wird die Leistung bei unterschiedlichen Lastbedingungen aufrechterhalten.

13. Fazit

Glückwunsch! Sie haben erfolgreich einen produktionsbereiten ADK-Agent mit einem GPU-beschleunigten Gemma-Backend bereitgestellt und das Autoscaling-Verhalten beobachtet.

✅ Was Sie erreicht haben

  • ✅ GPU-beschleunigtes Gemma-Modell-Backend in Cloud Run bereitgestellt
  • ✅ Sie haben einen ADK-Agenten erstellt und bereitgestellt, der in das Gemma-Backend integriert ist.
  • ✅ Agent über die ADK-Weboberfläche getestet
  • ✅ Autoscaling-Verhalten über zwei koordinierte Cloud Run-Dienste hinweg beobachtet

💡 Wichtige Erkenntnisse aus diesem Lab

  1. 🎮 GPU-Beschleunigung: Die NVIDIA L4-GPU verbessert die Leistung der Modellinferenz erheblich.
  2. 🔗 Dienstkoordination: Zwei Cloud Run-Dienste können nahtlos zusammenarbeiten.
  3. 📈 Unabhängige Skalierung: Jeder Dienst wird basierend auf seinen individuellen Lasteigenschaften skaliert.
  4. 🚀 Produktionsvorbereitung: Die Architektur kann reale Traffic-Muster effektiv verarbeiten.

🔄 Nächste Schritte

  • Mit verschiedenen Lastmustern experimentieren und das Skalierungsverhalten beobachten
  • Verschiedene Gemma-Modellgrößen ausprobieren (Arbeitsspeicher und GPU entsprechend anpassen)
  • Monitoring und Benachrichtigungen für Produktionsbereitstellungen implementieren
  • Multiregionale Bereitstellungen für globale Verfügbarkeit

🧹 Bereinigen

Löschen Sie die Ressourcen, wenn Sie fertig sind, um Gebühren zu vermeiden:

gcloud run services delete production-adk-agent --region=europe-west1
gcloud run services delete ollama-gemma3-270m-gpu --region=europe-west1

📖 Ressourcen