beta9 : un runtime serverless pour charges GPU, entre SDK Python et moteur auto-hébergé

Le problème : exécuter du code Python sur GPU sans gérer de machines

Le README positionne Beam comme un runtime open source pour charges IA serverless, avec une interface Python pour déployer et mettre à l'échelle des applications. Trois cas d'usage sont illustrés dans le dépôt. Le premier est la sandbox : lancer du code généré par un LLM dans un conteneur isolé. Le deuxième est l'endpoint d'inférence : exposer un modèle derrière une route qui s'adapte à la demande. Le troisième est la tâche de fond : traiter des images ou des files d'attente à la place d'un courtier de messages classique. Le public visé est donc l'ingénieur qui écrit du Python, mais qui doit faire tourner ce code sur des cartes graphiques louées ou possédées, avec un redémarrage rapide entre deux invocations.

La promesse du README tient en une phrase : une interface Python pour déployer et mettre à l'échelle sans surcharge d'infrastructure. Le dépôt assume aussi une double identité. Beta9 est le moteur qui alimente la plateforme managée Beam, et il peut être auto-hébergé, comme l'indique l'encadré du README. Cette dualité explique la présence d'un fichier de licence AGPL-3.0 et d'un site commercial dans la même page.

Ce que le dépôt contient réellement : Go côté moteur, Python côté utilisateur

Le langage principal déclaré est Go, tandis que tous les exemples du README sont en Python. La coupure est nette : le client que vous installez avec pip install beam-client parle à un moteur écrit en Go, qui planifie les conteneurs et gère le cache. Le README nomme trois briques internes : un runtime de conteneurs personnalisé, un ordonnanceur et un cache embarqué. C'est cette combinaison qui est présentée comme la source des démarrages rapides annoncés sous la seconde.

Les versions publiées confirment cette architecture. Les trois dernières releases listées portent le préfixe worker et un numéro de patch élevé (worker-0.1.750, 0.1.751, 0.1.752), publiées à quelques jours d'intervalle en septembre 2026. Un composant qui bouge à ce rythme est un composant qui vit, et le numéro de version indique que le moteur est encore en 0.1.x. Le matériel fourni ne détaille pas la répartition entre les services du plan de contrôle et les workers, ni les dépendances externes. Toute estimation de charge ou de coût d'exploitation à partir de ces seules informations serait une extrapolation.

Trois décorateurs, trois modèles d'exécution

Le README expose trois points d'entrée distincts, et il vaut la peine de les comparer.

La sandbox est la plus directe. On construit un objet Sandbox avec une Image, on appelle create(), puis on exécute du code par sandbox.process.run_code("print('I am running remotely')") et on lit response.result. C'est le cas d'usage du code produit par un modèle de langage : du texte arbitraire à exécuter dans un conteneur jetable.

L'endpoint est le modèle de service. Le décorateur @endpoint prend une image, un type de GPU, du CPU, de la mémoire et un autoscaler. Le README donne l'exemple d'un QueueDepthAutoscaler(max_containers=5, tasks_per_container=30) avec gpu="A10G" et memory="16Gi". Le mécanisme est explicite : la profondeur de file pilote le nombre de conteneurs, et chaque conteneur absorbe jusqu'à trente tâches. Le handler retourne ici un dictionnaire de classification factice, mais la structure est celle d'un service qui répond à des requêtes.

La file de tâches est le modèle asynchrone. Le décorateur @task_queue prend un nom, une image, des ressources, un schéma d'entrée et une TaskPolicy. Le README montre TaskPolicy(max_retries=3) et un appel my_background_task.put(image_url="..."), présenté comme un moyen d'invoquer une tâche depuis une application sans la déployer au préalable. Le même code peut ensuite être exposé derrière un endpoint versionné avec beam deploy app.py:my_background_task --name image-processor.

Mise en route : ce que le README donne, ce qu'il omet

L'installation tient en une commande : pip install beam-client. Le parcours nominal passe ensuite par la création d'un compte sur beam.cloud et par un guide de démarrage hébergé sur platform.beam.cloud/onboarding. Autrement dit, la voie la mieux documentée dans le README mène au service managé, pas à une installation locale.

Pour le code lui-même, les commandes visibles sont peu nombreuses. Le déploiement d'une file de tâches derrière un endpoint se fait avec beam deploy app.py:my_background_task --name image-processor, en commentaire dans l'exemple. Le reste passe par le décorateur : les clés de configuration nommées dans le matériel sont gpu, cpu, memory, autoscaler, image, inputs, task_policy, name, max_containers, tasks_per_container et max_retries. Ce sont ces clés, et non un fichier YAML, qui portent la configuration.

