租一台卡跑模型、给推理服务扩容、临时借一台做微调——GPU服务器这件事听起来就是装个驱动跑起来真做起来才发现装驱动从来不是难点难点是驱动装完了、nvidia-smi 也出图了但 PyTorch 告诉你torch.cuda.is_available()是 False。我把验收拆成了三层来看卡在不在、驱动对不对、算力能不能真的用起来。这三层任何一层出问题前一层都还是好的——这正是它难查的原因。先说清楚口径我手头这台机器没有 NVIDIA 卡下面出现的输出是典型格式示例字段含义与版本对应关系取自 NVIDIA 官方 nvidia-smi 手册与 CUDA Toolkit Release Notes截至 2026 年 10 月不是本机实测。命令和判读顺序本身是通用的你照着跑一遍就能对上自己的环境。先把概念定下来gpu服务器是什么它不是一个单独的机器品类而是普通服务器插上了 NVIDIA 计算卡T4、A10、A100 这类并配好驱动栈——硬件部分是卡软件部分是驱动 CUDA 运行时 上层框架。所谓验收验的就是这条链通不通。一、先分清楚一件事你要验的是驱动装没装对还是算力能不能用起来这两种情况的处理路径完全不同混着查会浪费大量时间。驱动层算力层典型现象nvidia-smi报错、无输出、卡数量不对nvidia-smi正常但框架用不了卡常见原因驱动没装、内核模块没编译、装完升级了内核容器没挂卡、CUDA 版本对不上、框架是 CPU 版排查入口lsmod、dmesg、安装日志nvcc、torch.version.cuda、容器运行时判断标准很简单先跑一次nvidia-smi。命令都出不来 → 驱动层问题往下看第三节命令正常但框架用不了 → 算力层问题直接跳到第五节。两条路都讲但重点在后者——因为前者报错明确后者常常看起来一切正常。拿到一台 GPU服务器我的建议是先花一分钟照这一节的判据对号入座再决定往哪条路走。二、30 秒快检四条命令我的建议是别一上来就通读 nvidia-smi 那一大屏输出先跑这四条把范围收窄。nvidia-smi# 卡在不在、驱动版本、CUDA 版本nvidia-smi-L# 列出每张卡的型号与 UUIDnvidia-smi --query-gpuindex,name,utilization.gpu,memory.used,memory.total--formatcsv nvidia-smi --query-compute-appspid,used_memory--formatcsv第三条是我最常用的它只返回需要的字段可以直接塞进脚本做定时采样比解析默认输出稳得多。默认那一大屏是给人看的--query-gpu是给程序看的。第四条能回答一个高频疑问显存被谁占了。云上 GPU 经常是多个人共用一台你看到显存只剩 2G多半是别人的进程还挂着。这里有个容易看漏的点--query-compute-apps只显示计算进程图形进程比如开着 X11不会出现在列表里但显存照样被它占着。三、nvidia-smi 顶部的三行和它们的真实含义先看默认输出长什么样典型格式字段以你的实际环境为准----------------------------------------------------------------------------- | NVIDIA-SMI 580.126.09 Driver Version: 580.126.09 CUDA Version: 13.0 | |--------------------------------------------------------------------------- | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | || | 0 NVIDIA A10 On | 00000000:00:1E.0 Off | 0 | | 0% 32C P8 12W / 150W | 0MiB / 24576MiB | 0% Default | ---------------------------------------------------------------------------第一行有两个版本号按 NVIDIA 官方手册的口径解释Driver Version是内核驱动的版本。这是唯一能直接判断驱动装没装对的数字。CUDA Version不是你装了什么 CUDA是这块驱动最高能支持到哪个 CUDA。这是全文最容易看错的一处——nvidia-smi 报 CUDA 13.0只代表你可以装 13.0 及以下的 toolkit不代表机器上装了 13.0。要查实际装了什么得用nvcc --version前提是你装了完整 toolkit。我见过太多人拿这两个数字去对 PyTorch 版本对不上就重装驱动其实方向反了。GPU-Util 那个百分比不是算力占用率这是最容易被误读的字段。按 NVIDIA 官方 nvidia-smi 手册 的原文定义GPUPercent of time over the past sample period during whichone or more kernels was executingon the GPU. The sample period may be between 1 second and 1/6 second depending on the product.翻过来就是它统计的是过去一小段时间里有 kernel 在跑的时间占比不是 SM 被用了多少。所以GPU-Util 100%只能说明这张卡一刻没闲着至于算力吃满了没有它不告诉你——一个只在做内存拷贝的 kernel 也能把这一列顶到 100%。反过来利用率低也不一定代表卡闲着可能是 kernel 之间有大量等待。手册还注明采样周期在 1 秒到 1/6 秒之间取决于产品所以瞬时值抖动是正常的判断趋势请用nvidia-smi dmon连续采样别盯着一次快照下结论。另外手册里有一条很实用驱动初始化阶段如果 ECC 是开着的会看到 GPU 和显存利用率偏高那是 ECC Memory Scrubbing 在做内存巡检不是有程序在跑。刚开机那几分钟看到高利用率先等一会儿再看。其余几个字段字段含义据 nvidia-smi 手册我一般怎么看Persistence-M驱动是否常驻。开启后即使没有客户端X11、nvidia-smi驱动也保持加载减少 CUDA 程序的启动延迟。仅 Linux长期跑服务的机器上建议开nvidia-smi -pm 1Compute M.计算模式Default允许多个上下文、Exclusive Process每卡只允许一个上下文、Prohibited禁止计算看到Prohibited就知道卡被禁了计算框架必然用不了Volatile Uncorr. ECC自上次驱动加载以来检测到的未纠正 ECC 错误数非零就要警惕手册说明这类错误会导致计算行为异常Memory-Usage显存用量 / 总量看的是占了多少不是用了多少算力Fan/Temp/Pwr风扇、温度、功耗云上一般看不到风扇虚拟化看到温度持续贴顶要查散热四、驱动、CUDA、框架三个版本怎么对齐先记住 NVIDIA 官方 CUDA Toolkit Release Notes 里的一句话The CUDA driver is backward compatible: applications compiled against a particular CUDA Toolkit version continue to work on subsequent (later) driver releases.驱动是向后兼容的——用某个 CUDA 版本编译的程序在更新的驱动上照样能跑。所以出问题的方向只有一个你用的 CUDA 比驱动能支持的还新。Release Notes 的 Table 3 给了小版本兼容的驱动范围CUDA Toolkit 版本驱动版本范围小版本兼容13.x≥ 58012.x≥ 525 且 58011.x≥ 450 且 525配套的驱动分支对应关系Table 2节选CUDA 13.4 → R615、13.3 → R610、13.2 → R595、13.1 → R590、13.0 → R580。我的建议是按框架版本倒推驱动不要按最新来装。先确定你要跑的 PyTorch / vLLM 需要哪个 CUDA再反推驱动最低版本——这样装出来的组合一定是能跑的。反过来先装最新驱动再挑框架很容易踩到驱动太新、框架还没适配的坑。三个数字分别怎么查nvidia-smi# 驱动版本 驱动支持的最高 CUDAnvcc--version# 实际安装的 toolkit没装就 command not foundpython-cimport torch; print(torch.version.cuda)# 框架编译时用的 CUDA关键判据框架编译时用的 CUDA 版本 ≤ 驱动支持的最高 CUDA 版本这个不等式成立就一定能跑不成立就会在初始化上下文时报错典型信息是CUDA driver version is insufficient for CUDA runtime version。这里我踩过一次坑nvcc报command not found不代表环境有问题。推理场景压根不需要编译器很多生产镜像比如nvidia/cuda:xx-runtime就是不带 nvcc 的。只有你要从源码编译算子时才需要 toolkit跑推理只需要驱动和运行时库。五、容器里看不到卡四个要检查的地方容器里看不到卡是 GPU服务器 验收时算力层最高频的一类问题nvidia-smi在宿主机上好好的进容器就No devices were found。按 NVIDIA Container Toolkit 官方文档 的做法容器要用上 GPU 需要宿主机装了 toolkit 并配置好运行时不是装了驱动就行。dockerrun--rm--gpusall nvidia/cuda:13.0-base nvidia-smi--gpus从 Docker 19.03 起可用。另一种方式是用环境变量NVIDIA_VISIBLE_DEVICES官方文档给的取值取值含义0,1,2或 GPU UUID逗号分隔的 GPU 编号或 UUIDall所有卡都可见CUDA 基础镜像的默认值none没有卡可见但驱动能力仍然启用空 / 未设置等价于不注入任何 GPU四个检查点按顺序来宿主机上nvidia-smi是否正常。不正常就先回到驱动层容器里的所有问题在这一步之前都是无解的。有没有装 NVIDIA Container Toolkit。只装了 docker 和驱动是不够的官方安装文档在docs.nvidia.com的 container-toolkit 章节。装完要重启 docker。运行时有没有配上去。docker info | grep -i runtime看不到nvidia就说明没配用nvidia-ctk runtime configure --runtimedocker配一下。环境变量有没有被覆盖。镜像里如果自己设了NVIDIA_VISIBLE_DEVICESvoid外面传--gpus all也不管用。我一般把这四条固化成一个验收脚本新建实例跑一遍省得每次现场查。六、四个对不上的地方一、nvidia-smi 显示有卡框架说没有多半是装成了 CPU 版的框架。pip install torch默认装的是 CPU 版本要装带 CUDA 的那一个。判据很简单torch.version.cuda返回None就是装错了版本重装比排查快。二、显存看着够还是 OOM注意区分两个数字Memory-Usage里总量是这张卡的物理显存但驱动和 CUDA 上下文本身要占一小块实际可用会略小于标称。另外多进程共享一张卡时别人的进程随时可能再申请——留 10% 余量是个稳妥的习惯。三、驱动装完重启就失效这是 Linux 上的经典坑腾讯云的 GPU 驱动文档里列得很清楚驱动安装时需要编译内核模块装完之后如果升级了内核版本原来的模块就对不上了。装驱动前先确认gcc和kernel-devel-$(uname -r)在位系统里存在多个内核版本时尤其要确认 DKMS 编译的是当前这个内核。华为云的文档也提示了同一类问题驱动安装日志通常在/var/log/nvidia-installer.log如果里面报的是编译错误比如内核接口参数不匹配基本就是内核与驱动版本不兼容换匹配的版本重装比硬调快。四、云上 GPU 的利用率和实例内看到的不一致云厂商的监控指标通常是分钟级采样而 nvidia-smi 的采样周期是秒级甚至更短。短促的算力尖峰在云监控曲线上会被抹平——两边数据不一致时先确认采样粒度再怀疑是不是真有问题。七、什么时候不需要自己折腾驱动说清楚边界免得用错力气只是临时跑一次推理→ 直接用云厂商预装驱动的镜像或云市场镜像别手动装。手动装驱动要匹配内核、要编译模块为一次性任务不值当框架已经提供了预编译包→ 用 conda / pip 装带 CUDA 的轮子如pytorch-cudaxx不要全局装完整 toolkit。全局装容易和系统里已有的版本打架vGPU / 虚拟化型实例→ 只能用特定版本的 GRID 驱动NVIDIA 官网那份通用驱动对不上走厂商给的镜像或云助手。选 gpu服务器规格 时就要确认好这张卡是直通还是虚拟化两种的驱动完全不同要图形渲染而不是通用计算→ 该装的是 GRID 驱动且需要 License装 Tesla 驱动解决不了反过来什么时候该自己装厂商自动装的版本和你的框架不匹配或者你要锁一个特定版本做复现——这两种情况手动装是更可控的。八、云上三家驱动这件事的默认行为不一样很多人搜 阿里云gpu、腾讯云gpu 这类词其实要找的就是这一节——三家的默认行为差别不小直接影响 GPU服务器 开出来之后第一步要做什么。阿里云GPU 实例本身不带驱动需要装 Tesla 驱动通用计算或 GRID 驱动图形渲染具体对应关系见阿里云 Tesla 或 GRID 驱动安装指引。创建实例时勾选自动安装是最省事的路子它会同时把 CUDA 和 cuDNN 一起装好耗时大约 10~20 分钟安装日志在/root/auto_install/auto_install.log成功会提示ALL INSTALL OK。安装过程中不要动 GPU 相关软件否则会失败。腾讯云分计算型和渲染型。计算型实例直通卡装 Tesla 驱动用于通用计算渲染型要装 GRID 驱动并申请 License安装方式见腾讯云创建实例后快速安装 Tesla 驱动。自动安装大约等 10 分钟。它的文档专门列了三条安装失败原因缺gcc/kernel-devel、多内核版本导致 DKMS 编译错版本、装完驱动又升级了内核。华为云提供已包含特定版本 GPU 驱动的公共镜像也可以在创建时勾选「自动安装 GPU 驱动」脚本用法见华为云自动安装 GPU 加速型 ECS 的 GPU 驱动Linux用私有镜像创建的实例则必须手动装否则拿不到计算加速能力。另外它明确提示同一台 ECS 只能装 GRID 或 Tesla 中的一种两种驱动内核冲突同时装会导致黑屏或显卡识别异常。装完建议执行sudo nvidia-smi -pm 1开启持久化模式。还有一条三家的共性问题容易被忽略重装或切换操作系统之后之前自动安装的驱动会失效得重新走一遍安装流程。三家的共同点是驱动版本、CUDA 版本、cuDNN 版本是绑在一起给的不要只挑其中一个升。要换就整套换换之前先卸载干净。九、顺序总结与验收清单顺序总结一下nvidia-smi 出来了吗 → 卡对不对 → 驱动与 CUDA 对齐了吗 → 容器能看到吗 → 框架能用吗。前面任何一步不过后面的都免谈。我把这个顺序固化成脚本之后新机器验收基本五分钟能走完比对着一屏输出猜快得多。# 一条命令出关键字段适合直接进监控脚本nvidia-smi --query-gputimestamp,name,driver_version,utilization.gpu,memory.used,memory.total,temperature.gpu--formatcsv,noheaderFAQGPU服务器 上 nvidia-smi 显示的 CUDA Version 是我装的 CUDA 吗不是。它表示当前驱动最高能支持到哪个 CUDA 版本实际安装了什么要用nvcc --version或python -c import torch; print(torch.version.cuda)查。驱动向后兼容所以驱动报的版本比框架用的高是正常且安全的。GPU-Util 显示 100%是不是说明算力跑满了不能这么判断。按 NVIDIA 官方手册这个数字是过去采样周期内有一个或多个 kernel 在执行的时间占比它反映忙碌程度不反映算力利用率。要看算力是否吃满得用 Nsight 之类的 profiling 工具。容器里 nvidia-smi 报 No devices were found怎么查按四步走宿主机 nvidia-smi 是否正常 → 有没有装 NVIDIA Container Toolkit → docker 运行时里有没有 nvidia → 镜像内有没有把NVIDIA_VISIBLE_DEVICES设成 void。绝大多数情况卡在前两步。GPU服务器 装完驱动、重启后 nvidia-smi 失效了是什么原因最常见的是内核被升级了。驱动安装时会针对当前内核编译内核模块内核一变模块就加载不上。装驱动前确认gcc与kernel-devel-$(uname -r)已安装并且系统里没有多余的休眠内核版本干扰 DKMS。云上 GPU 实例需要自己装驱动吗看厂商。阿里云需要除非创建时勾选自动安装腾讯云计算型需要华为云用公共镜像创建的计算加速型实例默认已预装。用私有镜像创建的基本都要手动装。说明文中涉及的驱动版本、CUDA 版本对应关系、安装耗时与默认行为均为发文时的产品文档口径不同实例规格与镜像版本会有出入具体以各家官网当期文档与控制台显示为准。
