Mit KI entwickeln

Cloudflare Containers neu konzipiert für On-Demand-Sandboxes von KI-Agenten

Cloudflare hat seine Containers-Infrastruktur aktualisiert, um die Auswahl von Laufzeitimages und Dateisystem-Snapshots zu unterstützen. Dies reduziert die Startzeiten für Workloads von KI-Agenten um mehr als das Sechsfache.

Automatisch aus dem englischen Original übersetzt.

Cloudflare hat seine Containers-Plattform grundlegend neu konzipiert, um den dynamischen Anforderungen von KI-Agenten besser gerecht zu werden. Das am 30. September 2026 veröffentlichte Update führt eine neue Scheduling-Richtlinie ein, die es Anwendungscode ermöglicht, Container-Images und Instanztypen zur Laufzeit anstelle des Deployments auszuwählen. Die Änderungen zielen darauf ab, Latenznachteile der traditionellen Container-Orchestrierung zu eliminieren, sodass Sandboxes in weniger als einer Sekunde starten können.

Was passiert ist

Bisher funktionierte Cloudflare Containers ähnlich wie traditionelle Anwendungsbereitstellungen. Entwickler mussten das Container-Image und die Rechenressourcen während des Build-Prozesses definieren und jede Konfiguration als separate Anwendung bereitstellen. Dieses Modell erforderte distincte Durable Object-Namensräume für jede Kombination aus Image und Instanztyp. Wenn ein Agent sowohl eine kleine Node.js-Umgebung als auch eine große Python-Build-Umgebung benötigte, mussten Entwickler zwei separate Anwendungen verwalten und den Datenverkehr manuell zwischen ihnen routen. Jede Änderung der Umgebung erforderte einen neuen Deployment-Zyklus, was die Anpassung an die unvorhersehbaren Ressourcenbedürfnisse von KI-Agenten erschwerte.

Die neue Architektur verlagert diese Entscheidungen in die Anwendungslogik selbst. Durch die Einführung der durable_object-Scheduling-Richtlinie ermöglicht Cloudflare dem Code, das spezifische Image und die Instanzgröße auszuwählen, wenn eine Aufgabe eingeht. Dies bedeutet, dass eine einzelne Durable Object-Klasse nun verschiedene Arten von Sandboxes nebeneinander hochfahren kann. Beispielsweise kann ein Agent eine leichte Umgebung für einfache Abfragen und eine leistungsstarke Build-Umgebung für komplexe Aufgaben anfordern, ohne dass eine Vorab-Provisionierung nötig ist. Dieser Wandel verwandelt die Infrastrukturkonfiguration von einem statischen Deployment-Artefakt in dynamischen Code, der zur Anfragezeit ausgeführt wird.

Neben dieser Flexibilität hat Cloudflare das kritische Problem der Startlatenz angegangen. KI-Agenten erstellen oft Sandboxes on-demand für individuelle Aufgaben, was bedeutet, dass Benutzer auf die Initialisierung der Umgebung warten müssen, bevor die Arbeit beginnt. Das vorherige globale Control-Plane-Modell führte zu erheblichem Overhead bei der Auflösung von Konfigurationen und der Koordination der Platzierung im Netzwerk. Das neue System lokalisiert diesen Prozess und startet Container wann immer möglich auf derselben Maschine wie das steuernde Durable Object. Dies reduziert die mediane Startzeit von knapp über vier Sekunden auf 648 Millisekunden, eine mehr als sechsfache Verbesserung, die durch unabhängige Benchmarks bestätigt wurde.

Wie es funktioniert

Der Kernmechanismus, der diese Geschwindigkeit und Flexibilität ermöglicht, ist die enge Integration zwischen Containers und Durable Objects. Jede Container-Instanz ist an ein Durable Object gebunden, das als persistentes, programmierbares Steuerorgan fungiert. Im neuen Modell verwaltet das Durable Object nicht nur den Lebenszyklus; es steuert die Konfiguration des Containers direkt über die native ctx.container-API. Wenn eine Anfrage eingeht, prüft der Code die Anforderungen der Aufgabe und wählt ein Image aus einer vordefinierten Liste in der Konfigurationsdatei. Der Scheduler sucht dann zuerst nach Kapazität auf dem lokalen Host und bevorzugt Maschinen, die das erforderliche Image oder Snapshot bereits im lokalen Speicher haben, um Download-Verzögerungen zu vermeiden.

Um die Startzeiten weiter zu reduzieren, bootet die Laufzeitumgebung nicht mehr für jede Anfrage eine virtuelle Maschine von Grund auf neu. Stattdessen stellt sie eine vorbereitete virtuelle Maschine wieder her, die bereits initialisiert, aber noch nicht zugewiesen ist. Dieser Ansatz nutzt Netzwerk- und Dateisystem-Setups erneut und bündelt Operationen, die zuvor sequenziell ausgeführt wurden. Zusätzlich hat Cloudflare ein sofort einsatzbereites Systemimage namens cloudflare/debian-trixie eingeführt. Dieses Basisimage umfasst Debian Trixie Slim und Node.js 24.20.0 LTS und wird im Voraus auf den Hosts verteilt. Agenten können diese Sandbox sofort starten und anschließend Ausführungsbefehle nutzen, um Repositories zu klonen oder Pakete zu installieren, wodurch das Erstellen und Pushen eigener Docker-Images für einfache Aufgaben entfällt.

