云GPU老将Tesla K80实战：租用、环境配置与PyTorch推理避坑指南

说起Tesla K80 GPU，不少刚接触云端算力的朋友第一反应是：这卡怎么还在卖？但你去翻任何一个算力租赁平台的库存，K80往往还是能搜到，而且按小时的价格便宜得让人心动。我最初也是抱着“试试看”的心态，在线上租了一台K80实例，结果发现它用来做模型验证、推理、批量图像处理这类任务，完全能打。这篇文章就把我从选配置、开机、SSH登录，到装驱动、跑PyTorch、控制账单的全过程，一步步拆开给你看，尤其是版本匹配和显存使用这些容易踩坑的地方。

1. 为什么到现在还要在云上点开一台K80

1.1 K80的硬件底细与真实价值

先把这台“老将”的底细说清楚。Tesla K80本质上是一张双芯计算卡，板卡上有两颗独立的GPU核心，每颗核心拥有12GB GDDR5显存，整卡合计24GB。它的计算能力等级是3.7，放在今天看确实落后，但它有两个其他老卡比不了的优势：一是显存大，二是云上价格低。

它的关键规格大概是这样：

第一个要记住的重点是：“24GB”不是一整块显存。由于双芯设计，K80在系统里通常被识别成两个12GB的设备，云厂商宣传的“单卡24GB”是物理合计值。你在PyTorch里直接写device='cuda'，默认只会用其中一张卡，也就是12GB。要真正把24GB都用上，得自己开两个进程，或者用DataParallel跨卡调用。

正因为显存不小，K80现在在云上的主要价值是：跑那些“显存需求明显、单核算力要求不高”的任务。比如大批量图像特征提取、目标检测的推理、BERT-base级别的文本向量化、传统机器学习里的数据并行训练，这些任务用K80慢慢跑，成本非常低。

1.2 适合与不适合的使用场景

我觉得有必要把使用场景说得直白些，避免有人看到便宜就租，结果任务跑不动还怪卡。

适合的任务：

• 中小模型的推理服务，只要不要求极低延迟，K80完全能扛住。
• 批量数据处理，例如给几十万张图片做缩放、裁剪、特征提取。
• 教学演示、算法验证、课程作业，跑LeNet、ResNet、VGG这类经典网络。
• 小batch的模型微调，batch size控制在16以内，常用模型还是能训练起来的。
• 双卡数据并行实验，用两个进程各跑一张卡，效率反而比单进程DataParallel可控。

不适合的任务：

• 大语言模型微调或推理，例如参数量亿级以上的模型，12GB显存根本塞不下。
• 大batch训练，想一次塞128张224x224图片训练ResNet50，显存直接爆。
• 需要FP16混合精度、Tensor Core加速的训练，K80这些都没有。
• 对实时性要求很高的在线推理，比如人脸识别闸机这种，建议换新卡。

一句话：K80是一个“算力便宜但算力不大”的GPU，适合把时间换成钱，不适合和现代显卡硬拼速度。

2. 创建GPU实例：把K80变成一台可远程登录的服务器

2.1 选平台选规格的思路

云上租GPU这件事，不同平台操作略有差异，但核心逻辑一样。你先别急着下单，先在平台确认三件事：

第一，平台是否真的提供K80型号。很多平台最近把老卡下架了，只有部分算力租赁平台还保留“GPU计算型K80”这类规格。搜不到K80，可能是入口藏得深，可以找“老款计算卡”或“高性价比GPU”专区。

第二，计费模式是不是按小时。K80这种老卡如果强制月付，性价比就大打折扣了。我一般优先选支持按量付费和竞价实例的平台，用完就释放，能省不少。

第三，是不是GPU直通。有些平台提供“GPU虚拟化”，把一张卡切成多份卖，这种对K80来说非常不划算，老卡性能本来就不强，再虚拟化就不剩多少了。选“直通”或“整卡独享”的模式，性能更可控。

