Beta9 自托管指南：Go 运行时下的 GPU 无服务器推理与沙箱
Ultrafast serverless GPU inference, sandboxes, and background jobs
秒懂
- 它是什么？
- Beta9 是 Beam 云端平台背后的开源引擎，用 Go 写了调度器、容器运行时和缓存，对外暴露 Python 装饰器。本文只依据仓库给出的材料，说明它解决什么、怎么跑起来、以及什么时候不该选它。
- 适合谁用？
- 适合已经在跑 GPU 推理或后台任务、并且有 Kubernetes 或裸机 GPU 资源可以自己运维的团队，也适合需要给 LLM 生成代码提供隔离执行环境的场景。不适合只想调用托管 API、不愿承担运行时运维成本的人，也不适合把 AGPL-3.0 代码嵌入闭源产品的团队。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Beta9 要解决的是 GPU 空闲账单
按小时租 GPU 最浪费的地方不是单价，是空转。一个推理端点白天被打满、凌晨无人访问，机器照样计费。Beta9 把这类负载做成无服务器形态：README 明确写着 Scale-to-Zero，工作负载默认按需启动，没有请求时不保留常驻容器。它的目标读者不是调 API 的应用开发者，而是手里已经有一批 GPU、想把这批卡的使用率压上去的团队。仓库描述里同时出现 faas、serverless-containers、llm-inference、fine-tuning 几个主题，说明它覆盖的不只是推理，还包括微调和后台批处理。README 给出的三个入口分别是沙箱、推理端点和任务队列，对应三类完全不同的使用方式：跑不可信代码、扛在线流量、消化离线队列。这三件事在别处通常要用三套系统拼起来。
Go 写调度与运行时，Python 只是外壳
从仓库信息看，主语言是 Go，README 里提到的组件包括自定义容器运行时、调度器和嵌入式缓存。用户侧接触到的只有 Python 包 beam-client，装饰器和上下文管理器负责把镜像、GPU 型号、CPU、内存这些参数打包成一次远程调用。以推理端点为例，@endpoint 装饰器接收 image、gpu、cpu、memory，以及 autoscaler 参数；README 的示例用 QueueDepthAutoscaler(max_containers=5, tasks_per_container=30)，意思是由队列深度决定扩缩容，最多 5 个容器，每个容器承载 30 个任务。任务队列走的是另一条路径：@task_queue 装饰器声明 name、image、cpu、memory、inputs 和 task_policy，其中 inputs 绑定一个 schema.Schema 子类做参数校验，TaskPolicy(max_retries=3) 控制重试。沙箱最简单，Sandbox(image=Image()).create() 之后调用 sandbox.process.run_code()，返回对象上取 result。三者的共同点是：开发者只描述资源需求，调度决策留在运行时里。
从 pip install 到第一次远程执行
安装只有一条命令，README 写的是 pip install beam-client。之后有两条路。第一条是托管：在 beam.cloud 注册账号，跟着 onboarding 引导走，不需要自己起任何服务。第二条是自托管，README 只给了一句「你可以免费自托管 Beta9」，没有在正文里给出部署步骤，具体命令需要去看 docs.beam.cloud 和仓库内的部署文件，这一点必须自己核实，本文无法替代。代码侧的入口是明确的。推理端点用 beam deploy app.py:my_background_task --name image-processor 这样的命令部署成带版本的端点，README 的注释里给了这个例子。后台任务可以在不部署的情况下直接从本地应用调用，写法是 my_background_task.put(image_url=...)，参数名与 schema 字段对应。沙箱不需要部署，创建即用。注意 Image(python_version="python3.11") 这类参数决定了远程容器的镜像基础，本地 Python 版本与它无关。
冷启动速度是设计目标，不是既成事实
README 把「一秒内启动容器」列为特性，并归因于自定义容器运行时、调度器和嵌入式缓存三者的组合。这是一个设计意图的陈述，不是可以外推的保证。真实冷启动时间取决于镜像大小、是否命中缓存、GPU 驱动初始化开销以及节点上是否已有可复用的容器。仓库材料里没有给出任何基准数字，也没有说明缓存命中率在什么条件下成立。工程上可以推断的是：嵌入式缓存的存在意味着首次拉取镜像和后续启动是两种不同的成本曲线，把大模型权重打进镜像的做法会直接吃掉这个优势，权重更适合放在 Volume 里，README 提到的 Volume Storage 就是为此准备的。如果你的场景对尾延迟敏感，需要自己在目标硬件上测一遍，而不是接受 README 的说法。
沙箱是隔离边界，也是责任边界
Sandbox 的定位在 README 里写得很直白：运行 LLM 生成的代码。这类代码不可信，可能死循环、可能读写文件、可能发起网络请求。Beta9 提供的是容器级隔离，创建、执行、取回结果三步。但仓库材料没有说明沙箱内的网络策略、文件系统生命周期、CPU 与内存上限如何配置，也没有说明超时后容器是被杀掉还是被回收复用。这些恰恰是沙箱能不能上生产的关键。如果你的用途只是跑一段确定性脚本，容器隔离足够；如果要执行完全由外部输入决定的代码，必须先把资源限制和网络出口策略从文档里找出来，确认它们存在并且可配置。把「有沙箱」等同于「安全」是常见误判。
AGPL-3.0 决定了它能被放在哪一层
许可证是 AGPL-3.0，不是 Apache 或 MIT。这个选择的实际含义是：如果你修改 Beta9 并通过网络向用户提供服务，AGPL 要求你向这些用户提供对应的源代码。把它当作内部基础设施、不对外暴露修改后的版本，通常不触发这一条；把它嵌进一个闭源 SaaS 产品并对外提供访问，就需要认真评估。Beam 自己采用的模式是开源引擎加托管云，README 里明确写了 Beta9 是驱动 Beam 云平台的引擎，你可以自托管，也可以买托管服务。这种双轨结构在很多基础设施项目里出现过，它意味着上游有商业动机持续维护，同时也意味着某些面向企业的功能可能只存在于托管版本。判断标准很简单：去看你需要的那个功能在开源仓库里是否完整。本文不提供法律意见，涉及分发形态时应咨询律师。
和直接上 Kubernetes 的差别在哪
最接近的替代方案是自己用 Kubernetes 加 GPU Operator 和 KEDA 拼一套。两者的差别在抽象层级。Kubernetes 给你 Pod、Deployment、HPA 这些原语，你需要自己写镜像构建流程、自己接队列深度指标、自己处理 GPU 调度和缩容到零（后者在原生 K8s 上需要额外组件）。Beta9 把这些打包成一个装饰器，代价是你接受了它的调度器、它的容器运行时和它的资源描述方式，出问题时排查路径也更长。另一个方向的替代是托管推理服务，你完全不碰基础设施，代价是单价和厂商绑定，以及无法运行需要自定义 CUDA 环境的负载。Beta9 的位置在中间：比 K8s 省事，比托管 API 可控，但需要你自己承担运行时的运维。选它之前先问一句，你的团队里有没有人能读懂 Go 写的调度器日志。
版本节奏与升级成本
仓库最近三个发布都是 worker 组件，版本号 worker-0.1.752、0.1.751、0.1.750，时间集中在 2026 年 9 月 8 日前后，间隔以小时计。这说明 worker 是活跃迭代的部分。对自托管用户来说，这意味着两件事：一是 worker 与调度器、API 之间的协议可能存在版本耦合，不能只升级其中一部分；二是 0.1.x 的版本号本身表明 API 尚未稳定，小版本之间出现不兼容变更是合理的预期。升级前应当固定住一组互相匹配的组件版本，并保留回滚路径。仓库材料没有提供兼容性矩阵或升级指南，这一点需要从 docs.beam.cloud 或发布说明中确认。如果你无法承受每月跟一次升级，托管版本会是更省心的选择。
编辑结论
适合已经在跑 GPU 推理或后台任务、并且有 Kubernetes 或裸机 GPU 资源可以自己运维的团队，也适合需要给 LLM 生成代码提供隔离执行环境的场景。不适合只想调用托管 API、不愿承担运行时运维成本的人，也不适合把 AGPL-3.0 代码嵌入闭源产品的团队。动手前先确认三件事：自托管部署文档里 scheduler、worker 与 Redis 的依赖关系，你手上的 GPU 型号是否在支持列表内，以及仓库里 worker 的发布节奏是否匹配你的升级窗口。
社区笔记