AWS Tái thiết kế Runtime AgentCore của Bedrock cho Bộ nhớ Đàn hồi và Khởi động Lạnh Nhanh

Amazon Web Services đã công bố runtime AgentCore mới vào ngày 18 tháng 9 năm 2026, một phiên bản được tái thiết kế của lớp tính toán được quản lý trong Amazon Bedrock AgentCore mà công ty cho rằng sẽ thu hồi bộ nhớ khi các phiên làm việc của agent giải phóng và cung cấp thời gian khởi động lạnh nhất quán bất kể kích thước hình ảnh container hay mức độ đồng thời.

Runtime AgentCore là lớp tính toán được quản lý, cung cấp cho các nhà phát triển một môi trường được quản lý hoàn toàn để triển khai và chạy các agent mà không cần xây dựng hay duy trì hạ tầng. AWS cho biết hàng ngàn nhóm đã sử dụng nó để chạy các agent sản xuất kể từ khi ra mắt, và phiên bản đầu tiên đã thiết lập nền tảng không máy chủ với cách ly phiên, hành vi thu nhỏ đến mức không (scale‑to‑zero), và mô hình giá trả theo mức sử dụng. Mô hình tiêu thụ này vẫn được áp dụng: phí tính dựa trên việc sử dụng tài nguyên mà không tính phí cho CPU nhàn rỗi chờ I/O, và nền tảng sẽ thu nhỏ hoàn toàn xuống 0 khi một agent không có công việc.

Các vấn đề mà lần ra mắt này giải quyết

Trong runtime gốc, một phiên sẽ giữ bộ nhớ đã cấp phát từ lúc cấp phát cho đến khi phiên kết thúc, vì không có gì thu hồi nó trong quá trình này. AWS cho biết điều này khiến các agent chạy lâu hoặc theo dạng bùng nổ phải trả phí cho mức sử dụng cao nhất suốt ngày đêm, ngay cả khi bộ nhớ đã không còn được sử dụng, tạo ra một khoảng trống đặc biệt đối với các agent chỉ tăng đột biến thỉnh thoảng nhưng phần lớn thời gian lại nhàn rỗi.

Hành vi khởi động là thách thức thứ hai. AWS cho biết một phiên được đặt trên môi trường đã được khởi tạo sẵn sẽ bắt đầu trong vòng dưới 100 miligiây, nhưng việc duy trì môi trường đủ ấm để đảm bảo điều đó đồng nghĩa với việc giữ tài nguyên tính toán dự trữ, vì vậy hầu hết các phiên bắt đầu bằng một khởi động lạnh, khởi động một môi trường mới, tải hình ảnh và khởi tạo agent trước khi yêu cầu đầu tiên được thực thi. Độ trễ này tăng lên theo kích thước hình ảnh và mức độ đồng thời và tệ nhất trong lưu lượng bùng nổ, khi có nhiều phiên đến và số môi trường sẵn sàng còn lại ít nhất. Theo AWS, khách hàng đã khắc phục cả hai vấn đề bằng cách duy trì các môi trường dự phòng sẵn sàng, tối ưu hóa việc cấp phát bộ nhớ và giảm công suất để kiểm soát chi phí.

Những gì AWS Đo lường

Để tách riêng phần mà nền tảng tự nó thêm vào thời gian khởi động lạnh, AWS đã thử nghiệm một agent echo trống không trả về gì ngoài đầu vào và không gọi mô hình hay công cụ nào. Một client Python chạy trên một instance Amazon EC2 ở us‑west‑2 đã gọi các agent ở us‑east‑1 qua internet công cộng mà không có kết nối VPC, sử dụng SDK boto3, vì vậy mỗi đo lường phía client bao gồm vòng quay giữa hai khu vực AWS cộng với thời gian khởi động riêng của nền tảng. Công ty đã gửi 5.000 lời gọi khởi động lạnh cho mỗi agent trên cả hai phiên bản runtime và năm kích thước hình ảnh, trong giới hạn tài khoản mặc định.

Với cách đo này, AWS báo cáo rằng runtime mới đạt độ trễ khởi động lạnh P75 khoảng 2 giây cho hình ảnh từ 200 MB lên tới 2 GB, vì kích thước hình ảnh không ảnh hưởng đến thời gian này, trong khi độ trễ của runtime gốc tăng theo kích thước hình ảnh từ khoảng 5,4 giây lên gần 30 giây. Trong thử nghiệm echo, mã của agent chạy khoảng 34 miligiây ở P75, vì vậy hầu hết thời gian đo được là thời gian khởi động của nền tảng. AWS đề xuất ẩn thời gian khởi động cho các agent tương tác bằng cách bắt đầu phiên ngay khi người dùng tương tác, chẳng hạn khi họ mở một cuộc trò chuyện, để môi trường được làm ấm trong khi họ gõ yêu cầu đầu tiên.

Cách Hoạt động của Runtime Mới

