FluxHive

研究团队常常会在临时 SSH 作业已经难以管理、却还没有准备好维护通用集群调度器时，遇到一个尴尬的中间阶段：任务彼此争抢显存，日志散落在不同机器上，也没有人能可靠地看清哪些任务正在运行、哪些仍在等待。

FluxHive 是为这个阶段设计的自托管控制面。它面向本地、实验室和云端 GPU 机器之间的训练、推理、批量实验与持续评测，同时尽量让小团队可以直接部署和提交任务。

三端系统

FluxHive 将平台拆成三个协作部分：

• Agent 与工作负载运行在同一侧，观察机器、启停进程，并持续回传状态与日志；
• Control Server 管理 Job 定义、任务下发、授权，以及每次 Run 的持久状态；
• Web Client 将控制面呈现为共享的任务提交、监控、日志与资源视图。

Agent 与服务端之间的持久连接是这套结构的关键。服务端需要在不轮询的情况下主动下发任务，Agent 也需要持续上传运行事件和 GPU 状态。显式定义这条协议，还能避免浏览器界面在演进中不知不觉变成系统真正的 API。

先定义 Job，再适配语言

平台的中心抽象是语言无关的 Job 协议，而不是只能由 Python 调用的函数封装。Python、TypeScript、Go 与 Rust SDK 提供更方便的声明接口，但协议本身仍允许其他运行时直接实现。

通过这层边界，调度系统可以根据 Manifest、资源需求、命令、环境、产物与运行事件理解一项工作。应用代码不必为了在另一台机器上运行，就导入控制服务或改造成某个分布式计算框架的程序。

基于真实资源信息调度

第一种真正有用的策略刻意保持简单：限制并发数量，并维持稳定的等待队列。在此基础上，GPU 观测才进一步支持显存感知选卡、单卡并发限制等放置决策。

这里需要明确区分已经形成的平台主干与仍在推进的策略路线图。仓库已经包含三端架构、Job 协议、执行与可观测链路；更高级的放置、恢复和实验自动化策略仍会继续演进。FluxHive 并不声称在所有规模上取代 Slurm 或 Ray，它更关心如何让小型研究计算集群在不强迫工作负载接入大型运行时的前提下，变得可见、可控。

项目带来的认识

FluxHive 让我更具体地认识到：调度的困难并不只是“下一项该选谁”，而是在机器断连、进程失败、用户重排队列、资源快照过期时，仍然维护可信的系统状态。一个真正有用的控制面不应只把队列画出来，还必须让这些状态变化可以被检查和恢复。