Agent Runtime 提供了部署参数，可让您优化和扩缩智能体的性能。通过配置这些参数，您可以有效处理不可预测或高峰流量模式。
本页面介绍了如何优化和扩缩 Agent Runtime 性能的最佳实践，涵盖以下场景：
这些场景展示了如何使用部署参数解决常见的性能瓶颈，尤其是实际应用中不可预测的峰值流量模式。
冷启动问题
当请求到达时，如果没有空闲实例或容器来处理该请求，就会发生冷启动，从而迫使 Agent Runtime 启动一个新实例或容器。这会给请求增加显著的延迟时间。
例如，向具有默认 min_instances=1 的智能体发送 300 个并发请求可能会显示以下结果：
冷启动（首次运行）：平均延迟时间约为 4.7 秒。
温启动（立即第二次运行）：平均延迟时间约为 0.4 秒。
超过 4 秒的开销几乎完全是由于启动新实例来处理负载造成的。
请尝试以下方法来缓解冷启动问题：
设置一个足够高的
min_instances值，以处理基准流量。例如，将min_instances=10设置为示例代理可以将冷启动的平均延迟时间缩短到大约 1.4 秒。对于流量高峰或高流量的应用，请将min_instances设置为可以处理典型负载的值，而无需从 1 开始扩缩。如需了解可接受的值范围，请参阅ReasoningEngineSpecREST 资源参考文档。使用队列向 Agent Runtime 发送稳定、持续、可预测的负载。例如，在基于智能体开发套件 (ADK) 的智能体上，使用
min_instances=10和默认concurrency(9) 运行持续负载测试（每分钟 1,500 次查询，即每秒 25 次查询），持续 60 秒，可能会产生以下结果：- 平均延迟时间始终保持在较低水平，约为 1.6 秒。
稳定、持续的负载可使服务保持预热状态，从而实现最佳性能。
未充分利用的异步工作器
默认情况下，container_concurrency 配置为同步代码，其中每个 Agent Platform 实例一次仅处理一个请求。异步智能体（例如基于智能体开发套件 (ADK) 的智能体）可以同时处理多个 I/O 密集型请求（例如 LLM 或工具调用）。
例如，向具有 min_instances=10 和默认 container_concurrency=9 的基于 ADK 的代理发送 300 个并发请求可能会产生以下结果：
- 虽然延迟时间中位数约为 4 秒，但最大延迟时间会飙升至 60 秒。这表示在服务缓慢扩容时，请求会严重排队。
为了缓解异步工作器利用率不足的问题，请增加 container_concurrency，以允许每个 Agent Platform 实例处理多个请求。每个代理进程可以处理的并发请求数为 container_concurrency / 9。值 9 表示每个容器中并行运行的代理进程数。
例如，向同一个基于 ADK 的智能体发送 300 个并发请求，其中 min_instances=10 和 container_concurrency=36，可能会产生以下结果：
- 最大延迟时间从 60 秒降至大约 7 秒。这表明现有实例可以更有效地吸收流量高峰。
对于异步代理（例如基于 ADK 的代理），请先将 container_concurrency 设置为 9 的倍数（例如 36）。这可以提高对流量高峰的响应能力，并减少横向扩容带来的延迟。
请注意，如果将 container_concurrency 值设置得过高，可能会导致内存不足 (OOM) 错误。