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 hambatan performa umum, terutama untuk pola traffic yang tidak dapat diprediksi dan berfluktuasi tajam dalam aplikasi dunia nyata.

Masalah cold start

Cold start terjadi saat permintaan tiba dan tidak ada instance atau penampung yang tidak digunakan untuk melayaninya, sehingga Vertex AI Agent Engine harus memulai yang 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.

  • Start warm (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 Anda. Misalnya, menyetel min_instances=10 ke agen contoh dapat mengurangi latensi rata-rata untuk cold start menjadi sekitar 1,4 detik. Untuk aplikasi dengan traffic tinggi atau lonjakan traffic, tetapkan min_instances ke nilai yang dapat menangani beban umum Anda tanpa perlu melakukan penskalaan dari 1. Nilai maksimumnya adalah 10.

  • Kirim beban yang stabil, berkelanjutan, dan dapat diprediksi ke Vertex AI Agent Engine Runtime menggunakan antrean. Misalnya, menjalankan uji beban berkelanjutan 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 selalu rendah, yaitu sekitar 1,6 detik.

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

Pekerja asinkron yang kurang dimanfaatkan

Secara default, container_concurrency dikonfigurasi untuk kode sinkron, di mana setiap instance Agent Engine hanya menangani satu permintaan dalam satu waktu. Agen asinkron, seperti yang berbasis Agent Development Kit (ADK), dapat menangani beberapa permintaan terikat I/O (seperti panggilan LLM atau 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 dalam antrean saat layanan melakukan penskalaan horizontal 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 menunjukkan jumlah proses agen yang berjalan secara paralel dalam setiap penampung.

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 secara 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 menyetel nilai container_concurrency terlalu tinggi dapat menimbulkan risiko error kehabisan memori (OOM).

Langkah berikutnya