打开浏览器，你随手搜一下“openrig”，大概率会看到一堆和你想法差不多的东西：有人在做多卡 GPU 机架，有人在折腾监控面板，还有人在卖“一键超频”的脚本。但如果让我用一句话说清楚 openrig 是什么，我会说：这是我自己攒的一套开源“多卡算力机架管理方案”，从硬件摆放、供电散热，到软件监控、告警自愈，再到远程管理，全部打通。不是某个公司出的商业产品，而是把一堆成熟工具按自己的需求拧在一起，让 4 张、6 张甚至更多显卡能在同一台机器里长期、稳定地跑 AI 训练、视频渲染和科学计算。
这篇文章就是这套 openrig 方案的完整复盘。我会把踩过的坑、算过的账、写过的脚本、还有那些“文档里不会写”的经验全部倒出来。适合谁看？实验室或工作室里管多卡机器的人，家里有几张显卡想组算力节点的极客，以及任何一个被“掉卡、高温、电费爆炸”折磨过的朋友。就算你目前只有两张卡，里面的供电计算和监控思路一样能用。
1. openrig 是什么：先搞清它管到哪一层
1.1 多卡场景真正的麻烦在哪
单卡机器其实没什么好管理的：插上显卡、装好驱动、跑个程序，完事。真正让人头疼的是机器里塞进 4 张、6 张卡之后——你会发现“装驱动”只是万里长征第一步。
我最早管过 4 台各自独立的 4 卡机器，每台机器一个 IP，每天上班先 SSH 挨个连上去，手动敲nvidia-smi看温度、看显存占用。某张卡温度飙到 88 度了？风扇狂转但就是没人理。某个进程把显存占满导致别人任务 OOM 了？等用户来骂你才知道。更难受的是显卡随机掉卡：头一天还好好的，第二天nvidia-smi里少了两张，你根本不知道是供电不稳、金手指氧化、还是 riser 线接触不良。
这还只是监控层面的问题。往下还有供电和散热：6 张 RTX 4090 满载功耗接近 3000W，家里普通墙壁插座 10A 只有 2200W，一跑负载就跳闸。往上还有自动化：任务挂了能不能自动重启？温度超标能不能自动降压？断电解电后能不能自己恢复开机？这些问题没有一样是“装个驱动”能解决的。
所以 openrig 的出发点很朴素：把一台挂了 6 张显卡的“裸架子”变成一台可监控、可告警、能自愈的算力节点。它不是某个单一软件，而是一整套分工明确的开源方案。
1.2 openrig 的定位：开源、可组合、不做上层调度
我自己在搭 openrig 时把它的能力边界划得很清楚，这里也建议你照着这个思路来。
openrig 负责的是“机架层”和“监控恢复层”：硬件怎么摆、电怎么供、风怎么走、温度怎么采、异常怎么处理。它明确不负责上层工作：不跑容器编排（那是 Kubernetes 的活），不做训练任务调度（那是 Slurm、Ray 或者你训练框架的事），也不碰模型调优。说白了，openrig 是让你机器“活着且健康”的那层管道，而不是让机器“干活”的那层系统。
这个边界为什么重要？因为我见过太多人把监控、调度、训练全塞进一个自定义脚本里，最后脚本比业务还复杂，一改就崩。把每一层拆开、各管各的，出了问题你才能快速定位是“电的问题”“风扇的问题”还是“显卡本身的问题”。openrig 里的软件也都是开源组件：Prometheus 做时序采集，Grafana 做可视化，nvidia-smi 和 NVML 做显卡指标，系统层面的监控交给 node_exporter 和 ipmitool。每一层都可以单独替换，不绑架你。
1.3 适合谁，需要什么基础
坦白说，openrig 不适合纯小白。你需要的基本功是：会用 Linux 命令行、能看懂一点点 bash 或 Python、对电脑硬件有基本常识（至少知道 PCIe 插槽和电源线是干嘛的）。如果你只是想把一张 4090 装进家里的游戏机箱玩 Stable Diffusion，那完全不需要这套东西，一个 ATX 电源加一个普通机箱就够了。
但如果你是以下三类人之一，openrig 会非常对路：
| 人群 | 典型场景 | openrig 能带来的价值 |
|---|---|---|
| 实验室/公司管理员 | 管 4 台以上多卡机器，经常被用户拉着看“卡怎么坏了” | 统一监控、掉卡告警、自动恢复，减少半夜被叫醒 |
| 渲染工作室/视频组 | 多卡渲染集群，任务跑十几个小时，中途一张卡过热就全废 | 温度和功耗墙策略，让渲染任务长期稳定跑完 |
| 家里有多卡的极客 | 自己攒了 2~4 张卡，想跑模型微调、模拟计算 | 供电和安全用电规划，避免跳闸和火灾隐患 |
2. 硬件侧设计与选型：稳定性的地基
2.1 机架结构与卡位：为什么我推荐开放式机架
软件写得再好，硬件没搭稳一切都白搭。openrig 的第一件事是决定机器“长什么样”。
我的建议是：4 张卡以上，优先考虑开放式机架，别硬塞进普通塔式机箱。普通机箱的显卡间距通常只有 1~2 个槽位，多卡满负载时的热风会互相“闷”在中间，尤其是使用开放式风扇（open-air，就是那种三风扇超长卡）的显卡，卡与卡凑太近会让中间那张吸进来的全是旁边卡排出的热风，温度直接飙 10 度以上。
开放式机架怎么选？我用的是 4040 铝型材自己拼，成本不高，而且非常灵活。关键尺寸有这么几条：
- 每张卡之间至少留 2 个 PCIe 槽位（约 40mm）的间隙，让风能穿过。
- 显卡安装方向：如果你的卡是涡轮风扇版（blower，尾部出风），水平放置、风道从前往后吹最合理；如果是开放式三风扇卡，垂直放置效果更好，热空气自然向上走，卡背面的均热板散热效率更高。
- 主板装在机架底部，PCIe riser 线从主板插槽引到显卡位置。这里我要单独提醒一句：如果你买的是网络上那种“矿卡神器”的 x1 转接线，省了带宽，但用在 AI 训练和渲染上会非常难受。
这句话值得展开说。PCIe x1 的带宽只有约 1GB/s（PCIe 3.0 x1），跑挖矿那种“显存为主、数据交换极少”的任务可以凑合，但模型训练、视频渲染、科学计算这些任务需要频繁在 CPU 和 GPU 之间搬运数据，用 x1 转接线的后果是显卡性能被严重拖累，4 张 4090 跑起来可能只有一张半张卡的效率，卡顿得你怀疑人生。所以 openrig 的选型标准是：至少用物理 x16 插槽转接，能跑 PCIe 4.0 x8 以上带宽再考虑多卡并联。不需要每张卡都跑满 x16，但 x8 是最低底线，再低就等着数据搬运成为瓶颈吧。
2.2 供电计算：先算账再下单
供电是 openrig 里最不能省钱、也最不能想当然的部分。我见过不止一个人买了 1600W 的电源，插上 6 张卡一满载就重启，然后怀疑显卡坏了——其实纯粹是供电余量不够。
供电计算别拍脑袋，拿支笔算。我以常见的 6 张 RTX 4090 为例：
- 单卡最大功耗（TGP）按 450W 算，6 张就是 2700W。
- 主板、CPU、内存、风扇、硬盘这些系统部件，满载算 150~200W 不过分。
- 所以整机满载热功耗在 2850~2900W 左右。
- 电源长期高负载会发热、老化、保护性断电，行业经验是把电源负载控制在额定功率的 80% 以内。那么你需要：2900W ÷ 0.8 ≈ 3625W 的额定功率。
看到这个数字你就明白，市面上单颗 2000W 的 ATX 电源都顶不住 6 张 4090，必须做多电源并联。我的做法是两颗 2000W 服务器电源（HP/Delta 那种，配合转接板）或者两颗 1600W ATX 铂金电源，拆成两路分别供电：一路给主板和 3 张卡，另一路给另外 3 张卡。这里有个细节：两组电源的 12V 输出要物理隔离，不能交叉给同一张卡供电，否则可能出现共地、倒灌问题，轻则保护，重则烧板。
电路这条也要注意。国内家庭标准插座一般是 10A 220V，最大功率 2200W，刚才算的 2900W 满载你一插就跳闸。多卡机架必须走 16A 甚至 20A 的空调插座或工业插座，我自己的做法是专门拉了一路 4 平方毫米电线的 16A 回路给机架用。如果你在办公室或实验室，先问物业这路电路能承受多少，别把整栋楼跳了。
线材别省。我见过便宜的 PCIe 电源线用 18AWG 甚至 20AWG 铜芯，满载时发热严重，线皮都烫软了。openrig 里的标准：这种大电流线至少用 16AWG 硅胶线，接显卡的 8pin/12VHPWR 转接线买正规品牌，别在拼接线上省那几十块钱。
最后再强调一次“瞬时功耗”这个坑。GPU 的瞬时功耗可以达到 TGP 的 1.5~2 倍，尤其是任务启动瞬间和驱动编译 shader 时。哪怕你“算好”了总功率，电源质量差或者余量只留了 10%，照样会在启动那一瞬间触发过流保护。我建议的实际经验：富余量留在 30%，预算允许就直接上铂金或钛金电源，转换效率高，电压稳定，长期电费也能省回来。
2.3 散热与功耗墙：用最少的电保住性能
散热这块，openrig 的核心不是“多买几个风扇”，而是把气流组织好。先给一个大致的参考公式：每 100W 热功耗大约需要 35~40 CFM 的风量。6 张 4090 满载 + 系统共 2900W，就需要 1000~1200 CFM 的风量。这个量级不是机箱后面贴几个 12cm 风扇能解决的，得靠机架风扇阵列或整个房间的排风。
风扇摆放要讲道理：我试过直接在显卡正上方吊一个大风扇“对着吹”，效果一般。更好的方式是让气流沿着显卡的散热器鳍片方向贯通——从机架的一端吸冷风，另一端排热风，让空气形成一股从冷区到热区的稳定流动。我的做法是机架后端装一排 12038 工业风扇（厚度 38mm，风压大，风量标称远大于普通 12cm 薄扇），统一向后抽风，前面板不设阻挡。
比风扇更重要的是功耗墙。你一定听说过“降压超频”或者“限制功耗”的操作，这在 openrig 里是标配动作。实测数据：一张 RTX 4090 在 80% 功耗墙（约 360W）下，跑 AI 训练和渲染的性能大概只损失 3%~5%，但核心温度能降 8~10 度，整机发热量少 540W，风扇转速也能明显降下来。这个交换在大多数场景下都非常划算。限制功耗用 nvidia-smi 就能做，我也会在后文实操部分给出具体命令。
最后补一句关于噪声的实话：6 张卡加一排工业风扇，满载噪声随便过 60dB，放在家里你会烦死周围所有人。所以如果你不是把它扔在机房、阳台或专门隔音的小房间，我强烈建议你优先用“空间散热+功耗墙”组合来压低噪声，而不是试图用更贵的静音风扇去硬扛 3000W 的发热——热力学不太会给你这个面子。
3. 软件监控层：让每一块卡开口说话
3.1 数据源：NVML、IPMI、SMART 各管一段
硬件搭好以后，接下来是 openrig 真正“智能”的部分：让机器把它的健康状况全都说给你听。先说数据从哪来。
显卡数据优先走 NVML。你可能很习惯敲nvidia-smi，但要知道它只是 NVML 库的一个命令行前端。nvidia-smi 能拿到显卡型号、温度、显存、功耗、风扇转速、利用率、PCIe 链路状态等信息。在脚本里批量拿数据可以用这个：
nvidia-smi --query-gpu=index,name,temperature.gpu,utilization.gpu,utilization.memory,power.draw,power.limit,memory.used,fan.speed --format=csv,noheader,nounits输出长这样，一卡一行，方便后续解析。这里面power.limit就是你设置的功耗墙，fan.speed只有在显卡风扇由驱动控制时才有值，很多开放式三风扇卡会显示为 0，属正常现象。
主板和整机层面的数据走 IPMI。如果你的主板带 BMC/IPMI（服务器主板基本都有，消费级主板一般没有），可以用ipmitool读到 CPU 温度、主板传感器、电源状态、风扇转速等数据：
ipmitool sensor list没有 IPMI 的消费级主板，可以用lm-sensors读板载传感器，虽然没有那么全，但 CPU/主板温度还是能拿到。
硬盘也不能漏。GPU 算力任务往往伴随大量数据读写，NVMe 盘长期高负载写入后出坏块的例子不少。用smartctl定期检查磁盘健康状态：
smartctl -a /dev/nvme0这些数据都拿到了，怎么汇总？我推荐 Prometheus 体系：显卡数据用 nvidia_gpu_exporter 或 NVIDIA 官方的 DCGM Exporter 采集，系统数据用 node_exporter，然后统一收进 Prometheus，Grafana 里画图。这套栈是开源监控的事实标准，网上资料多，组件成熟，不会烂尾。
3.2 告警与自愈：不只在群里喊，还要自己动手
监控没有告警等于白装。openrig 的告警规则我分成两级：警告和严重。警告级别比如 GPU 温度超过 78 度、显存占用超过 90%、功耗被限制（说明撞墙了）。严重级别比如 GPU 温度超过 85 度、进程长期占用 GPU 但利用率归零（死锁征兆）、NVMe 盘报 SMART 错误、PCIe 链路降级。
Prometheus 的告警规则长这样：
groups: - name: gpu_alerts rules: - alert: GPUTempHigh expr: nvidia_gpu_temperature_celsius > 85 for: 5m labels: severity: critical annotations: summary: "GPU {{ $labels.gpu }} 温度过高，当前 {{ $value }} 度" - alert: GPUPowerCap expr: nvidia_gpu_power_limit_watts < nvidia_gpu_power_max_limit_watts - 1 for: 10m labels: severity: warning annotations: summary: "GPU {{ $labels.gpu }} 功耗被限制，可能性能受影响"注意那个for: 5m。这是我踩坑后才加上的——之前不少规则是瞬时触发，结果显卡跑一个瞬时尖峰任务，告警就噼里啪啦炸一轮，值班的人第二天起来看到 300 条消息直接拉黑。设置连续 5 分钟满足条件才报警，误报能砍掉八成。还要提醒一句：不同 exporter 的指标名会有差异，部署后先用curl拉一下 metrics 接口确认真实指标名再配置规则。
告警渠道上，我用的企业微信/钉钉的 webhook，比邮件快，也不用担心附件问题。Alertmanager 里直接配置 webhook 地址即可。
光告警还不够，openrig 的自动化要能“自愈”。我的重启脚本思路是分三步走：
- 先用
nvidia-smi检查是否有进程长时间占用 GPU 但利用率接近 0，如果有，先尝试杀掉那个进程。 - 如果显卡在
nvidia-smi里显示为 “ERR!” 或直接消失，尝试重新加载驱动：sudo modprobe -r nvidia再sudo modprobe nvidia，这种操作对老版本驱动偶尔管用。 - 如果驱动重载也不行，记录当前运行的任务状态，然后让机器自动重启。
别一上来就重启。粗暴重启虽然立竿见影，但如果只是某个用户进程把显存占满导致的 OOM，kill 掉那个进程就完事了，完全没必要拖着整台机器里的其他任务一起陪葬。自愈脚本要“最小动作”优先，杀进程 > 清显存 > 重载驱动 > 重启，一级一级往上走。
# 简易看门狗：发现某张卡利用率归零但温度偏高，怀疑卡死 for i in $(nvidia-smi --query-gpu=index --format=csv,noheader,nounits); do util=$(nvidia-smi -i $i --query-gpu=utilization.gpu --format=csv,noheader,nounits) temp=$(nvidia-smi -i $i --query-gpu=temperature.gpu --format=csv,noheader,nounits) if [ "$util" -lt 5 ] && [ "$temp" -gt 60 ]; then echo "GPU $i 利用率异常低但温度不低，疑似卡死" # 这里再根据你跑的框架决定是 kill 进程还是重启 fi done这只是个框架示例，真正用的时候要把你跑的框架（比如训练脚本）和任务状态考虑进去。
3.3 远程管理：系统死了也要能进门
前面说的告警和自愈，前提是你有办法“进门”操作。远程管理这块我给 openrig 定了几条原则。
第一条，SSH 只允许密钥登录，不能用密码。这不用我解释吧，密码认证的公网服务器每天都在被字典爆破。开机密码、密钥生成、禁用密码登录该做的都做了，你的机器在机房里才敢接外网。
第二条，系统级的远程管理要走带外管理（Out-of-band）。只要主板有 IPMI/BMC，即使系统宕机、SSH 连不上，你也可以通过 IPMI 远程开机、远程看 BIOS 界面、甚至远程挂载 ISO 重装系统。没有 IPMI 的消费级主板怎么办？加一个 PiKVM 或 JetKVM 这类基于树莓派的开源 KVM over IP 设备，把主板的 HDMI 输出和 USB 键盘鼠标口接进去，就相当于给机器装了一个“永远在线的外置 BMC”。这玩意儿是我用下来最值的一笔小钱，机器半夜挂了、还在千里之外出差的时候，它就是你的救命稻草。
第三条，不要把它暴露在公网裸奔。如果机房有局域网，就只在局域网内做管理；需要异地访问，走带身份认证的 SSH 端口转发，把 Grafana 和 Prometheus 的端口都绑在本地回环地址上，不要直接开公网端口。
4. 从零搭建一套 openrig 的完整实操流程
4.1 选型清单：按卡数选平台
这部分是给准备动手的人看的“抄作业”列表。硬件选型最关键的是 PCIe 通道数，不是你 CPU 多快。
| 显卡数量 | 主板/平台建议 | 理由 |
|---|---|---|
| 1~2 张 | 主流消费级主板（Z690/Z790/X670E） | 通道数够用，成本低，散热简单 |
| 3~4 张 | 消费级主板 + 开 Above 4G Decoding 和 Resizable BAR，或用 X99 等二手平台 | 消费级平台 PCIe 通道有限，3~4 张必须合理分配，别盲目堆 |
| 4~8 张 | 二手 EPYC 7002 系列 + H11SSL/S8030 这类服务器主板 | 64 条甚至 128 条 PCIe 通道，不用为带宽打架 |
| 8 张以上 | 直接上 4U 机架式服务器 | 供电、散热、管理都是现成的，自己攒性价比反而低 |
我自己主力机用了 EPYC 7302P + 超微 H11SSL，16 核 32 线程，64 条 PCIe 4.0 通道，跑 6 张卡每张能分到 x8，非常宽裕。CPU 不必追求旗舰，多卡机器里 CPU 只是“司机”，算力大头都在 GPU 上。内存建议至少 64GB 起，跑数据预处理和加载模型的时候就不会卡脖子。
其他配件清单给个参考：
| 部件 | 推荐方向 | 备注 |
|---|---|---|
| 显卡 | 推荐涡轮版（blower）或开放式大卡 | 涡轮版散热好但噪音大，开放式大卡温度低但吃风道 |
| 机架 | 4040 铝型材自拼 | 灵活、便宜、散热好 |
| 电源 | 双 1600W 或双 2000W 铂金/钛金 | 记得留 30% 余量，分路供电 |
| riser | 物理 x16 线缆，PCIe 4.0 支持 | 拒绝 x1 矿线，性能差太多 |
| 风扇 | 12038 工业风扇阵列 | 风压大，适合穿通风道 |
| 网卡 | 板载 2.5G，要求高可用 Intel X710-DA2（10G） | 数据量大时 1G 口是瓶颈，集群场景上 10G 不亏 |
4.2 驱动、持久模式与开机自启
系统我用的 Ubuntu Server 22.04 LTS。装驱动有一条我很推荐：直接装官方 .run 包，比 apt 源里的版本更新，而且能避免 apt 自动升级把驱动搞坏。不过 .run 装完以后每次内核升级都要重装模块，所以如果你不想折腾，用 Ubuntu 的ubuntu-drivers方案也完全没问题。
sudo apt update sudo apt install ubuntu-drivers-common sudo ubuntu-drivers install # 重启后验证 nvidia-smi装好驱动后，两件必须做的事：
第一，打开持久化模式。默认情况下，进程跑完释放 GPU 后，显卡会进入低功耗状态，下次启动任务时初始化成本较高。用nvidia-smi -pm 1让显卡一直保持工作状态。这在多卡频繁起任务的场景下尤其重要。
第二，设置功耗墙。之前说过，80% 功耗墙是甜点。比如 4090 默认 450W，设成 360W 试跑一下任务，性能几乎没感觉，温度却舒服很多：
sudo nvidia-smi -pm 1 sudo nvidia-smi -pl 360但注意，-pl的数值范围是由显卡 VBIOS 决定的，有些卡最低只能到某个值，设偏了会报错。执行后可以用nvidia-smi看 Power Limit 那几栏来确认。
问题是这些设置重启后就没。所以要做成开机自启。我写了一个 systemd 服务：
[Unit] Description=NVIDIA GPU initial setup After=multi-user.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/nvidia-smi -pm 1 ExecStart=/usr/bin/nvidia-smi -pl 360 [Install] WantedBy=multi-user.target把这段保存到/etc/systemd/system/nvidia-setup.service，然后：
sudo systemctl daemon-reload sudo systemctl enable --now nvidia-setup重启之后手动看一眼nvidia-smi确认Persistent Mode是 enabled、Power Limit是你设的值。
4.3 监控栈部署：一条 docker-compose 拉起
监控栈我直接用 Docker Compose 管理，几分钟就能拉起来。这是我的精简版配置：
version: "3.8" services: node-exporter: image: prom/node-exporter container_name: node-exporter network_mode: host restart: unless-stopped nvidia-gpu-exporter: image: utkuozdemir/nvidia_gpu_exporter container_name: nvidia-gpu-exporter network_mode: host restart: unless-stopped prometheus: image: prom/prometheus container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./alert.rules.yml:/etc/prometheus/alert.rules.yml - prometheus-data:/prometheus network_mode: host restart: unless-stopped grafana: image: grafana/grafana container_name: grafana environment: - GF_SECURITY_ADMIN_PASSWORD=StrongPass123 volumes: - grafana-data:/var/lib/grafana network_mode: host restart: unless-stopped volumes: prometheus-data: grafana-data:对应的prometheus.yml里，把 node-exporter 和 nvidia-gpu-exporter 都抓进来：
global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: node static_configs: - targets: ["localhost:9100"] - job_name: nvidia-gpu static_configs: - targets: ["localhost:9835"]utkuozdemir/nvidia_gpu_exporter默认端口就是 9835，抓回来之后 Grafana 里导入开源社区做好的 NVIDIA GPU 面板模板（在 Grafana 官网搜 “nvidia gpu” 就能找到），几分钟就能看到温度曲线和功耗曲线。这里我不直接放完整面板 JSON，因为版本不同字段有差异，最重要的是你明白了这套链路是怎么转起来的。
别忘了启动后curl localhost:9835/metrics看一眼，确认显卡指标真的在输出，再进 Grafana 里配数据源。
4.4 压测与性能验证：不能只跑三分钟就说稳定
配置全部落地后，别急着跑正式任务。先压测，压测不过关的机器上线就是定时炸弹。
GPU 稳定性压测我习惯用 gpu-burn，这个工具非常直接，就是把每张卡的运算单元全部打满，持续烤：
git clone https://github.com/wilicc/gpu-burn.git cd gpu-burn make ./gpu_burn 600600 秒就是 10 分钟。跑之前看一眼室温，跑的时候同时盯着nvidia-smi的温度和功耗。合格标准是：每张卡温度到达平衡后不再持续爬升（一般 70~85 度之间，取决于你的功耗墙和散热条件），且中途没有任何一张卡掉进“ERR!”或被驱动踢掉。
我更推荐的做法是压测的同时打开 Grafana 实时看曲线，一台机器二十分钟内温度曲线应该是一条平缓的上升线，最后趋于平坦。如果某张卡的温度一直在往上走、不带停的，说明风道有问题或卡间距太近，别硬扛，先解决散热再上线。
除了 GPU 烤机，我还会用 Blender Benchmark 或一个小型 AI 训练任务做“真实负载”验证。GPU-burn 测的是极限功耗下的稳定性，而真实任务能暴露显存分配、数据搬运这些环节的问题。两个配合起来，才算过了 openrig 的上线门槛。
5. 常见问题与排查技巧实录
5.1 显卡掉卡：最常见也最玄学的问题
“开机时还是 6 张卡，跑了一天变 5 张了。”这是 openrig 运维里遇到最多的问题，没有之一。
排查顺序我总结成一张表：
| 步骤 | 命令/操作 | 说明 |
|---|---|---|
| 1. 确认系统是否看到卡 | lspci | grep -i nvidia | 如果系统都看不到，多半是硬件/供电层面问题 |
| 2. 看内核日志 | dmesg | grep -i "nvrm|aer|reset" | 会看到 PCIe 错误、驱动 reset 信息 |
| 3. 确认驱动状态 | nvidia-smi | 如果 nvidia-smi 输出卡的数量少于 lspci，驱动加载失败 |
| 4. 物理检查 | 断电后重新插拔显卡/riser | 金手指氧化、riser 线松动是最常见物理原因 |
| 5. 供电检查 | 万用表/电源使用情况 | 瞬时功耗触发保护导致的掉卡很隐蔽 |
掉卡的原因大概率是这几类：riser 线质量差（这是头号嫌犯）、PCIe 金手指接触不良、电源瞬时供电不足、以及主板 BIOS 设置问题。我的建议是先把所有 riser 换成品牌线材，并且在 BIOS 里确认开启了 Above 4G Decoding。这个选项在很多消费级主板上默认是关闭的，多卡环境下不开会出现各种奇怪的“少卡”现象，甚至开机自检就卡住。
还有一条容易被忽略的经验：如果你用的是双电源，注意两组电源的启动时序。要么用一个 24pin 转接板实现主电源带动副电源同步启动，要么确保副电源在系统开机前已经上电。副电源晚启动的瞬间，PCIe 设备可能因为供电不稳定直接不被识别，表现就是“开机少一张卡”。
5.2 一样的卡，为什么温度和转速差很多
经常有人问我：六张一模一样的卡，同样的功耗墙，为什么 3 号卡总是比 1 号卡高 12 度？
我的排查顺序是先看位置，再看风道，最后怀疑卡本身。
第一，位置问题。机架里每张卡的“待遇”不一样：靠近主板南桥的卡可能被 CPU 散热器的热风污染，靠近电源的卡可能被电源排出的热风直吹。这种物理位置造成的温度差非常正常，你能做的是重新安排卡位，把最容易发热的卡放在风道入口一侧。
第二，airflow dead zone。检查机架风扇阵列是不是真的覆盖了所有卡的出风方向。我踩过最典型的坑是：风扇装了一排，但两张卡中间有个缝隙，气流从缝隙“短路”了，反而是旁边的卡没吃到风。解决方法是加一块导流板，或者调一下风扇位置让气流强制穿过显卡散热鳍片。
第三，如果是同位置、同风道，温度差还是大于 5 度，就要怀疑卡本身的散热模组问题了。尤其是二手卡，我遇到过不少“看起来新、实际热垫已经干裂”的情况。你可以在 Linux 下看 GPU 的 Hotspot 温度：
nvidia-smi -q -d TEMPERATURE如果核心温度和 Hotspot 温度差值超过 15 度，基本就是导热垫老化或者核心硅脂干了，该拆开重涂了。这里顺带提醒：拆涡轮卡时注意核心周边的显存导热垫厚度，买错 0.5mm 都可能接触不良导致显存比核心还烫。
风扇转速差这事，如果 nvidia-smi 里fan.speed显示为 0，别慌——很多开放式显卡的风扇不是由驱动控制的，而是在显卡 BIOS 里根据核心温度自动调速，Linux 下你是看不到也改不了的。这种情况下，想让显卡凉快，请回到风道和功耗墙这两件事情上。
5.3 掉电/重启后起不来，人在外地怎么办
机房空调跳闸一次，整台机器就再也叫不醒，这种事情我经历过一次之后，再也不敢不配置“上电自恢复”。
很多服务器主板和部分消费级主板在 BIOS 里都有一项叫 “Restore on AC Power Loss” / “AC Power Recovery”，把默认的 “Power Off” 改成 “Power On” 或 “Last State”（恢复成上次的状态）。这样断电再来电，机器会自己开机，不需要你人跑到机房按电源键。
但如果断电后是因为系统文件损坏起不来，那“自恢复开机”也救不了你。这时候就是前面说的带外管理登场的时刻：IPMI 的 SOL（Serial Over LAN）能让你看到完整的启动日志，PiKVM 级别的 KVM 设备能让你像坐在显示器前一样操作 BIOS。我个人的血泪建议：openrig 里至少要有一台带 IPMI 的机器做“旗舰节点”，其他机器可以用 PiKVM 顶，否则任何一次远程断电事故都能让你焦虑一整天。
另外，如果你部署在经常不稳的电网上，一台 UPS（不间断电源）不是可选件。UPS 的意义不只是“断电后还能撑几分钟”，更重要的是它输出的电压波形稳定，能过滤电网里的杂波和电压跌落。GPU 对供电瞬变极其敏感，很多莫名的“掉卡”“重启”其实都是电压跌落造成的。有条件的话，让 openrig 的整机功耗保持在 UPS 额定功率的 60% 以内，再用 UPS 的 USB 口接自动关机脚本，断电后系统能优雅关机而不是硬断电。
5.4 监控告警轰炸与误报处理
告警系统上线第一天很安静，跑了一周以后开始疯狂轰炸，这是常态。我自己踩过的坑主要这几个：
第一个坑是告警规则没加“持续条件”。瞬时温度超过 85 度不代表出问题，很多卡在任务启动瞬间温度尖峰一下又回落。所以一切告警规则都尽量加for: 5m。真有严重故障，它绝对等不了 5 分钟就会被你发现。
第二个坑是 Alertmanager 没有做分组和抑制。显卡掉卡不是一张张掉的，常常一瞬间掉三张，一条规则触发三次告警，再加上相关联的 PCIe 链路告警、温度告警一起冲进来，灌满了群。在 Alertmanager 配置里按 GPU 实例做分组，并且用inhibit_rules把“掉卡”告警抑制掉同实例上的其他次要告警，群里瞬间就清净了。
第三个坑是数据源指标名不统一。nvidia_gpu_exporter、DCGM exporter、版本不同、指标名不同，你从网上抄的查询表达式很可能直接查不到数据。我的习惯是先用curl拉一次 metrics，搜一下temperature、power关键字，确认实际指标名再配规则，不要盲抄。
Grafana 侧的经验是：做一块“总览 Dashboard”，把最重要的几个数字放到最上面：整机功耗、最高 GPU 温度、最低显存余量、风扇全速百分比。不用每天盯着十几张图表，瞄一眼总览就够了。细化到某张卡的深挖页面再进层去看。
最后再分享两个我自己的心得
这套 openrig 方案走到今天，我其实没有用任何“神级工具”，全是公开的开源组件加一套不算复杂的脚本。但最值钱的部分反而不是软件，而是我在供电和散热上多抠出来的那点“余量”。机器稳定跑了大半年，掉卡次数从最初的每周几次降到几乎为零，靠的就是把每个环节的富余做足：电源余量 30%，风量比理论值多 20%，功耗墙留 20% 性能牺牲换来的温度安全垫。这些看起来“浪费”的东西，最后都会回报你。
如果你准备动手，我的建议是先从小处开始：用你手头现有的两张卡，把监控和告警先跑起来，再算清楚家里电路到底能吃多少功率，最后决定要不要上开放式机架和更多卡。openrig 不是一次性买齐所有东西的清单，它是一套可以拆开逐步迭代的框架。等你把单机的温度、功耗、远程管理都理顺了，再往多机集群方向扩展，那又是另一个级别的挑战了。
