1. openrig的项目定位与整体设计思路1.1 从“rig”说起这台机架到底在干什么第一次看到“openrig”这个词很多人的第一反应是“又是一个挖矿机架”。如果你也是这么想的那就把方向搞错了。rig在硬件社区里真正的意思是“一套组装好的设备”游戏玩家把攒的整台主机叫gaming rig影视行业把摄影器材组叫camera rig。而在AI训练这个圈子里rig越来越常被用来指代一套用于跑深度学习任务的计算装置——几块显卡插在同一个主板上或者几台服务器通过网络连在一起目的只有一个把模型训练这件事跑得更快。openrig这个项目的初衷就是想把这套训练装置真正“开源化”。市面上的AI服务器方案不少厂商整机价格奇高而且很多关键配置是黑盒用的是什么固件、怎么组网络、散热设计余量有多大售后不告诉你文档里也查不到。openrig做的事情是把机架整体的硬件搭配方案、网络拓扑、系统部署脚本、调度配置、监控面板全部摊开让一个没有厂商支持的小团队也能照着搭出一套能用的多卡训练环境。适合谁看首先是手里有几张显卡或者一台服务器、想把它们变成正经训练资源的研究生和算法工程师。其次是正在规划小规模算力机房、天天被厂商报价单烦到头的技术负责人。再就是单纯想搞明白“大模型训练到底需要什么东西”的好奇型选手。看完你会对整条链路有一个非常具体的概念从电源插座到显卡利用率每一层都有坑而openrig这类项目存在的意义就是把这些坑提前标出来。1.2 三条设计原则可复制、可维护、可降级我在梳理openrig的技术方案时给自己定过三条硬性原则每一条都是从踩坑经历里总结出来的。第一条是可复制。这意味着方案里不出现“按供应商定制”“需要商务沟通”这类字眼。所有硬件型号必须能在公开渠道买到所有配置文件必须能在一个空白的Linux系统上从零执行。很多企业级的集群方案看上去很美但里面的组件高度绑定某家厂商的服务别人拿到手也复刻不了那就没有“开源”的意义。第二条是可维护。小团队没有专职的HPC运维所有事情可能就一两个人负责。所以openrig在软件层的选择上刻意倾向那些社区活跃、文档友好、出问题能搜到答案的工具。一个组件再强大如果全网只有开发商自己的三篇文档它就不适合出现在这套方案里。我会在后面的软件栈部分具体展开这个取舍。第三条是可降级。不是每个人都有8张A100也不是每个场景都需要InfiniBand。openrig在设计时就允许你从4张消费级显卡起步先用千兆网顶着跑小模型等预算到位再平滑升级到万兆网和服务器级GPU。很多团队一开始把目标定得太高结果光网络设备就把预算吃完了实际训练任务反而没跑起来。可降级的设计就是让你第一步先“动起来”。这三条原则决定了整个项目的气质不炫技、不堆料、一切以“照着做能成”为最高优先级。1.3 开源协议与技术栈选型软件协议上openrig主体采用Apache License 2.0配置文件这类非代码内容则采用较为宽松的许可。选Apache而不是GPL的考虑很简单这套方案里的配置和脚本本质上是对既有成熟工具的编排而不是全新的核心代码过度强制的开源约束会劝退很多只想“先用起来”的团队。如果有人在openrig基础上改进并商业化Apache协议允许他闭源分发虽然会让部分理想主义者不舒服但从生态繁荣的角度讲这反而鼓励了更多企业参与贡献。技术栈的选型是这轮设计里最关键的环节。底层系统选用 Ubuntu Server 22.04 LTS原因是NVIDIA驱动和PyTorch生态对它的支持测试最充分遇到兼容性问题时最容易找到解决方案。容器层用Docker加NVIDIA Container Toolkit训练框架镜像直接基于NGC上的PyTorch官方镜像修改省去自己装CUDA和cuDNN的苦工。作业调度选Slurm这套在超算中心打磨了几十年的调度器在排队策略上非常成熟比自己在Kubernetes上写调度器要稳得多。网络靠NCCL做多机通信存储层用NFS打底、对象存储做数据集中转。上面每一层的选择后面都会细讲为什么不是别的。2. 硬件选型与组网细节预算怎么花才不冤枉2.1 计算节点显卡与整机配置的搭配思路计算节点的配置是openrig方案里最烧钱的部分也是大家最容易上头的地方。我的建议是先把训练负载类型定下来再决定显卡。以目前的主流需求来看百亿参数以内的模型训练和微调多卡4090的组合是性价比极高的选择。虽然4090不支持NVLink导致多卡通信只能走PCIe但FP16算力和24GB显存应付LoRA微调、中小规模预训练都够用。要是你有明确的钱学森目标要跑百亿级以上模型的预训练那就老老实实准备服务器级产品比如H800或A800这类带NVLink的卡。一套80G显存的八卡服务器加上CPU、内存、存储总成本轻松破百万这不是个人爱好者能随便碰的必须提前做预算论证。计算节点的主板选择有个隐藏学问。很多人只盯着显卡插槽忽略了CPU和内存通道的搭配结果8张卡插上去有4张的PCIe链路实际跑在x8上训练效率直接打七折。按我的验机经验选主板时一定要确认每个PCIe x16插槽是否都直连CPU或者至少是同一颗CPU下的完整x16通道。如果用的是双路主板还要格外注意两张卡分别挂在哪个CPU上跨CPU访问内存在某些场景下会带来额外延迟。内存容量按“每张卡配32GB系统内存”这个经验值去配比如8卡节点就配256GB内存这个比例能保证DataLoader的多进程数据加载不会成为瓶颈。整机配置还有个容易被忽视的东西CPU核数。很多人以为训练是GPU的事CPU随便配个8核就够了。但实际上数据预处理、tokenize、数据增强这些流水线操作全在CPU上跑很多团队的GPU利用率上不去不是卡的问题是CPU来不及把数据喂进去。我的建议是每张显卡至少配4个物理核心8卡机配一颗32核的Threadripper或者两颗Xeon Gold起步跑起来你就知道差距了。2.2 网络拓扑大模型训练的“高速公路”规划如果显卡决定了你算力上限网络就决定了你能把多少算力真正用出来。单机多卡靠PCIe通信多机之间就只能走网络而NCCL这类分布式通信库对网络的延迟和带宽极其敏感。最简单的组网方案是全千兆以太网这套配置基本不额外花钱但只适合单机训练或者仅做推理服务的情况。一旦跨节点跑分布式训练千兆网的带宽通常不到200MB/s而一张卡的数据读取需求往往是这个数值的好几倍通信立刻变成瓶颈。再往上就是万兆以太网方案这也是openrig默认推荐的标准配置。一张双口万兆网卡价格不贵配合RoCEv2协议能实现类似RDMA的效果。这里有个很容易踩的坑RoCEv2需要交换机开启PFC流控和服务等级映射如果网络交换机没做这些配置RoCE在拥塞时会出现大规模丢包性能反而比普通TCP还差。很多团队照教程配好了RoCE测速却跑不出来问题基本都出在交换机这一层。最高端的是InfiniBand方案比如NVIDIA的ConnectX网卡和配套交换机。IB网络延迟可以压到微秒级多机训练时NCCL的AllReduce通信耗时能比万兆网降低一半以上。但IB网卡和交换机的价格比同规格以太网贵出一大截而且IB交换机通常只能专网专用不能跟管理网络复用。性价比思路就清晰了openrig的配置单里低配版用千兆网兜底标准版上万兆RoCE高配版才考虑IB中间每一级都能平滑升级。2.3 存储方案别让数据集被读写速度卡死硬件讨论到最后往往剩一个没有存在感但又极其致命的部分存储。训练过程中GPU一边做矩阵运算一边等CPU把图片、文本这些样本从硬盘搬进内存。如果你的数据集放在一块普通的SATA机械硬盘上读取速度不到150MB/s那光是数据加载就能把8卡机器的利用率拉到30%以下。我见过不止一个小团队在存储上省钱最后GPU的钱白花了。openrig的存储方案是四级分层的思路。第一层是算盘节点本地NVMe盘负责跑当前实验的缓存数据读写速度最快第二层是一台独立存储服务器挂几块大容量企业级SSD做热数据区通过NFS或SMB共享给所有计算节点第三层是冷数据归档可以用仓库里的大容量机械硬盘或者对象存储服务器专门放原始数据集和训练好的权重文件第四层是备份定期把结果同步到异地的备份盘防止训练数月的心血被一块坏盘清零。存储服务器的网卡也要单独算进预算里。NFS共享在千兆网下可能只有100到200MB/s的吞吐但如果存储服务器插一块万兆网卡传输速度能提升到1000MB/s以上单机八卡做数据加载就完全不慌了。如果后续要跑更大规模的数据集还可以考虑在存储服务器上跑一套BeeGFS分布式文件系统几百MB到上GB的吞吐都能撑住而且配置比Lustre简单两个数量级是openrig升级路径里最值得优先考虑的一个组件。2.4 供电与散热两个最容易被低估的环节显卡插上、系统装好很多人就觉得大功告成结果一上负载就频繁重启、掉卡、蓝屏排查半天发现是电源和散热的问题。这两块是openrig实战经验里出现频率最高的“坑区”必须单独说。先算算供电账。一张RTX 4090的极限功耗是450W8张满载就是3600W加上CPU、主板、内存、风扇一台八卡整机在跑满负载时功耗普遍在4200W到4800W之间。这就意味着你至少需要两个2000W左右的冗余电源模块而且必须用专门的服务器电源配合分线板绝不能用普通ATX电源串联解决否则轻则启动失败重则烧毁接口。小规模部署时还需要认真算一下家里的电路容量一个普通空调插座通常只有16A一条220V线路最多带约3500W负载八卡机一开机直接跳闸是常有的事必须安排专用空开线缆。散热问题更隐蔽。GPU在满载时核心温度超过90度就开始自动降频你看到的计算卡利用率虽然是100%但实际算力已经缩水了20%。openrig默认推荐用开放式机架配合强力风扇直吹而不是把显卡塞进密闭塔式机箱。开放式机架看起来简陋但空气流动效率比普通机箱高太多了。有条件的话可以在机架顶部加装排风管道把热空气直接导出机房两台八卡机在同一房间运行时没有导风措施的话五分钟内室温就能升到40度往上人先受不了机器更受不了。3. 软件栈搭建与分布式训练实操3.1 容器化环境与驱动版本管理硬件到位之后软件栈的搭建决定你能不能稳定地把算力跑满。openrig在这块的核心理念很简单所有依赖尽量容器化物理机的系统环境保持纯净。先处理驱动层。无论你最终跑什么训练框架NVIDIA驱动都建议采用“独立驱动 官方容器”的方式宿主机只装显卡驱动和一个版本固定的CUDA驱动库cuDNN、TensorRT、PyTorch这些全部装进镜像里版本各自独立。这样做的直接好处是不同项目可以用不同的CUDA版本和PyTorch版本互不干扰。今天我跑PyTorch 2.1配CUDA 12.2明天跑TensorFlow 2.13配CUDA 11.8只需要拉两个镜像就好宿主机永远不用重装。Docker的配置里有一个关键项就是NVIDIA Container Toolkit。在常规Docker环境中容器是访问不了GPU的需要在宿主机上安装nvidia-container-toolkit这个插件它会把宿主的GPU设备驱动动态挂载进容器。安装完之后用docker run --gpus all这样的写实参数就能直接让容器看到全部显卡。这里提醒一个细节不同版本的驱动对应不同版本的Toolkit用新版驱动配旧版Toolkit虽然能跑但偶尔会在某些调用上出怪问题我的做法是驱动更新之后第一时间同步升级Toolkit。镜像管理还有个土办法特别好用。自己写好Dockerfile把基础镜像构建成团队内部镜像推到本地仓库避免每次训练都从外网重新拉。国内网络拉国外镜像时不稳定的情况时常存在等镜像拉完了心情也就凉了半截。所以openrig的部署脚本里特意加了内网镜像仓库的支持一次拉取全员复用。3.2 调度系统为什么选择Slurm而不是裸K8s到了多机多卡的场景你不可能永远手动ssh到每台机器去敲命令那样既不安全也不可靠。openrig在作业调度层选用了Slurm而没有选当下更热门的Kubernetes这个选择值得展开讲。Kubernetes在互联网应用编排上确实强大但在高性能计算训练场景下有个先天的错位它的核心抽象是“服务”和“应用”而训练任务本质上是“一次性作业”。你在K8s上跑分布式训练要自己处理Pod间的通信编排自己管理GPU资源的调度还要抽空排障网络标记这活儿其实比直接用Slurm复杂得多。而Slurm生来就是为了调度批处理作业它管的是“哪个节点有空闲把这个GPU任务排到哪”它的优先级队列、资源预留、分区管理都是为高吞吐计算场景精心打磨过的。社区里虽然也有KubeFlow这类跑训练的方案但那段曲线爬起来真的费头发。这里我们并不否定K8s的辅助角色。openrig的架构里如果团队同时有模型推理服务和Web应用那这部分完全可以跑在K8s上而训练和微调这类重计算任务则交给Slurm。两者通过共享NFS存储打通数据路径互不干扰各干各的。这就好比一家公司的研发团队用OneNote管理开发文档而财务部独立用金蝶记账工具不同但只要数据能打通整体效率反而更高。Slurm配置时需要注意的关键参数是节点分区Partition和CPU/GPU绑定。针对一台八卡机器可以在slurm.conf里把节点定义一个gpu分区并声明该节点的Gres为gpu:8。每个任务提交时用#SBATCH --gresgpu:8声明需要全部GPU或者#SBATCH --gresgpu:4只占用4张卡Slurm会自动帮你做资源隔离。3.3 多机多卡训练的通信参数配置硬件网络通了Slurm调度正常了接下来就是分布式训练框架的通信配置。这是从“跑通”到“跑满”的必经之路也是很多团队搞不清楚的环节。openrig在实战里整理的几个参数可以帮助大家直接用。以PyTorch的多机训练为例如果你的模型脚本用torchrun来启动分布式训练核心参数是这几个--nproc_per_node表示每台机器上用几张卡这个要和Slurm分配给本节点的GPU数量一致填错了资源不够会直接报CUDA out of memory。--nnodes表示参与训练的节点总数一般手动填也可以通过环境变量自动获取。还有--rdzv_endpoint指的是主节点的IP和端口用于进程间的发现和同步这个IP必须是所有训练节点都能访问到的IP通常是管理网络或专有训练网络的IP。通信库层PyTorch Distributed底层走NCCL需要设置好NCCL所依赖的网络参数。常用的环境变量这样设置export NCCL_SOCKET_IFNAMEeth1 # 把训练网卡指定到实际使用的接口 export NCCL_IB_GID_INDEX3 # RoCEv2场景下需要设置RoCE GID索引 export NCCL_DEBUGINFO # 调试阶段开INFO日志生产环境可以改WARN其中NCCL_SOCKET_IFNAME是个特别容易踩坑的点。服务器上通常有多个网络接口管理口、存储口、计算口如果NCCL选错了接口多机通信可能走得是千兆管理网络那么即使你配好了万兆网卡训练依然慢得跟老牛拉车一样。正确做法是在配置脚本里把训练网卡的名称固定下来测试连通性后用NCCL_SOCKET_IFNAME明确指给它。要在动手之前先测试一下通信性能。用NCCL的官方带宽测试工具就能看得明明白白它会打印每两个进程间的通信速度。如果在RoCE环境下跑到了接近网卡物理上限的吞吐量说明配置没问题如果速度严重偏低优先检查交换机的流控设置和网卡驱动版本。3.4 监控告警与运维自动化Uptime是训练团队的命脉一次8卡训练任务跑了两天突然某个节点掉卡如果没有监控你就得自己ssh进去慢慢排查两天的算力就算白扔了。在openrig方案里监控系统是标配组件而不是可选项。监控系统的基础组合是Prometheus加Grafana。计算节点上部署node_exporter采集CPU、内存、磁盘和网络指标再用DCGM Exporter采集NVIDIA显卡的利用率、温度、显存占用和功耗数据最后统一拉到Prometheus存储Grafana负责可视化。这个组合里最值得关注的是DCGM因为它能看到每张卡的核心状态包括电源状态是否正常、显存是否有ECC错误、温度是否过高。很多掉卡问题的前兆早就在这些指标里出现了只是你没看。配置告警规则时我建议至少设置三类阈值。一是GPU利用率持续五分钟低于20%说明任务可能卡死或数据加载出现问题二是GPU温度超过85度散热需要介入三是节点网络吞吐异常下降排查网线或交换机端口。告警可以推到钉钉、飞书或企业微信不管人在哪出问题能第一时间收到通知。openrig还内置了一个简易的自动巡检脚本每天凌晨把所有节点的GPU状态、磁盘剩余空间、关键服务进程状态检查一遍结果输出到统一日志文件。磁盘空间这个指标最容易被忽略但大型数据集和中间检查点加起来动辄几百GB一旦某个节点的磁盘满了写检查点失败会直接导致训练中断。4. 从装机到跑通训练任务的完整流程4.1 机架初始化与验收清单新机器从开箱到能跑训练中途会踩到不少隐性坑openrig把整个过程流程化成了一个“验收清单”照着做能省掉大量排障时间。第一步是硬件自检。插上显卡后用nvidia-smi确认系统识别到了所有GPU且驱动正确加载。如果某张卡没有显示优先检查PCIe插槽是否插紧其次检查辅助电源是否接好。供电不稳导致掉卡在普通电源上是家常便饭这一步值得多花时间。第二步是网络连通性测试。配置好IP之后用ip a确认网卡状态UP用ping测试节点之间的连通性再于每台计算节点相互执行iperf3跑TCP吞吐测试。如果预期的万兆网络实际只跑出了千兆水平排在前面检查的就是网线、交换机的端口协商速率而不是系统和配置。第三步是存储挂载测试。所有机器确认可以同时读写NFS共享目录并测试小文件和大文件的读写速度。NFS的并发性能往往会成为瓶颈如果测试低于预期可以考虑在NFS服务端调整rsize/wsize参数或者换成高并发模式如RDMA挂载。第四步是跑一个简单的单机训练任务验证整体环境。用PyTorch自带的图像分类脚本在单机上跑一个最小训练确认Docker和GPU环境没有问题把这一步称为“冒烟测试”。冒烟测试通过以后再提交一个双机分布式任务跑通之后再上正式训练这能帮你把问题控制在可控范围内。4.2 提交一次多节点训练任务的完整过程理论说了很多来看一个实际提交任务的例子。假设你在openrig环境里要跑一个两机十六卡的模型训练首先编写slurm_job.sh脚本#!/bin/bash #SBATCH --job-nametrain_demo #SBATCH --nodes2 #SBATCH --ntasks-per-node1 #SBATCH --gresgpu:8 #SBATCH --cpus-per-task64 #SBATCH --partitiongpu #SBATCH --time12:00:00 srun python -m torch.distributed.run \ --nnodes2 \ --nproc_per_node8 \ --rdzv_backendc10d \ --rdzv_endpointnode01:29500 \ train.py \ --epochs 100 \ --batch_size 512 \ --data_dir /data/dataset提交命令很简单sbatch slurm_job.sh。Slurm会自动把任务分配到两个空闲节点上把脚本里的--nodes2和--gresgpu:8资源匹配起来。任务开始之后在计算节点上可以看到16个Python训练进程每个进程绑定一个GPU。训练日志默认写到slurm-jobid.out文件里用tail -f随时查看进度。这个过程里有个细节值得牢记#SBATCH --time12:00:00最好按实际需求估满一点。如果任务设置的运行时间比实际短Slurm会在时间到点时直接杀掉你的训练进程而你的模型检查点如果保存频率低可能出现断点回退几个小时的尴尬。检查点保存间隔建议设为一个epoch或者每30分钟保存一次同时在Slurm脚本里对time参数留出20%的余量。4.3 日志排查与断点恢复技巧训练跑了一半挂了这是家常便饭。openrig能帮你做的是让挂掉这件事不可怕具备快速定位和恢复能力。首先要养成看日志的好习惯分开记录系统日志和训练日志。系统日志看的是驱动、硬件和Slurm层面的信息训练日志看的是loss、精度、学习率这些业务指标。很多团队把两者混在一个文件里定位问题全靠CtrlF效率极低。openrig的模板方案里训练进程的stdout重定向到独立文件/var/log/messages、dmesg中的硬件报错另外归拢两路分开互相不污染。断点恢复也是每个项目必须提前写进训练脚本的。在训练代码里每隔固定步数用torch.save保存模型、优化器和随机数生成器的完整状态这样崩溃之后就能从最近的检查点继续训练。恢复逻辑很简单判断指定路径下有没有检查点文件有就从它恢复没有就重新开始。这个习惯一定要养成别嫌麻烦等你跑过一次100小时的任务在中途崩掉又要从头再来才能体会什么叫欲哭无泪。5. 常见问题速查与降本避坑实录5.1 高频问题与排查思路对照表由于openrig项目社区里大家踊跃回馈我整理了一张高频问题速查表把大家反馈最多的几个方向列出来基本涵盖了从装机到训练的前期常见故障。故障现象可能原因排查步骤解决办法nvidia-smi不显示GPUPCIe没插好或辅助供电缺失检查插槽和电源线重启机器重新插拔换供电接口NCCL通信超时网卡接口选错NCCL走了慢速口跑all_reduce测试检查NCCL_DEBUG日志设置NCCL_SOCKET_IFNAME明确指定训练网卡训练时GPU利用率低CPU来不及喂数据查看CPU占用率和磁盘IO增加num_workers扩大DatLoader预取数节点中途离线电源不足或过热保护查看IPMI日志和温度记录升级电源、改善散热通风NFS挂载卡顿并发读写锁竞争检查NFS服务端负载和网络吞吐调整NFS挂载参数或者考虑升级BeeGFS多机训练速度不达标RoCE交换机未开启PFC跑NCCL测试观察丢包率在交换机上配置PFC和QoS测试不同服务等级这张表不能覆盖所有问题但它覆盖了90%的小团队最初阶段会遇到的疑难杂症。搞不定的问题先按表排查跑不通的概率会大幅降低。5.2 三个被我从方案里删掉的组件维护开源项目最大的好处就是能借用户反馈反思自己的决策。openrig有几版方案里出现过几个组件最后因为投入产出比太差被我移除了这里聊聊为什么。第一个是分布式训练专用的高性能作业编排框架。它的功能丰富但配置复杂度也高要学一套全新的模板语法还要处理它和Slurm之间的角色冲突。对大多数只需要“提交任务、查看日志、保存检查点”的团队而言这套重量级框架带来的价值远不及其折腾成本。我从openrig里把它拿掉只保留最小可用的srun torchrun组合效果反而更好。第二个是网络上自动抓取的GPU虚拟显存技术配置方案。这个功能听着很实用但实际用起来限制很多不少模型类型不支持某些算子会出现随机错误而且诊断起来极其困难。单靠开源项目临时解决显存不够的问题其实不如优先优化batch size和数据加载策略。如果24G显存还是不够就该认真考虑换一张更大显存的卡而不是继续折腾虚拟显存。第三个是部分版本中引入的系统级自动调参工具。自动调参听着很美但在没有经验和足够实验预算的小团队里调参策略往往还不如人工经验来得稳。模型训练的核心变量是学习率、batch size和模型结构这些靠人工调整已经足够。我保留了脚本化的超参扫描工具但砍掉了一整套复杂的自动化搜索服务让方案保持在“看得懂、改得动”的状态。5.3 小团队部署openrig的预算参考最后给一套粗略的预算参考这里主要是帮助大家建立一个预算用量感具体价格会随行情波动不构成采购建议。最精简的入门配置是一台四卡4090整机搭配一台千兆交换机、一块48TB机械硬盘作为数据仓库总投入在五到八万元区间。这个配置适合跑百亿参数以内的LoRA微调、中小规模模型训练和各类视觉任务。进阶配置是两到三台八卡4090整机再来一台万兆交换机存储服务器使用两块企业级SSD配合大容量机械盘预算大概二十五到四十万元。这个组合已经能够覆盖多机分布式训练的主流场景。更高阶的就是带NVLink的八卡服务器级GPU配InfiniBand整套两机十六卡集群的预算轻松破一百五十万元这通常是企业级需求才会触碰的领域openrig的配置单虽然包含这个路径但建议谨慎评估好预算和实际负载再动手。各价位方案的核心宗旨是一致的硬件尽量按最简需求采购基础设施留足升级空间。很多团队把预算全花在显卡上最后发现网卡、存储、电力改造都不够用反而卡在算力发挥不出来。openrig的配置模版都预留了清晰的升级路径一开始不需要一步到位跑通一个小任务再逐步扩展才是最务实的路线。最后聊个人体会。我搭过多次训练机架最大的感受是这套东西的技术细节远不如传闻中复杂真正难的是在整个过程里保持耐心。第一台机器从装机到跑通花了三个周末几乎每一个环节都在踩文档没写的坑。但等项目跑起来GPU利用率稳定在90%以上的时候之前的疲惫就都值了。openrig后续我还会继续维护下去最近在考虑补一套自动断电恢复脚本让训练任务在异常重启之后能够自动回到检查点继续跑。如果你也在搭自己的训练环境欢迎从openrig的配置单开始然后做减法、微调成自己的版本这个过程本身就是最好的学习机会。