Runtime mới bắt đầu mỗi phiên với một hồ sơ bộ nhớ nhỏ thay vì một dung lượng được cấp phát đầy đủ, sau đó cấp phát và nạp thêm bộ nhớ theo nhu cầu khi khối lượng công việc yêu cầu. Khi một agent giải phóng các bộ đệm theo yêu cầu hoặc cho phép dữ liệu đã lưu trong bộ nhớ cache hết hạn giữa các yêu cầu, nền tảng sẽ thu hồi lại bộ nhớ thay vì để nó vẫn được giữ cho đến khi phiên kết thúc. AWS cho biết họ đã điều chỉnh hành vi thu hồi dựa trên phân tích các mẫu cấp phát qua hàng tỷ phiên.

Khởi động lạnh thay đổi vì mỗi agent chỉ tải một lần rồi chạy từ một snapshot. Khi một runtime được tạo hoặc cập nhật, AgentCore khởi chạy container, chờ nó báo cáo là khỏe mạnh và chụp một snapshot của môi trường đang chạy, vì vậy các khởi tạo một lần như tải các artefact mô hình và lấy cấu hình tĩnh đã được thực hiện. Mỗi phiên bản mới sẽ khôi phục snapshot đó thay vì khởi tạo lại từ đầu. AWS cho biết runtime loại bỏ cache và bộ nhớ tạm thời khỏi snapshot nên kích thước của nó gần như ổn định khi hình ảnh container tăng lên, giúp độ trễ khôi phục ổn định trên một dải rộng các kích thước hình ảnh.

Việc tính phí thay đổi theo mô hình bộ nhớ. Runtime mới tính phí cho bộ nhớ mà một agent thực sự sử dụng, được nạp theo nhu cầu và thu hồi khi không hoạt động, thay vì tính phí cho việc giữ toàn bộ hình ảnh container trong bộ nhớ suốt thời gian của một phiên. AWS mô tả sự thay đổi này là mức phí cao hơn nhưng áp dụng cho ít GB‑giờ hơn nhiều, và cho biết đối với hầu hết các agent, dung lượng giảm nhiều hơn mức phí tăng, vì vậy hóa đơn sẽ giảm.

Các Phiên bản Nền tảng, Vùng, và Giới hạn

Các nhà phát triển bật runtime mới bằng cách đặt trường platformVersion thành V2 khi tạo hoặc cập nhật một runtime, theo Hướng dẫn dành cho nhà phát triển AgentCore. V1 là mặc định: bỏ qua trường khi tạo sẽ tạo ra một runtime V1, và bỏ qua khi cập nhật sẽ giữ phiên bản nền tảng hiện tại của runtime. V2 có sẵn ở us-east-1, us-east-2, us-west-2, eu-west-1 và ap-northeast-1.

Vì việc tạo hoặc cập nhật V2 chuẩn bị và chụp ảnh môi trường, các thao tác này mất vài phút trước khi runtime đạt trạng thái READY, trong khi runtime V1 chỉ cần vài giây để sẵn sàng. AgentCore thực hiện chụp ảnh khi nhận được phản hồi khỏe mạnh đầu tiên từ endpoint /ping của container, và nếu container không báo cáo trạng thái khỏe mạnh trong vòng 120 giây kể từ khi khởi động, quá trình tạo sẽ thất bại với lỗi kiểm tra sức khỏe. Hướng dẫn cũng cho biết hiện tại V2 giới hạn tổng kích thước biến môi trường ở mức 1,5 KB cho việc triển khai mã trực tiếp và 2,5 KB cho các agent container, so với 4 KB trên V1, và AWS CloudFormation cùng AWS CDK chưa hỗ trợ thiết lập platformVersion.

Các ảnh chụp theo dõi các phiên bản và endpoint của runtime thay vì được quản lý trực tiếp. AgentCore chuẩn bị một ảnh chụp khi một endpoint trỏ tới một phiên bản và xóa ảnh chụp khi không có endpoint nào trỏ tới nó, và quá trình xóa có thể kéo dài tới 8 giờ, thời gian sống tối đa của phiên, vì các phiên đang chạy trên ảnh chụp sẽ tiếp tục cho đến khi kết thúc. Các phiên chạy trong các microVM riêng biệt với tài nguyên CPU, bộ nhớ và hệ thống tệp cách ly, tồn tại tối đa 8 giờ và sẽ kết thúc sau 15 phút không hoạt động, sau đó microVM sẽ bị xóa và bộ nhớ được làm sạch.

Lộ trình và Bắt đầu

Sau khi ra mắt, AWS đã liệt kê một số khả năng sẽ được triển khai: giảm giá cơ bản cam kết bảo lưu mức bộ nhớ tối thiểu cho mỗi phiên với khả năng bùng nổ theo nhu cầu phía trên, hướng tới các phiên luôn hoạt động liên tục; tăng dung lượng RAM, vCPU và lưu trữ phiên; hỗ trợ microVM x86; tạm dừng và tiếp tục với chụp ảnh bộ nhớ cộng với các hook runtime để tuần tự hoá trạng thái trước khi một phiên hoạt động kết thúc; và các khóa ngữ cảnh phiên cho phép mỗi phiên có danh tính phạm vi riêng cho các agent không có người giám sát.

AWS đã chỉ dẫn các nhà phát triển tới AgentCore Developer Guide, kho mẫu AgentCore trên GitHub, và một ví dụ kiểm tra tải kèm theo, minh họa độ trễ khởi động lạnh của runtime mới trong tài khoản AWS của người dùng.