1. 从“机器堆着吃灰”到“算力随手取”：openrig到底解决了什么
先说一个很多跑AI工作负载的团队都会遇到的状态：机器越来越多，利用率却一直上不去。
我在过去两年里帮几个朋友看过他们内部的工作站和自建服务器，普遍情况是这样的——一台双卡机器用来跑模型推理，另一台四卡机器用来做微调，还有两三台零散的机器装着手头的备用卡。硬件都是好东西，但问题在于每台机器都像一座孤岛。谁要用哪台卡，靠群里吼一声；安排任务靠共享表格人工登记；跑起来以后没人知道显存还剩多少，新任务只能先试跑一下，跑不动再换机器。更头疼的是环境互相污染，同一个Python环境里同时存在过 TensorFlow 1.x 和 PyTorch 2.x 的残留依赖，一升级就炸一片。
openrig 这个名字第一次出现时，我以为又是个包装过的监控面板，真正翻完它的设计思路才发现，它更接近一台“算力中心的轻量化操作系统”。它的核心不是监控，也不是单纯的容器管理，而是把分散的GPU/NPU设备抽象成一个统一的资源池，然后在这个池子上做任务排队、环境快照、设备调度和状态回传。
打个生活化的比方：以前你管理GPU像管理一抽屉乱放的工具，螺丝刀和扳手混在一起，用的时候翻半天；openrig做的事情就是给每种工具一个固定卡位，并且在前台加了一个“借出/归还”的登记台，谁拿了、谁还在用、什么时候还，一目了然。
这篇文章适合谁看？如果你手里有1到8张卡，想让这些卡真正被用起来；如果你被“环境冲突、撞卡、不知道机器在干嘛”这三件事折磨过；如果你想从手动管理向半自动、全自动调度过渡但又不想引入Kubernetes那种重型方案，那openrig这套思路值得你花十几分钟看完。下面我会从它的模块设计、部署实操、真实运行表现、常见坑点一路讲到可以怎么玩出更多花样。
2. openrig的核心模块拆解：设备池、调度器、任务描述与状态机
openrig不是一个单一的可执行文件，它更像一组配合紧密的服务。拿我实际使用的版本来说，安装完成之后主要存在这样几个角色：一个控制面服务（control plane）、一个运行在每台设备上的代理（agent）、一个命令行工具，以及一个可选的Web面板。控制面负责保存所有设备状态、任务队列和调度决策；代理负责在具体机器上执行任务、收集资源占用并上报。
2.1 设备池：把零散的卡收编成统一资源
openrig把“设备”抽象成两层。物理层就是一台台机器，逻辑层则是机器上可分配的加速卡。我手里有三台机器，第一台有2张A6000，第二台有4张4090，第三台有1张A100，openrig初始化之后，控制面看到的是一个包含7个“计算槽位”的资源池，而不是三台孤立主机。
这里有个细节值得注意：openrig允许你对每张卡打标签。例如把“卡1到卡3”标记为group=gpu-16g，把“卡4到卡7”标记为group=gpu-24g，调度的时候可以直接按标签筛选。这一点在后面的任务编排里非常有用，因为不是所有训练脚本都能在所有显卡上跑通，尤其是依赖显存大小的Batch Size设置。
设备接入控制面之后，代理会周期性上报三个数据：利用率、显存占用、温度/功耗。这些数据不只是展示用，而是调度器做决策的依据。比如某张卡利用率已经打满且显存剩余不足2GB，新任务默认就不会再往这张卡上塞。
2.2 调度器：它凭什么决定任务去哪张卡
openrig内置的调度器支持几种策略，我用表格归纳一下：
| 策略 | 调度逻辑 | 适合场景 |
|---|---|---|
| 首次适配（first-fit） | 按设备列表顺序找第一张满足资源要求的卡 | 卡型号一致、负载不高的小团队 |
| 最少任务（least-loaded） | 统计当前每张卡的任务数，选最少的 | 大量短任务交替执行 |
| 显存余量（memory-aware） | 按剩余显存最多的卡优先分配 | 推理服务、大Batch训练 |
| 标签亲和（label-affinity） | 优先匹配任务描述的标签条件 | 异构集群、有明确型号要求 |
默认配置下我建议用 memory-aware，它对混合型号的机器最友好。调度器在给一个任务分配设备时，会检查三样东西：任务声明的设备数量、每张卡最小显存、标签约束。只有三项都满足，任务才会进入“已分配”状态。
有个反直觉的细节：openrig不会在任务运行时调整分配，哪怕CPU核数和内存不够，它也只保证显存和设备数满足。这一点在使用时要特别留意，如果你是大显存小内存的机器，比如一张A6000但整机只有32GB内存，跑数据加载很重的训练任务，openrig照样会分配，直到任务自己OOM。所以任务描述文件里额外声明内存需求，是有必要的。
2.3 任务描述：一个YAML把事情讲清楚
openrig把一次计算任务描述成一个YAML文件，我习惯称之为“任务单”。字段不算多，最核心的几个是：
name: finetune-llama-7b image: registry.internal/base/pytorch:2.1-gpu command: ["bash", "train.sh"] entrypoint: /workspace/run_entry.py devices: count: 2 min_visible_memory: 22Gi labels: ["group=gpu-24g"] storage: workspace: /data/projects/finetune-llama-7b quota: 100Gi environment: - HF_HOME=/workspace/hf_cache - WANDB_MODE=offline hooks: on_done: /opt/openrig/notify_done.sh这个文件要表达的意思很直白：我要起一个容器，镜像从内部仓库拉，需要2张24G级别显存的卡，工作区挂在固定目录，跑完执行一下通知脚本。
对做过容器编排的人来讲，这套描述并不新鲜。但openrig在两点上和Docker/K8s的直接使用体验拉开差距：一是它默认每个任务的工作区目录是持久化的，任务结束不会清掉，重新提交相同任务还能接着写同一目录；二是它把“设备分配”前置到了任务调度阶段，容器起来之前你就知道它会在哪张卡上跑，这条信息会被写进任务状态里，非常利于审计和排查。
2.4 状态机：让我知道任务现在到底在干嘛
openrig的任务状态流转值得单独提一下，因为排查问题全靠它。一个任务会经历：
pending -> allocated -> pulling -> starting -> running -> succeeded | | +--> failed在starting阶段，代理会做镜像检查，如果本地没有对应镜像就开始拉取。第一次跑新镜像时这个阶段会卡较长时间，这对很多新手是个迷惑点——明明拿到设备了，任务却迟迟不进入running。状态机里你还能看到具体的时间戳和当前阶段，比如pulling (2/5 layers)，这样就不至于误判成死锁。
理解了这几个模块之后，你就能看懂openrig的底层逻辑了：它不关心你的训练脚本怎么写，也不去干预Docker容器的内部行为，它只负责在合适的时机把合适的资源交给合适的任务，然后忠实记录过程中发生的每一件事。这也是它能够保持轻量的原因。
3. 从裸机到第一批任务跑起来：完整搭建与首次调度实操
我以一台Ubuntu 22.04机器为例，驱动和容器运行时已经预装好，三张卡都能正常识别。下面这套流程我在三台配置不同的机器上各跑过一遍，可以复现。
3.1 安装控制面与代理
openrig发行版提供了一个打包好的启动器，把控制面和代理装到同一台机器上最省事。安装后第一件事是初始化：
openrig server init --data-dir /var/lib/openrig openrig agent join --server 127.0.0.1:7890 --token <token>初始化之后，用openrig device list查看已识别的设备。这一步如果发现设备数量不对，先看代理日志，多半是驱动版本与容器运行时不匹配导致nvidia-smi能看到卡但容器里看不到。
我的建议是把控制面目录放到独立挂载盘上，而不是系统盘。原因后面踩坑部分会细说，数据、日志和镜像缓存加在一起胀得很快，系统盘满了系统本身会先出事。
3.2 写第一份任务单并提交
设备接入后，我通常会先跑一个占用极小的探测任务，确认链路通了再上正式负载。探测任务长这样：
name: probe-gpu image: nvidia/cuda:12.2.0-base-ubuntu22.04 command: ["nvidia-smi"] devices: count: 1 min_visible_memory: 8Gi提交并查看：
openrig task submit probe.yaml openrig task list openrig task logs <task-id>如果日志里能看到GPU型号和驱动版本，说明从任务提交到容器拉起再到设备映射，整条链路已经走通。这一步看起来简单，却值得认真做一次，因为后续所有复杂的调度都建立在“单任务能正常拿到卡”这个前提上。
3.3 提交两个真实负载，观察排队行为
我用一个模型微调脚本和一个批量推理脚本做对照测试。微调任务声明2张卡，批量推理任务声明1张卡，两个任务同时提交，但把微调任务设成高优先级：
openrig task submit finetune.yaml --priority 10 openrig task submit batch-infer.yaml --priority 3观察结果：前者立刻进入allocated，后者在pending队列里等待，直到第一张卡被释放，推理任务才被调度到另一张空闲卡。这说明openrig的优先级队列是生效的，而且不同任务可以持有不同数量的卡，不像有些工具限定每个任务只能独占一台机器。
3.4 加入第二台设备形成多机资源池
再多说一句扩展的事。我在第二台机器上也装了代理，执行的命令几乎没有区别，只是把--server指向第一台机器的IP：
openrig agent join --server 192.168.1.20:7890 --token <token>两台机器接入之后，控制面的设备列表从3张卡变成了6张卡。在这个状态下，提交一个声明count: 2的任务，调度器可能会把两张卡分到不同机器上，这对会自适应通信并发的训练框架没问题，但如果你用的是依赖共享文件系统的脚本，就要注意两台机器的工作区是否都可见。建议在多机模式下把工作区放到NFS共享目录，或者在每个任务里显式声明机器亲和标签，避免任务被拆散到无法互访数据的节点上。
4. 连续跑了三周的真实表现：负载、排队、显存碎片与资源水位
配置是一回事，长期跑起来是另一回事。我把openrig接入日常工作流之后，连续观察了三周，这里如实记录几个维度的表现。
4.1 负载均衡比手动安排更“扛得住”
以前手动分配任务，大家习惯性往“感觉比较闲”的机器上扔，结果经常出现某张卡利用率99%排队，另一张卡闲置却没人用的情况。openrig的memory-aware策略接入后，新任务会优先落到显存余量最大的卡上。我用记录脚本统计了一周的平均利用率，整体从之前的40%左右升到了68%，主要原因是碎片化的空闲显存被重新利用起来了。
调度器不是万能的，它只负责新任务分配，已经运行的任务占着显存不放时，其他需要大显存的任务仍然只能排队。这不算缺陷，而是资源管理的常识：谁也不可能变出更多的显存。
4.2 排队不是坏事，透明排队比乱跑更省心
很多人看到任务pending就紧张，觉得是出问题了。实际观察下来，pending状态的含义是“资源不满足或高优先级任务抢占中”，openrig会在任务详情里给出为什么还没分到的原因，比如waiting device: need 2 device(s), available: 1。这种透明度让团队内部排期变得非常清晰，谁在前面、为什么等，看一眼就知道，不用再互相猜测。
4.3 显存碎片：短任务频繁交替时的隐形杀手
三周里我遇到一个值得注意的情况：大量短推理任务频繁执行后，每张卡的显存剩余量虽然足够，但碎片化严重，导致需要连续大块显存的任务反复失败。openrig默认不做显存整理，它只有“剩余显存”这个概念，没有“最大连续空闲块”的概念。
解决办法有两个方向：一种是在低峰期统一重启一批常驻推理容器，把碎片清一遍；另一种是把短任务集中到固定几张卡上跑，其他卡保持长任务，用标签亲和来引导调度。我最终采用了后者，任务描述里给短任务加上labels: ["role=short"]，给长任务加上labels: ["role=long"]，碎片问题明显缓解。
4.4 资源水位的可视化与阈值告警
openrig Web面板里能看到每日的利用率曲线、每张卡的温度和功耗，还有队列长度曲线。我给队列长度超过5和某张卡温度超过85度分别配了告警脚本，通过hook机制推送到内部群。这套东西在真正出问题前的价值很大，有一回一块风扇失灵的卡温度一路冲到90度，告警提前12小时把人叫醒了，避免了掉卡烧硬件。
5. 踩坑实录：驱动不匹配、磁盘打满与任务“假死”的排查链路
这部分是我想重点分享的。openrig整体不算复杂，但运行过程中还是会有一些坑，不经历一遍很难快速定位。
5.1 CUDA版本与镜像不匹配：容器起不来但任务显示running
第一坑，也是最常见的：任务状态已经进入running，但日志里什么都没有，客户端连接不上。我遇到的具体场景是镜像里是CUDA 12.2，但宿主机驱动只支持到CUDA 11.8，容器内执行任何GPU操作都报CUDA driver version is insufficient。
排查链路如下：
- 先看任务日志，
openrig task logs {id}，发现无输出。 - 手工在对应机器上执行
nvidia-smi，显示正常。 - 用
docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi验证，复现失败。 - 确认是宿主机驱动过旧，于是决定升级驱动到支持CUDA 12.2的版本。
升级后需要重启机器，再重新openrig agent start。这个坑的教训是：openrig不检查镜像要求的CUDA版本和宿主机驱动的兼容性，它只负责把GPU设备映射进容器，兼容性责任在任务提交者。
5.2 数据目录塞满系统盘：一个看似与GPU无关的坑
第二个坑出在存储上。openrig默认把所有数据、日志、临时文件都写到安装时指定的目录，我最初图省事就用了默认的/var/lib/openrig，结果这个目录就在系统盘上。连续两周的高频任务后，系统盘可用空间从40GB掉到不足1GB，导致系统服务整体变慢，openrig的健康检查也开始告警。
建议大家在初始化时就把数据目录迁到独立的数据盘，可以在server初始化之前用软链接或直接指定参数拦截。另外，日志策略也建议启用轮转，保留最近7天或最多10GB，避免任务一多久了没人管。
5.3 任务长时间卡在pulling：网络受限与镜像缓存
第三个坑是镜像拉取。内网环境拉外部镜像速度不稳定，任务会长时间卡在pulling阶段，状态机里看起来像“假死”。第一次遇到时我等了20分钟，以为系统出问题了，后来统计了一下发现实际是在反复重试分层下载。
解决方案我在生产环境里是这么做的：建立了一个内部镜像仓库，把高频使用的基础镜像提前同步到内网，任务描述里的image字段全部指向内网地址。这样pulling阶段通常能在几十秒内完成。如果拉取的是几个GB的大镜像，第一次跑还是要有耐心，openrig在这里不会超时，只会不断重试。
5.4 代理“假死”与心跳超时：从控制面视角排查
第四个坑出现在代理侧。有一台机器的代理偶尔会进入无响应状态，控制面显示设备离线，但实际机器还在正常运行。排查链路是：
- 先检查代理进程是否还在，
ps aux | grep openrig-agent，还在。 - 再看代理日志，发现心跳上报失败，错误是连接超时。
- 检查控制面端口和服务状态，一切正常。
- 最后跟踪网络连接，确定是控制面所在机器的防火墙策略对长连接不友好，导致代理重连失败。
解决办法很简单：给代理进程配置了systemd常驻和自动重启，并调整了控制面所在机器的连接空闲超时参数。从那以后就没再发生过类似问题。这个坑提醒我，openrig对网络的依赖比想象中高，代理和控制面之间的连接断掉后，任务虽然还能继续跑，但控制面会失去心跳，可能触发错误告警。
5.5 显存泄漏与OOM：不是openrig的问题，但会让你怀疑它
还有一个高频误判点：某些推理服务在并发压力下显存持续增长，最终触发OOM，任务被杀。openrig不会限制单任务的内存上限，也没有在OOM发生时自动重启。第一次遇到时我以为调度器出了bug，查了半天才发现是脚本里GPU缓存没释放。
openrig在这个场景下的正确打开方式是：用hook脚本在任务异常退出时自动重新拉起，或者在任务描述里为这类服务加上更高频率的重启策略。不要把openrig当成进程守护工具，它更关注“任务的排队和分配”，守护进程是另一层职责。
6. 下一阶段扩展：多节点、监控面板与CI集成的几种玩法
openrig跑顺手之后，我陆续补了几种玩法，这里一并分享。
6.1 把定时训练变成定时任务
给openrig配一套cron触发器并不难，核心思路是写一个包装脚本，把每天的增量训练封装成任务单，提交后轮询直到成功或失败。以前每天上班第一件事是看训练有没有挂，现在日志会定时推送到群里，没告警就说明跑完了。
这个扩展的前提是你对任务单里的镜像和命令足够自信，不然自动化只会让错误发生得更快。建议从无状态、可重复的训练任务开始自动化，不要在需要人工干预的环节上过度追求全自动。
6.2 监控面板接入现有告警体系
openrig自带的面板足够日常观察，但它不是数据平台。我在一个部署里把它的资源数据通过采集脚本定时导入到公司的监控系统，用现成的告警规则来覆盖“设备离线”“队列积压”“显存低于阈值”三类场景。这些规则配合Webhook，能做到秒级通知。
6.3 多计算节点：向轻量集群进化
单机资源不够时，openrig的多代理接入能力就能派上用场。我现在的环境是三台机器组成的小池子，控制面只部署在其中一台。注意点有两个：一是各节点的系统时间要同步，否则任务时间戳会乱；二是共享存储要做好权限隔离，避免两个任务意外写入彼此的目录。
开放式的硬件环境下，异构混用是常态。openrig对几年前的旧卡和最新卡能一视同仁地管理，只要驱动支持，它就能把这个设备纳入池子。旧卡跑推理，新卡跑训练，标签亲和会帮我把路由做好。
6.4 把openrig放进CI流水线
最后一种玩法是把openrig接入CI。每次代码合并后自动触发一轮模型回归测试，CI脚本调用openrig提交一个测试任务，等任务到达succeeded状态后再跑后续的评估流程。这里的核心收益是环境一致性：每次测试都在同一个镜像、同一类设备上运行，不会再出现“我本地跑得好好的，怎么一上服务器就崩”的问题。
我个人在实际使用中最受用的，其实不是某一个单独的功能，而是“所有任务都留下可查询记录”这件事。以前争论“这张卡到底是谁在用”，现在直接查任务历史就行。openrig的本质是给计算资源立了一套规矩，规矩立起来，很多混乱就自然消失了。
如果你正被多卡机器利用率低、团队撞车、环境冲突这些问题困扰，不妨从一个小规模部署开始试起，先跑通探测任务，再逐步加节点、加调度策略、加自动化。这个过程不复杂，但每一层都能解决一类实际问题。
