Chúng tôi đã sớm đặt cược vào việc trao cho LLM khả năng chạy các đoạn mã tùy ý. Bài viết này nói về lý do tại sao chúng tôi thực hiện nước đi đó, và cần những gì để vận hành hàng nghìn môi trường sandbox như vậy cùng lúc, khởi tạo và tắt đi nhanh chóng ngay khi người dùng bắt đầu và kết thúc cuộc trò chuyện với tác nhân (agent).
Mỗi cuộc trò chuyện mà người dùng thực hiện với tác nhân Adapt đều được hỗ trợ bởi máy tính riêng của nó. Không chỉ là một container bị khóa chặt trên máy chủ dùng chung, mà là một máy ảo (VM) biệt lập mà mô hình có thể làm bất cứ điều gì nó muốn: cài đặt phần mềm, viết và chạy chương trình, duyệt web, giao tiếp với các API. Chúng tôi gọi đây là các sandbox, và chúng là một trong những nguyên lý cốt lõi mà Adapt được xây dựng dựa trên đó.
Toàn quyền kiểm soát
Các LLM là những thiên tài lập trình, và công việc của tôi phần lớn là xây dựng môi trường phát triển hoàn hảo để chúng làm việc.
Cách thông thường để kết nối AI với thế giới bên ngoài là tự xây dựng các tích hợp, một trình kết nối riêng cho GitHub, một cái khác cho HubSpot, một cái khác cho Stripe, hoặc chờ đợi từng dịch vụ phát hành máy chủ MCP. Cách này không thể mở rộng được, và tôi thực sự không muốn viết mã tích hợp ngày này qua ngày khác.
Vì vậy, thay vì tự mình làm công việc đó, chúng tôi để mô hình tự thực hiện. Bất kỳ dịch vụ nào cung cấp API đều có thể được truy cập từ Adapt, bởi vì chúng tôi cung cấp cho LLM mọi thứ nó cần để viết tập lệnh hoặc chương trình giao tiếp với API đó. Đó là một phần quan trọng trong ý nghĩa khi chúng tôi gọi Adapt là một "trí tuệ nằm ngang" (horizontal intelligence): nó không bị gắn chặt vào một danh sách công cụ cố định, nó có thể tự xây dựng công cụ cần thiết ngay tại chỗ.
Nền tảng của việc này là cung cấp cho LLM toàn quyền truy cập vào sandbox. Thay vì đưa cho mô hình một tập hợp ngôn ngữ và công cụ CLI tĩnh với quyền truy cập hạn chế vào hệ thống tệp, chúng tôi cung cấp cho nó quyền truy cập hoàn toàn vào mọi thứ. Nó chạy dưới quyền root. Và trong khi các sandbox của chúng tôi đi kèm với các runtime phổ biến như Node và Python, thì sao nếu SDK tốt nhất cho API của một dịch vụ nào đó lại được viết bằng Go? Mô hình có thể cứ thế cài đặt và chạy nó.
LLM có cần viết một chương trình Go không? Cứ việc cài đặt Go và chạy nó thôi.
Vậy nếu chúng tôi cho phép mô hình cài đặt bất cứ thứ gì nó muốn và thực thi mã mà chưa con người nào kiểm duyệt, làm thế nào để chúng tôi bảo mật nó? May mắn thay, chúng tôi không phải là những người đầu tiên cần chạy mã không xác định. Có hai runtime bảo mật rất phổ biến cho chính mục đích này: gVisor và Firecracker. Hành trình của chúng tôi cho đến nay đã giúp chúng tôi làm quen rất kỹ với cả hai.
Từ gVisor đến Firecracker
Bước đầu tiên của chúng tôi vào các sandbox bảo mật cho LLM là cách tiếp cận "dễ dàng": chạy mỗi sandbox với gVisor trên GKE (Google Kubernetes Engine), sử dụng GKE Sandbox. Chúng tôi đã chạy tất cả các dịch vụ khác của mình trên GKE, vì vậy đây là bước đi tự nhiên đối với chúng tôi.
gVisor nằm giữa một container và kernel của máy chủ. Thay vì để một chương trình thực hiện các lệnh gọi hệ thống (system call) trực tiếp đến kernel Linux thực, thứ mà bạn thực sự không muốn mã không xác định đụng vào, gVisor chặn các lệnh gọi đó trong một kernel không gian người dùng (user-space kernel) của riêng nó và tự xử lý chúng. Bạn nhận được hầu hết sự tiện lợi của một container thông thường với bề mặt tấn công nhỏ hơn nhiều. Và GKE Sandbox đóng gói tất cả những thứ này lại. Bạn triển khai các Pod (container) và chúng chạy một cách minh bạch dưới gVisor mà chúng tôi không cần phải thực hiện nhiều cấu hình cơ sở hạ tầng.
Và cách này đã hoạt động rất tốt lúc ban đầu. Chúng tôi định nghĩa sandbox "cơ sở" là một image Docker và để GKE mở rộng nó ra số lượng sandbox mà chúng tôi cần tại bất kỳ thời điểm nào. Các bản cập nhật cho phần mềm mà sandbox đi kèm chỉ đơn giản là cập nhật Dockerfile và tăng phiên bản trong tệp manifest.
Hàng trăm Pod sandbox chạy dưới GKE Sandbox.
Nhưng chính sự trừu tượng hóa giúp gVisor trở nên dễ dàng lại là thứ chúng tôi liên tục gặp khó khăn. Vì gVisor triển khai lại bề mặt syscall của Linux trong không gian người dùng, không phải mọi thứ đều hoạt động chính xác như trên một kernel thực, và các khối lượng công việc mà mô hình của chúng tôi nghĩ ra lại khó dự đoán nhất có thể. Việc chặn các lệnh gọi giúp bạn an toàn nhưng lại gây tốn kém cho các công việc nặng về syscall và I/O. Và việc dựa vào GKE cho toàn bộ vòng đời có nghĩa là những phần chúng tôi muốn kiểm soát nhất như thời gian khởi động, mật độ đóng gói, mạng, và mức độ tích cực khi tái chế máy móc, lại là những phần chúng tôi ít có quyền kiểm soát nhất. Pod OutOfcpu đi lạc ở trên là kiểu vấn đề bạn bắt đầu thấy khi đẩy bộ lập lịch của người khác vượt quá giới hạn mà nó mong muốn.
Đó là điều đã thúc đẩy chúng tôi đến với Firecracker.
Các microVM Firecracker là các máy ảo thực sự, mỗi cái có kernel khách riêng, chạy với ảo hóa phần cứng, nhưng được tinh giản để khởi động trong tích tắc với chỉ vài megabyte bộ nhớ đệm. Đó là cùng một công nghệ mà AWS đã xây dựng để đóng gói số lượng lớn các khối lượng công việc Lambda và Fargate lên phần cứng dùng chung. Nó cung cấp cho chúng tôi ranh giới cô lập mạnh mẽ hơn so với một kernel dùng chung, khởi động đủ nhanh để cảm thấy tức thì, và đủ nhỏ để đóng gói rất nhiều máy trên một máy chủ vật lý.
Điểm đánh đổi là Firecracker chỉ cung cấp cho bạn một máy ảo và không gì khác. Không có lớp kiểu GKE nào thực hiện lập lịch, mạng và điều phối vòng đời. Vì vậy, chúng tôi đã tự xây dựng một cái và gọi nó là orc.
Rootfs chỉ là một image
Một điều chúng tôi không muốn từ bỏ khi chuyển khỏi container là định nghĩa sandbox dưới dạng một Dockerfile đơn thuần. Container làm cho việc đó trở nên tầm thường; máy ảo truyền thống thì không, vì một microVM khởi động một hệ thống tệp gốc (root filesystem), chứ không phải một OCI image.
Vì vậy, orc kết nối cả hai. Khi được yêu cầu tạo một máy ảo, nó lấy một image Docker/OCI thông thường và tạo hệ thống tệp gốc của máy ảo từ đó ngay lập tức, lưu vào bộ nhớ đệm kết quả để các lần khởi động sau của cùng một image đó diễn ra nhanh chóng. Sandbox cơ sở của chúng tôi vẫn chỉ là một Dockerfile, và orc biến nó thành một rootfs có thể khởi động khi có yêu cầu.
Điều đó giúp quy trình làm việc của chúng tôi giống hệt như thời còn dùng GKE: chỉnh sửa Dockerfile, phát hành sandbox mới, trong khi vẫn chạy trên các máy ảo thực bên dưới. Và nó mở ra một cánh cửa mà chúng tôi chỉ mới bắt đầu bước qua. Vì bất kỳ OCI image nào cũng có thể trở thành một microVM, chúng tôi có thể khởi động các sandbox từ các image khác ngoài image mặc định. Bạn muốn một máy ảo đã cài sẵn Postgres và pgvector? Hãy trỏ orc vào image đó và bạn sẽ có nó như một máy biệt lập của riêng mình. Sandbox không còn là một môi trường cố định duy nhất mà trở thành "bất kỳ image nào mà công việc cần, được khởi động như một máy ảo riêng biệt."
Thực thi ở quy mô lớn
Và đây là điều khiến vấn đề này thực sự khó khăn: mỗi cuộc trò chuyện đều có sandbox riêng. Một máy cho mỗi cuộc trò chuyện. Tại bất kỳ thời điểm nào, chúng tôi có hàng nghìn sandbox đang hoạt động, và con số đó không bao giờ đứng yên. Mỗi khi ai đó mở một cuộc trò chuyện, một sandbox phải xuất hiện; mỗi khi cuộc trò chuyện im ắng, một sandbox phải biến mất để chúng tôi không phải trả phí cho nó. Chúng tôi liên tục khởi tạo và tắt các sandbox.
Hai con số chi phối mọi thứ: tốc độ chúng tôi chuẩn bị một sandbox nhanh đến mức nào, và chúng tôi có thể nhét bao nhiêu sandbox vào một máy chủ.
Độ trễ khởi động. Một microVM Firecracker khởi động trong vài trăm mili giây. Tốc độ đó đủ nhanh để chúng tôi không cần giữ một nhóm sandbox "ấm" (warm pool) nào cả, đây là một trong những chiến thắng thầm lặng của việc chuyển đổi. Dưới GKE, chúng tôi đã phải giữ lại công suất dự phòng để che giấu thời gian khởi động. Với orc, một sandbox mới sẽ sẵn sàng trước khi bạn kịp nhận ra, vì vậy chúng tôi chỉ tạo sandbox theo yêu cầu khi cuộc trò chuyện bắt đầu và gỡ bỏ nó khi cuộc trò chuyện kết thúc. Không còn nhóm sandbox nhàn rỗi nào để trông coi hay trả phí nữa.
Mật độ. Vì mỗi microVM rất nhỏ, chúng tôi có thể đóng gói rất nhiều sandbox trên một máy chủ vật lý. Chúng tôi định cỡ CPU và bộ nhớ của mỗi sandbox theo nhu cầu thực tế thay vì cấp phát dư thừa, đây chính là điều cho phép chúng tôi chạy hàng nghìn sandbox một cách kinh tế.
Bản thân orc được thiết kế nhỏ gọn một cách có chủ đích. Nó là một mặt phẳng điều khiển (control plane) giao tiếp qua một API đơn giản: tạo một máy ảo với N vCPU và M megabyte bộ nhớ từ một image nhất định, truyền các lệnh vào đó, đọc và ghi tệp bên trong nó, gắn nhãn để chúng tôi có thể tìm thấy nó sau này, và xóa nó khi hoàn tất. Mỗi máy khách chạy một tiến trình init nhỏ dưới dạng PID 1 và có mạng biệt lập riêng. Đó là hầu hết mọi thứ. Phép thuật không nằm ở bất kỳ thủ thuật thông minh nào, mà là ở chỗ các nguyên lý này đủ nhàm chán và đủ nhanh để vận hành cả một đội quân sandbox.
Phần thưởng cho tất cả những công việc hạ tầng này chính là thứ mà chúng tôi đã bắt đầu: một mô hình có thể cài đặt bất cứ thứ gì, viết một chương trình, truy cập một API, và trả lại cho bạn câu trả lời, tất cả đều trên một máy tính thực.
