beta9 を自前で動かす前に読む、Beam のサーバーレス GPU ランタイムの輪郭
Ultrafast serverless GPU inference, sandboxes, and background jobs
ひと目でわかる
- これは何？
- beam-cloud/beta9 は Beam のクラウドを支えるオープンソースの実行エンジンで、Python のデコレータから GPU 付きコンテナを起動する。README とリポジトリの構成から読み取れる範囲で、仕組みと導入判断の境界を整理する。
- 誰に向いている？
- 採用を検討すべきなのは、Kubernetes の上に自前の GPU スケジューラを組む代わりに、Python のデコレータだけでコンテナの起動とスケールを扱いたいチームだ。逆に、GPU を持たずマネージドの Beam を使うつもりなら、beta9 を自前で動かす理由は薄い。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
beta9 が埋めるのは、GPU コンテナの起動待ちという隙間
サーバーレスで GPU を使うとき、多くのチームが最初にぶつかるのは、モデルの推論ロジックそのものではなく、コンテナを立ち上げて GPU を割り当てるまでの待ち時間だ。README は beta9 を「fast, open-source runtime for serverless AI workloads」と位置づけ、特徴の先頭に「Fast Cold Starts」を挙げている。カスタムのコンテナランタイム、スケジューラ、組み込みキャッシュによってコンテナを 1 秒未満で起動すると説明されている。対象読者は、推論エンドポイント、LLM が生成したコードを走らせるサンドボックス、画像処理のようなバックグラウンドジョブを、Kubernetes のマニフェストを書きながら組み立てたくない開発者だ。README が示す 3 つのユースケースはこの順に対応しており、いずれも Python のコードから直接デプロイする形になっている。
デコレータが実行単位を決め、autoscaler がコンテナ数を決める
beta9 の中心にあるのは Python のデコレータで、関数に実行環境の指定をまとめて付ける。推論エンドポイントの例では @endpoint に対して image、gpu="A10G"、cpu=2、memory="16Gi" を渡し、autoscaler として QueueDepthAutoscaler(max_containers=5, tasks_per_container=30) を指定する。名前のとおりキューの深さを見てコンテナ数を決める仕組みで、1 コンテナあたり 30 タスクを目安に、最大 5 コンテナまで広げるという指定だ。バックグラウンド処理は @task_queue で定義し、name、image、cpu、memory、inputs、task_policy を渡す。inputs には schema.Schema を継承したクラスを指定し、task_policy=TaskPolicy(max_retries=3) で再試行回数を決める。呼び出し側は my_background_task.put(image_url=...) のように書くだけで、デプロイせずにタスクを投入できる。デプロイする場合は README のコメントにあるとおり beam deploy app.py:my_background_task --name image-processor のようにファイルと関数を指定する。関数のシグネチャに context が現れる点も見逃せない。ハンドラは入力と実行コンテキストの両方を受け取る前提で書かれている。
サンドボックスは同じランタイムを分離された実行環境として使う
Sandbox は、LLM が生成したコードを走らせる用途を README が明示している数少ない機能だ。Sandbox(image=Image()).create() で環境を作り、sandbox.process.run_code("print('I am running remotely')") のように文字列を渡して実行し、response.result で結果を受け取る。注目したいのは、エンドポイントやタスクキューと同じ Image の指定を共有している点だ。つまりサンドボックスは別系統の仕組みではなく、beta9 のコンテナ起動の経路をそのまま分離された実行単位として使っていると読める。任意のコードを実行する前提の機能である以上、分離の強度がどこで担保されているかは README からは分からない。ここは導入前に docs.beam.cloud の該当ページで確認すべき箇所で、推測で補うべきではない。
セルフホストかマネージドか、同じコードが別の運用になる
README は Self-Hosting vs Cloud の節で、beta9 が Beam のマネージドクラウドを動かしているオープンソースのエンジンであり、無料でセルフホストできるか、Beam のマネージドホスティングを選べると説明している。この二択は単なる料金の違いではない。GPU の調達、コンテナランタイムの運用、スケジューラの監視が自分の側に来るかどうかの違いだ。README は GPU について「Run on our cloud (4090s, H100s, and more) or bring your own GPUs」と書いており、マネージド側では 4090 や H100 が選べる一方、セルフホストでは自分で GPU を用意する前提になっている。クライアントは pip install beam-client で入る。つまり同じ Python コードを、自分のクラスタに向けるか Beam のクラウドに向けるかを後から選べる構造になっている。
AGPL-3.0 であることが、社内利用と対外提供を分ける
beta9 のライセンスは AGPL-3.0 で、README のバッジもこれを示している。AGPL は、ソフトウェアを改変してネットワーク越しに利用者へ提供する場合に、その改変版のソースを開示する方向に働く条項を含むことで知られる。社内の推論基盤として動かすだけなら影響は限定的だが、beta9 を組み込んだサービスを外部に提供する形を取るなら、この条件が設計に影響する。ここで注意したいのは、beta9 本体のライセンスと、beta9 を使ってデプロイした自分のモデルやアプリのコードのライセンスは別物だという点だ。とはいえ、どこまでが派生著作物に当たるかの判断は事例ごとに異なる。特定の構成での扱いについては、オープンソースのライセンスに通じた法務の確認が必要で、この記事で結論を出せる話ではない。
worker のバージョン番号が示す更新の速さ
リポジトリの直近リリースは worker-0.1.752、worker-0.1.751、worker-0.1.750 で、いずれも 2026 年 9 月 8 日付、最後のプッシュは 2026 年 9 月 10 日となっている。同じ日に 3 つのバージョンが並んでいることは、worker コンポーネントのリリース間隔が短いことを示す。これは活発さの裏返しであり、セルフホストする側にとっては追従コストの話でもある。0.1.x という番号からは、API がまだ安定版の約束に達していない可能性が読み取れる。実際のところ、どのバージョン間で互換性が壊れるのかは提供された情報からは判断できない。運用に組み込むなら、どのバージョンを固定するかを決め、更新のたびに差分を確認する前提で臨むほうが現実的だ。
Celery や独自のスケジューラと何が違うのか
バックグラウンド処理の比較対象として README 自身が挙げているのは Celery だ。「replace your Celery queue」という表現で、タスクキューをデコレータ一つで置き換える発想を示している。両者の違いは実行環境の扱いにある。Celery はワーカープロセスを自分で用意し、そのワーカーが動くマシンの資源を前提にタスクを流す。beta9 はタスクごとにコンテナのイメージ、CPU、メモリを指定し、必要なら GPU も付ける。タスクの入力は schema.Schema で型として宣言し、再試行は TaskPolicy(max_retries=3) で指定する。つまりキューとデプロイの境界がなく、タスク定義がそのまま実行環境の定義になる。すでに Celery で CPU 中心のジョブを安定運用していて、GPU を必要としないなら、置き換える動機は薄い。逆に、GPU を使うジョブをキューに混ぜたいがためにワーカーのノードプールを分けているような構成なら、beta9 のモデルのほうが記述量は少なくなる。
導入前に確かめるべき 3 つのこと
最初に確認するのはセルフホストの依存関係だ。README はセルフホストが可能だと述べるだけで、必要なコンポーネントの一覧も手順も書いていない。docs.beam.cloud のセルフホスト手順を読み、自分のクラスタで再現できるかを確認する必要がある。次に、GPU の調達だ。bring your own GPUs とある以上、セルフホストでは GPU ノードを自分で用意する。A10G を指定する例が README にあるが、手元にその型がなければ別の型に読み替えることになる。3 つ目は、エンドポイントとタスクキューがそれぞれどうスケールするかの実測だ。QueueDepthAutoscaler の max_containers と tasks_per_container は数値で指定するが、その値が自分のワークロードで妥当かは documentation を読んだだけでは分からない。向いているのは、Python で書きながら GPU コンテナの起動待ちを減らしたいチームだ。向かないのは、推論をマネージド API で完結させたい場合や、AGPL の条件を満たす形での外部提供をまだ設計できていない段階のプロダクトだ。
編集部の結論
採用を検討すべきなのは、Kubernetes の上に自前の GPU スケジューラを組む代わりに、Python のデコレータだけでコンテナの起動とスケールを扱いたいチームだ。逆に、GPU を持たずマネージドの Beam を使うつもりなら、beta9 を自前で動かす理由は薄い。また AGPL-3.0 のため、改変した beta9 をネットワーク越しに提供する形のサービスを計画している場合は、ライセンス条件を先に確認する必要がある。最初に確かめるべきは、docs.beam.cloud のセルフホスト手順に書かれた依存コンポーネントの一覧と、worker のバージョン番号が短期間に何度も上がっている事実が自分の運用に許容できるかどうかだ。
コミュニティノート