Beta9 自架評測：用 Go 寫的 serverless GPU runtime，從 sandbox 到 task queue 的實際取捨
Ultrafast serverless GPU inference, sandboxes, and background jobs
秒懂
- 它是什麼？
- Beta9 是 Beam 雲端平台背後的開源引擎，提供 Python 介面的 serverless GPU 推論、sandbox 與背景任務。本文只根據 README 與 release 資訊，拆解它的機制、部署指令、AGPL-3.0 授權限制，以及什麼情況下你該改用別的方案。
- 適合誰用？
- 如果你已經有 GPU 機器、需要把 LLM 產生的程式碼放進隔離容器執行，或想把 Celery 佇列換成帶 GPU 排程的版本，Beta9 值得先在自己的機器上跑一次 self-host 流程再決定。若你只想託管模型、不想維運 scheduler 與 worker，直接用 Beam 雲端或其他託管服務會省事得多。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Beta9 要解的問題：GPU 閒置與容器啟動太慢
多數團隊把模型跑起來不難，難的是讓它只在有請求時才佔用 GPU。傳統做法是常駐一個推論服務，GPU 整天空轉；或者用一般的容器平台，冷啟動要幾十秒，對互動式應用等於不可用。Beta9 的定位就在這個縫隙：README 把它描述為「a fast, open-source runtime for serverless AI workloads」，並強調「Fast Cold Starts」，說法是透過自製的 container runtime、scheduler 與 embedded caching，讓容器在不到一秒內啟動。目標讀者是已經有 GPU 或願意租 GPU、但不想自己寫排程層的 Python 開發者。它的三個原語對應三種常見需求：Sandbox 用來跑 LLM 生成的程式碼，endpoint 用來做 autoscaling 的推論服務，task_queue 用來取代 Celery 這類背景任務系統。這三件事過去通常要三套不同的基礎設施，Beta9 把它們收在同一個 Python 套件裡。
Sandbox、endpoint、task_queue：三種原語的實際寫法
Sandbox 的用法在 README 裡只有五行：從 beam 匯入 Image 與 Sandbox，用 Image() 建立映像後呼叫 .create()，再對 sandbox.process.run_code() 傳入字串，結果從 response.result 取回。這個 API 形狀說明了它的用途：把不可信的程式碼丟到遠端容器執行，本地只拿回傳值。endpoint 裝飾器則把參數直接攤在裝飾器上，gpu 指定型號，cpu 與 memory 給資源額度，autoscaler 傳入 QueueDepthAutoscaler(max_containers=5, tasks_per_container=30)，意思是佇列深度驅動擴縮，最多 5 個容器，每個容器同時處理 30 個任務。task_queue 裝飾器多了 inputs 與 task_policy 兩個參數：inputs 接一個 schema.Schema 子類別做輸入驗證，task_policy 用 TaskPolicy(max_retries=3) 控制重試次數。README 的範例還示範了兩條路徑，一條是在應用程式裡直接呼叫 my_background_task.put(...) 而不部署，另一條是用 beam deploy app.py:my_background_task --name image-processor 部署成帶版本號的 endpoint。這個雙軌設計是它跟單純任務佇列最大的差別：同一個函式可以當內部呼叫用，也可以對外變成 HTTP 端點。
從 pip install 到部署：實際會打到的指令與設定鍵
安裝只有一行：pip install beam-client。README 的 Quickstart 接著要求你先到 beam.cloud 註冊帳號，再走 platform.beam.cloud 的 onboarding 流程。這裡有個容易忽略的分岔：走完 onboarding 等於在用 Beam 的託管雲，而不是自架。想自架的人要改讀 Self-Hosting 那一段，README 只寫了「You can self-host Beta9 for free」，沒有把安裝步驟攤在首頁，實際指令得回到 docs.beam.cloud 或 repository 裡找。部署階段的指令是 beam deploy app.py:my_background_task --name image-processor，格式是檔案路徑加冒號再加函式名。設定方面，能從 README 確認的鍵值都在裝飾器上：image、gpu、cpu、memory、autoscaler、inputs、task_policy、name。Image 物件本身接受 python_version，範例用的是 python3.11。記憶體寫法有兩種，endpoint 範例用字串 "16Gi"，task_queue 範例用整數 1024，兩種都出現在官方範例裡，實際單位差異請以文件為準。GPU 型號在 endpoint 範例中是 "A10G"，Features 段落則提到雲端提供 4090、H100 等選項，並支援 bring your own GPUs。
自架 Beta9 與用 Beam 雲端的真實分界
README 用一段引言把兩者關係講白了：Beta9 是驅動 Beam 這個 fully-managed cloud platform 的開源引擎，你可以免費自架，也可以選擇託管。這句話的實務含義是，自架版本與商業版本共用同一套程式碼，但維運責任完全不同。自架要自己處理 scheduler、worker 與容器執行環境，而 release 列表顯示 worker 元件的版本節奏相當快，worker-0.1.750、0.1.751、0.1.752 三個版本集中在 2026 年 9 月 8 日到 9 月 8 日之間發布，間隔以小時計。這種發布密度對自架團隊是成本：你要嘛跟著升，要嘛接受落後。反過來說，如果你的工作負載本來就在自己的 GPU 上，自架省下的是推論資料不出門這條合規理由，以及雲端按用量計費的變動成本。README 沒有提供任何自架與雲端的成本比較數字，任何這類估算都得自己算。
AGPL-3.0 對自架團隊意味著什麼
repository 標示的授權是 AGPL-3.0，README 的 badge 也指向同一份授權檔。這是整個評估裡最需要先釐清的一點。AGPL 與 GPL 的差別在於網路使用條款：如果你修改 Beta9 並把它當成網路服務提供給他人使用，通常需要以同授權釋出你的修改。對內部自用、不對外提供服務的團隊，這個條款的實際壓力小得多；如果你打算把 Beta9 包進商業產品再轉售，或修改後以 SaaS 形式對外開放，就得先讓法務看過。這裡不提供法律意見，只指出這個授權選擇與專案的商業模式一致：Beam 同時賣託管雲，AGPL 讓競爭者難以直接拿開源版去做託管生意。如果你需要在閉源產品裡嵌入這類 runtime，這是採用前必須先解決的阻礙，而不是事後補救的細節。
什麼時候 Beta9 是錯的工具
第一種情況是你要的是單一模型的長期常駐服務。Beta9 的預設是 serverless 與 scale-to-zero，這個設計在流量稀疏時省錢，在流量持續滿載時反而多了一層排程與冷啟動的變數。第二種情況是你的團隊沒有維運容器平台的人力。自架需要有人負責 scheduler、worker 與映像快取，README 沒有提供自架的完整操作手冊，這部分得自己從 repository 與文件拼出來。第三種情況是硬體不在支援範圍內。README 只列出 4090、H100 與 A10G 這些型號，其他加速卡是否可用，材料裡沒有答案。第四種情況是延遲預算極緊。README 聲稱冷啟動在一秒以內，但這是專案自己的說法，沒有第三方數據佐證，如果你的 SLA 要求的是穩定的毫秒級尾延遲，冷啟動模型本身就不適合，該用常駐服務加排隊。
替代方案：Ray Serve、Modal 與 Celery 的差異在哪
如果你的核心需求是分散式 Python 推論，Ray Serve 走的是完全不同的路：它是一個通用分散式運算框架上的服務層，你要自己定義 deployment 與 replica，擴縮邏輯由你寫，好處是對模型並行、多模型組合這類複雜拓樸的控制力更細。Beta9 把擴縮收進 QueueDepthAutoscaler 這一個參數，換來的是少寫程式、少一層抽象。若你不想碰基礎設施，Modal 這類全託管服務與 Beam 雲端同屬一條路線，差別在於 Beta9 讓你把同一份程式碼搬回自己的機器，這是託管服務給不了的。至於背景任務，README 明確把 task_queue 定位成「replace your Celery queue」的選項，Celery 是純 CPU 世界的成熟佇列，生態與 broker 選擇多；Beta9 的差異在於任務本身可以指定 GPU 與映像，代價是你被綁進它的部署模型，Celery 那種用 Redis 或 RabbitMQ 自組的彈性就沒有了。
版本節奏與升級成本
release 列表只涵蓋 worker 元件，最新三筆是 worker-0.1.752、0.1.751、0.1.750，時間落在 2026 年 9 月 8 日前後。這透露兩件事：專案仍在活躍開發，且版本號停在 0.1.x，尚未進入 1.0。對自架團隊來說，0.x 意味著介面與行為都還可能變動，升級前該看 release notes 而不是只看版本號。README 提到的 hot-reloading 與 webhooks 屬於開發體驗功能，但它們是否跨版本穩定，材料裡沒有說明。實務上，如果你的部署依賴某個特定 worker 版本的行為，就該把版本號固定住，而不是跟著 main 分支走。這也是評估自架與託管的一個隱藏成本差異：託管方會替你吸收升級，自架方要自己決定何時升、升了之後重測哪些路徑。
編輯結論
如果你已經有 GPU 機器、需要把 LLM 產生的程式碼放進隔離容器執行，或想把 Celery 佇列換成帶 GPU 排程的版本，Beta9 值得先在自己的機器上跑一次 self-host 流程再決定。若你只想託管模型、不想維運 scheduler 與 worker，直接用 Beam 雲端或其他託管服務會省事得多。動手前先確認三件事：AGPL-3.0 是否與你的產品授權相容、你的環境能否跑起官方支援的安裝路徑、以及你的 GPU 型號是否落在支援清單內。README 只列出 4090 與 H100，其他卡種請在 issue 或文件裡查清楚再投入。
社群筆記