So sánh các nền tảng Sandbox cho AI Agent năm 2026: Hiệu năng, chi phí và hạ tầng

Mọi tác nhân (agent) viết mã đều cần một nơi để thực thi. "Nơi đó" hiện đã trở thành một danh mục sản phẩm với ít nhất một tá nhà cung cấp, bốn mô hình thanh toán không tương thích và các trang tiếp thị quảng cáo thời gian khởi động nguội (cold start) được đo lường trong những điều kiện mà không ai công bố.

Bài so sánh này chuẩn hóa các đơn vị đo lường. Nó bao gồm năm nền tảng mà hầu hết các đội ngũ đều đưa vào danh sách rút gọn — E2B, Daytona, Modal Sandboxes, Cloudflare Sandbox SDK và Vercel Sandbox — cùng với Runloop, Fly.io Sprites và Northflank ở những điểm mà chúng làm thay đổi kết quả.

Bốn câu hỏi thực sự quyết định vấn đề này

Các ma trận tính năng cho danh mục này phần lớn chỉ là nhiễu. Bốn thuộc tính làm thay đổi kiến trúc, còn mọi thứ khác chỉ là tùy chọn ưu tiên:

1. Khởi động nguội (Cold start): những con số thực sự nói lên điều gì

Các tuyên bố của nhà cung cấp không thể so sánh trực tiếp với nhau. Trang định giá của Daytona quảng cáo thời gian tạo sandbox dưới 90ms. E2B thường được trích dẫn ở mức khoảng 150ms. Modal quảng cáo thời gian khởi động nguội dưới một giây cho các container đã được lưu bộ nhớ đệm trước (pre-cached). Không ai trong số này nêu rõ tính đồng thời, khu vực, kích thước image, hoặc liệu đồng hồ dừng lại khi nhận được phản hồi API hay khi lệnh đầu tiên được thực thi.

Tập dữ liệu công khai hữu ích nhất là bảng xếp hạng sandbox của ComputeSDK, vốn là mã nguồn mở và chạy theo lịch trình. Nó đo lường Thời gian đến khi tương tác (TTI): khoảng thời gian trôi qua từ lệnh create đến lệnh thành công đầu tiên bên trong sandbox, với 100 lần lặp lại cho mỗi nhà cung cấp, được khởi chạy đồng thời trong một đợt duy nhất, từ một host 4 vCPU tại Bắc Virginia.

Kết quả từ lần chạy ngày 21 tháng 8 năm 2026:

Ba điều trong bảng đó quan trọng hơn cả thứ hạng.

Tự tái hiện kết quả này

Tác vụ đáng để đo lường là tác vụ mà tác nhân của bạn thực hiện, chứ không phải lệnh echo hello. Một bộ đo lường hữu ích sẽ chạy cùng một đơn vị công việc ở mọi nơi: cài đặt pandas, đọc một tệp CSV, vẽ biểu đồ và trả về một tệp PNG. Hãy đo thời gian bốn điểm kiểm tra một cách riêng biệt.

Hãy báo cáo tti và tác vụ riêng biệt. Các nhà cung cấp tối ưu hóa cái thứ nhất, còn người đọc lại quan tâm đến cái thứ hai. Hãy cố định khu vực, cố định image và công bố cả chuỗi tuần tự lẫn chuỗi đồng thời, vì chúng trả lời cho những câu hỏi khác nhau.

2. Định giá theo giây, đã chuẩn hóa

Các mức giá được công bố tính đến ngày 27 tháng 8 năm 2026, đã được quy đổi sang một đơn vị chung. Modal định giá theo nhân vật lý, được họ định nghĩa là 2 vCPU, vì vậy giá trị tương đương vCPU được hiển thị để so sánh.

Hai chú thích mà mọi người thường hiểu sai.

3. Chi phí cho mỗi 1.000 lần thực thi

Mức giá không phải là chi phí. Mô hình dưới đây cố định khối lượng công việc và chạy nó qua bảng giá của từng nhà cung cấp.

Các giả định: Sandbox 2 vCPU / 4 GiB, 1.000 lần thực thi, không bao gồm mức phí tối thiểu của gói, không tính phí lưu lượng truy cập ra (egress), khu vực mặc định (Vercel iad1, Cloudflare standard-3 ở mức 2 vCPU / 8 GiB / 16 GB ổ cứng vì kích thước instance là cố định).

Kịch bản A: đợt chạy ngắn — 90 giây hoạt động, trung bình 50% CPU

Kịch bản B: trạng thái chờ nhiều — 10 phút hoạt động, trung bình 5% CPU

Đây là diện mạo của một vòng lặp tác nhân thực tế. Sandbox đang mở, mô hình đang suy nghĩ, không có gì được thực thi.

Vercel chuyển từ vị trí rẻ thứ 4 lên thứ 3, và đường chi phí CPU của nó giảm từ $3.20 xuống $2.13 trong khi các nhà cung cấp khác tăng tuyến tính. Đường chi phí CPU hoạt động của Cloudflare giảm xuống còn $1.20. Đó là toàn bộ lập luận cho việc tính phí theo CPU hoạt động, và nó đáng giá gấp khoảng 2 lần trên khối lượng công việc này.

