DeepSeek công bố DSec: Hạ tầng sandbox chuyên dụng cho huấn luyện AI Agent

Huấn luyện mô hình lớn (Large Model) dựa vào sức mạnh tính toán (compute), còn huấn luyện Agent lại dựa vào môi trường. Làm thế nào để tạo ra môi trường đó? Bài báo mới nhất của DeepSeek với chữ ký của Lương Văn Phong (Liang Wenfeng) đã công khai các chi tiết kỹ thuật này.

Hệ thống mà DeepSeek xây dựng có tên là DSec (DeepSeek Elastic Compute), công việc của nó là tạo hàng loạt sandbox (hộp cát) để huấn luyện Agent.

Mỗi giây hệ thống có thể tạo ra hơn 5.000 sandbox, đạt 3 triệu sandbox mỗi ngày, với đỉnh điểm vận hành đồng thời 380.000 sandbox. Cụm máy chủ (cluster) đơn lẻ hỗ trợ quy mô này cũng rất khổng lồ, với khoảng 160 node, 30.000 nhân CPU và 250TB RAM.

Tại sao huấn luyện một Agent lại tốn công sức đến vậy?

Bởi vì môi trường huấn luyện mô hình lớn chỉ là cụm GPU, nạp dữ liệu và tính toán gradient, nhưng Agent thì hoàn toàn khác. Nó phải viết mã, chạy biên dịch, mở trình duyệt, thậm chí cài đặt hệ điều hành trong sandbox... Mỗi bước thực thi đều làm thay đổi trạng thái môi trường và có thể khiến môi trường bị sập bất cứ lúc nào. Vì vậy, mỗi vòng huấn luyện đều phải cung cấp cho nó một sandbox hoàn toàn mới, sạch sẽ, dùng xong là bỏ, huấn luyện xong là xóa.

Do đó, vấn đề cuối cùng vẫn quay trở lại cơ sở hạ tầng — những cơ sở hạ tầng này cần phải cài đặt hoàn chỉnh một hệ điều hành và chuỗi công cụ (toolchain) cho mỗi sandbox với tốc độ 5.000 sandbox mỗi giây. Đồng thời, không được để hàng trăm nghìn sandbox chạy đồng thời làm cạn kiệt RAM và CPU của cụm máy chủ.

Cụ thể phải làm thế nào, bài báo đã phơi bày toàn cảnh của toàn bộ quy trình kỹ thuật này.

Huấn luyện Agent cần "một thế giới"

Vấn đề cốt lõi đầu tiên mà DSec cần giải quyết là các loại tác vụ Agent khác nhau có yêu cầu cực kỳ khác biệt về môi trường sandbox, và các môi trường này phải được điều phối thống nhất trên cùng một nền tảng.

Một Agent giải bài tập OJ chỉ cần một môi trường gọi hàm (function call) không trạng thái, chạy xong lấy kết quả là được, thậm chí không cần lưu trữ hệ thống tệp.

Nhưng một Agent làm SWE-bench lại cần không gian người dùng (user space) Linux hoàn chỉnh, phải cài đặt các phụ thuộc, sửa mã, chạy pytest, thậm chí khi đang làm tác vụ dở dang có thể cần thêm các gói mới vào môi trường.

Đến các kịch bản tấn công và phòng thủ bảo mật hay computer-use, việc cách ly ở cấp độ container là không đủ. Agent cần thao tác trình duyệt hoặc thậm chí là máy tính để bàn, một Agent có lỗ hổng có thể vô tình làm treo máy chủ vật lý, vì vậy bắt buộc phải dùng máy ảo (VM).

Trường hợp cực đoan nhất là huấn luyện Agent thao tác các phần mềm thương mại, nó cần một hệ điều hành Windows hoặc macOS hoàn chỉnh, có giao diện đồ họa, có driver, gần như không khác gì một chiếc máy tính thật.

DSec chuẩn bị bốn loại backend cho bốn kịch bản này: FnCall xử lý gọi hàm không trạng thái, Container chạy Docker, MicroVM dùng Firecracker để tạo máy ảo nhẹ, và Full VM dùng QEMU để chạy hệ điều hành hoàn chỉnh.

Độ cách ly và mức tiêu thụ tài nguyên của bốn backend tăng dần, nhưng phía khung huấn luyện (training framework) chỉ nhìn thấy một Python SDK thống nhất là libdsec.