选好平台后，规格通常长这样：CPU给4到8核，内存给16到32GB，显卡是Tesla K80一块或两块。如果你只是跑跑推理，一块K80加4核CPU、16GB内存足够了；如果你想顺便用CPU做数据预处理，那就选8核，内存给到32GB，减少瓶颈。

2.2 创建实例的几个关键参数

创建实例时，控制台里有一堆选项，我按实际经验给一份推荐参数：

数据盘这一点很多人会忽略。K80实例多半是平台的老库存，系统盘重置很频繁，如果把代码和模型放在系统盘，实例一旦释放就什么都没了。我习惯把数据盘单独挂载到/data目录，所有模型、数据集、代码仓库都放/data下面，系统盘随便重置都不慌。

2.3 登录前要检查的三件事

实例启动不是点一下“购买”就完事，启动完成到能登录，中间有几个坑需要提前排掉。

第一件事是确认公网IP。有些平台默认不分配公网IP，实例创建完只有一个内网地址，你在本地根本连不上。一定要在实例详情页确认已经绑定了公网IP，或者用弹性公网IP功能临时绑定一个。

第二件事是安全组规则。安全组就是云上的防火墙，默认可能只放行某些端口。你至少要放行TCP 22端口，否则SSH登录直接被拦在外面。有的平台把安全组配置放在网络页面里，不显眼，找不到就文档搜索“安全组”或“防火墙”。

第三件事是密钥权限。如果你在Linux/Mac上使用SSH密钥，私钥文件权限太放开的话，系统会拒绝使用。一般要执行chmod 600把密钥文件权限收回来。Windows用户则要注意密钥下载路径和权限设置。

登录前还可以看一眼计费规则：这个实例是“开机计费”还是“关机仍计费”？不同平台差别很大。有的平台关机后不再收GPU费用，但数据盘和IP费用照收；有的平台关机了依然收整机费用。搞清楚这一点，后面控制成本才有据可依。

3. 远程环境初始化：驱动、CUDA与Python环境一次理清

3.1 SSH登录与基础设置

拿到公网IP后，在本地终端里执行：

chmod 600 ~/.ssh/k80_key.pem ssh -i ~/.ssh/k80_key.pem root@<公网IP>

第一次连接时会有“是否确认主机指纹”的提示，输入yes回车即可。登录成功后，先做几件基础的事情：

apt update && apt install -y build-essential curl htop git

htop用来观察CPU和内存状态，git用来拉取代码，build-essential保证有些pip包需要编译时不会缺工具链。接下来先跑一条最关键的检查命令：

nvidia-smi

如果这条命令正常输出一张GPU信息表格，说明驱动已经就绪，省掉了一大半麻烦。如果提示command not found，或者报错说找不到设备，先别急着装最新驱动，往下看版本问题。

3.2 驱动与CUDA版本对应关系

K80的计算能力是3.7，这意味着它对新驱动和新CUDA的兼容性正在逐步收窄。很多教程让你直接装最新驱动、最新CUDA，结果装完发现K80根本不识别，或者PyTorch报“no kernel image is available for execution on the device”。

我的建议是，不要追求最新，追求“刚好能用”。下面是这些年比较稳的组合：

如果你不想手动装驱动，最简单的做法是使用已经配置好CUDA的Docker容器镜像，驱动层依赖主机上的驱动，容器里只需要匹配CUDA版本即可。这样主机驱动只要能用nvidia-smi看到卡，容器里就基本能跑。

如果平台给的镜像是“裸系统”，没有驱动，需要手动安装，我的建议是选470系列的Linux驱动，不要选最新分支。安装完用nvidia-smi确认驱动版本，再安装与驱动匹配的CUDA工具链。

3.3 Python环境准备

系统自带的Python版本可能比较老，建议用虚拟环境把项目依赖隔离起来。我用的是Python自带的venv：

apt install -y python3-venv python3-pip python3 -m venv ~/envs/k80 source ~/envs/k80/bin/activate pip install --upgrade pip

