企业官网建设流程全解析

OpenRIG这个名字，圈内人一看就知道是奔着多卡机群去的。简单说，它是一套开源的、基于Linux的GPU集群管理发行版，最早来自AMD的社区项目，定位非常明确：把一堆显卡插到主板上，通过网络统一管理、监控、调度，让管理员不用每天跑机房插拔显示器。有人把它当“矿机系统”用，也有人拿它做渲染农场或者分布式计算节点，本质上它就是一个长在显卡堆里的轻量级Linux控制台。

我当时折腾这套东西，是因为机房里有十来张品牌杂、驱程乱、系统版本五花八门的显卡要归拢到一起。Windows方案看着友好，真到二三十台规模时，你会发现每台机器都要配显示器、键鼠、手动更新驱动，纯体力活。OpenRIG这种把“管理端”和“算力端”拆开的设计，正好治这个病。这篇东西不打算写成官方文档复读机，就按我自己从零部署、调优到踩坑的全过程来写，适合手里已经有一台以上多卡主机、想从手动运维里解脱出来的朋友。如果你完全没碰过Linux命令行，也不要紧，跟着步骤敲就行，每条命令我都会解释它在干什么。

1. 先搞清楚 OpenRIG 到底是个什么东西

1.1 它和你理解的“显卡服务器系统”有什么区别

很多人在听到“基于Linux的显卡集群系统”时，第一反应是“这不就是个Ubuntu装个驱动吗”。对，也不对。OpenRIG的高明之处在于，它不是一套给你开机进桌面、手动点鼠标的普通发行版，而是把“单机操作”这件事压缩到了最小，把“集中管理”放大到了核心位置。

具体来说，它由两层组成：一层是管理端，部署在一台服务器或者你日常用的电脑上，负责收集所有算力节点的状态，比如温度、功耗、显存占用、驱动版本、在线离线情况；另一层是算力节点，也就是插满显卡的机器本身，它们开机后通过局域网自动连接管理端，上报数据、接收指令。这个结构有点像一个健身房：管理端是前台，所有跑步机（显卡）的状态都能在一个屏幕上看完，而跑步机本身不需要有人一直守着。

所以它跟你熟悉的“桌面Linux + 远程桌面”有本质区别。远程桌面是模拟人坐在机器面前操作，OpenRIG是让机器自己找前台报到。你不需要知道第4号机器的显示器在哪，只要管理端能看到它在线，就可以远程下发重启、改功耗、刷驱动这类操作。

1.2 适合谁折腾，不适合谁折腾

先说不适合的。如果你只有一张显卡，插在自己常用的电脑里，平时就玩玩渲染或跑跑小模型，那OpenRIG对你是负优化。它引入的网络通信、代理进程、管控面板全是额外开销，一张卡直接装驱动就行，没必要绕这一圈。

它真正的甜区，是三台以上、每台插着4到6张显卡的小型机房。这种规模下，Windows的每台单独运维成本已经高得让人烦躁，而商用显卡服务器的授权和服务费又贵得离谱。OpenRIG这种开源方案正好卡在这个空档：不要钱、可定制、能批量操作。

另外，适合折腾它的朋友，至少得对Linux有一点“愿意查日志”的耐心。它不像家用系统那样出问题弹个提示框，很多时候故障靠的就是dmesg和journalctl这两条命令来定位原因。如果你连SSH是什么都还没概念，建议先花半小时把Linux的基本目录结构和开机日志看一眼，再上手，否则遇到问题容易抓瞎。

2. 选型思路：为什么最后把主力机群搬到了 OpenRIG 上

2.1 对比 Windows 方案的三个关键差异

很多刚入行的人喜欢用Windows，理由很朴素：驱动好装，显卡控制面板熟悉。但真到机房规模，Windows的三个短板会越来越明显。

第一是远程管理麻烦。Windows的远程桌面在同一局域网里还好，一旦跨网段或者需要同时看多台机器，要么搭跳板机，要么用第三方工具，还不一定稳定。OpenRIG天生就是为无人值守设计的，开机即连接管理端，没有“桌面”这个概念，也就不存在桌面卡死导致机器失联的问题。

