DeepSeek công bố nghiên cứu mới về huấn luyện Agent với sự tham gia của Lương Văn Phong

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400">

23-09-2026 15:29:50 Nguồn: QbitAI

Có khả năng tạo ra hơn 5.000 sandbox mỗi giây

Kexie, đưa tin từ Aofeisi, QbitAI | Tài khoản chính thức QbitAI

Huấn luyện mô hình lớn dựa vào sức mạnh tính toán, còn huấn luyện Agent 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 sự đứng tên của Lương Văn Phong (Liang Wenfeng) đã công khai các chi tiết kỹ thuật.

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à sản xuất hàng loạt sandbox cho việc huấn luyện Agent.

Nó có thể tạo ra hơn 5.000 sandbox mỗi giây, đạ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 đơ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 vất vả đến vậy?

Bởi vì môi trường huấn luyện mô hình lớn là cụm GPU, chỉ cần 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ể làm sập môi trường 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à hủy.

Do đó, vấn đề xoay quanh đi quẩn lại vẫn quay về 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ụ 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 bộ bức tranh 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ôi trường gọi hàm không trạng thái (stateless), chạy xong lấy kết quả là được, thậm chí không cần hệ thống tệp bền vững.

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

Đến các kịch bản bảo mật tấn công/phòng thủ và computer-use, sự cô lập ở cấp độ container là không đủ. Agent cần thao tác trên 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ể làm treo máy chủ vật lý, nên bắt buộc phải dùng máy ảo.

Trường hợp cực đoan nhất là huấn luyện Agent thao tác trên 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 sử dụng Firecracker để tạo máy ảo nhẹ, và Full VM sử dụng QEMU để chạy hệ điều hành đầy đủ.

Mức độ cô lập và tiêu tốn tài nguyên của bốn backend tăng dần, nhưng khung huấn luyện chỉ nhìn thấy một SDK Python thống nhất là libdsec.

Bất kể tầng dưới là container hay máy ảo, đều sử dụng giao diện giống nhau để 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 đồng nhất.

Để bốn backend này chạy trên cùng một cụm, 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 quy trình thành sáu tầng.

Chuỗi này bắt đầu từ yêu cầu tạo 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) chọn một node mục tiêu từ cụm dựa trên tài nguyên dư thừa, và thành phần Edge trên node đó chịu trách nhiệm 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 Agent thực thi và mỗi dòng kết quả tạo ra đều được chuyển tiếp qua một thành phần giao tiếp nội bộ sandbox có tên là Chronus về khung huấn luyện, giúp khung biết Agent đã thực hiện đế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 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 không vấn đề gì ở 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, với 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ở.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