KI-Agenten steuern immer häufiger echte Browser in der Cloud, und genau dort wurde Tempo bisher teuer erkauft. Der Anbieter Browser Use zeigt in einem technischen Blogbeitrag[1], wie sich ein Cloud-Browser in unter einer Sekunde starten lässt. Möglich macht das eine Virtualisierungstechnik, die eigentlich für serverlose Dienste gedacht war.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Mit Firecracker packt der Dienst jede Cloud-Sitzung in eine winzige eigene virtuelle Maschine. Der Kaltstart dieser Mini-VM dauert unter 400 Millisekunden. Über die öffentliche Schnittstelle steht ein fertiger Browser im Mittel nach 825 Millisekunden bereit, im 99. Perzentil nach 1,35 Sekunden.
Das Wichtigste in Kürze
- Der Anbieter Browser Use betreibt jede Browser-Sitzung isoliert in einer eigenen Firecracker-MicroVM auf AWS EC2.
- Der Kaltstart der Mini-VM liegt unter 400 Millisekunden.
- Über die öffentliche Schnittstelle steht der Browser nach 825 Millisekunden im Mittel bereit.
- Der Preis sinkt von 0,06 auf 0,02 US-Dollar pro Browser-Stunde. Auf dem unabhängigen Ranking-Portal BrowserArena liegt Browser Use damit auf Platz eins, bei 100 Prozent Zuverlässigkeit.
Wie fährt der Browser so schnell hoch?
Firecracker startet eine Mini-VM in unter 400 Millisekunden und stellt einen pausierten Browser blitzschnell wieder her. Die Steuerung sucht eine freie Maschine, lädt das gespeicherte Browser-Abbild, startet Chromium und liefert eine Verbindungs-URL zurück.
Den größten Zeitanteil frisst nicht die VM, sondern der Browser selbst. Chromium braucht nach dem Aufwachen rund 545 Millisekunden, bis es steuerbar ist. Vorbereitete Abbilder verkürzen diesen Weg, weil das System nicht jede Sitzung von Grund auf neu aufbaut. Größere Speicherseiten von 2 statt 4 Kilobyte drücken laut Anbieter die Seitenfehler beim Wiederaufwecken einer pausierten VM von rund 100.000 auf etwa 1.100 – die Zeit bis zu einem steuerbaren Browser sinkt dadurch von 9,8 auf 3,1 Sekunden.
Ungewöhnlich ist der Unterbau. Firecracker läuft normalerweise auf nackter Server-Hardware, hier dagegen innerhalb der ohnehin virtualisierten EC2-Instanzen von AWS. Diese Verschachtelung spart Kosten, weil kein teurer Bare-Metal-Server nötig ist. Zuvor setzte Browser Use auf die Unikraft-Plattform, wechselte aber, weil dort horizontales Autoscaling über mehrere EC2-Instanzen fehlte.
Schnelle, isolierte Browser in der Cloud sind die stille Voraussetzung für brauchbare KI-Agenten. Ohne Tempo und saubere Trennung bleibt jede Automatisierung im Web ein Versprechen auf später.
— Michael Dobler, Herausgeber Dr. Web
Warum ist das für KI-Projekte relevant?
KI-Agenten, die Webseiten bedienen, brauchen pro Aufgabe einen frischen, isolierten Browser. Schneller Start und niedrige Kosten entscheiden darüber, ob solche Automatisierung im großen Stil überhaupt bezahlbar ist.
Für Unternehmen, die Recherche, Buchungen oder Tests automatisieren wollen, zählt jede Zehntelsekunde und jeder Cent pro Sitzung. Die saubere Trennung in eigene Mini-VMs senkt zugleich das Sicherheitsrisiko, weil keine Sitzung in die andere greift. Wie sich solche Agenten sinnvoll einsetzen lassen, ordnet die KI-Rubrik von Dr. Web regelmäßig ein. Tempo und Isolation sind dabei keine Kür, sondern Grundbedingung.
Der Ansatz zeigt, wie sehr KI-Anwendungen an der Infrastruktur darunter hängen. Ein Modell ist nur so nützlich wie die Umgebung, in der es handeln darf. Gut gebaute Plattformen entscheiden am Ende über die Wirtschaftlichkeit.
Quelle
[1] Browser Use: „How We Made Cloud Browsers 3x Cheaper and Faster“ ↩
2 Kommentare
„Ein Anbieter zeigt nun, …“
Wer denn nun ???
Autor Markus Seyfferth
bleibt vage.
Aussage nebulös.
Hallo Anon, danke für den Hinweis. Eigentlich stand der Name schon am Anfang des Artikels im zweiten Paragraphen: „Mit Firecracker packt der Dienst Browser „Use“ jede Cloud-Sitzung in eine winzige eigene virtuelle Maschine.“
Den Artikel haben wir nochmal verständlicher formuliert, vielen Dank also für den Kommentar!