Mengoptimalkan dan menskalakan performa Agent Runtime

Agent Runtime menyediakan parameter deployment yang memungkinkan Anda mengoptimalkan dan menskalakan performa agen. Dengan mengonfigurasi parameter ini, Anda dapat menangani pola traffic yang tidak dapat diprediksi atau melonjak secara efektif.

Halaman ini menjelaskan praktik terbaik tentang cara mengoptimalkan dan menskalakan performa untuk Agent Runtime, 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 melonjak dalam aplikasi dunia nyata.

Masalah cold start

Cold start terjadi saat permintaan masuk dan tidak ada instance atau container yang tidak ada aktivitas untuk melayaninya, sehingga memaksa Agent Runtime untuk memulai yang baru. Hal ini akan menambahkan latensi yang signifikan ke permintaan.

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

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

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

Overhead yang 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 tinggi atau tidak stabil, tetapkan min_instances ke nilai yang dapat menangani beban standar Anda tanpa perlu melakukan penskalaan dari 1. Untuk mengetahui rentang nilai yang diterima, lihat referensi resource REST ReasoningEngineSpec.

  • Mengirim beban yang stabil, berkelanjutan, dan dapat diprediksi ke Agent Runtime menggunakan antrean. Misalnya, menjalankan uji beban berkelanjutan sebesar 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 memberikan hasil berikut:

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

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

Worker asinkron yang kurang dimanfaatkan

Secara default, container_concurrency dikonfigurasi untuk kode sinkron, dengan setiap instance Agent Platform hanya menangani satu permintaan dalam satu waktu. Agen asinkron, seperti yang didasarkan pada 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 memberikan hasil berikut:

  • Meskipun latensi mediannya sekitar 4 detik, latensi maksimumnya melonjak hingga 60 detik. Hal ini menunjukkan bahwa permintaan sangat mengantre sementara layanan perlahan-lahan melakukan penyebaran skala.

Untuk mengurangi worker asinkron yang kurang dimanfaatkan, tingkatkan container_concurrency agar setiap instance Agent Platform 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 memberikan 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 penyebaran skala.

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

Langkah berikutnya

Panduan

Pelajari cara mengelola agen yang telah di-deploy ke runtime terkelola Agent Platform.

Panduan

Menggunakan agen dengan Agent Platform Runtime.

Referensi

Pelajari kuota dan batas untuk Agent Platform.