Rivet ra mắt nền tảng điều phối AI agent trên nền S3

Phần mềm06 tháng 11, 2026·5 phút đọc

Startup Rivet (YC F25) vừa ra mắt nền tảng mã nguồn mở giúp điều phối và mở rộng các tác vụ AI agent bằng mô hình actor thay vì sandbox nặng nề. Mỗi agent chỉ tốn 72 KB bộ nhớ và khởi động lạnh 4,99 ms, rẻ hơn khoảng 10 lần so với lưu trữ SSD truyền thống.

Rivet ra mắt nền tảng điều phối AI agent trên nền S3

Rivet, startup từng tham gia chương trình YC F25, vừa công bố nền tảng điều phối (orchestrator) mã nguồn mở chuyên dành cho các tác vụ AI agent. Thay vì cấp một sandbox nặng nề cho mỗi agent, Rivet dùng actor – tiến trình nhẹ chạy dài hạn – và lưu trữ nền trên S3.

Điểm đáng chú ý nhất nằm ở con số hiệu năng: mỗi actor chỉ chiếm 72 KB bộ nhớ và khởi động lạnh (cold start) 4,99 ms ở p99, so với 512 MB và 1,7 giây của một sandbox tối thiểu.

Bài toán đằng sau Rivet

Nhóm sáng lập Nathan và Nicholas cho biết khi dự YC năm 2023, họ xây hạ tầng cho game nhiều người chơi như Diep và Krunker. Quá trình tối ưu matchmaking, tin nhắn thời gian thực và mở rộng hạ tầng cho thấy Postgres không theo kịp thông lượng. Họ thử viết script Lua trên Redis nhưng khó bảo trì, rồi mở rộng bộ điều phối game server thành mô hình actor: nhiều worker nhẹ có trạng thái trong bộ nhớ và lưu trữ bền vững. Cách này từng phục vụ hàng chục triệu người dùng hoạt động hàng tháng.

Khi AI agent phổ biến, nhóm nhận ra chạy agent trong sandbox không hiệu quả: tốn kém, phần lớn thời gian rảnh rỗi và khởi động chậm. Actor tiết kiệm bộ nhớ hơn nhiều và khởi động nhanh hơn hàng trăm lần.

Kiến trúc: S3 làm được như SSD

Trước đây Rivet chạy trên FoundationDB. Nhưng nhóm phát hiện doanh nghiệp lưu lượng dữ liệu trên actor lớn gấp nhiều lần so với trên Postgres – bản ghi phiên dài, tài liệu agent sinh ra, cả hệ thống file POSIX. Dữ liệu phình ra khiến họ phải trả tiền cho SSD nằm nhàn rỗi phần lớn thời gian.

Rivet chuyển sang lấy S3 làm lưu trữ chính. Vấn đề là ghi thẳng dữ liệu nhỏ lên S3 vừa chậm vừa đắt. Giải pháp là dùng thêm tầng đệm SSD:

  • Khi ghi vào cơ sở dữ liệu SQLite của actor, dữ liệu được xác nhận sau khi có mặt trên SSD ở 2 trong 3 vùng khả dụng (availability zone)
  • Sau đó dữ liệu được gom lô (batch) đẩy lên S3 ở chế độ nền
  • S3 không bao giờ nằm trên đường ghi, giúp giảm độ trễ và chi phí
  • Khi đọc hoặc đánh thức actor, Rivet đọc từ SSD nếu đã có cache, ngược lại mới lấy từ S3

Với kiến trúc này, Rivet công bố độ trễ ghi bền vững 1,07 ms (3 vùng khả dụng, p99), đọc 1,36 ms (p99) và đọc từ object storage 138 ms (p99). Theo Rivet, chi phí lưu trữ rẻ hơn khoảng 10,4 lần so với ba bản sao SSD EBS gp3.

So sánh trực tiếp với sandbox

Tiêu chíRivet ActorSandbox
Khởi động lạnh (p99)4,99 ms1,70 giây
Bộ nhớ mỗi thực thể72,4 KB512 MiB
Lưu trữSQLite trên S3, rẻ hơn khoảng 10,4 lần so với SSD nhân bảnỔ đĩa riêng mỗi sandbox

Rivet cho biết các con số của mình lấy từ bộ benchmark so sánh Rivet Actors với Cloudflare Durable Objects, chạy trên phiên bản Rivet 3.0.3, có mã nguồn và script để tái lập. Số liệu sandbox lấy từ cấu hình bộ nhớ mặc định được công bố và một benchmark khởi động lạnh của bên thứ ba.

Mã nguồn mở và tự triển khai được

Rivet hoạt động theo mô hình tương tự Cloudflare Durable Objects nhưng là mã nguồn mở theo giấy phép Apache 2.0, có thể tự triển khai (self-host). Tự chạy chỉ cần một binary Rust duy nhất, với S3 là phụ thuộc duy nhất. Rivet Cloud cung cấp cụm chuyên dụng trên AWS hoặc GCP ở mọi khu vực; tùy chọn BYOC (mang cloud riêng) cho phép chạy bên trong VPC của khách hàng mà vẫn do Rivet vận hành.

Actor của Rivet có thể viết bằng TypeScript hoặc Rust, chạy trực tiếp trên Node.js và Bun gốc, không cần runtime tùy chỉnh nên các gói, công cụ và bài test hiện có vẫn dùng được. Nền tảng hỗ trợ sẵn agent, workflow, ứng dụng thời gian thực, chạy mã do AI sinh ra (thông qua agentOS) và các tích hợp như Vercel Eve hay Turso.

So với Durable Objects của Cloudflare, Rivet không giới hạn bộ nhớ ở 128 MB, không giới hạn SQLite ở 10 GB, không tự ý loại bỏ actor và cho phép kiểm soát runtime.

Góc nhìn

Với đội ngũ đang xây sản phẩm AI agent, chi phí hạ tầng thường nằm ở chỗ duy trì trạng thái phiên hội thoại và các tiến trình "ngủ đông" chờ người dùng. Mô hình actor đánh thức theo yêu cầu (hibernate khi rảnh) giúp giải quyết đúng điểm này: chỉ trả tiền khi agent thực sự hoạt động.

Việc chọn S3 làm lưu trữ chính cũng đáng để các kỹ sư Việt Nam lưu tâm. Object storage có mặt ở hầu hết nhà cung cấp cloud và cả các giải pháp tương thích S3 như MinIO, Cloudflare R2 hay Hetzner, nên kiến trúc tầng đệm SSD phía trước S3 có thể áp dụng cho các hệ thống cần lưu lịch sử lớn mà ngân sách eo hẹp. Tuy vậy, nên tự kiểm chứng bằng benchmark trên chính tải của mình thay vì tin tuyệt đối vào con số p99 của nhà cung cấp.

Nguồn: github.com · Quy trình biên tập

Chia sẻ:FacebookX