搭建gpu云服务器，显卡型号和镜像怎么选

第一次租GPU云服务器，不少人是在环境上耗掉两三天。驱动和CUDA版本对不上，框架报错，容器里看不到显卡，账单却一小时一小时地往上走。这篇文章按实际操作的先后顺序，讲搭建GPU云服务器时哪些地方要定下来，并用一个小团队的做法说明每一步为什么这样选。

先想清楚任务需要什么样的显卡

选型之前，先回答三个问题：跑训练还是跑推理，模型有多大，数据量有多少。大多数时候，显存比算力先卡住你。拿7B参数的模型举例，光是加载bf16权重就要约14GB显存。真正微调时，梯度、优化器状态和激活值还会再占一大块。24GB勉强够做LoRA微调，全参数微调基本要上80GB级别的卡。

创建实例时，镜像优先选平台自带的深度学习镜像。驱动和CUDA通常已经装好，能省掉大部分环境问题。系统盘留100GB以上比较稳妥。模型权重和数据集放到单独挂载的数据盘上，重装系统或者更换实例时，数据还在。

安全组要尽早收紧。SSH端口只对办公网出口IP开放，关掉密码登录，改用密钥。Jupyter、TensorBoard这类服务不要直接暴露在公网上，需要时通过SSH隧道访问。不少GPU实例被挖矿程序盯上，入口多半是默认端口开着，再加一个弱密码。实例创建完成后，最好马上把这两项处理掉。

如果用的是裸机镜像，驱动要自己装。在Ubuntu上，可以依次执行下面几条命令，先查看推荐驱动，再自动安装并重启：

sudo ubuntu-drivers devices
sudo ubuntu-drivers autoinstall
sudo reboot

重启后运行 nvidia-smi。如果能看到显卡型号、驱动版本和显存占用，说明驱动已经加载成功。

CUDA版本要和驱动配套。一般来说，新驱动可以兼容较旧的CUDA运行时，反过来就不行。所以更稳的顺序是：先确认框架要求的CUDA版本，再决定驱动装哪个版本。

多人协作时，建议用Docker统一环境。装好NVIDIA Container Toolkit以后，容器就能访问宿主机的显卡：

docker run –rm –gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

这条命令能输出显卡信息，说明容器GPU支持已经打通。如果提示找不到设备，多半是container toolkit的运行时没配置好，重启Docker服务后再试一次，通常就能解决。

正式训练之前，用一段很短的代码确认框架能识别GPU。以PyTorch为例，先看 torch.cuda.is_available() 是否返回True，再在显卡上做一次矩阵乘法，记下耗时和显存变化。这一步成本很低，却能提前暴露版本冲突，省得训练跑了几个小时才报错。

一个算法小组要微调7B中文模型。最开始只有一台本地工作站，显存不够，训练还得排队。他们分三步走。

第一步，在云平台租一台24GB显存的实例做开发，用平台深度学习镜像，数据盘挂在 /data 目录，代码走Git管理。开发阶段只用小样本跑通流程，确认数据格式、损失曲线和显存占用都正常。

第二步，LoRA方案确认可行后，把正式训练迁到80GB显存的实例上。训练环境用Docker封装，开发机和训练机使用同一个镜像版本，所以迁移只花了不到半天。容器镜像和数据盘在前面就已经准备好了。

第三步，训练结束后，先把权重同步到对象存储，再给实例做快照，最后释放实例。这样GPU只在训练时计费，空闲时间基本为零。这个小组后来发现，最大的浪费往往来自忘记关机。

GPU按小时计费，单价高，空转的钱累积得很快。下面几件事做到位，基本能把支出管住：

搭好GPU云服务器，关键是把环境固定下来。镜像、驱动、CUDA版本和容器配置确定以后，训练和推理就能稳定复现，新任务来了也不用重新折腾一遍环境。