Kịch bản B với chế độ tạm dừng (suspend)

Các nền tảng thua ở Kịch bản B có thể giành lại lợi thế nếu quá trình điều phối của bạn tạm dừng giữa các lượt thay vì giữ sandbox mở. Cùng khối lượng công việc, 30 giây thức mỗi lần thực thi:

Con số của E2B bao gồm khoảng 17 giây chi phí tạm dừng và tiếp tục cho một sandbox 4 GiB. Chi phí đó là biến số quyết định: việc tạm dừng chỉ mang tính kinh tế khi khoảng cách giữa các lượt dài hơn đáng kể so với chính thời gian tạm dừng.

Bộ phát hiện trạng thái chờ của Fly rất cụ thể về những gì được tính là hoạt động: một yêu cầu HTTP hoặc API đang diễn ra, đầu ra cho stdout của phiên, kết nối TCP đang mở hoặc một tác vụ đang hoạt động (sprites.dev). Một tác nhân giữ kết nối mở trong khi chờ đợi là tác nhân sẽ bị tính phí. Việc chuyển hướng đầu ra sang một tệp không được tính là hoạt động, đây là một đòn bẩy thực sự.

4. Tính bền vững của hệ thống tệp giữa các lượt

Đây là nơi các nền tảng khác biệt nhiều nhất, và là nơi lựa chọn sai lầm sẽ dẫn đến việc node_modules phải được xây dựng lại sau mỗi lượt.

Ba chi tiết đáng để ghi nhớ:

5. Chính sách lưu lượng truy cập ra (Egress)

Mọi nền tảng trong bài so sánh này hiện đều có thể chạy sandbox mà không cần truy cập internet. Sự khác biệt nằm ở độ ưu tiên, tính chi tiết và việc liệu chính sách có thể thay đổi mà không cần khởi động lại hay không.

Bẫy độ ưu tiên

E2B và Vercel giải quyết xung đột theo các hướng ngược nhau. Trong E2B, các quy tắc cho phép (allow) được ưu tiên hơn các quy tắc chặn (deny): một IP nằm trong cả hai danh sách sẽ được cho phép. Trong Vercel Sandbox, các dải IP bị chặn sẽ ghi đè lên các dải IP được cho phép. Một chính sách được chuyển từ nền tảng này sang nền tảng kia mà không viết lại sẽ không mang ý nghĩa tương đương.

Bẫy chế độ lỗi

E2B ghi nhận rằng các kết nối TCP bị chặn có thể trông như thành công từ bên trong sandbox. Tường lửa chấp nhận kết nối trước khi quyết định xem đích đến có được phép hay không, vì vậy một socket được mở nhưng không có gói tin nào đến nơi. Hãy xác minh lưu lượng truy cập ra bằng phản hồi ở cấp ứng dụng — trạng thái HTTP, bắt tay TLS — chứ không phải bằng một lệnh connect thành công. Bất kỳ bộ kiểm thử nào khẳng định "mạng bị chặn" bằng cách kiểm tra lỗi kết nối đều sẽ vượt qua đối với một sandbox không bị chặn.

Tiêm thông tin xác thực (Credential injection) mới là yếu tố khác biệt thực sự

Chặn lưu lượng truy cập ra là yêu cầu cơ bản. Việc cho phép sandbox thực hiện một cuộc gọi đã xác thực mà không bao giờ nắm giữ thông tin xác thực mới là điều quan trọng.

Cloudflare chạy các trình xử lý đầu ra trong runtime Workers, bên ngoài sandbox, với quyền truy cập vào các binding của Workers. Sandbox đưa ra một yêu cầu thông thường, trình xử lý đính kèm bí mật, và ctx.containerId giới hạn thông tin xác thực cho từng instance (tài liệu). Vercel môi giới thông tin xác thực ở đầu ra với các bộ khớp (matcher) được giới hạn theo đường dẫn, phương thức, chuỗi truy vấn hoặc tiêu đề, và tuyên bố tường lửa chạy trên host bên ngoài microVM nơi mã sandbox không thể vô hiệu hóa nó (Vercel). E2B cung cấp các trình chuyển đổi yêu cầu theo host trong bản beta công khai, giúp tiêm các tiêu đề tại proxy đầu ra, bao gồm cả các token định danh khối lượng công việc mà sandbox không bao giờ nhìn thấy. Runloop cung cấp một Credential Gateway với khả năng tiêm token ẩn.

Đối với các tác nhân xử lý đầu vào không đáng tin cậy, thiết kế này quan trọng hơn cả khởi động nguội. Một tác nhân bị tiêm prompt (prompt-injected) với token GitHub trong môi trường của nó là một sự cố khác biệt hoàn toàn so với một tác nhân chỉ có thể tiếp cận GitHub thông qua một proxy nắm giữ token đó.