[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2e4kzlm0xle83":3},{"code":4,"message":5,"data":6,"timestamp":25},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":22,"homepage":10,"updated_at":23,"history":24},"Samsara-1999\u002FBursar",8,"Accounts and quotas for a shared GPU cluster.",null,203,3,32,6,[],"在保留 SSH 工作流的前提下，为共享 Linux GPU 集群加上账户、配额与策略管理，而不是引入调度器。","如果你管理的是几台靠 SSH 共用的 Linux GPU 主机，需要按用户记账和限制用量，而不是上一整套调度器，Bursar 值得看一看。它的主要成本在运维：一个控制器、一个 PostgreSQL 数据库，以及每台计算节点上的 agent，而且目前还缺少长期部署的公开证据。细节可看[仓库 README](https:\u002F\u002Fgithub.com\u002FSamsara-1999\u002FBursar\u002Fblob\u002Fmain\u002FREADME.md)和[架构说明](https:\u002F\u002Fgithub.com\u002FSamsara-1999\u002FBursar\u002Fblob\u002Fmain\u002Fdocs\u002Farchitecture.md)。\n\n## 解决什么问题\n\n几台 GPU 机器由团队通过 SSH 共用。每台机器有人管，但没有一份集中记录：谁用了哪块 GPU、花了多少 CPU 时间、超出非正式预算后该怎么处理。要限制资源或检查可疑进程，只能逐台登录。\n\nBursar 让用户继续用 SSH，同时由控制器从各节点收集 GPU、CPU、内存、磁盘、进程、会话和 agent 健康状态。管理员可以按 GPU 型号和 CPU 核心分钟定价，设置积分池、结转、透支策略和按节点覆盖，再施加 CPU、内存、磁盘和 GPU 可见性等策略。结果是共享资源有了集中账本，也有了能对远程进程执行操作的政策层，而不需要 notebook 网关或自建作业调度器。\n\n## 有什么不同\n\nBursar 明确不替代 SSH，也不充当调度器。它把 Go 控制器放在 PostgreSQL 前面，并在每台计算节点上运行 Go agent；agent 读取操作系统、GPU、cgroup 和 SSH 状态，执行控制器下发的动作。这种拆分让它既能汇总全集群用量、又能按节点执行限制，同时保留用户原有的登录方式。agent 一侧的说明见[节点部署文档](https:\u002F\u002Fgithub.com\u002FSamsara-1999\u002FBursar\u002Fblob\u002Fmain\u002Fdocs\u002Fnode-agent.md)。\n\n除指标之外，它还加入类似计费的账务：GPU 与 CPU 核心分钟定价、积分池、结转和透支规则。对实验室或小公司来说，用这种方式协调共享集群，往往比迁移到 Slurm 或 Kubernetes 更自然。代价是它属于治理软件而非调度软件：不负责作业放置、排队预留 GPU，也不能替代网络隔离、系统加固、监控和经过验证的备份，README 本身也这样说明。\n\nREADME 还提到可选的加密同步到备用控制器，以及加密备份到独立仓库。这些功能在运维上有用，但各自依赖脚本和生命周期假设，应当作为部署计划的一部分，而不是一个勾选项。\n\n## 谁值得试\n\n适合：已有 Linux GPU 主机、使用 SSH 工作流，需要核算共享 GPU\u002FCPU 用量、审核注册、把平台账户映射到节点账户并施加限制的研究组或小公司，且不想采用完整调度器。需要临时用户或委派管理员的团队也会用到内置的身份管理。\n\n不适合：想要作业调度器、Kubernetes operator 或托管控制面的人；需要现成容器镜像的人（项目不发布镜像，两条快速开始路径都从源码构建）；以及不愿维护控制器、PostgreSQL 和每节点 agent 的团队。macOS 可作为控制器主机，但节点 agent 始终直接运行在计算节点上，需要 cgroup、systemd、SSH 和 GPU 驱动访问权限。\n\n## 使用条件与边界\n\n部署不是单个二进制文件。Docker 路径仍需 Docker Compose 和四个不同的随机密钥；源码路径还需要 Go 1.26.6、Node.js 20.20+、pnpm 10.28.2、OpenSSL 和 curl，而且 HA 与备份脚本按源码路径设计。节点 agent 不能容器化，必须逐台安装到计算主机。\n\n更大的约束是日常维护：agent、数据库迁移、密钥、备份以及可选的备用控制器都需要你自行运营。README 明确把 Bursar 定位为面向已在运行 Linux GPU 主机团队的治理工具，不能替代加固或备份。所给 README 摘录没有记录针对特定 GPU 驱动或发行版的兼容性测试，部署到整个集群前应先核对。\n\n## HotRepo 点评\n\nBursar 创建于 2026-10-18，截至 2026-10-25 在 HotRepo 新项目榜（非总榜）以 203 个总 star 排第 #8。这是一次快照，不是单日增长数据，HotRepo 的可比历史不足，无法判断热度能否持续。\n\n思路是自洽的，但在把 agent 铺到整个集群之前，应先按你实际的 GPU 驱动和 Linux 发行版组合核对文档。",{"slug":19,"name":20},"devops","运维与部署",[],"Apache-2.0","2026-10-25T03:04:31Z",[],1792906425]