本頁說明如何最佳化及擴充 Vertex AI Agent Engine Runtime 的效能，涵蓋下列情境：
這些情境說明如何使用部署參數解決常見的效能瓶頸，特別是實際應用程式中無法預測的尖峰流量模式。
冷啟動問題
如果要求送達時，沒有閒置的執行個體或容器可處理，Vertex AI Agent Engine 就會強制啟動新的執行個體或容器，這就是冷啟動。這會大幅增加要求的延遲時間。
舉例來說，如果使用預設的 min_instances=1，同時傳送 300 個要求給代理程式，可能會出現下列結果：
冷啟動 (首次執行)：平均延遲時間約為 4.7 秒。
暖啟動 (立即第二次執行)：平均延遲時間約為 0.4 秒。
超過四秒的額外負擔幾乎完全是因為新執行個體啟動來處理負載所致。
請嘗試下列方法，減少冷啟動問題：
設定足夠高的
min_instances值，以處理基準流量。舉例來說，將min_instances=10設為範例代理程式，可將冷啟動的平均延遲時間縮短至約 1.4 秒。如果應用程式的流量尖峰或高流量，請將min_instances設為可處理一般負載的值，不必從 1 開始擴充。最大值為 10。使用佇列將穩定、持續且可預測的負載傳送至 Vertex AI Agent Engine 執行階段。舉例來說，在以 Agent Development Kit (ADK) 為基礎的代理程式上，以
min_instances=10和預設concurrency(9) 持續執行負載測試，每分鐘 1,500 個查詢 (每秒 25 個查詢)，持續 60 秒，可能會產生下列結果：- 平均延遲時間持續偏低，約為 1.6 秒。
穩定且持續的負載可讓服務保持運作，達到最佳效能。
非同步工作者未充分發揮效用
根據預設，container_concurrency 會設定為同步程式碼，每個 Agent Engine 執行個體一次只能處理一個要求。非同步代理 (例如以 Agent Development Kit (ADK) 為基礎的代理) 可以同時處理多個 I/O 繫結要求 (例如 LLM 或工具呼叫)。
舉例來說，如果使用 min_instances=10 和預設的 container_concurrency=9，同時向以 ADK 為基礎的代理程式傳送 300 個要求，可能會產生下列結果：
- 雖然中位數延遲時間約為 4 秒，但最大延遲時間會飆升至 60 秒。這表示服務緩慢擴充時，要求會大量排隊。
如要減少非同步工作站閒置的情況，請增加 container_concurrency，讓每個 Agent Engine 例項都能處理多個要求。每個代理程序可處理的並行要求數量為 container_concurrency / 9。值 9 代表每個容器中平行執行的代理程序數量。
舉例來說，使用 min_instances=10 和 container_concurrency=36 同時向同一個 ADK 型代理程式傳送 300 個要求，可能會產生下列結果：
- 延遲時間上限從 60 秒降至約 7 秒。這表示現有執行個體能更有效地吸收流量尖峰。
如果是非同步代理程式 (例如以 ADK 為基礎的代理程式)，請將 container_concurrency
設為 9 的倍數 (例如 36)，做為起點。這有助於提升對流量尖峰的反應速度，並減少擴充作業造成的延遲。
請注意，如果將 container_concurrency 值設得太高，可能會導致記憶體不足 (OOM) 錯誤。