工程 / 工程
弹性内存管理与一致性冷启动
亚马逊云科技宣布推出全新 AgentCore 运行时,作为 Amazon Bedrock AgentCore 的核心计算层,专为生产级 AI 智能体的速度、灵活性与成本效率而设计。新版本解决了两大关键挑战:其一,原有运行时在整个会话周期内持续占用峰值内存,即便智能体已停止使用这部分资源;其二,冷启动时间随容器镜像大小和并发量增加而显著延长,在流量突发时尤为明显。新运行时采用按需分页内存分配机制,在内存进入冷态后主动回收,账单随实际使用量动态变化。同时,平台通过预先准备环境快照并在每次新实例启动时直接还原,使冷启动时间保持稳定,不再受镜像大小或并发规模影响。这一升级使开发者无需自行维护预热容量池,即可获得可预期的启动性能与更精准的资源计费。
AI 智能体的应用形态正在快速演变。早期的智能体多以问答聊天机器人形式存在,交互在数秒内完成。如今,编程智能体可以持续运行数分钟乃至数小时,在多个步骤间保持上下文;更进一步的环境感知型智能体则始终在线,由事件触发、无人值守地运行,仅在任务完成或遇到需要人工介入的决策时才浮出水面。智能体的数量也从少数实验性项目扩展为嵌入产品功能、由其他智能体调度启动的大规模部署。
面对这一演变,原有 AgentCore 运行时的两个局限愈发明显。在内存管理方面,会话从分配内存起便持续占用至会话结束,即便后续请求已不再使用这部分内存,账单依然按峰值计算。对于偶发性流量突增但大部分时间处于空闲状态的智能体而言,这意味着全天候为短暂的峰值买单。在冷启动方面,每个新会话都需要完整经历启动环境、拉取镜像、初始化智能体的过程,延迟随镜像体积和并发量线性增长,在流量突发时恰好是最多会话同时到达、可用预热环境最少的时刻。
为应对上述挑战,许多团队不得不自行构建补偿机制:预留备用环境以规避冷启动、手动优化内存分配、在低峰期主动释放资源以控制成本。这套运维体系复杂且昂贵,预留的计算资源无论是否被使用都会产生费用,且在流量突发超出预留量时仍会失效。这些工作与智能体本身的业务逻辑毫无关联,却消耗了大量工程资源。
新版 AgentCore 运行时从根本上重构了内存管理逻辑。每个会话启动时采用精简的初始内存配置,后续按需分页分配额外内存。基于对数十亿次会话分配模式的分析,平台在内存进入冷态且不再可能被访问时主动回收,而非等待会话结束。这意味着账单不再锁定在历史峰值,而是随会话生命周期内的实际使用量动态变化,长时运行或流量不均匀的智能体可从中获得显著的成本节省。
冷启动一致性的改善源于快照机制的引入。平台预先完成环境初始化并生成快照,每次新实例启动时直接还原该快照,跳过重复的启动与初始化流程。由于快照体积小且固定,启动时间不再随镜像大小或并发规模波动,用户等待智能体恢复响应的体验因此变得可预期。这一机制与弹性内存管理共同作用,使开发者能够在不维护预热容量池的前提下,同时获得低延迟启动和精准计费两项能力。
新版运行时延续了 AgentCore 原有的无服务器模型核心优势:按实际消耗计费、弹性伸缩至零、会话间完全隔离。在此基础上,它将这些特性的适用范围从短时交互型智能体扩展至长时运行的自主型智能体。随着智能体从辅助工具演变为嵌入产品核心流程的基础设施组件,底层计算平台的弹性与可预测性将直接影响产品的经济模型与用户体验,这也是 AWS 此次升级所针对的核心命题。
要点
- 新版 AgentCore 运行时引入按需分页内存分配,在内存冷态时主动回收,账单跟随实际使用量而非峰值变化,显著降低长时运行或流量不均匀智能体的成本。
- 通过预生成环境快照并在新实例启动时直接还原,冷启动时间实现一致性,不再受容器镜像大小或并发规模影响,改善用户等待体验。
- 开发者无需自行维护预热容量池或手动优化内存分配,平台接管了这部分基础设施复杂度,使工程资源可专注于智能体业务逻辑本身。
- 新运行时同时适配短时交互型与长时自主型智能体,为 AI 智能体从实验性部署走向大规模生产提供了更具弹性的计算基础。
原始标题:The new AgentCore runtime: Elastic, optimized, and consistently fast starts
本文由 DataHub 基于公开来源整理,用于信息发现与摘要阅读;具体事实、数据和后续更新以原始来源为准。