PyTorch版本不建议装最新的，选1.10到1.13之间即可，这些版本对Kepler架构的兼容性还可以。例如：

pip install torch==1.12.1 torchvision==0.13.1

这里有个经验：不是每个PyTorch版本都会为所有老显卡预编译kernel，如果你装了较新的版本，跑起来报no kernel image，优先降级PyTorch，而不是去装新驱动。装完之后验证一下：

python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count())"

如果输出True和数字2，说明环境已经没问题了。

4. 跑一个真实任务：容器化部署与推理代码实操

4.1 为什么我建议容器化

裸环境能用，但我更推荐在K80上用Docker容器跑实际任务。原因很简单：可复现、可销毁、不污染系统。

你可以把容器镜像理解成一个“打包好的环境”，里面预装好了CUDA、PyTorch、常用库。换到另一台K80实例时，把同一个镜像拉下来，跑起来就是一模一样的环境，不会再出现“本地能跑云端报错”的问题。

拉取一个适合K80的CUDA 11基础镜像：

docker pull nvidia/cuda:11.0-cudnn8-devel-ubuntu20.04

然后用--gpus all参数启动容器：

docker run -it --rm --gpus all --shm-size=8g \ -v /data:/data \ -v /root/envs/k80:/workspace \ nvidia/cuda:11.0-cudnn8-devel-ubuntu20.04 bash

进入容器后先跑nvidia-smi，如果能看到两张K80，说明容器正常接入了GPU。如果看不到，多半是容器运行时缺少nvidia组件，这个问题我在后面的故障表里会细说。

在容器内还需要补一个PyTorch安装步骤。由于基础镜像里只有CUDA，没有Python的深度学习库，启动容器后执行pip install torch==1.12.1 torchvision==0.13.1即可。你也可以先把这些依赖写进Dockerfile，构建一个自定义镜像，以后每次拉起来就是现成的。

4.2 准备数据与模型

数据上传这件事，最忌讳用SCP传几十GB的大文件。我的习惯是：先把数据和模型压缩上传到对象存储或者平台共享目录，然后在实例里用内网工具下载。这样既快又不消耗公网带宽流量费。

如果只是验证环境能不能跑通，甚至可以用随机生成的假数据。我在项目里经常先用随机张量跑一个最小训练循环，确定GPU计算链路没问题，再用真实数据上任务，这个习惯能帮我快速排除环境问题。

4.3 运行PyTorch验证代码

下面这段代码是我在K80上验证环境的常用脚本，随机初始化一个小卷积网络，跑50步回归训练，观察loss是否下降：

import torch import torch.nn as nn device = torch.device('cuda:0') model = nn.Sequential( nn.Conv2d(3, 16, kernel_size=3, padding=1), nn.ReLU(), nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Linear(16, 10) ).to(device) x = torch.randn(128, 3, 64, 64, device=device) y = torch.randn(128, 10, device=device) loss_fn = nn.MSELoss() optimizer = torch.optim.Adam(model.parameters(), lr=1e-3) model.train() for step in range(50): optimizer.zero_grad() out = model(x) loss = loss_fn(out, y) loss.backward() optimizer.step() if step % 10 == 0: print(step, loss.item())

正常情况下loss会一路下降，比如从0.25降到0.01附近。这说明CUDA计算、显存分配、反向传播全链路都没问题。

在另一个SSH窗口里，用watch -n1 nvidia-smi实时观察显存和核心使用率，你会看到其中一个GPU设备占用率上升，显存占用在1GB左右。如果显存始终是0，说明程序实际没跑到GPU上，这种情况通常是环境变量或设备指定有问题。

4.4 把数据放到GPU显存的注意点

K80并不是一张“大显存合并卡”，所以跑任务时要留意显存边界。单设备只有12GB，实际可用的显存会因为驱动预留、PyTorch缓存机制而减少。碰到CUDA out of memory，优先做三件事：

第一，调小batch size。从64降到32，再不行降到16，这是最直接的办法。

第二，在推理代码里包with torch.no_grad():，避免推理过程占用额外显存。

