7 phút đọc
Trong bối cảnh các mô hình AI Agent ngày càng đòi hỏi khả năng xử lý song song và phân nhánh tác vụ (fan-out) phức tạp, việc khởi tạo môi trường thực thi cô lập (sandbox) truyền thống thường gặp phải rào cản lớn về độ trễ khởi động. Repository deeplethe/forkd — dự án nguồn mở viết bằng ngôn ngữ Rust hiện đạt 2.901 stars và 225 forks trên GitHub — mang đến một tiếp cận hoàn toàn mới: áp dụng cơ chế fork() của hệ điều hành cho các microVM dựa trên KVM.
Thay vì phải khởi động lạnh (cold-boot) toàn bộ kernel cho từng sandbox, forkd cho phép tạo ra 100 microVM con từ một tiến trình cha đã được “làm nóng” (warm parent) chỉ trong khoảng 101 ms, đồng thời hỗ trợ rẽ nhánh (BRANCH) một VM đang chạy chỉ trong khoảng 56–150 ms.
Nguyên lý hoạt động: Kế thừa bộ nhớ Copy-on-Write trên nền Firecracker
forkd được xây dựng dựa trên phiên bản tùy biến của Firecracker (tại nhánh deeplethe/firecracker:forkd-v0.4-mem-backend-shared-v1.12). Quy trình xử lý của forkd diễn ra theo các bước chính:
- Khởi tạo VM cha: MicroVM cha khởi động một lần duy nhất, tải sẵn các runtime cần thiết như Python cùng các thư viện phụ thuộc, JVM đã JIT-warm, hoặc mô hình machine learning đã nạp vào bộ nhớ, sau đó tạm dừng và lưu trạng thái xuống đĩa.
- Tạo tiến trình con bằng mmap: Mỗi microVM con là một tiến trình Firecracker riêng biệt, thực hiện ánh xạ (mmap) hình ảnh bộ nhớ của VM cha bằng cờ
MAP_PRIVATE. - Xử lý Copy-on-Write (CoW): Kernel Linux sẽ đảm nhận cơ chế Copy-on-Write ở cấp độ trang bộ nhớ (page level). Các VM con chia sẻ chung bộ nhớ với VM cha cho đến khi có dữ liệu ghi mới phát sinh.
Cơ chế này mang lại hai đặc tính quan trọng cùng lúc: vừa đảm bảo mức độ cô lập phần cứng an toàn bằng KVM cho từng VM con, vừa giảm chi phí khởi tạo xuống mức tương đương với lời gọi hàm fork(2) trong Linux thay vì một VM khởi động lạnh thông thường.
Về mặt hạ tầng, forkd yêu cầu môi trường Linux phiên bản tối thiểu từ 5.7 trở lên, hỗ trợ cgroup v2, có quyền tiếp cận
/dev/kvmvà cấu hìnhvm.unprivileged_userfaultfd=1(hoặc quyềnCAP_SYS_PTRACE). Tệp công cụforkd doctorđi kèm sẽ tự động kiểm tra các điều kiện tiên quyết này.
Cơ chế BRANCH và chuỗi Diff-Snapshot qua các phiên bản
Không chỉ dừng lại ở bước khởi động ban đầu, forkd còn cung cấp tính năng BRANCH: tạm dừng một sandbox đang chạy, chụp ảnh trạng thái tức thời (in-flight state) và khôi phục lại để agent có thể rẽ nhánh ngay giữa quá trình suy luận (“mid-thought”).
Tối ưu độ trễ rẽ nhánh trong v0.4
Ở phiên bản v0.4 với chế độ Live BRANCH, cửa sổ tạm dừng nguồn (source-pause window) được rút ngắn từ khoảng 200 ms xuống còn 56 ms (p50) và 64 ms (p90) đối với bộ nhớ nguồn dung lượng 1,5 GiB. Khi thiết lập tham số wait: false, lệnh gọi sẽ phản hồi lại ngay sau ~70 ms trong khi tiến trình sao chép bộ nhớ vẫn tiếp tục chạy ngầm phía sau. Điều này mang lại mức cải thiện thời gian phản hồi tới 200 lần cho các tác vụ BRANCH dạng “phát-và-quên” (fire-and-forget) từ mã nguồn agent.
Chuỗi Diff-Snapshot trong v0.5
Phiên bản v0.5 giải quyết bài toán lãng phí bộ nhớ khi agent lưu trữ nhiều snapshot liên tiếp (ví dụ: từng bước pip install numpy, pandas, scikit-learn). Thay vì lưu 3 bản sao riêng biệt của bộ nhớ nền 1,5 GiB, v0.5 giới thiệu cấu trúc chuỗi diff-snapshot (diff-snapshot chains). Mỗi tầng snapshot chỉ ghi lại liên kết parent_tag kèm mã băm nội dung (content-hash) với tầng bên dưới. Khi khởi tạo, daemon sẽ duyệt qua chuỗi và dựng lại hình ảnh bộ nhớ trong một lượt duy nhất.
Thử nghiệm thực tế với tác vụ phân nhánh dạng ReAct trên framework LangGraph cho thấy: một agent gốc khi bị rẽ nhánh giữa chừng có thể phân ra 3 agent con. Mỗi agent con nhận một gợi ý (hint) khác nhau và đưa ra các lịch trình khác biệt, nhưng vẫn thừa hưởng toàn bộ ngữ cảnh suy luận và trạng thái tệp tin trước đó (chẳng hạn một tệp nhị phân 50 MiB hay thư mục __pycache__) mà không cần nạp lại vào prompt.
So sánh hiệu năng thực tế với các giải pháp Sandbox
Trong bài kiểm tra chuẩn (benchmark) khởi tạo đồng thời 100 sandbox cùng thực thi đoạn mã Python import numpy; numpy.zeros(5).tolist() trên cùng một máy chủ bare-metal (Ubuntu 24.04, Linux 6.14, 20 vCPU, 30 GiB RAM, KVM), kết quả ghi nhận như sau:
- forkd: Hoàn thành toàn bộ 100 sandbox trong 101 ms (tính theo wall-clock time).
- CubeSandbox (v0.2.0): Đạt 1,06 giây ở luồng xử lý nhanh (fast-path). (Lưu ý: trong cấu hình chậm chưa tối ưu kích thước lớp ghi, thời gian này từng ghi nhận là 20,3 giây với tỷ lệ thành công 77/100).
- OpenSandbox (mặc định Docker): Mất 8,2 giây.
- BoxLite: Mất 46,8 giây (do dự án tập trung tối ưu cho một Box dài hạn thay vì khởi tạo hàng loạt).
Mặc dù đạt tốc độ ấn tượng trong bài toán rẽ nhánh từ bộ nhớ ấm, forkd cũng có những phạm vi hạn chế rõ ràng. Đối với nhu cầu khởi động lạnh thuần túy từ đầu, CubeSandbox công bố tốc độ dưới 60 ms cho bản thể đơn lẻ. Các giải pháp như Daytona phù hợp hơn cho môi trường workspace dài hạn của người dùng; BoxLite mạnh về khả năng nhúng đa nền tảng (hỗ trợ macOS qua Hypervisor.framework); còn các runtime cấp hàm (function-level) loại bỏ môi trường Linux đầy đủ có thể nhanh hơn forkd một khoảng rộng nhưng đổi lại không thể chạy server Python thực thụ, không dùng được apt install hay gọi kết nối HTTPS ra ngoài.
Khả năng triển khai và những điểm cần tiếp tục hoàn thiện
forkd hỗ trợ triển khai trên Kubernetes thông qua mô hình một Pod forkd-serve quản lý N sandbox con, giúp giảm tải cho bộ lập lịch của K8s so với mô hình mỗi sandbox một Pod. Tuy nhiên, các cụm K8s đám mây (GKE, EKS, AKS) cần chuẩn bị các node dạng bare-metal hoặc hỗ trợ ảo hóa lồng (nested virtualization) để truy cập được /dev/kvm.
Dù đã giải quyết được vấn đề trôi trạng thái VM (vmstate-drift) với tỷ lệ vượt qua bài kiểm tra 90/90 (100%), forkd vẫn còn chi phí kiểm tra mã SHA-256 của tầng nền (~460 ms cho 512 MiB trên CPU i7-12700). Đội ngũ phát triển dự kiến sẽ đưa cơ chế tối ưu xác thực tăng tiến (mmap-once-then-incremental verify) vào phiên bản v0.6 tiếp theo để xử lý điểm nghẽn này.
Nguồn tham khảo: Xem bài gốc