Wichtige Details

  • Laufzeitkonfiguration: Die neue durable_object-Scheduling-Richtlinie ermöglicht es dem Code, Container-Images und Instanztypen zur Laufzeit auszuwählen, wodurch separate Deployments für jeden Umgebungstyp entfallen.
  • Startleistung: Die mediane Startzeit sank von 4,049 Sekunden auf 648 Millisekunden, wobei sich das 95. Perzentil von 5,839 Sekunden auf 910 Millisekunden verbesserte.
  • Dateisystem-Snapshots: Eine Public-Beta-Funktion ermöglicht das Speichern und Wiederherstellen von Container-Dateisystemen, sodass Agenten langlaufende Aufgaben pausieren und fortsetzen können, ohne den Zustand zu verlieren oder Setup-Schritte zu wiederholen.
  • Vorbereitetes Basisimage: Das cloudflare/debian-trixie-Image ist vorab auf den Hosts verteilt, sodass Agenten eine Linux-Umgebung sofort starten können, ohne eigene Images zu bauen.
  • Burst-Kapazität: Vorläufige Tests zeigten, dass das System 100.000 Container in 5,387 Sekunden an sechs Standorten starten konnte, was eine hohe Skalierbarkeit für Burst-Workloads demonstriert.
  • Rollout-Steuerung: Rollouts werden nun über Code innerhalb des Durable Objects verwaltet, was Strategien wie Canary-Releases oder das Pinning aktiver Projekte auf spezifische Images ohne plattformseitige Konfigurationsänderungen ermöglicht.

Warum das wichtig ist

Für Ingenieure, die Plattformen für KI-Agenten entwickeln, entfernt dieses Update einen großen Engpass in der Benutzererfahrung. Traditionelle Container-Orchestrierung ist für langlaufende Dienste konzipiert, nicht für ephemere Aufgaben, die sofort starten müssen. Durch die Verlagerung der Konfiguration in die Laufzeit können Entwickler effizientere Systeme erstellen, die Ressourcen nur bei Bedarf verbrauchen. Dies ist besonders wichtig für Coding-Agenten, Evaluierungs-Frameworks und Reinforcement-Learning-Systeme, die Tausende isolierter Umgebungen erfordern. Die Fähigkeit, eine Sandbox in unter einer Sekunde zu starten, bedeutet, dass Benutzer weniger Zeit damit verbringen, auf die Provisionierung von Umgebungen zu warten, und mehr Zeit mit der Interaktion mit dem Agenten.

Die Einführung von Dateisystem-Snapshots verändert auch, wie der Zustand in serverlosen Umgebungen verwaltet wird. Zuvor erforderte das Bewahren der Arbeit eines Agenten komplexe externe Speicherlösungen oder das dauerhafte Laufenlassen von Containern, was die Kosten erhöhte. Nun kann ein Agent seinen Workspace speichern, den Container beenden und ihn später genau dort wiederherstellen, wo er aufgehört hat. Diese Funktion unterstützt asynchrone Workflows und langlaufende Aufgaben, die Tage dauern können, und macht es machbar, anspruchsvollere Agent-Anwendungen auf serverloser Infrastruktur zu bauen, ohne persistente Server verwalten zu müssen.

Was Sie tun können

  • Aktualisieren Sie Ihre wrangler.jsonc, um die durable_object-Scheduling-Richtlinie einzubinden und die Images zu deklarieren, auf die Ihr Durable Object zugreifen kann.
  • Refaktorieren Sie bestehende Container-Logik, um Images und Instanztypen basierend auf Aufgabenparametern innerhalb der Durable Object-Klasse auszuwählen.
  • Testen Sie das cloudflare/debian-trixie-Basisimage für Aufgaben, die keine eigenen Docker-Builds erfordern, um vorverteilte Assets zu nutzen.
  • Implementieren Sie Dateisystem-Snapshotting in Ihrem Workflow, um den Agenten-Zustand nach wichtigen Meilensteinen zu speichern und bei der Fortsetzung wiederherzustellen.
  • Nutzen Sie Durable Object Storage, um Rollout-Strategien zu verwalten, wie z. B. das Pinning spezifischer IDs auf ältere Images während Migrationsphasen.
  • Überwachen Sie Startmetriken über die neue ctx.container-API, um sicherzustellen, dass Ihre Agenten von den Verbesserungen beim lokalen Scheduling profitieren.

Tools aus dem Bytechap-Shop

$89

DocBento

Selbst gehostetes Dokumentenmanagement, das jeden Scan liest und mit Seitenzitaten antwortet.

Live-Demo

Weiterlesen

Alle Artikel