第二是驱动更新的批量化成本高。Windows下更新显卡驱动，常规路径是去官网下驱动包，然后一台台登录、安装、重启。OpenRIG可以直接在管理端看到每台机器的驱动版本，用包管理器统一更新，甚至预置好一套驱动配置，新机器连上就自动匹配。

第三是系统本身的开销和稳定性。Windows开机后后台服务一大堆，长期不重启就会出现内存泄漏、更新弹窗、杀毒软件抽风之类的问题。OpenRIG的精简系统开完机就只剩GPU相关服务，跑几个月不重启是常态。我一个朋友机房里有台OpenRIG节点稳定跑了11个月，最后还是因为换电源线才重启的。

2.2 管理架构和工作模式

OpenRIG管理端和节点端的交互模式，可以简化成下图这样理解：

• 管理端：保存所有节点的注册信息、历史状态、告警规则，提供一个Web页面供人查看和操作。
• 节点端：开机后向管理端注册，然后周期性上报显卡状态。中间如果没有管理端，节点也能独立工作，只是没人知道它干得好不好。
• 通信协议：走的是局域网内的自定义协议，默认端口固定。管理端通过节点ID区分不同机器，你可以在Web面板上给每台机器打标签备注。

这套架构最让我喜欢的一点，是它对硬件故障的容忍度。某台机器的某个传感器坏了，它不会拒绝上报，只是会在面板里显示这个指标异常。我原来用Windows时，传感器数据混杂在事件管理器里，根本没人会定期翻；OpenRIG则是主动上报，异常直接标红，省了巡检的体力活。

2.3 性能与兼容性的合理预期

先说结论：OpenRIG对A卡（AMD显卡）的兼容性明显优于N卡（NVIDIA显卡），这不是玄学，而是它的基因决定的——项目早期就是围绕AMD显卡和自家的驱动栈开发的。如果你手里清一色N卡，倒也能用，但调优的余地小一些，部分高级控制项在界面上看不到，得靠命令行手动改。

性能方面，Linux下AMD显卡驱动的OpenCL和OpenGL性能一直不差，加上系统负载低，同样的显卡在OpenRIG上跑出来的成绩通常比Windows下高几个百分点。但这种差异不是每次都能复现，我的建议是：你先拿一块卡在Windows和OpenRIG里分别跑一把同样的负载，记录数据再决定要不要整体迁移。别听网上说谁谁强就无脑换系统，性能这事儿跟具体型号、驱动版本、散热环境关系太大。

3. 从零部署：一个 6 卡算力节点的完整流程

3.1 硬件准备与启动盘制作

先说硬件底线。我建议的配置是：ATX大板（至少6条PCIe插槽）、CPU不用太强（4核心就够，但别用那种不支持虚拟化或PCIe通道数太少的阉割型号）、内存8GB起步（多卡同时跑缓存时16GB更稳）、电源按显卡总功耗加40%冗余来算。

这里有个很多新手会踩的坑：PCIe供电能力。插满6张显卡时，光靠主板上的PCIe插槽供电是远远不够的，必须用电源线延长线或者转接板给显卡单独供电。我见过有人直接6张卡全插主板上，开机没五分钟就重启，原因就是主板PCIe供电过载。

启动盘制作很简单，下载好OpenRIG镜像后，用写盘工具写入U盘。Linux下直接用dd，Windows下用写盘工具，这里以dd为例：

# 注意/dev/sdX是U盘设备名，写错会覆盖你的硬盘，务必确认 sudo dd if=openrig.iso of=/dev/sdX bs=4M status=progress

写入完成后，U盘插到目标机器，开机进入BIOS，把启动顺序改成U盘优先，保存重启，正常情况下会看到一个简洁的安装引导界面。

3.2 分区与基础配置

OpenRIG的安装过程比Ubuntu桌面版清爽很多，没有那么多下一步，主要就三件事：磁盘分区、时区网络、root密码。

分区我建议直接用全盘安装，不用手工分。它默认会把系统装在一块盘上，剩下的空间留给日志和临时文件。如果你机器里有多块盘，注意选择正确的目标盘，这步选错就等着哭吧。

网络配置尽量用静态IP，别用DHCP。道理很简单：节点端需要让管理端稳定找到它。DHCP分配的IP一旦变化，管理端就会显示离线，你还得去机房里看屏幕才能发现问题。