L'encadré du README indique que Beta9 peut être auto-hébergé gratuitement, mais la page fournie ne contient ni commande d'installation du moteur, ni liste de composants, ni prérequis matériels. C'est la principale lacune du document : la promesse d'auto-hébergement est affirmée sans être outillée dans le texte disponible. Un lecteur qui veut évaluer cette voie devra sortir du README et consulter la documentation du projet.

Les limites que le README ne masque pas, et celles qu'il tait

La première contrainte est structurelle : beta9 déplace le problème, il ne le supprime pas. Vous n'écrivez plus de code de planification, mais vous exploitez un moteur Go, un runtime de conteneurs et un cache. En auto-hébergement, cela reste un système distribué à faire tourner et à mettre à jour. Le rythme des releases worker (trois versions en une semaine dans les données fournies) donne la mesure du travail de suivi : ce n'est pas un binaire qu'on installe une fois.

La deuxième contrainte concerne la portabilité. Les exemples s'appuient sur des décorateurs et des objets propres au SDK : @endpoint, @task_queue, Sandbox, Image, QueueDepthAutoscaler, TaskPolicy, schema.Schema. Ce code n'est pas exécutable ailleurs tel quel. La logique métier est réutilisable, l'enveloppe ne l'est pas.

Il faut aussi noter ce que le README ne dit pas. Aucune information n'est donnée sur les limites de taille d'image, sur les quotas par compte, sur le comportement des volumes en cas de panne, ni sur la persistance des tâches en cours lors d'une mise à jour du moteur. Le README mentionne le montage de volumes de stockage distribué, sans préciser le mécanisme. Ce sont des questions à poser avant de placer une charge de production dessus, pas après.

Alternatives : Kubernetes avec KEDA, ou un service serverless classique

L'alternative la plus proche est un cluster Kubernetes auquel on ajoute un autoscaler piloté par événements, par exemple KEDA pour mettre à l'échelle sur la profondeur d'une file, plus un runtime de conteneurs adapté aux GPU. La différence tient au travail de plomberie. Avec Kubernetes, vous gardez la main sur chaque couche et vous héritez de la configuration des nœuds GPU, des pilotes, de la mise en file et du cache d'images. Avec beta9, le README annonce un runtime, un ordonnanceur et un cache intégrés, et vous écrivez surtout des décorateurs. Le prix de cette simplicité est l'adhérence au SDK et la dépendance à la feuille de route du projet.

Une plateforme serverless généraliste est l'autre option. Elle excelle sur des fonctions CPU déclenchées par HTTP, mais l'accès à un GPU, la persistance d'un volume monté et l'exécution de code arbitraire dans une sandbox y sont souvent absents ou fortement encadrés. Le README de beta9 place ces trois éléments au premier plan, ce qui dessine la frontière : beta9 vise les charges qui ont besoin d'un GPU, d'un conteneur complet ou d'un code non fiable, pas les fonctions courtes sans état.

Enfin, la plateforme managée Beam reste l'alternative interne au projet : même moteur, exploitation déléguée. Le choix se réduit donc à qui porte les mises à jour du worker.

Licence AGPL-3.0 et coût de maintenance

Le dépôt est publié sous AGPL-3.0, et le README pointe vers le fichier de licence correspondant. C'est une licence copyleft forte, avec une clause réseau : si vous exposez une version modifiée du logiciel à des utilisateurs via un réseau, des obligations de publication du code source correspondant peuvent s'appliquer. Le matériel fourni ne permet pas d'analyser les conséquences pour un usage donné, et cette question dépasse le cadre d'une fiche technique. Si vous envisagez d'intégrer beta9 dans un produit exposé à des tiers, faites examiner ce point par une personne compétente avant de construire dessus.

Sur la maintenance, les seuls éléments observables sont le rythme des releases worker et l'absence d'archive sur le dépôt. Le coût réel dépend de votre mode de déploiement : en cloud Beam, la mise à jour du moteur n'est pas votre problème ; en auto-hébergement, chaque version du worker est un composant à suivre. Le README ne décrit pas de canal de versions stables ni de politique de compatibilité entre le client pip et le moteur, ce qui rend difficile de planifier un gel de version.

Conclusion éditoriale

beta9 s'adresse aux équipes qui veulent garder le contrôle de l'exécution (sandboxes, endpoints GPU, files de tâches) sans écrire leur propre ordonnanceur, et qui acceptent d'exploiter un plan de contrôle Go. Il n'est pas le bon choix si vous cherchez uniquement un service managé sans exploitation, ou si vos charges sont de simples fonctions CPU déclenchées par HTTP : le passage par les images de conteneur et le vocabulaire GPU ajoutent de la surface pour rien. Avant de vous engager, vérifiez deux points précis dans le dépôt : la procédure d'installation auto-hébergée et la liste des composants à déployer, absentes du README fourni, puis le champ autoscaler de votre endpoint, car c'est lui qui détermine le coût réel d'un service qui reste exposé.

Sources officielles

1. beam-cloud/beta9 on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases