Wir haben früh darauf gewettet, dem LLM die Möglichkeit zu geben, beliebigen Code auszuführen. In diesem Beitrag geht es darum, warum wir diese Wette eingegangen sind und was es bedeutet, Tausende dieser Sandboxes gleichzeitig zu betreiben, die so schnell hoch- und runtergefahren werden, wie Nutzer Chats mit dem Agenten starten und beenden.
Jede Konversation, die ein Nutzer mit dem Adapt-Agenten führt, wird von einem eigenen Computer unterstützt. Nicht nur irgendein eingeschränkter Container auf einem gemeinsam genutzten Server, sondern eine isolierte VM, mit der das Modell tun kann, was immer es will: Software installieren, Programme schreiben und ausführen, im Web surfen, mit APIs kommunizieren. Wir nennen diese Sandboxes, und sie sind eines der grundlegenden Elemente, auf denen Adapt aufbaut.
Volle Kontrolle
LLMs sind Programmiergenies, und meine Aufgabe bestand größtenteils darin, die perfekte Entwicklerumgebung für sie zu schaffen.
Der übliche Weg, eine KI mit der Außenwelt zu verbinden, besteht darin, Integrationen von Hand zu bauen – einen maßgeschneiderten Connector für GitHub, einen weiteren für HubSpot, einen für Stripe – oder darauf zu warten, dass jeder Dienst einen MCP-Server bereitstellt. Das ist nicht skalierbar, und ich habe wenig Lust, Tag für Tag Integrationscode zu schreiben.
Anstatt diese Arbeit selbst zu erledigen, lassen wir das Modell sie machen. Jeder Dienst, der eine API bereitstellt, kann von Adapt aus aufgerufen werden, weil wir dem LLM alles geben, was es zum Schreiben des Skripts oder Programms benötigt, das mit dieser API kommuniziert. Das ist ein wesentlicher Teil dessen, was wir meinen, wenn wir Adapt als „horizontale Intelligenz“ bezeichnen: Es ist nicht an eine feste Liste von Tools gebunden, sondern kann das benötigte Tool bei Bedarf sofort selbst erstellen.
Grundlegend dafür ist, dem LLM vollen Zugriff auf die Sandbox zu geben. Anstatt dem Modell einen statischen Satz an Sprachen und CLI-Tools mit eingeschränktem Zugriff auf das Dateisystem zu geben, gewähren wir ihm kompletten Zugriff auf alles. Es läuft als Root. Und während unsere Sandboxes mit gängigen Runtimes wie Node und Python ausgeliefert werden, was ist, wenn das beste SDK für die API eines Dienstes in Go geschrieben ist? Das Modell kann es einfach installieren und ausführen.
Muss das LLM ein Go-Programm schreiben? Nur zu, installiere Go und führe es aus.
Wenn wir dem Modell also erlauben, alles zu installieren, was es will, und Code auszuführen, den kein Mensch überprüft hat, wie sichern wir das ab? Glücklicherweise sind wir nicht die Ersten, die unsicheren Code ausführen mussten. Es gibt zwei sehr beliebte sichere Runtimes genau dafür: gVisor und Firecracker. Unsere bisherige Reise hat uns mit beiden sehr vertraut gemacht.
Von gVisor zu Firecracker
Unser erster Vorstoß in sichere Sandboxes für LLMs war der „einfache“ Ansatz: Jede Sandbox mit gVisor auf GKE (Google Kubernetes Engine) auszuführen, unter Verwendung von GKE Sandbox. Wir betreiben bereits alle unsere anderen Dienste auf GKE, daher war dies der natürliche Schritt für uns.
gVisor sitzt zwischen einem Container und dem Host-Kernel. Anstatt einem Programm zu erlauben, Systemaufrufe direkt an den echten Linux-Kernel zu richten – das Ding, an dem man auf keinen Fall unsicheren Code herumspielen lassen möchte –, fängt gVisor diese Aufrufe in einem eigenen User-Space-Kernel ab und bedient sie selbst. Man erhält den Großteil des Komforts eines normalen Containers mit einer deutlich kleineren Angriffsfläche. Und GKE Sandbox verpackt das alles. Man stellt Pods (Container) bereit, und sie laufen transparent unter gVisor, ohne dass wir viel an der Infrastruktur konfigurieren müssen.
Und das funktionierte anfangs sehr gut. Wir definierten die „Basis“-Sandbox als Docker-Image und ließen GKE sie auf die Anzahl der Sandboxes skalieren, die wir zu einem bestimmten Zeitpunkt benötigten. Updates für die Software, mit der die Sandboxes ausgeliefert wurden, waren einfache Dockerfile-Updates und eine Versionsanpassung in einem Manifest.
Hunderte von Sandbox-Pods, die unter GKE Sandbox laufen.
Aber dieselbe Abstraktion, die gVisor einfach machte, war diejenige, gegen die wir ständig ankämpften. Da gVisor die Linux-Systemaufruf-Oberfläche im User-Space neu implementiert, verhält sich nicht alles genau so, wie es auf einem echten Kernel der Fall wäre, und die Workloads, die sich unser Modell ausdenkt, sind so unvorhersehbar, wie Workloads nur sein können. Das Abfangen, das einem Sicherheit verschafft, kostet einen bei Systemaufruf- und I/O-intensiven Arbeiten Leistung. Und sich für den gesamten Lebenszyklus auf GKE zu verlassen bedeutete, dass die Teile, die wir am meisten kontrollieren wollten – Bootzeit, Packdichte, Netzwerk und wie aggressiv wir Maschinen recyceln –, die Teile waren, über die wir am wenigsten Kontrolle hatten. Der „OutOfcpu“-Pod oben ist die Art von Dingen, die man sieht, wenn man den Scheduler eines anderen stärker beansprucht, als er es möchte.
Das hat uns zu Firecracker getrieben.
Firecracker-MicroVMs sind echte virtuelle Maschinen, jede mit ihrem eigenen Gast-Kernel, die mit Hardware-Virtualisierung laufen, aber so weit reduziert sind, dass sie in einem Bruchteil einer Sekunde mit nur wenigen Megabyte Overhead booten. Es ist dieselbe Technologie, die AWS entwickelt hat, um eine enorme Anzahl von Lambda- und Fargate-Workloads auf gemeinsam genutzter Hardware unterzubringen. Sie bietet uns eine stärkere Isolationsgrenze als ein gemeinsam genutzter Kernel, bootet schnell genug, um sich sofort anzufühlen, und ist klein genug, um viele davon auf einem einzigen Host unterzubringen.
Der Kompromiss ist, dass Firecracker einem eine VM gibt und nicht viel mehr. Es gibt keine Ebene im GKE-Stil, die das Scheduling, das Networking und die Orchestrierung des Lebenszyklus übernimmt. Also haben wir eine gebaut und nennen sie „orc“.
Das rootfs ist nur ein Image
Eine Sache, die wir beim Wechsel weg von Containern nicht aufgeben wollten, war die Definition einer Sandbox als einfaches Dockerfile. Container machen das trivial; VMs tun das traditionell nicht, da eine MicroVM ein Root-Dateisystem bootet und kein OCI-Image.
Also schlägt orc die Brücke zwischen beidem. Wenn es aufgefordert wird, eine VM zu erstellen, nimmt es ein gewöhnliches Docker/OCI-Image und generiert daraus im laufenden Betrieb das Root-Dateisystem der VM. Dabei wird das Ergebnis zwischengespeichert, sodass spätere Bootvorgänge desselben Images schnell sind. Unsere Basis-Sandbox ist immer noch nur ein Dockerfile, und orc verwandelt es bei Bedarf in ein bootfähiges rootfs.
Das hält unseren Workflow identisch mit den GKE-Tagen: Dockerfile bearbeiten, neue Sandbox bereitstellen, während man auf echten VMs darunter läuft. Und es öffnet eine Tür, durch die wir gerade erst zu gehen beginnen. Da jedes OCI-Image zu einer MicroVM werden kann, können wir Sandboxes von anderen Images als dem Standard-Image booten. Möchtest du eine VM, in der Postgres und pgvector bereits integriert sind? Weise orc auf dieses Image hin, und du erhältst es als eigene isolierte Maschine. Die Sandbox hört auf, eine einzige feste Umgebung zu sein, und wird zu „welchem Image auch immer der Job benötigt, gebootet als eigene VM“.
Ausführung in großem Maßstab
Und hier ist der Punkt, der dies zu einem wirklich schwierigen Problem macht: Jeder Chat erhält seine eigene Sandbox. Eine Maschine pro Konversation. Zu jedem Zeitpunkt haben wir Tausende davon aktiv, und diese Zahl steht niemals still. Jedes Mal, wenn jemand einen Chat öffnet, muss eine Sandbox erscheinen; jedes Mal, wenn ein Chat verstummt, muss eine verschwinden, damit wir nicht dafür bezahlen. Wir fahren ständig Sandboxes hoch und runter.
Zwei Zahlen dominieren alles: wie schnell wir eine Sandbox bereitstellen können und wie viele wir auf einen Host bekommen.
Start-Latenz. Eine Firecracker-MicroVM bootet in wenigen hundert Millisekunden. Das ist schnell genug, dass wir überhaupt keinen „warmen“ Pool vorhalten müssen, was einer der stilleren Vorteile des Wechsels ist. Unter GKE hätten wir freie Kapazitäten vorhalten müssen, um die Startzeit zu verbergen. Mit orc ist eine frische Sandbox bereit, bevor man es bemerkt, also erstellen wir einfach eine bei Bedarf, wenn ein Chat beginnt, und fahren sie herunter, wenn der Chat beendet ist. Kein leerlaufender Pool mehr, um den man sich kümmern oder für den man bezahlen muss.
Dichte. Da jede MicroVM winzig ist, können wir viele davon auf einen physischen Host packen. Wir dimensionieren die CPU und den Arbeitsspeicher jeder Sandbox auf das, was sie tatsächlich benötigt, anstatt Ressourcen zu überprovisionieren – das ist es, was uns ermöglicht, Tausende von ihnen wirtschaftlich zu betreiben.
orc selbst ist bewusst klein gehalten. Es ist eine Steuerungsebene, die eine einfache API spricht: Erstelle eine VM mit N vCPUs und M Megabyte Arbeitsspeicher aus einem gegebenen Image, streame Befehle hinein, lies und schreibe Dateien darin, markiere sie mit Labels, damit wir sie später finden können, und lösche sie, wenn wir fertig sind. Jeder Gast führt einen winzigen Init-Prozess als PID 1 aus und erhält sein eigenes isoliertes Netzwerk. Das ist das Wesentliche. Die Magie ist kein einzelner cleverer Trick, sondern dass diese Grundelemente langweilig und schnell genug sind, um eine ganze Flotte damit zu betreiben.
Der Lohn für all diese Arbeit ist das, womit wir begonnen haben: ein Modell, das alles installieren, ein Programm schreiben, eine API aufrufen und dir eine Antwort zurückgeben kann – alles auf einem echten Computer.