root密码一定要设得复杂些。OpenRIG是暴露在局域网里的，虽然家庭/IDC机房环境相对封闭，但管理口如果被猜到弱密码，别人就能远程控制你的显卡，轻则折腾你改配置，重则直接关掉所有算力。密码建议长度16位以上，混合大小写加符号。

3.3 驱动初始化与节点注册

OpenRIG安装完后，理论上已经集成了AMD显卡驱动，不需要你再去官网下载。但有个东西必须检查：驱动模块是否正常加载。执行：

lsmod | grep amdgpu

如果输出里有amdgpu字样，说明驱动加载成功。然后看显卡是否被系统识别：

lspci | grep -i "vga\|3d"

这条命令会列出一串显卡设备，数一下数量和你的物理显卡数量是否一致。如果不一致，先别慌，多数是PCIe识别问题，后面的排查章节有具体解法。

接下来是节点注册。OpenRIG节点端默认会在启动时自动寻找局域网内的管理端，但前提是管理端IP已经配置好。找到配置文件：

# 不同版本路径可能有差异，一般在/etc/openrig/下 vi /etc/openrig/agent.conf

把管理端IP填进去，然后重启节点服务：

systemctl restart openrig-agent

回管理端刷新页面，如果看到新节点上线，并且状态是绿色，恭喜你，这一步就通了。如果没看到，直接journalctl -u openrig-agent -f看日志，基本能定位是对端IP填错还是网络不通。

3.4 多卡算力与功耗调优

节点注册完成后，重点就是让6张卡稳定跑出性能。这里我不建议一上来就追逐极限参数，优先保证“连续48小时不出故障”，再考虑超频。

先看各卡状态和温度曲线。SSH登录节点后执行：

for i in /sys/class/drm/card*/device/hwmon/hwmon*/temp1_input; do echo "$i: $(( $(cat $i) / 1000 ))°C"; done

这条命令循环读取每张显卡的显存或核心温度传感器，打印成人类能看懂的摄氏度。正常空载温度应该在35到50度之间，满载能到75度以上但最好不要长期超过90度。

调优时，优先调整功耗墙（Power Limit）。A卡自带的功耗限制大家可以先不动，OpenRIG里有通过系统文件直接调整的入口。比如把某张卡的核心频率上限写低一点，降低整体功耗：

echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "s 0 3000" > /sys/class/drm/card0/device/pp_od_clk_voltage

这两行命令的意思是：先把功耗管理切到手动模式，再追加一组核心频率电压参数（这里的s 0 3000代表第0档频率设为3000MHz，具体数值要看你的卡支持范围）。改完之后用cat /sys/kernel/debug/dri/0/amdgpu_pm_info验证当前状态。

特别提醒：调这些参数前记下来原始值，改挂了还能改回去。我早期就是一边调一边忘，最后只能重装系统。

4. 日常监控与远程管理的落地细节

4.1 Web面板怎么用才高效

OpenRIG管理端的Web面板，默认给了一张总览页，能看到所有节点的温度、状态、显卡类型。但坦白说，默认布局对几十台节点的场景并不高效。我的习惯是：在“标签”功能里按照机房位置、显卡型号、使用场景分好类，然后保存为不同视图。

比如你有一个机柜专门跑高频负载，另一个机柜只做备用，那就分别建两个视图，只显示对应节点。面板不是用来“看”的，而是用来“快速定位异常”的，把无关机器折叠掉，异常出现时一眼扫到，比在列表里一行行翻快得多。

另外，把“节点离线”和“温度过高”两条告警规则调出来，阈值设好后，通知渠道建议选邮件或者Webhook。实测下来，邮件是最稳的，不会因为社交软件的接口变动而失效。

4.2 命令行是真正的日常工具

Web面板适合巡检和快速操作，但真正高频率的场景，我反而推荐SSH命令行。比如批量执行某条命令时，可以用循环脚本一次扫完所有节点：

for host in rig01 rig02 rig03; do echo "==== $host ====" ssh root@$host "uptime && nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader" done

这条循环会依次登录三台机器，显示开机时长和GPU温度。相比在Web面板上点开三个页面，命令行方式更适合批量脚本化，也便于以后接进自动化运维工具。

