兄弟，你的这个问题确实挺折磨人的——高负载跑2-4小时才崩，系统日志还没多少有效线索，先把你的配置和问题再理清楚：

• 硬件配置：两块RTX 3090（NVLink连接）、老旧主板、64GB内存、i5-9600K CPU，电源是SEASONIC 1300W（应该是你打错了13000W）
• 运行场景：Ubuntu Server系统跑llama.cpp，运行2-4小时后崩溃
• 崩溃现象：系统先卡顿几秒，然后显示**PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)**这类错误（对应你贴的报错截图），几秒后自动重启
• 已排查项：GPU温度稳定、重装过系统、内存占用正常、dmesg无有效日志

结合这些信息，给你几个针对性的排查方向，按优先级试试：

1. 先排除电源与供电的潜在问题 #

虽然1300W标称足够两块3090+CPU的负载，但有几个细节容易忽略：

• 检查电源的PCIe供电线：是不是用的电源原生线？有没有插紧？有些第三方转接线或者松脱的接口会导致高负载下供电不稳
• 电源老化排查：如果电源用了好几年，标称功率可能打折扣，条件允许的话换一块同规格的全新电源测试，看还会不会崩
• 主板PCIe供电能力：老主板的PCIe插槽供电模块可能老化，高负载下供电不足，你可以摸一下主板PCIe插槽附近的供电MOS管，崩溃前是不是异常烫手

2. 排查NVLink相关的兼容性/硬件问题 #

NVLink高负载下也可能出问题：

• 先断开NVLink桥，单卡跑llama.cpp测试，如果长时间不崩溃，那大概率是NVLink桥本身或主板NVLink支持的问题
• 检查NVLink桥有没有插紧，有没有灰尘或者针脚氧化的情况，拔下来清理一下再插回去试试

3. 深挖系统日志，别只看dmesg #

dmesg空不代表没有日志，试试这些：

• 查看/var/log/syslog和/var/log/kern.log，找崩溃前几分钟的日志，说不定能找到一些被dmesg遗漏的错误信息
• 修改Grub参数开启内核调试：编辑/etc/default/grub，把GRUB_CMDLINE_LINUX_DEFAULT加上debug log_buf_len=16M，然后执行sudo update-grub重启系统，下次崩溃后再查日志，大概率能抓到更多线索

4. 软件层面的负载调整 #

也有可能是llama.cpp的参数设置太激进，导致硬件长期处于极限负载：

• 降低llama.cpp的--batch-size、--n-gpu-layers这类参数，减少GPU的瞬时负载，看能不能延长运行时间甚至不崩溃，如果有效，那说明当前硬件扛不住这么高的持续负载

备注：内容来源于stack exchange，提问作者user2741831