Mengoptimalkan dan menskalakan Vertex AI Agent Engine Runtime

Halaman ini menjelaskan praktik terbaik tentang cara mengoptimalkan dan menskalakan performa untuk Runtime Agent Engine Vertex AI, yang mencakup skenario berikut:

Skenario ini menunjukkan cara menggunakan parameter deployment untuk mengatasi bottleneck performa umum , terutama untuk pola traffic yang tidak dapat diprediksi dan tidak stabil dalam aplikasi dunia nyata.

Masalah cold start

Cold start terjadi saat permintaan tiba dan tidak ada instance atau container yang tidak aktif untuk melayaninya, sehingga Vertex AI Agent Engine harus memulai instance atau container baru. Hal ini akan menambahkan latensi yang signifikan pada permintaan.

Misalnya, mengirim 300 permintaan serentak ke agen dengan min_instances=1 default dapat menunjukkan hasil berikut:

  • Cold start (run pertama): Latensi rata-rata sekitar 4,7 detik.

  • Warm start (run kedua langsung): Latensi rata-rata sekitar 0,4 detik.

Overhead lebih dari empat detik hampir seluruhnya disebabkan oleh instance baru yang dimulai untuk menangani beban.

Coba metode berikut untuk mengurangi masalah cold start:

  • Tetapkan nilai min_instances yang cukup tinggi untuk menangani traffic dasar pengukuran Anda. Misalnya, menetapkan min_instances=10 ke agen contoh dapat mengurangi latensi rata-rata untuk cold start menjadi sekitar 1,4 detik. Untuk aplikasi dengan traffic yang tidak stabil atau tinggi, tetapkan min_instances ke nilai yang dapat menangani beban umum Anda tanpa perlu menskalakan dari 1. Nilai maksimumnya adalah 75.

  • Kirim beban yang stabil, berkelanjutan, dan dapat diprediksi ke Runtime Agent Engine Vertex AI menggunakan antrean. Misalnya, menjalankan uji beban berkelanjutan sebanyak 1.500 kueri per menit (25 kueri per detik) selama 60 detik pada agen berbasis Agent Development Kit (ADK) dengan min_instances=10 dan concurrency default (9) dapat menghasilkan hasil berikut:

    • Latensi rata-rata secara konsisten rendah, yaitu sekitar 1,6 detik.

Beban yang stabil dan berkelanjutan membuat layanan tetap warm dan menghasilkan performa yang optimal.

Pekerja asinkron yang kurang dimanfaatkan

Secara default, container_concurrency dikonfigurasi untuk kode sinkron, dengan setiap instance Agent Engine hanya menangani satu permintaan dalam satu waktu. Agen asinkron, seperti agen yang didasarkan pada Agent Development Kit (ADK), dapat menangani beberapa permintaan terikat I/O (seperti LLM atau panggilan alat) secara bersamaan.

Misalnya, mengirim 300 permintaan serentak ke agen berbasis ADK dengan min_instances=10 dan container_concurrency=9 default dapat menghasilkan hasil berikut:

  • Meskipun latensi median sekitar 4 detik, latensi maksimum melonjak hingga 60 detik. Hal ini menunjukkan bahwa permintaan sangat banyak diantrekan saat layanan menskalakan secara perlahan.

Untuk mengurangi pekerja asinkron yang kurang dimanfaatkan, tingkatkan container_concurrency agar setiap instance Agent Engine dapat menangani beberapa permintaan. Jumlah permintaan serentak yang dapat ditangani oleh setiap proses agen adalah container_concurrency / 9. Nilai 9 mewakili jumlah proses agen yang berjalan secara paralel dalam setiap container.

Misalnya, mengirim 300 permintaan serentak ke agen berbasis ADK yang sama dengan min_instances=10 dan container_concurrency=36 dapat menghasilkan hasil berikut:

  • Latensi maksimum turun dari 60 detik menjadi sekitar 7 detik. Hal ini menunjukkan bahwa instance yang ada dapat menyerap lonjakan traffic dengan lebih efektif.

Untuk agen asinkron (seperti agen berbasis ADK), tetapkan container_concurrency ke kelipatan 9 (misalnya, 36) sebagai titik awal. Hal ini meningkatkan responsivitas terhadap lonjakan traffic dan mengurangi latensi dari penskalaan.

Perhatikan bahwa menetapkan nilai container_concurrency terlalu tinggi dapat berisiko menyebabkan error kehabisan memori (OOM).

Langkah berikutnya