如果你需要定时巡检，还可以在管理端写个crontab，每小时把各节点的核心指标汇总成一个文件：

0 * * * * /usr/local/bin/check_all_rigs.sh >> /var/log/openrig_check.log 2>&1

这样即使你某天没看面板，回头翻日志也能掌握所有机器在过去一段时间里的运行趋势。

4.3 断电重启与自动恢复

机房中经常遇到的一个问题是突然断电。OpenRIG默认开机会自动启动代理服务，但如果你在BIOS里没开“来电自启”，断电后还是要手动去按电源键。建议在每台算力节点的BIOS里把“AC Power Loss”设置成“Power On”，这样来电时机器会自动开机。

同时，建议把OpenRIG代理服务设为开机自启，并加一个看门狗定时任务，检测代理进程崩溃时自动拉起：

systemctl enable openrig-agent

在此基础上，再配合一个简单的健康检查脚本，如果节点在指定时间内没有上报心跳，就尝试重启代理服务。这几层下来，节点基本能做到“断电再来自愈”，不用你半夜跑去机房。

5. 实际问题排查与避坑清单

5.1 常见问题速查表

我把实际运维中遇到过的高频问题整理成一张表，按“现象-原因-处理”排列，方便你直接对照操作。

这五类问题覆盖了绝大多数节点故障。剩下的问题，基本都是硬件层面的，比如显卡供电线松动、PCIe插槽积灰导致接触不良，这些靠日志看不出，只能用最笨的插拔法排查。

5.2 我在调优时踩过的几个特有坑

第一个坑是风扇策略。有些非公版显卡的风扇控制芯片在Linux下默认不会全速转，导致温度到了90度风扇还是只有40%。解决办法是先手动把风扇转速拉满测试：

# 以A卡为例，找hwmon目录下的pwm文件 echo 200 > /sys/class/drm/card0/device/hwmon/hwmon*/pwm1

pwm1的值从0到255，200差不多是80%转速。如果调完声音明显变大、温度下降，说明控制有效，剩下就是温度策略的问题，可以写一个根据温度自动调转速的脚本。

第二个坑是不要同时用两套监控工具。OpenRIG自带的监控和第三方远程管理工具一起跑，会导致传感器被轮询过频，个别显卡会出现I2C总线占用冲突，表现出来就是某张卡的功耗数值忽高忽低，跟波浪线一样。如果你非要用第三方工具，就把OpenRIG自带的采集周期拉长到30秒以上。

第三个坑是日志文件无限增长。我有一台节点跑了两个月后管理端突然变卡，排查半天发现是系统盘日志占满。OpenRIG默认日志级别比较详细，时间长了文件会很大。建议在日志服务配置里加上按大小切割和保留期限限制。

5.3 故障恢复的“三板斧”

当节点出问题，又确定不是硬件问题时，按顺序执行下面三个操作，大概能恢复八成的小毛病：

1. 重启代理服务：systemctl restart openrig-agent，解决大部分通信和上报问题。
2. 重启整个节点：reboot，解决驱动状态异常、显存泄露之类的问题。
3. 重建配置：如果重启后还是老样子，检查/etc/openrig/agent.conf是否被改动过，必要时备份后重置。

这三板斧看着简单，但运维这行最重要的从来不是炫技，而是把常规恢复动作标准化、让大家都能照着做。OpenRIG整套系统的设计思路，恰恰也是这个逻辑：减少单点操作，把稳定性和可恢复性内置到系统里。

我在实际使用中最大的体会是：折腾OpenRIG，最后得到的收获反而不是“怎样把系统调得更快”，而是理解了Linux下管理多张显卡、多台设备的基本方法。无论以后你是去管理渲染集群、GPU计算集群，还是做边缘计算设备，这套“管理端收集状态、节点端上报数据、脚本化自动巡检”的思路都是通用的。而且它完全开源、不锁硬件，想怎么魔改都行，只要你能看到日志、稳住供电，它就能一直跑下去。如果你手里正好有几台闲置的多卡机器，不妨从单台先试起，把这套流程完整走一遍，后续扩到满机房时就不会手忙脚乱了。