Bất kể bên dưới là container hay máy ảo, tất cả đều sử dụng cùng một giao diện để tạo sandbox, thực thi lệnh, lấy kết quả; cách gọi các bước hoàn toàn giống nhau.

Để bốn loại backend chạy được trên cùng một cụm máy chủ, tầng điều phối của nền tảng cũng phải theo kịp.

DSec chia toàn bộ chuỗi liên kết thành sáu tầng.

Chuỗi này bắt đầu từ một yêu cầu tạo sandbox của khung huấn luyện, đi qua xác thực IAM, vào API Server, sau đó công cụ điều phối (Placement Engine) sẽ chọn một node mục tiêu từ cụm máy chủ dựa trên tài nguyên còn dư, và thành phần Edge trên node đó chịu trách nhiệm thực tế việc khởi chạy loại sandbox tương ứng.

Cổng mạng và hình ảnh quản lý gói của sandbox được Aether ủy quyền thống nhất. Mọi lệnh mà Agent thực thi bên trong và mọi dòng kết quả tạo ra đều được chuyển tiếp về khung huấn luyện thông qua một thành phần giao tiếp nội bộ sandbox có tên là Chronus, giúp khung huấn luyện biết Agent đã làm đến bước nào và cần phản hồi gì.

Nhờ vào việc vượt ngưỡng tài nguyên (resource oversubscription) và triển khai mật độ cao, một node đơn lẻ có thể chứa đồng thời 3.200 container hoặc 800 MicroVM.

Làm thế nào để vận hành 3 triệu sandbox mỗi ngày?

Tuy nhiên, thách thức lớn nhất về quy mô của DSec không phải là điều phối, mà là xây dựng môi trường.

Mỗi khi sandbox khởi động, nó cần một bộ hình ảnh hệ điều hành hoàn chỉnh cộng với chuỗi công cụ, tương đương với việc cài đặt hệ điều hành cho 5.000 "máy tính" mỗi giây.

Tư duy của Docker truyền thống là đóng gói hình ảnh cơ sở, không gian làm việc và bộ công cụ thành một hình ảnh hoàn chỉnh. Giải pháp này ổn ở quy mô nhỏ, nhưng backend container của DSec đã tích lũy sử dụng 11.266 hình ảnh cơ sở và 102.171 không gian làm việc, 67,8% sandbox cần chồng thêm ít nhất một lớp không gian làm việc hoặc bộ công cụ lên trên hình ảnh cơ sở.

Với sự đa dạng này, một khi một bộ công cụ được cập nhật, tất cả các hình ảnh kết hợp chứa nó đều phải được xây dựng lại, chi phí là O(m·N).

Cách làm của DSec là chia môi trường thành ba lớp hình ảnh chỉ đọc EROFS độc lập: hình ảnh cơ sở, không gian làm việc và bộ công cụ, mỗi lớp được đánh phiên bản riêng biệt và kết hợp theo yêu cầu khi sandbox khởi động thông qua overlayfs. Việc cập nhật bộ công cụ chỉ ảnh hưởng đến lớp đó, chi phí giảm xuống còn O(m)+O(k).

Sau khi hình ảnh được tạo xong, làm thế nào để chuyển đến các node cũng quan trọng không kém. Theo trực giác, nên kéo hình ảnh về bộ nhớ đệm cục bộ trước, nhưng bài báo đã thống kê dữ liệu vận hành thực tế:

Hình ảnh container Python là 6,0GB, nhưng Agent thực tế chỉ đọc 6,0% dữ liệu trong đó;

Hình ảnh Java là 12,1GB, chỉ 9,2% được truy cập;

Hình ảnh C++ là 4,9GB, chỉ 8,7% được truy cập.

Nghĩa là, phần lớn nội dung hình ảnh, Agent từ đầu đến cuối thậm chí còn không chạm vào.

Vì vậy, DSec chọn cách tải theo yêu cầu (on-demand loading), hình ảnh được lưu trữ ở định dạng EROFS trên 3FS (hệ thống tệp phân tán Fire-Flyer), siêu dữ liệu được lấy trước về cục bộ, các khối dữ liệu chỉ được kéo từ 3FS khi sandbox thực sự đọc đến.

Nhóm DeepSeek đã đo đạc thực tế, việc triển khai đột ngột 8.192 container chỉ mất 35 phút với cách tải theo yêu cầu, trong khi việc kéo lạnh (cold pull) của Docker mất hơn 60 phút.