Samsara-1999/Bursar

如果你管理的是几台靠 SSH 共用的 Linux GPU 主机，需要按用户记账和限制用量，而不是上一整套调度器，Bursar 值得看一看。它的主要成本在运维：一个控制器、一个 PostgreSQL 数据库，以及每台计算节点上的 agent，而且目前还缺少长期部署的公开证据。细节可看仓库 README和架构说明。

解决什么问题

几台 GPU 机器由团队通过 SSH 共用。每台机器有人管，但没有一份集中记录：谁用了哪块 GPU、花了多少 CPU 时间、超出非正式预算后该怎么处理。要限制资源或检查可疑进程，只能逐台登录。

Bursar 让用户继续用 SSH，同时由控制器从各节点收集 GPU、CPU、内存、磁盘、进程、会话和 agent 健康状态。管理员可以按 GPU 型号和 CPU 核心分钟定价，设置积分池、结转、透支策略和按节点覆盖，再施加 CPU、内存、磁盘和 GPU 可见性等策略。结果是共享资源有了集中账本，也有了能对远程进程执行操作的政策层，而不需要 notebook 网关或自建作业调度器。

有什么不同

Bursar 明确不替代 SSH，也不充当调度器。它把 Go 控制器放在 PostgreSQL 前面，并在每台计算节点上运行 Go agent；agent 读取操作系统、GPU、cgroup 和 SSH 状态，执行控制器下发的动作。这种拆分让它既能汇总全集群用量、又能按节点执行限制，同时保留用户原有的登录方式。agent 一侧的说明见节点部署文档。

除指标之外，它还加入类似计费的账务：GPU 与 CPU 核心分钟定价、积分池、结转和透支规则。对实验室或小公司来说，用这种方式协调共享集群，往往比迁移到 Slurm 或 Kubernetes 更自然。代价是它属于治理软件而非调度软件：不负责作业放置、排队预留 GPU，也不能替代网络隔离、系统加固、监控和经过验证的备份，README 本身也这样说明。

README 还提到可选的加密同步到备用控制器，以及加密备份到独立仓库。这些功能在运维上有用，但各自依赖脚本和生命周期假设，应当作为部署计划的一部分，而不是一个勾选项。

谁值得试

适合：已有 Linux GPU 主机、使用 SSH 工作流，需要核算共享 GPU/CPU 用量、审核注册、把平台账户映射到节点账户并施加限制的研究组或小公司，且不想采用完整调度器。需要临时用户或委派管理员的团队也会用到内置的身份管理。

不适合：想要作业调度器、Kubernetes operator 或托管控制面的人；需要现成容器镜像的人（项目不发布镜像，两条快速开始路径都从源码构建）；以及不愿维护控制器、PostgreSQL 和每节点 agent 的团队。macOS 可作为控制器主机，但节点 agent 始终直接运行在计算节点上，需要 cgroup、systemd、SSH 和 GPU 驱动访问权限。

使用条件与边界

部署不是单个二进制文件。Docker 路径仍需 Docker Compose 和四个不同的随机密钥；源码路径还需要 Go 1.26.6、Node.js 20.20+、pnpm 10.28.2、OpenSSL 和 curl，而且 HA 与备份脚本按源码路径设计。节点 agent 不能容器化，必须逐台安装到计算主机。

更大的约束是日常维护：agent、数据库迁移、密钥、备份以及可选的备用控制器都需要你自行运营。README 明确把 Bursar 定位为面向已在运行 Linux GPU 主机团队的治理工具，不能替代加固或备份。所给 README 摘录没有记录针对特定 GPU 驱动或发行版的兼容性测试，部署到整个集群前应先核对。

HotRepo 点评

Bursar 创建于 2026-10-18，截至 2026-10-25 在 HotRepo 新项目榜（非总榜）以 203 个总 star 排第 #8。这是一次快照，不是单日增长数据，HotRepo 的可比历史不足，无法判断热度能否持续。

思路是自洽的，但在把 agent 铺到整个集群之前，应先按你实际的 GPU 驱动和 Linux 发行版组合核对文档。