beam-cloud/beta9: Serverless-GPU-Runtime mit eigenem Container-Startpfad
Ultrafast serverless GPU inference, sandboxes, and background jobs
Auf einen Blick
- Was ist das?
- Beta9 ist die Go-Engine hinter Beam. Sie kombiniert Sandboxes, Inferenz-Endpunkte und Task-Queues in einer Python-Oberfläche. Der Reiz liegt im schnellen Containerstart, der Preis in der AGPL-Lizenz und in der Frage, wie viel Betrieb man selbst tragen will.
- Für wen ist es gedacht?
- Wer Sandboxes für LLM-generierten Code, autoskalierende Inferenz-Endpunkte und Retry-fähige Hintergrundjobs in einer einzigen Python-Datei bündeln will, findet in beta9 ein kohärentes Modell. Wer seinen Cluster bereits über Kubernetes mit GPU-Operator und KEDA betreibt, gewinnt durch einen Wechsel wenig, weil beta9 einen eigenen Scheduler mitbringt.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Lücke beta9 schließt
Die drei Arbeitslasten, die das README nennt, haben unterschiedliche Betriebsprofile. Eine Inferenz-Anfrage soll sofort einen Container bekommen und danach wieder verschwinden. Eine Sandbox soll länger leben, damit generierter Code darin schrittweise ausgeführt werden kann. Ein Hintergrundjob soll bei einem Fehler erneut anlaufen, ohne dass der Aufrufer die Wiederholung selbst implementiert. Klassisches FaaS deckt meist nur den ersten Fall ab und lässt den Aufrufer bei Timeouts und Wiederholungen allein. Genau an dieser Stelle setzt beta9 an: Die drei Muster teilen sich dieselbe Bild- und Deployment-Beschreibung, unterscheiden sich aber im Lebenszyklus.
Die Zielgruppe ist im README eng umrissen. Es ist eine Python-Oberfläche für Teams, die Modelle oder generierten Code betreiben und dafür keine eigene Scheduler-Schicht schreiben wollen. Das Decorator-Modell setzt voraus, dass der aufrufende Code in Python vorliegt. Für Go, Rust oder Java gibt es in der gezeigten Oberfläche keinen entsprechenden Einstieg.
Der Decorator als Vertrag zwischen Code und Scheduler
Das Muster ist in allen drei Beispielen identisch. Eine Funktion wird mit @endpoint, @task_queue oder über Sandbox dekoriert, dazu kommen image, cpu, memory und gpu als Parameter. Diese Parameter sind kein Kommentar, sondern der Vertrag, den der Scheduler beim Start eines Containers auswertet. Der Handler selbst bekommt im Task-Beispiel zusätzlich context übergeben, was darauf hindeutet, dass Laufzeitinformationen in die Funktion gereicht werden können.
Beim Endpunkt-Beispiel fällt die Autoskalierung auf. QueueDepthAutoscaler(max_containers=5, tasks_per_container=30) koppelt die Anzahl der Container an die Tiefe der Warteschlange und legt zugleich fest, wie viele Aufgaben ein einzelner Container abarbeiten soll. Das ist eine andere Logik als CPU- oder Speicherauslastung als Skalierungssignal. Bei kurzen Anfragen reagiert die Warteschlangentiefe direkter, weil sie nicht auf ein Messintervall warten muss. Der Preis: Die Zahl 30 muss zur tatsächlichen Batch-Größe des Modells passen. Ist sie zu hoch, staut sich Arbeit in einem Container. Ist sie zu niedrig, starten mehr Container als nötig.
Der Task-Teil zeigt das Gegenmodell zur Warteschlange. TaskPolicy(max_retries=3) beschreibt, wie oft eine fehlgeschlagene Ausführung wiederholt wird. Das ist die Stelle, an der beta9 die Resilienz übernimmt, die bei Celery typischerweise in der Anwendungskonfiguration liegt. Das Schema Input mit schema.String() dient als Eingabetyp für den Aufruf. Der Aufruf selbst erfolgt über my_background_task.put(image_url=...), also ohne vorheriges Deployment. Alternativ nennt das README beam deploy app.py:my_background_task --name image-processor, um die Funktion hinter einem versionierten Endpunkt bereitzustellen.
Sandbox: Container als Objekt im Python-Prozess
Das Sandbox-Beispiel ist das kürzeste und das aufschlussreichste. Sandbox(image=Image()).create() liefert ein Objekt, auf dem process.run_code("print('I am running remotely')") aufgerufen wird. Der Rückgabewert response.result enthält die Ausgabe. Der Container wird also nicht über ein Deployment beschrieben, sondern als Ressource im laufenden Python-Prozess erzeugt.
Für LLM-generierten Code ist das der passende Zuschnitt, weil der Aufrufer die Ausführungsschritte einzeln steuern kann und nicht bei jeder Änderung ein neues Deployment auslösen muss. Das README zeigt allerdings nur einen einzigen Aufruf. Ob die Sandbox zwischen mehreren run_code-Aufrufen Zustand hält, ob sie einen Timeout hat und wie sie beendet wird, geht aus dem Material nicht hervor. Wer diesen Pfad produktiv nutzen will, muss das in der Dokumentation unter docs.beam.cloud prüfen, bevor er sich auf das Objektmodell verlässt.
Was das README über den Unterbau sagt und was nicht
Die Feature-Liste nennt drei Bausteine, die den schnellen Start erklären sollen: eine eigene Container-Runtime, einen Scheduler und eingebettetes Caching. Das ist eine ungewöhnliche Kombination, weil die meisten Serverless-Plattformen auf der Container-Runtime des Hosts aufsetzen. Ein eigener Startpfad kann den Overhead senken, den ein Standard-Runtime beim Anlegen von Namespaces und Netzwerk mitbringt. Er verlangt aber auch, dass das Betriebsteam diesen Pfad selbst aktualisiert, wenn Sicherheitslücken in Kernel oder Runtime bekannt werden.
Die Aussage "Launch containers in under a second" steht ohne Messbedingungen im README. Ob das für einen kalten Start ohne zwischengespeichertes Image gilt oder für einen bereits vorgewärmten Knoten, lässt sich aus dem Material nicht beantworten. Die Angabe sollte man als Entwicklungsziel lesen, nicht als Zusage für die eigene Hardware.
Deutlicher ist, was fehlt. Es gibt keinen Abschnitt zu Persistenz, keine Angabe zu Netzwerk-Isolation zwischen Mietern, keine Erwähnung von Multi-Tenancy-Grenzen und keine Beschreibung, wie der Scheduler GPU-Knoten auswählt. Volume Storage wird in der Feature-Liste genannt, aber ohne Beispiel für das Einbinden. Für eine Plattform, die fremden Code in Containern ausführt, sind das die Fragen, die vor einem Self-Hosting-Versuch zu klären sind.
Installation und der erste Lauf
Der Einstieg ist knapp dokumentiert. pip install beam-client installiert den Client. Danach folgt laut README die Kontoerstellung auf beam.cloud und der Onboarding-Link. Das ist die managed Variante: Der Client spricht mit dem gehosteten Dienst, ohne dass ein eigener Cluster existiert.
Für den Self-Hosting-Pfad nennt das README nur die Existenz der Möglichkeit, nicht die Schritte. Es gibt kein docker compose, kein Helm-Chart und kein Installationsskript im gezeigten Material. Wer self-hosted betreiben will, muss die Anleitung in der Dokumentation suchen. Die Repositories der Releases tragen Namen wie worker-0.1.752, was darauf hindeutet, dass Worker-Komponenten unabhängig vom Rest versioniert werden. Ein Upgrade betrifft also möglicherweise nur einen Teil des Systems, nicht das Ganze. Das ist für den Betrieb angenehm, macht aber die Frage wichtiger, welche Client-Version zu welcher Worker-Version passt. Das README beantwortet sie nicht.
Grenzen und der Fall, in dem beta9 das falsche Werkzeug ist
Die AGPL-3.0 ist die erste Grenze, die auffällt. Wer beta9 als Bestandteil eines eigenen Dienstes betreibt und Nutzern über ein Netzwerk zugänglich macht, muss die Lizenzbedingungen prüfen. Das README behandelt das nicht, und ich gebe dazu keine Rechtsberatung. Es ist aber der Punkt, an dem viele Teams eine Entscheidung treffen müssen, bevor sie Code schreiben.
Die zweite Grenze ist die Sprache. Die gezeigte Oberfläche ist Python. Ein Team, dessen Dienste in Go oder TypeScript geschrieben sind, müsste einen Python-Dienst dazwischen setzen, nur um Endpunkte und Tasks zu definieren. Der Nutzen sinkt dadurch, weil die Warteschlange dann über eine Sprachgrenze hinweg angesprochen wird.
Die dritte Grenze betrifft die Arbeitslast. Für lang laufende Trainingsjobs mit Checkpointing ist eine Plattform, die auf Skalierung auf null und kurze Container ausgelegt ist, nicht der richtige Ort. Das README nennt fine-tuning als Topic, beschreibt aber keinen Trainingsablauf. Wer einen Job über Stunden laufen lässt, braucht Persistenz und Wiederaufsetzpunkte, und dazu findet sich im Material nichts. Für diesen Fall ist ein klassischer Job-Scheduler die passendere Wahl.
Der Vergleich mit Kubernetes plus KEDA
Der naheliegende Gegensatz ist ein eigener Kubernetes-Cluster mit GPU-Operator, KEDA für die Skalierung nach Warteschlangentiefe und einem Job-Controller für Wiederholungen. Der Unterschied liegt nicht im Ergebnis, sondern im Aufwand und in der Kontrolle. In dieser Kombination definiert das Team jede Skalierungsregel selbst, kann aber auch jede Regel anpassen: Pod-Affinität, Taints für GPU-Knoten, Netzwerkrichtlinien, Ressourcenquoten pro Namespace. beta9 nimmt diese Entscheidungen ab und ersetzt sie durch Parameter wie max_containers und tasks_per_container.
Für ein kleines Team mit einer überschaubaren Zahl von Endpunkten ist der zweite Weg kürzer. Für eine Plattform, die viele Teams mit unterschiedlichen Anforderungen bedient, ist die fehlende Sichtbarkeit in die Scheduling-Entscheidungen ein Nachteil, weil sich Probleme nur über die Dokumentation und nicht über eigene Konfiguration lösen lassen. Ein zweiter Vergleichspunkt sind die Sandboxes selbst. Modell-Anbieter bieten ähnliche isolierte Ausführungsumgebungen als gehosteten Dienst an, ohne dass man einen Cluster betreiben muss. beta9 unterscheidet sich davon dadurch, dass die Sandbox neben Endpunkten und Tasks im selben Modell liegt und self-hosted laufen kann. Wer nur gelegentlich generierten Code ausführen will, fährt mit einem gehosteten Sandbox-Dienst günstiger.
Wartung, Releases und was vor dem ersten Deployment zu prüfen ist
Die Release-Kadenz ist hoch. Innerhalb von drei Tagen erscheinen worker-0.1.750, 0.1.751 und 0.1.752. Für Betreiber bedeutet das, dass ein Update-Pfad eingeplant werden muss, bevor der erste Container läuft. Ob die Worker-Versionen untereinander kompatibel sind und ob der Client eine bestimmte Worker-Version voraussetzt, steht nicht im README. Wer self-hosted betreibt, sollte das vor dem Upgrade in den Release Notes prüfen und nicht nachträglich feststellen, dass ein Endpunkt nicht mehr startet.
Für die managed Variante entfällt dieser Teil, dafür wandert die Abhängigkeit zum Anbieter. Das README positioniert Beam als den gehosteten Dienst und beta9 als die Engine darunter. Diese Trennung ist ehrlich beschrieben und hilft bei der Entscheidung. Sie bedeutet aber auch, dass die Self-Hosting-Dokumentation der Ort ist, an dem sich zeigt, wie vollständig das Projekt außerhalb der eigenen Cloud ist. Genau diese Dokumentation ist im vorliegenden Material nicht enthalten. Der sinnvollste erste Schritt ist deshalb kein Deployment, sondern ein Blick in docs.beam.cloud auf die Abschnitte zu Self-Hosting, GPU-Auswahl und Volume-Einbindung, bevor eine einzige Zeile Produktionscode entsteht.
Redaktionelles Fazit
Wer Sandboxes für LLM-generierten Code, autoskalierende Inferenz-Endpunkte und Retry-fähige Hintergrundjobs in einer einzigen Python-Datei bündeln will, findet in beta9 ein kohärentes Modell. Wer seinen Cluster bereits über Kubernetes mit GPU-Operator und KEDA betreibt, gewinnt durch einen Wechsel wenig, weil beta9 einen eigenen Scheduler mitbringt. Vor dem ersten Deployment zu klären: ob der Betrieb die AGPL-3.0-Pflichten im eigenen Geschäftsmodell akzeptiert, ob die dokumentierte GPU-Auswahl zur eigenen Hardware passt und ob der eigene Code LLM-generierte Programme in einer Sandbox ausführen muss, denn genau dort liegt der stärkste Unterschied zu klassischen FaaS-Plattformen.
Community-Notizen