CLI 优先
用熟悉的命令完成排队、控制和查看。
Skip to content
gflow01 02 03 04
gflow面向共享机器的单节点调度
让一台 Linux 机器拥有真正的任务调度器
在共享工作站上，用轻量 CLI 和本地 daemon 完成 GPU 或 CPU 任务的提交、排队与查看。
- 单节点设计
- GPU 感知调度
- 基于 tmux 的执行
- 可供 Agent 使用的 MCP
可恢复
随时 attach、追踪日志、重做任务。
策略明确
明确声明 GPU、显存、优先级、预约和依赖。
$ gflowd up
daemon ready on 127.0.0.1:5577
$ gbatch --gpus 1 --project vision python train.py
submitted batch job 184
$ gqueue
JOBID NAME ST TIME GPU NODELIST(REASON)
184 train R 00:12:41 1 0
185 eval PD - 0 (WaitingForDependency)
$ gjob log 184
step=420 loss=0.184 throughput=178 img/s
队列快照
运行中04
排队中09
挂起01
GPU 策略
可见设备0,1,2,3
共享方式按显存调度
为什么需要它
当一台机器不再只属于你
一旦工作站开始共享，临时 tmux 会话和口头约定很快就会失效。
没有队列纪律时
- 长任务会和交互式工作互相打架。
- 失败后难以恢复，因为状态和日志散落在不同地方。
- GPU 使用规则只能靠经验相传。
使用 gflow 后
- 本地 daemon 统一保存状态和队列控制。
- 每个任务都有可查看、可恢复的生命周期。
- 资源和依赖在提交时明确声明。
工作流
四条命令进入可控状态
gflowd up启动本地调度器。
gbatch --gpus 1 python train.py用明确的资源声明提交命令或脚本。
gqueue查看运行中、排队中或已完成任务。
gjob log <job_id>追踪日志，或在需要时 attach 会话。
能力概览
为日常工作站使用而设计
队列与生命周期
支持提交、挂起、恢复、取消、更新与重做，并提供可检查的状态模型。
GPU 感知调度
直接声明 GPU 数量，开启共享模式，并设置显存上限。
工作流编排
通过依赖、数组任务和参数扫描组织多阶段任务。
可观测性
通过表格、树状、JSON、CSV 或 YAML 查看队列状态。
可恢复执行
每个任务都运行在独立 tmux 会话中，便于日志查看和恢复。
自动化与 AI 集成
通过本地 MCP server 暴露调度操作，供 Agent 调用。
适用场景
常见场景
共享实验室 GPU 服务器
多人共用一台机器时，用明确规则替代口头协调。
个人研究主机
让长时间实验保持结构化、可恢复。
本地评测与自动化流水线
用依赖关系串联预处理、训练、评测和汇总。
文档入口
按你的阶段开始
AI 集成
把调度操作暴露成 Agent 可调用的工具
将 gflow 作为本地 stdio MCP server 运行后，Agent CLI 可以直接查看队列并驱动调度流程。
gflow mcp serve从你已经拥有的那台机器开始调度
把这套文档当作运维手册。