简介GPU_Burn是一款面向Linux/Ubuntu/CentOS系统的高性能GPU压力与性能测试工具适用于硬件爱好者、开发者和系统管理员常用于游戏、图形渲染、深度学习等重负载场景用于验证GPU在长时间高负荷下的极限算力、稳定性与散热表现同时可量化浮点运算能力、纹理填充率等关键指标并生成跑分报告便于横向对比不同NVIDIA显卡的性能差异。整个压缩包共包含8个文件、整体约65KB覆盖可执行程序、Makefile构建配置、C与CUDA源码、PTX后端表示及说明文档可执行文件可直接运行测试源码则方便二次开发或深入分析GPU压力测试中的负载生成、数据搬运和校验逻辑。已有8990人学习/下载该资源适合需要评估GPU性能、排查驱动或散热问题以及基于实测数据进行硬件调优和对比选型的用户。借助该工具可获得可复现的压测方法与跑分数据快速暴露潜在不稳定因素帮助辨别驱动兼容、散热系统或系统配置等隐患为性能优化、故障排查和硬件选型提供量化依据。同时对于Linux平台上的GPU资源管理与稳定性验证而言这是一套轻量但完整的参考方案。 新装好的机器开机点亮大部分人第一件事就是跑个分。跑分能说明上限但说明不了稳定性一块卡在 3DMark 里贴近满帧不代表它在 24 小时 AI 训练里不黑屏、不报错、不掉驱动。这正是 GPU 性能压力测试要回答的问题。gpu_burn 是圈子里很常用的开源压测工具它不给你打分数只做一件事把所有能调用的 GPU 持续拉到接近满负载让散热、供电、显存、ECC 在长时间运转中把问题暴露出来。如果你手头有刚验收的新卡、机房上下架的机器、或者不定时出现训练中断的服务器这篇内容应该能帮你少走点弯路。下面按我实际的用法把 gpu_burn 从编译、运行、看结果到排查故障的完整流程捋一遍。1. 压测到底在测什么gpu_burn 解决的稳定性盲区先把这个工具定位说清楚。跑分是短时间打峰值压测是长时间满负载运转两者解决的问题完全不一样。gpu_burn 本质上是一个循环调度 CUDA 核函数的程序它会对 GPU 的计算单元、显存控制器和电源系统持续施压。它不会给你一个好看的分数而是把硬件的薄弱环节放大给你看。为什么最怕的故障往往不是开机瞬间而是机器热起来之后因为热量会改变很多东西硅脂老化、热胀冷缩带来的接触电阻、供电模块过热后的降流、显存颗粒在高温下的位翻转。很多卡刚上机时一切正常跑十分钟后开始报错这就是压测存在的意义。用生活里的话说跑分像百米冲刺压测像马拉松gpu_burn 就是那个逼着 GPU 跑马拉松的教练。所以在实际工作中我一般不会用 gpu_burn 去判断“这张卡比那张卡快多少”而是用它判断“这台机器能不能稳定接业务”。尤其是在 AI 训练场景里一次训练跑几天中途因为一张卡掉线导致任务重来损失远大于跑分带来的那点心理满足。2. 编译安装前先确认环境省得卡在 make 阶段gpu_burn 没有复杂的安装流程一个 make 就能编出来但这不意味着你不需要准备环境。它依赖的是 NVIDIA 驱动和 CUDA Toolkit驱动只负责运行时编译必须要 nvcc。很多人在第一步就栽了nvidia-smi能正常显示显卡但 make 时报找不到 nvcc。我在 Linux 下最常用的流程是这样git clone https://github.com/wilicc/gpu-burn.git cd gpu-burn make编译之前先确认三件事nvidia-smi能正常列出显卡nvcc --version能正常输出 CUDA 版本系统里有 make 和 gcc 等基础编译工具。如果nvcc不在默认 PATH 里最典型的原因是 CUDA Toolkit 装了但没有配环境变量。手动指定一下基本能解决export CUDA_HOME/usr/local/cuda export PATH$CUDA_HOME/bin:$PATH make clean makemake 成功之后目录下会出现gpu_burn这个可执行文件。整个编译过程通常一两分钟就结束如果卡了很久大概率是驱动版本和 CUDA Toolkit 版本不匹配。有一点提醒一下gpu_burn 这个工具在 Linux 下最顺手官方也不太维护 Windows 原生编译链。如果你只能拿到 Windows 机器要么用 WSL 里的 CUDA 环境要么选择其他图形压力测试工具别在 gpu_burn 的 Windows 编译上耗太多时间。3. 把命令跑起来时长、多卡选择和输出含义3.1 最基本的运行命令gpu_burn 的用法非常简单直接给一个秒数就行./gpu_burn 60这个 60 表示跑 60 秒。你也可以跑 300、1800甚至 7200取决于你想压多久。我个人的习惯是这样分档新机器快速自检跑 5 到 10 分钟新显卡验收30 分钟起步返修机器或长时间高负载业务1 小时以上。如果不传参数工具内部有一个默认时长我建议不要依赖它每次显式写清楚秒数方便后续留记录。如果机器上有多个 GPU默认情况下 gpu_burn 会把 CUDA 可见的所有卡全部拉满。如果想单独测某一张卡用环境变量控制CUDA_VISIBLE_DEVICES0 ./gpu_burn 300先跑nvidia-smi -L确认卡号和卡序再决定要测哪几张这一步在多卡机器上特别关键。3.2 怎么判断这轮压测有没有通过跑的时候终端会先列出识别的 GPU 型号和 UUID然后打印烧录时长。一轮正常结束的 60 秒压测输出差不多是这样GPU 0: NVIDIA GeForce RTX 4080 (UUID: GPU-xxxxxxxx) GPU 1: NVIDIA GeForce RTX 4080 (UUID: GPU-yyyyyyyy) Burning for 60 seconds... GPU 0: OK GPU 1: OK这里最重要的就是最后一行每张卡是不是都以OK结尾。只要有某张卡不是 OK或者程序中途退出都要当成失败处理。不要因为前面输出看起来很顺利就放松。真正要警惕的是那种“跑 20 分钟才报错”的情况所以我通常会在压测的同时另开一个终端跑监控眼里不能只盯着 OK 两个字。4. 只看 OK 不够同时盯着这四个数据gpu_burn 的 OK 代表 CUDA 层面没有检测到错误但机器是否健康还要看压测过程中有没有热降频、供电不稳、显存错误。我每次压测都会在另一个终端挂 nvidia-smi 的监控nvidia-smi dmon -s pucvmet -d 5这条命令会每 5 秒打一次点显示功率、利用率、时钟、显存、温度等信息。数据持续刷屏的时候重点看下面这几项指标正常表现异常信号GPU 温度升到一个稳定值后基本持平不再继续涨反复逼近温度墙风扇满转但温度还是压不住功率接近这张卡的 TGP 标称值曲线平滑突然掉到很低或者周期性跳动核心/显存时钟保持在高频附近不频繁大幅跳变频繁降频说明散热或供电约束严重利用率GPU 利用率保持在很高位某张卡利用率突然掉下去可能已经报错退出这里有个容易误解的点gpu_burn 压的是计算和显存带宽不一定把显存容量吃满。你不要看到显存占用不高就以为工具没在工作判断核心是否满载主要看 GPU-Util 是不是一直贴近 100%而不是看显存容量用了多少。再补一个容易忽略的细节跑压测的过程中不要在同一个 GPU 上跑业务任务比如一边压测一边开推理服务。这不是能不能压测的问题而是会让结果变得不干净真出了问题你没法判断是压测发现的还是业务任务干扰出来的。5. 多卡压测最容易翻车的三个场景我压测过不少多卡机器总结下来问题通常集中在这几类。电源余量不足。多张卡在同一时间拉满功耗整机峰值功率会远高于平时。有的卡在压测中途直接掉到 0W 或者消失不是显卡坏了而是电源保护触发或者 12V 供电线分流不均匀。遇到这种情况先换电源线、换供电接口、换 PCIe 插槽重新测别急着判卡死。机箱内风道积热。多卡靠近摆放时上面那张卡的进风温度可能就是下面那张卡的出风温度。压测十分钟后卡间温差会越来越大。如果温差超过合理范围通常是风道设计的问题不是某张卡的个体差异。服务器里进风温度、前后压差同样会直接影响结果所以压测时最好把机柜环境温度和风扇策略也记录下来。CUDA_VISIBLE_DEVICES 误解。很多人以为默认只测当前正在显示的卡但 gpu_burn 会遍历所有 CUDA 可见卡。机器上八张卡你只插了电源线没有插业务线一跑 gpu_burn 照样全部满载。想测哪张就明确设置环境变量尤其是那种“我只想看看这张卡是不是坏了”的场景。这几类问题在单卡机器上不明显但多卡机器一跑就是连锁反应。我的习惯是多卡压测前先把所有 GPU 的型号、位置、UUID 全部打出来跑的过程中用 dmon 的日志逐卡对比哪一张数据掉队说明哪一张有问题。6. 压测失败怎么办我的排查链路如果 gpu_burn 跑到一半退出或者输出 FAILED先别急着重装驱动。按下面这套顺序排查通常能快速缩小范围。第一步先確認程序本身没跑错。用CUDA_VISIBLE_DEVICES0只测一张卡如果单卡也失败问题大概率集中在卡、供电或 PCIe 通道上如果单卡能过但多卡一跑就挂更可能是电源余量或整机散热问题。第二步看系统日志。Linux 下优先查 dmesg 里有没有 NVIDIA 相关的错误dmesg -T | grep -i nvidia dmesg -T | grep -i xid压测失败对应的 Xid 错误会把出错的总线和原因带出来。这一步非常重要因为很多故障不是每次都能复现。第三步查显存 ECC 错误计数nvidia-smi -q -d ECC如果 Uncorrectable ECC 计数一直在涨说明显存颗粒已经不稳定这种情况基本不能靠驱动解决该考虑售后了。第四步做硬件替换实验。把那张疑似故障的卡换到一个已知正常的 PCIe 插槽上跑一轮短压测再把一张正常卡放到原来的插槽上再跑一轮。两次对比能快速区分是显卡本身的问题还是主板插槽、供电线、电源的问题。第五步如果 gpu_burn 短时间能过但长时间不过可以用显存专项工具做补充和 gpu_burn 互补。日常运维里我很少单靠一个工具下结论通常是一轮 gpu_burn 加一轮显存专项测试两边都通过才敢继续走流程。整套流程跑下来如果还是要压测失败建议把操作系统、GPU 驱动版本、CUDA 版本、bios 设置、机器所在地的电力情况一起记录下来再去处理。很多随机性故障是环境因素不是单卡计算单元的问题。最后说一个我自己的习惯压测记录不要只看一个 OK把温度曲线、功率曲线、当天室温、机器序列号一起存档。以后出了问题横向对比时这些数据比一张截图有用得多。本文还有配套的精品资源点击获取 GPU稳定性压测指南：gpu_burn安装运行与故障排查
简介GPU_Burn是一款面向Linux/Ubuntu/CentOS系统的高性能GPU压力与性能测试工具适用于硬件爱好者、开发者和系统管理员常用于游戏、图形渲染、深度学习等重负载场景用于验证GPU在长时间高负荷下的极限算力、稳定性与散热表现同时可量化浮点运算能力、纹理填充率等关键指标并生成跑分报告便于横向对比不同NVIDIA显卡的性能差异。整个压缩包共包含8个文件、整体约65KB覆盖可执行程序、Makefile构建配置、C与CUDA源码、PTX后端表示及说明文档可执行文件可直接运行测试源码则方便二次开发或深入分析GPU压力测试中的负载生成、数据搬运和校验逻辑。已有8990人学习/下载该资源适合需要评估GPU性能、排查驱动或散热问题以及基于实测数据进行硬件调优和对比选型的用户。借助该工具可获得可复现的压测方法与跑分数据快速暴露潜在不稳定因素帮助辨别驱动兼容、散热系统或系统配置等隐患为性能优化、故障排查和硬件选型提供量化依据。同时对于Linux平台上的GPU资源管理与稳定性验证而言这是一套轻量但完整的参考方案。 新装好的机器开机点亮大部分人第一件事就是跑个分。跑分能说明上限但说明不了稳定性一块卡在 3DMark 里贴近满帧不代表它在 24 小时 AI 训练里不黑屏、不报错、不掉驱动。这正是 GPU 性能压力测试要回答的问题。gpu_burn 是圈子里很常用的开源压测工具它不给你打分数只做一件事把所有能调用的 GPU 持续拉到接近满负载让散热、供电、显存、ECC 在长时间运转中把问题暴露出来。如果你手头有刚验收的新卡、机房上下架的机器、或者不定时出现训练中断的服务器这篇内容应该能帮你少走点弯路。下面按我实际的用法把 gpu_burn 从编译、运行、看结果到排查故障的完整流程捋一遍。1. 压测到底在测什么gpu_burn 解决的稳定性盲区先把这个工具定位说清楚。跑分是短时间打峰值压测是长时间满负载运转两者解决的问题完全不一样。gpu_burn 本质上是一个循环调度 CUDA 核函数的程序它会对 GPU 的计算单元、显存控制器和电源系统持续施压。它不会给你一个好看的分数而是把硬件的薄弱环节放大给你看。为什么最怕的故障往往不是开机瞬间而是机器热起来之后因为热量会改变很多东西硅脂老化、热胀冷缩带来的接触电阻、供电模块过热后的降流、显存颗粒在高温下的位翻转。很多卡刚上机时一切正常跑十分钟后开始报错这就是压测存在的意义。用生活里的话说跑分像百米冲刺压测像马拉松gpu_burn 就是那个逼着 GPU 跑马拉松的教练。所以在实际工作中我一般不会用 gpu_burn 去判断“这张卡比那张卡快多少”而是用它判断“这台机器能不能稳定接业务”。尤其是在 AI 训练场景里一次训练跑几天中途因为一张卡掉线导致任务重来损失远大于跑分带来的那点心理满足。2. 编译安装前先确认环境省得卡在 make 阶段gpu_burn 没有复杂的安装流程一个 make 就能编出来但这不意味着你不需要准备环境。它依赖的是 NVIDIA 驱动和 CUDA Toolkit驱动只负责运行时编译必须要 nvcc。很多人在第一步就栽了nvidia-smi能正常显示显卡但 make 时报找不到 nvcc。我在 Linux 下最常用的流程是这样git clone https://github.com/wilicc/gpu-burn.git cd gpu-burn make编译之前先确认三件事nvidia-smi能正常列出显卡nvcc --version能正常输出 CUDA 版本系统里有 make 和 gcc 等基础编译工具。如果nvcc不在默认 PATH 里最典型的原因是 CUDA Toolkit 装了但没有配环境变量。手动指定一下基本能解决export CUDA_HOME/usr/local/cuda export PATH$CUDA_HOME/bin:$PATH make clean makemake 成功之后目录下会出现gpu_burn这个可执行文件。整个编译过程通常一两分钟就结束如果卡了很久大概率是驱动版本和 CUDA Toolkit 版本不匹配。有一点提醒一下gpu_burn 这个工具在 Linux 下最顺手官方也不太维护 Windows 原生编译链。如果你只能拿到 Windows 机器要么用 WSL 里的 CUDA 环境要么选择其他图形压力测试工具别在 gpu_burn 的 Windows 编译上耗太多时间。3. 把命令跑起来时长、多卡选择和输出含义3.1 最基本的运行命令gpu_burn 的用法非常简单直接给一个秒数就行./gpu_burn 60这个 60 表示跑 60 秒。你也可以跑 300、1800甚至 7200取决于你想压多久。我个人的习惯是这样分档新机器快速自检跑 5 到 10 分钟新显卡验收30 分钟起步返修机器或长时间高负载业务1 小时以上。如果不传参数工具内部有一个默认时长我建议不要依赖它每次显式写清楚秒数方便后续留记录。如果机器上有多个 GPU默认情况下 gpu_burn 会把 CUDA 可见的所有卡全部拉满。如果想单独测某一张卡用环境变量控制CUDA_VISIBLE_DEVICES0 ./gpu_burn 300先跑nvidia-smi -L确认卡号和卡序再决定要测哪几张这一步在多卡机器上特别关键。3.2 怎么判断这轮压测有没有通过跑的时候终端会先列出识别的 GPU 型号和 UUID然后打印烧录时长。一轮正常结束的 60 秒压测输出差不多是这样GPU 0: NVIDIA GeForce RTX 4080 (UUID: GPU-xxxxxxxx) GPU 1: NVIDIA GeForce RTX 4080 (UUID: GPU-yyyyyyyy) Burning for 60 seconds... GPU 0: OK GPU 1: OK这里最重要的就是最后一行每张卡是不是都以OK结尾。只要有某张卡不是 OK或者程序中途退出都要当成失败处理。不要因为前面输出看起来很顺利就放松。真正要警惕的是那种“跑 20 分钟才报错”的情况所以我通常会在压测的同时另开一个终端跑监控眼里不能只盯着 OK 两个字。4. 只看 OK 不够同时盯着这四个数据gpu_burn 的 OK 代表 CUDA 层面没有检测到错误但机器是否健康还要看压测过程中有没有热降频、供电不稳、显存错误。我每次压测都会在另一个终端挂 nvidia-smi 的监控nvidia-smi dmon -s pucvmet -d 5这条命令会每 5 秒打一次点显示功率、利用率、时钟、显存、温度等信息。数据持续刷屏的时候重点看下面这几项指标正常表现异常信号GPU 温度升到一个稳定值后基本持平不再继续涨反复逼近温度墙风扇满转但温度还是压不住功率接近这张卡的 TGP 标称值曲线平滑突然掉到很低或者周期性跳动核心/显存时钟保持在高频附近不频繁大幅跳变频繁降频说明散热或供电约束严重利用率GPU 利用率保持在很高位某张卡利用率突然掉下去可能已经报错退出这里有个容易误解的点gpu_burn 压的是计算和显存带宽不一定把显存容量吃满。你不要看到显存占用不高就以为工具没在工作判断核心是否满载主要看 GPU-Util 是不是一直贴近 100%而不是看显存容量用了多少。再补一个容易忽略的细节跑压测的过程中不要在同一个 GPU 上跑业务任务比如一边压测一边开推理服务。这不是能不能压测的问题而是会让结果变得不干净真出了问题你没法判断是压测发现的还是业务任务干扰出来的。5. 多卡压测最容易翻车的三个场景我压测过不少多卡机器总结下来问题通常集中在这几类。电源余量不足。多张卡在同一时间拉满功耗整机峰值功率会远高于平时。有的卡在压测中途直接掉到 0W 或者消失不是显卡坏了而是电源保护触发或者 12V 供电线分流不均匀。遇到这种情况先换电源线、换供电接口、换 PCIe 插槽重新测别急着判卡死。机箱内风道积热。多卡靠近摆放时上面那张卡的进风温度可能就是下面那张卡的出风温度。压测十分钟后卡间温差会越来越大。如果温差超过合理范围通常是风道设计的问题不是某张卡的个体差异。服务器里进风温度、前后压差同样会直接影响结果所以压测时最好把机柜环境温度和风扇策略也记录下来。CUDA_VISIBLE_DEVICES 误解。很多人以为默认只测当前正在显示的卡但 gpu_burn 会遍历所有 CUDA 可见卡。机器上八张卡你只插了电源线没有插业务线一跑 gpu_burn 照样全部满载。想测哪张就明确设置环境变量尤其是那种“我只想看看这张卡是不是坏了”的场景。这几类问题在单卡机器上不明显但多卡机器一跑就是连锁反应。我的习惯是多卡压测前先把所有 GPU 的型号、位置、UUID 全部打出来跑的过程中用 dmon 的日志逐卡对比哪一张数据掉队说明哪一张有问题。6. 压测失败怎么办我的排查链路如果 gpu_burn 跑到一半退出或者输出 FAILED先别急着重装驱动。按下面这套顺序排查通常能快速缩小范围。第一步先確認程序本身没跑错。用CUDA_VISIBLE_DEVICES0只测一张卡如果单卡也失败问题大概率集中在卡、供电或 PCIe 通道上如果单卡能过但多卡一跑就挂更可能是电源余量或整机散热问题。第二步看系统日志。Linux 下优先查 dmesg 里有没有 NVIDIA 相关的错误dmesg -T | grep -i nvidia dmesg -T | grep -i xid压测失败对应的 Xid 错误会把出错的总线和原因带出来。这一步非常重要因为很多故障不是每次都能复现。第三步查显存 ECC 错误计数nvidia-smi -q -d ECC如果 Uncorrectable ECC 计数一直在涨说明显存颗粒已经不稳定这种情况基本不能靠驱动解决该考虑售后了。第四步做硬件替换实验。把那张疑似故障的卡换到一个已知正常的 PCIe 插槽上跑一轮短压测再把一张正常卡放到原来的插槽上再跑一轮。两次对比能快速区分是显卡本身的问题还是主板插槽、供电线、电源的问题。第五步如果 gpu_burn 短时间能过但长时间不过可以用显存专项工具做补充和 gpu_burn 互补。日常运维里我很少单靠一个工具下结论通常是一轮 gpu_burn 加一轮显存专项测试两边都通过才敢继续走流程。整套流程跑下来如果还是要压测失败建议把操作系统、GPU 驱动版本、CUDA 版本、bios 设置、机器所在地的电力情况一起记录下来再去处理。很多随机性故障是环境因素不是单卡计算单元的问题。最后说一个我自己的习惯压测记录不要只看一个 OK把温度曲线、功率曲线、当天室温、机器序列号一起存档。以后出了问题横向对比时这些数据比一张截图有用得多。本文还有配套的精品资源点击获取