第三，手动释放不再使用的张量。比如一个中间结果用完就可以del，再配合torch.cuda.empty_cache()清理缓存。

如果单张12GB确实不够，可以用两块卡分工。最省事的写法是DataParallel：

model = nn.DataParallel(model, device_ids=[0, 1])

但要注意，K80的卡间通信走了PCIe总线，并行效率不像新卡那么高。如果任务本身不算太重，我更推荐直接开两个Python进程，一个进程指定CUDA_VISIBLE_DEVICES=0，另一个指定1，各自处理一批数据，效果反而更稳。

5. 性能实测与账单控制：按需省钱才是关键

5.1 一张表看清K80的真实算力

说句实在话，K80跑起来不会有惊喜，它的定位是“稳定且便宜”。我用torch.cuda.Event做过几次简单计时，给大家一个数量级参考：

start = torch.cuda.Event(enable_timing=True) end = torch.cuda.Event(enable_timing=True) model.eval() with torch.no_grad(): start.record() out = model(x) end.record() torch.cuda.synchronize() print(start.elapsed_time(end))

参考数值：

不同驱动、不同CUDA版本下的成绩会有差异，这个表格只表示数量级，不是精确benchmark。如果你准备跑生产级推理，需要先用自己的模型做一次基准测试，再决定要不要继续用K80。

5.2 成本控制三板斧

K80便宜，但如果不控制，账单也会在不知不觉中变大。我总结了三个省钱方法，都是实操验证过的。

第一，按时间段使用。把K80当成“夜间批量计算工具”，白天调代码，晚上提交批量任务，睡觉前挂起实例，第二天起来收结果。相比一直开机，这种方式能省一半以上成本。

第二，善用竞价实例。很多算力平台提供“竞价型”或“抢占型”K80，价格比按量付费再便宜不少。缺点是实例可能被系统回收，适合那些能容忍中断的任务，比如批量推理、数据预处理。

第三，数据不走公网。大数据集和模型权重尽量用对象存储的内网通道传输，避免公网流量费用。一个不小心用SCP传几个GB，流量费可能超过GPU费用。

再看一眼账单里有没有“弹性IP费”和“数据盘容量费”。实例关机后GPU不再收费，但IP和数据盘通常还是按小时或按容量收费，这些隐藏费用才是账单翻车的元凶。

6. 高频问题与排查速查表

6.1 常见故障诊断表

我在云上踩过的坑，基本都集中在连接、驱动、显存这三类。整理成速查表，遇到问题直接对照：

遇到no kernel image这类错误，很多人第一反应是重装最新驱动，我不建议。K80这种老卡，新版驱动和最新CUDA不一定还保留优化，降级到老版本反而更稳。

6.2 几条保命经验

说几个只有实际折腾过才会知道的细节。

第一次拿到实例，先别急着传数据，花两分钟跑一遍nvidia-smi和PyTorch验证脚本，确认GPU链路是通的。很多平台实例虽然显示“运行中”，但驱动或调度出了问题，早发现早联系客服，别等跑了大半天任务才发现白跑。

做任何环境操作前，把系统盘做一次快照或镜像。云平台一般都有这个功能，花几分钟拍个快照，后面就算把系统搞挂了，也能直接回滚。

所有代码、依赖清单、Dockerfile一定要落到Git或对象存储。K80实例在你手里就是一个可以随时丢弃的“算力容器”，环境毁了大不了重建，但代码丢了就真的没了。

最后，记得在控制台设置自动释放时间，或者养成“用完就释放”的习惯。K80这种卡的价值在于按需使用，你不是买了一张永久卡，而是租了它几个小时。省掉闲置时间，比任何性能调优都更省钱。

我自己用K80的方式很明确：把它当成一个便宜的批量计算执行器，脚本全部容器化，数据全部放持久化磁盘，跑完一个任务立刻关掉。只要不指望它跟新卡拼速度，它就能在预算有限的时候帮你把事情做得稳稳当当。