Vertex AI Agent Engine Runtime optimieren und skalieren

Auf dieser Seite werden Best Practices zur Optimierung und Skalierung der Leistung für die Vertex AI Agent Engine-Laufzeit beschrieben. Dabei werden die folgenden Szenarien behandelt:

In den Szenarien wird gezeigt, wie Sie Bereitstellungsparameter verwenden, um häufige Leistungsengpässe zu beheben, insbesondere bei unvorhersehbaren, sprunghaften Traffic-Mustern in realen Anwendungen.

Kaltstartproblem

Ein Kaltstart erfolgt, wenn eine Anfrage eingeht und keine inaktiven Instanzen oder Container zur Bearbeitung vorhanden sind. In diesem Fall muss Vertex AI Agent Engine eine neue Instanz oder einen neuen Container starten. Dadurch wird die Latenz der Anfrage erheblich erhöht.

Wenn Sie beispielsweise 300 gleichzeitige Anfragen an einen Agenten mit dem Standardwert min_instances=1 senden, können die folgenden Ergebnisse angezeigt werden:

  • Kaltstart (erster Lauf): durchschnittliche Latenz von etwa 4,7 Sekunden.

  • Warmstart (sofortige zweite Ausführung): durchschnittliche Latenz von etwa 0,4 Sekunden.

Der Overhead von mehr als vier Sekunden ist fast ausschließlich auf das Starten neuer Instanzen zur Verarbeitung der Last zurückzuführen.

Mit den folgenden Methoden können Sie das Kaltstartproblem beheben:

  • Legen Sie einen min_instances-Wert fest, der hoch genug ist, um Ihren Referenz-Traffic zu bewältigen. Wenn Sie min_instances=10 beispielsweise auf den Beispiel-Agent festlegen, kann die durchschnittliche Latenz für einen Kaltstart auf etwa 1,4 Sekunden reduziert werden. Legen Sie für Anwendungen mit unregelmäßigem oder hohem Traffic min_instances auf einen Wert fest, der die typische Last bewältigen kann, ohne dass eine Skalierung von 1 erforderlich ist. Der Höchstwert ist 10.

  • Senden Sie mit einer Warteschlange eine stabile, kontinuierliche und vorhersagbare Last an die Vertex AI Agent Engine-Laufzeit. Wenn Sie beispielsweise einen Lasttest mit 1.500 Anfragen pro Minute (25 Anfragen pro Sekunde) für 60 Sekunden für einen auf dem Agent Development Kit (ADK) basierenden Agenten mit min_instances=10 und dem Standardwert concurrency (9) ausführen, kann das folgende Ergebnis erzielt werden:

    • Die durchschnittliche Latenz ist mit etwa 1,6 Sekunden konstant niedrig.

Eine stabile, kontinuierliche Last hält den Dienst warm und führt zu einer optimalen Leistung.

Unterausgelastete asynchrone Worker

Standardmäßig ist container_concurrency für synchronen Code konfiguriert, wobei jede Agent Engine-Instanz jeweils nur eine Anfrage verarbeitet. Asynchrone Agents, z. B. solche, die auf dem Agent Development Kit (ADK) basieren, können mehrere E/A-gebundene Anfragen (z. B. LLM- oder Tool-Aufrufe) gleichzeitig verarbeiten.

Wenn Sie beispielsweise 300 gleichzeitige Anfragen an einen ADK-basierten Agenten mit min_instances=10 und dem Standardwert container_concurrency=9 senden, kann das folgende Ergebnis erzielt werden:

  • Die mediane Latenz beträgt etwa 4 Sekunden, die maximale Latenz steigt jedoch auf 60 Sekunden. Das bedeutet, dass Anfragen in der Warteschlange stehen, während der Dienst langsam skaliert wird.

Um die Unterauslastung asynchroner Worker zu verringern, erhöhen Sie container_concurrency, damit jede Agent Engine-Instanz mehrere Anfragen verarbeiten kann. Die Anzahl der gleichzeitigen Anfragen, die von jedem Agent-Prozess verarbeitet werden können, ist container_concurrency / 9. Der Wert 9 steht für die Anzahl der Agent-Prozesse, die parallel in jedem Container ausgeführt werden.

Wenn Sie beispielsweise 300 gleichzeitige Anfragen mit min_instances=10 und container_concurrency=36 an denselben ADK-basierten Agenten senden, kann das folgende Ergebnis erzielt werden:

  • Die maximale Latenz sinkt von 60 Sekunden auf etwa 7 Sekunden. Das zeigt, dass vorhandene Instanzen den Traffic-Anstieg effektiver auffangen können.

Bei asynchronen Agents (z. B. ADK-basierten Agents) legen Sie container_concurrency als Ausgangspunkt auf ein Vielfaches von 9 fest (z. B. 36). Dadurch wird die Reaktionsfähigkeit auf Traffic-Spitzen verbessert und die Latenz beim Skalieren reduziert.

Wenn Sie den Wert container_concurrency zu hoch festlegen, kann es zu Fehlern aufgrund fehlenden Speichers (OOM, Out-of-memory) kommen.

Nächste Schritte