GPU算力选型与驱动安装实战：从算力基准到故障排查的工程指南

CoreWeave、Nebius 这类名字频繁出现时很多讨论都把焦点放在英伟达 GPU 算力平台背后的资本关系、定价变化和长期竞争上。对一线开发者和平台工程师来说更值得关心的是另一条主线算力资源紧张、价格波动、新卡型号不断出现的环境下如何确认一台 GPU 机器满足任务如何在 Linux 上装好驱动如何测量有效算力如何在采购和排障时不被显卡名、网卡名和宣传参数带偏。这篇文章会围绕 GPU 算力选型、驱动安装、算力基准验证、成本评估和故障排查展开整理一套可以复用、也可以直接抽章节使用的工程方法。读完以后遇到“这台机器能不能跑这个模型”“为什么新实例价格波动这么大”“驱动装完突然找不到 GPU”这类问题都可以按文中的清单逐步处理。先说明一个边界本文不评价任何公司“能撑多久”也不会报具体云厂商的实时价格。公开资料和价格页面变化很快项目开始前务必以厂商页面、SLA 和合同为准。真正值得长期沉淀的是可迁移的技术判断方式。1. 先厘清“算力”到底是什么再谈论涨价和选型1.1 算力不是单一数字精度和场景决定有效算力“算力”不是一个可随便比较的标量。同样的 GPU处理 FP32、FP16、BF16、INT8 运算时速度差别很大处理卷积、矩阵乘法、注意力计算、多卡通信时表现也不同。厂商宣传页上的“峰值算力”往往是在理想时钟、理想散热和特定精度下取得的实际任务很难跑到这个数字。因此在工程沟通里看到类似“某显卡算力多少 T”“某平台算力有多少 P”的说法应该先反问三个问题这个数值使用的是 FP32、FP16、BF16 还是 INT8数值是理论峰值还是跑特定模型测出的实际吞吐是单卡结果还是通过多卡扩展得到的结果三者都不同结论就可能从“够用”变成“完全不够用”。训练任务和推理任务对算力的要求也不一样。训练阶段通常希望 GPU 计算单元尽量饱和一批数据在显存里被反复前向、反向计算推理阶段则要同时关注首 token 延迟、单次请求生成速度和并发吞吐。同型号显卡在训练和推理上的“有效算力”不能直接用同一个 TFLOPS 数字代表。1.2 TOPS、TFLOPS、token、API 不要混在一起许多新项目最容易把“算力、token、API”三个词混用。它们确实相关但不是同一个维度。先建立一张速查表后续讨论成本时能少很多误会。名词典型含义常见场景注意点TFLOPS每秒万亿次浮点运算通常表示 GPU 浮点算力GPU 选型、训练集群规划必须说明计算精度FP16/BF16 的数值可能比 FP32 高很多TOPS每秒万亿次整数运算常出现于端侧芯片、NPU、车规计算平台边缘设备、量化推理、智驾域控与 TFLOPS 不能直接换算也要看 INT8 还是 INT4token模型处理文本/代码时切分出的基本单元大模型 API 计费、推理延迟统计英文、中文、代码按不同词表会得到不同 token 数GPU 实例云平台上按需分配的显卡或裸金属资源训练、推理、调优可能独占整卡、占用 MIG 切片也可能共享时间片API把模型封装成远程接口供程序调用业务系统接入大模型能力计费通常按 token背后实际消耗的是 GPU 算力和显存数据/模型/场景算法项目的三个输入维度需求设计数据量决定预训练时间模型决定显存场景决定并发和延迟要求举个例子用户调用一次大模型 API服务商按“输入 token 输出 token”收费。用户感知的是 token 计费和响应速度服务商内部需要采购 GPU、组织显存、调度推理实例。用户看到的“价格/百万 token”和底层“GPU 算力/小时单价”并不相同但两者可以通过模型吞吐率换算。在一次项目评估里可以按这样的链路理解成本模型每秒可生成的 token 数 × GPU 同时服务的请求数 × 每 token 单价 单卡单位时间的服务收入能力反过来如果自己租 GPU 跑推理最需要关心的指标是“每秒能生成多少 token”以及“达到这个吞吐时用了多少显存和几张卡”。1.3 算力波动对工程师的真正影响不在新闻而在运维细节当 GPU 供给紧张、芯片生态和云厂商之间的合作发生变化时工程侧会出现一系列可以预见的后果。首先是实例可能无法随时创建。按需实例显示“库存不足”不代表产品不可用而是该地域、该显卡规格暂时没有配额。此时需要把队列请求、不同地域资源、多云备选方案纳入系统设计。其次是抢占型或竞价型实例的稳定性下降。价格波动剧烈时低价实例可能在训练中途被回收。训练任务必须做到断点续跑模型权重、优化器状态、学习率调度、随机数状态都要定期持久化到分布式存储或对象存储。最后是新硬件的软件兼容性问题。新显卡发布后驱动、CUDA、PyTorch 等框架未必马上支持。直接在新卡上跑老镜像很可能出现“驱动版本不够、CUDA 版本过旧、容器内看不到 GPU”等报错。这个问题放在后文排错部分详细展开。2. 认识 GPU 算力平台云实例、裸金属与硬件识别2.1 GPU 云厂商到底提供什么CoreWeave、Nebius 以及主流云厂商中的 GPU 实例本质上都是把 NVIDIA GPU 通过虚拟化、容器化或裸金属方式提供给用户使用。它们之间的差异更多体现在供给量、网络、存储、调度能力和合同模式上。对普通开发者来说选择哪一家 GPU 云第一步不是看“便宜多少”而是确认这家平台能否提供如下能力指定型号的 NVIDIA GPU以及可选的 MIG 切片或虚拟化实例可直接使用的 Ubuntu/CUDA 基础镜像或自定义镜像容器运行时已经接入 nvidia-container-toolkit支持需要高速网卡通信的训练集群比如 InfiniBand 或 RoCE提供按需、竞价、预留等不同计费方式并有清晰的 SLA。GPU 算力平台通常会交付一台“已经能跑 GPU 任务”的机器。用户创建实例后要能直接执行nvidia-smi看到显卡而不是再从裸机开始装驱动。这一点应该作为验收标准写进接入流程。2.2 云实例、裸金属和自建机房如何选择不同交付形态的差异不只是价格。形态优势风险适合场景共享 GPU 云实例价格低秒级开通算力可能被调度抢占邻居负载影响性能短期测试、原型验证、低优先级任务独占 GPU 云实例整卡资源隔离明确稳定性高于共享实例比共享实例贵创建同样受库存影响常规训练、线上推理、需要稳定吞吐的场景GPU 裸金属几乎无 Hypervisor 损耗多卡通信更稳定需要自行维护驱动、固件、运维大规模多卡训练、通信敏感型任务自建机房长周期成本可控数据留在本地采购周期长、硬件贬值快、运维负担重利用率高且稳定的长期项目或数据合规要求极高的场景实际选型不应只比较“一小时多少钱”。对于训练任务还要评估排队等待时间、存储读取速度、多节点网络带宽、故障恢复机制。一个需要排队两天才能启动的便宜实例往往不如第二天能启动、但贵一点的预留实例。2.3 不要靠网卡型号猜测 GPU 型号在很多硬件采购和技术讨论中会出现把“CX8”“B300”等型号混在一起的情况。CX 开头的设备通常是 NVIDIA ConnectX 系列网卡而 B300 是面向 AI 计算的 GPU 名称。两者是不同设备不能从一张网卡型号反推 GPU 规格。可靠的检查方式是进入系统后执行命令确认# 查看 PCI 设备中所有 NVIDIA 设备会同时看到 GPU、网卡等 lspci | grep -i nvidia# 查看 NVIDIA 驱动程序识别到的 GPU nvidia-smi -L如果机器已经装好驱动nvidia-smi -L的结果最准确因为它是驱动枚举出的真正显卡。如果驱动没有安装lspci只能看到设备 ID不能确定该卡在定制 SKU 下的具体显存和功耗设计。因此不要去猜直接看整机物料清单或厂商管理接口确认。注意采购表格里的“显卡型号”和“网卡型号”必须分开列。只写一个编号会让后面的驱动安装、网络连通性排查都找不到方向。3. 动手准备在 Ubuntu 24.04 上安装英伟达官方驱动3.1 安装前要确认的三件事驱动安装失败多数不是命令敲错而是没有确认硬件型号、内核版本和旧驱动状态。首先确认显卡型号lspci | grep -i nvidia然后确认当前系统内核uname -r最后检查是否加载了 NVIDIA 官方之外的开源驱动 Nouveaulsmod | grep nouveau如果lsmod输出中包含nouveau建议先禁用它再安装官方驱动否则可能出现模块冲突驱动加载失败或者安装完成后仍需重启才能生效。如果机器带图形界面并且你不想在安装过程中出现黑屏或登录循环建议全程通过 SSH 安装不要直接在当前图形会话里运行 .run 安装包。3.2 最稳妥使用 Ubuntu 官方仓库安装驱动Ubuntu 提供ubuntu-drivers工具。它首先检测 NVIDIA 显卡然后列出仓库中可用的驱动版本并给出 recommended 建议。对于大多数云服务器和学习环境这是最省事、也最容易回滚的方式。sudo apt update sudo apt install -y linux-headers-$(uname -r) ubuntu-drivers devices输出中会看到类似nvidia-driver-570、nvidia-driver-550这样的候选包。选择一个版本安装sudo apt install -y nvidia-driver-570 sudo reboot重启后验证nvidia-smi这种方式的优点是包管理器会自动处理内核模块编译依赖。如果内核升级导致驱动和内核不匹配再次执行apt install或apt upgrade时通常会重新匹配不需要手动写内核模块。常见误区是装了某个版本驱动后看到其他版本号更新就想手动替换。对于生产环境建议固定一个被 Ubuntu 标记为 recommended 的驱动系列并记录在变更清单里不要频繁升级驱动避免因为驱动变化导致 CUDA 应用行为变化。3.3 需要“历史版本驱动”时使用官方 .run 安装包企业内偶发情况是新驱动与内部 CUDA 应用不兼容需要回退到“官网某个历史版本”。Ubuntu 仓库通常只保留当前可用版本这时可以到 NVIDIA 官网驱动下载页面选择产品系列和操作系统下载对应的.run文件。安装前需要先准备好核心工具sudo apt update sudo apt install -y build-essential gcc make linux-headers-$(uname -r)创建 Nouveau 黑名单文件sudo tee /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF更新内核镜像并重启sudo update-initramfs -u sudo reboot重启后不要启动图形桌面直接在字符终端或 SSH 会话中执行sudo bash NVIDIA-Linux-x86_64-570.124.06.run如果是在既有图形桌面上补救可以临时切换运行级别sudo systemctl set-default multi-user.target sudo systemctl isolate multi-user.target安装完成并确认nvidia-smi正常后再恢复图形界面sudo systemctl set-default graphical.target sudo systemctl isolate graphical.target需要说明的是服务端通常不应该安装图形桌面。带 GUI 的机器安装驱动后若出现登录循环常见原因是驱动安装时安装了 OpenGL 文件和桌面环境冲突。此时可重新安装驱动并在提示是否安装 32 位兼容库和 OpenGL 文件时按要求选择若无法解决优先去掉自带的 Xorg 桌面而不是继续在 GUI 环境里折腾。3.4 麒麟等国产操作系统的安装差异“麒麟系统怎么安装英伟达显卡驱动”这个问题需要先判断系统基座。麒麟 V10 有的版本基于 Ubuntu/Debian有的基于 openEuler/CentOS 生态。步骤差异很大。先执行cat /etc/os-release cat /proc/version如果包管理器是apt通常可按 Ubuntu 方式安装但要把内核头包改成对应内核版本sudo apt update sudo apt install -y gcc make linux-headers-$(uname -r)如果包管理器是yum或dnf需要安装kernel-devel并且版本必须和当前内核完全一致sudo yum install -y gcc make kernel-devel-$(uname -r)由于麒麟的软件仓库不一定包含 NVIDIA 官方驱动最稳妥的做法仍然是从 NVIDIA 官网下载对应 Linux 版本的.run文件并先按 3.3 节的方式禁用 Nouveau。遇到驱动编译报错时第一优先检查内核头文件是否安装成功而不是反复重装驱动。系统基座包管理器常用内核头包驱动推荐方式Ubuntu 24.04aptlinux-headers-$(uname -r)nvidia-driver-*或官网 .run麒麟 V10Ubuntu 基座apt需要与内核匹配优先官网 .run禁用 Nouveau麒麟/openEuler 生态dnf/yumkernel-devel-$(uname -r)官网 .run 或发行版 kmod-nvidia任何一个依赖内核的驱动都遵循同一个规则内核模块的编译对象是“当前正在运行的内核”不是“最新内核”。升级内核后原来的 NVIDIA 内核模块通常失效需要重装驱动或重新生成模块。3.5 验证驱动安装成功安装完成后执行nvidia-smi正常输出应看到类似结构--------------------------------------------------------------------------------------- | NVIDIA-SMI 570.124.06 Driver Version: 570.124.06 CUDA Version: 12.8 | |----------------------------------------------------------------------------------- | 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 A100 80GB On | 00000000:3B:00.0 Off | 0 | | 0% 32C P0 52W / 300W | 1MiB / 81920MiB | 0% Default | ---------------------------------------------------------------------------------------注意第二行CUDA Version: 12.8表示“当前驱动支持的最高 CUDA 版本”并不代表用户态 CUDA 工具包已经安装。要查看编译工具版本需要执行nvcc --version如果系统找不到nvcc说明 CUDA Toolkit 未安装或未加入 PATH但很多基于 PyTorch 的项目使用的是自带 CUDA runtime不一定需要系统级安装完整 Toolkit。这个区分能避免把“驱动支持版本”和“本地编译工具版本”混为一谈。4. 不只验证“能显示显卡”用实际任务量化算力4.1 学会读 nvidia-smi 关键指标nvidia-smi不只是用来确认显卡存在还承载了性能监控和故障排查功能。实际操作中真正有用的指标有以下几项。指标含义排障时的价值Temp显卡当前温度温度持续接近 90°C 时可能降频算力会下降Pwr:Usage/Cap当前功耗 / 最大功耗如果功耗远低于上限且任务不复杂可能未充分利用Memory-Usage显存占用判断模型显存是否足够GPU-Util显卡计算单元利用率使用率低可能是小算子、数据加载瓶颈或 CPU 瓶颈Compute M.计算模式若显示 Restricted 或 Exclusive Process需要确认是否被占用Persistence-M持久化模式负载频繁启动时建议开启可减少模块初始化开销在监控脚本中更推荐使用查询模式而不是解析整屏输出nvidia-smi --query-gpuname,temperature.gpu,utilization.gpu,memory.used,memory.total,power.draw --formatcsv -l 1如果需要记录多个时间点nvidia-smi dmon -s pucvmet -d 5这里-s选择监控维度-d 5表示每 5 秒刷新一次。通常观察一个推理任务是否稳定至少要看 10 分钟以上不能只看任务刚启动瞬间。任务启动阶段会加载模型和数据GPU 利用率短暂偏低是正常的。另一个容易误判的点是显存占用很高不等于显卡在计算。显存中装满模型权重后如果数据加载慢GPU 计算单元依然会空转。看到Memory-Usage高而GPU-Util低先查 CPU、磁盘 IO 和网络读取速度。4.2 用 PyTorch 跑最小 GPU 验证最小验证使用 Python 和 PyTorch。先确认 PyTorch 能看到 GPUimport torch print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))执行一个小矩阵乘法并强制同步避免因为算子异步提交导致误判import torch device cuda a torch.randn(4096, 4096, devicedevice) b torch.randn(4096, 4096, devicedevice) torch.cuda.synchronize() c torch.matmul(a, b) torch.cuda.synchronize() print(c.shape) print(c.dtype)torch.cuda.synchronize()的作用是等待 GPU 任务执行完成。如果不等待代码可能已经往下执行并打印出尚未完成计算的中间结果无法用来对比耗时。如果运行报错 “CUDA driver version is insufficient for the CUDA runtime version”说明驱动版本太老而 PyTorch 自带的 CUDA runtime 版本太高。此时应该升级驱动而不是重新安装一个更老的 PyTorch。4.3 推理场景需要测量 token 吞吐大模型推理关注的不只是多少 TFLOPS而是每秒能生成多少 token。生产环境常用的指标如下指标含义如何计算TTFT首 token 延迟即用户发出请求后到收到第一个输出 token 的时间记录请求时间和首 token 到达时间差TPOT生成每个 token 的平均耗时总生成时间 / 生成 token 数tokens/s单卡或单实例的生成吞吐生成 token 总数 / 总耗时1M token 成本百万 token 级别计费成本实例小时成本 / 每小时产出 token 数 × 100 万用一个简单脚本大致测量当前硬件的生成能力import time from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen/Qwen2.5-7B-Instruct device cuda tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16).to(device) prompt TCP/IP 三次握手发生在哪一层 inputs tokenizer(prompt, return_tensorspt).to(device) start time.time() output model.generate(**inputs, max_new_tokens128) elapsed time.time() - start input_len inputs[input_ids].shape[1] output_len output.shape[1] - input_len print(f生成 token 数: {output_len}) print(f总耗时: {elapsed:.2f}s) print(f吞吐: {output_len / elapsed:.2f} tokens/s)这里的吞吐数字只适用于“当前模型、当前 prompt、当前 batch_size1、当前显卡”的组合。改变 batch size 后单请求吞吐可能下降但整卡总吞吐会上升。做性能对比时必须固定这些条件。4.4 多卡和大规模训练的检查点如果任务是多卡训练驱动层之外还要确认卡间通信。单看nvidia-smi无法验证 A100 与 A100 之间的 NVLink 或跨节点网络是否正常。常见命令# 查看卡间拓扑 nvidia-smi topo -m# 查看 NVLink 状态 nvidia-smi nvlink -s如果环境使用 InfiniBandibstat ibv_devinfo如果使用 RoCE 或普通以太网可以用iperf3测试两台机器之间的 TCP 带宽iperf3 -siperf3 -c 对端IP -P 8 -t 30注意大规模训练性能不是只看 GPU 型号。多卡拓扑、NVLink 连接情况、跨节点网络延迟都会成为瓶颈。一个训练任务从单机 8 卡扩展到两机 16 卡后没有线性增长先检查网络带宽再怀疑框架参数。5. 算力价格波动时怎样做成本评估和容量规划5.1 不同计费模型对应不同确定性GPU 云商的计费方式差异很大。评估时不要把“一小时价格”当成唯一指标还要看任务能否被抢占、实例生命周期多长、是否有最低使用时长。计费模型价格确定性稳定性适合场景按需实例较高高随时可创建按秒或按小时计费上线验证、无法容忍中断的服务竞价/Spot 实例低随供需变化低存在被回收风险高容错批处理任务、实验性训练预留实例/包年包月高高资源有保障长期稳定运行的训练集群GPU 裸金属中高高专用硬件对通信和硬件访问要求高的任务自建机房高但前期投入大取决于运维能力长期高利用率、合规要求严的项目如果预算紧张可以混合使用核心数据任务放到按需实例或预留实例非关键批量任务放到竞价实例。但竞价实例运行的训练任务必须满足两个条件可以随时从 checkpoint 恢复以及任务本身不需要低延迟输出。5.2 用“GPU 小时成本”换算成“每百万 token 成本”训练项目常用“GPU 小时”作为成本单位。比如一个任务使用 8 张 GPU 跑了 5 小时就是 40 个 GPU 小时。推理服务更适合换算成“每个 token”的成本。下面是一个演示计算过程数字不是真实报价只用于说明换算思路假设某单卡实例价格为 100 元/小时在线推理时该卡稳定输出 1000 tokens/s则一小时的输出量为1000 tokens/s × 3600 s 3,600,000 tokens每百万 token 成本约为100 元 / 3.6 约 27.8 元 / 1M tokens这个计算没有包含多副本负载不均、请求失败、冷启动、存储费用和人工成本。真实项目需要用监控数据按天统计每天 GPU 费用 ÷ 每天实际成功生成的 token 数。除了单次成本还要关注任务的“端到端时间”。当某型号 GPU 价格高、排队时间长时选择低一档但立刻有货的 GPU整体耗时反而更短。因此规划训练任务时要把“等待库存时间”也纳入工期。5.3 多供应平台评估清单无论是传统云厂商还是面向 AI 的云平台接入前都要按同一套清单评估避免 A 平台能跑、B 平台跑不了。是否有目标 GPU 型号驱动默认版本是什么。是否支持自定义镜像基础镜像是否包含 CUDA。实例是否支持 GPU 直通和 MIG 切片。Docker 或 Kubernetes 的容器运行时是否已接入 NVIDIA 组件。跨节点网络是普通以太网、RoCE 还是 InfiniBand。存储服务的读写带宽是否满足训练数据加载需求。是否允许设置实例标签或资源组账单能否按部门/项目拆分。合同是否允许在业务变化时调整实例数量。是否提供尽量详细的 GPU 监控指标而不是只有一个 CPU 指标。是否有真实可联系的技术支持以及故障响应 SLA。评估时不要只跑一个torch.cuda.is_available()就算通过。应该准备一个“标准验收镜像”里面包含加载模型、跑推理、检查显存、读写数据、多机通信五类步骤在所有候选平台上执行同一套脚本拿到可对比数据。5.4 直接调用 API 还是自购算力这个问题没有统一答案需要按使用频率、数据私密性、延迟要求、运维能力和成本确定性判断。维度使用商业大模型 API自建 GPU 推理或训练低频少量请求成本低省心需要空闲机器性价比低高频稳定请求单价可能高于自建容量充分时成本更可控私有数据需评估数据合规要求数据留在自有环境更可控特殊模型结构通常不支持可以自行加载任何开源权重延迟与运行环境依赖服务商链路可部署在业务系统同一内网运维负担低高需管理驱动、显存、扩容大多数团队会采用混合方案先用公开 API 验证产品形态确认模型效果后再把高并发、高成本或涉及敏感数据的部分迁移到自建 GPU 集群。迁移前要把模型负载、token 吞吐、显存占用和成本数据采集完整否则迁移决策没有依据。6. 高频故障排查从驱动不可见到容器内 OOM6.1nvidia-smi不存在或无法与驱动通信现象执行nvidia-smi提示命令找不到或者报错NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.处理顺序如下检查驱动模块是否加载lsmod | grep nvidia如果没有任何输出尝试手动加载sudo modprobe nvidia如果加载失败查看内核日志dmesg | grep -i nvidia | tail -50检查系统是否启用 Secure Boot。开启 Secure Boot 时未经签名的第三方内核模块可能被拒绝加载驱动安装看似成功重启后仍无法使用。测试环境可以进入 BIOS 关闭 Secure Boot或者按引导流程注册 MOK 密钥。服务器环境要按安全策略决定不能一律关闭。检查内核是否升级过。驱动安装后如果执行过内核升级nvidia.ko需要针对新内核重新编译。通常重新运行一次驱动安装程序或者执行apt install --reinstall nvidia-driver-xxx再重启即可。6.2 CUDA 版本与驱动版本不匹配现象PyTorch 或 CUDA 程序启动时报CUDA error: CUDA driver version is insufficient for the CUDA runtime version这里的规则是驱动版本决定它“支持”的最高 CUDA 版本。nvidia-smi输出中的CUDA Version是支持上限。如果编译应用用的 CUDA Toolkit 版本超过驱动支持上限就会出现该错误。排查步骤nvidia-smi nvcc --version比较两个