干这行久了你会发现很多需要大算力的场景都逃不过同一个循环租卡、做自定义镜像、用镜像把实例拉起来干活。这套流程我第一次跑的时候也卡了很久尤其是镜像上传和版本不匹配的问题反复折腾了好几轮。所以今天想把租卡、自定义镜像及其使用的相关流程从头到尾拆开聊一遍。这篇文章适合刚接触云上 GPU 的人也适合那些已经租过几次卡、但每次都在重复装环境的人。我会把选型思路、镜像制作、上传启动、问题排查这几块全部讲透所有操作都是实际验证过、可以直接照着做的不需要你有太深的运维基础。1. 先别急着下单说说租卡前怎么定需求1.1 先搞清楚自己到底需要多大显存我见过太多人第一步就走偏一上来直接租最贵的卡跑完发现显存只用了三分之一也有人租了中等显存卡结果模型权重刚加载完就把显存撑爆了。显存估算这件事其实不复杂但很多人懒得算最后要么浪费钱要么干不了活。先说推理场景。模型加载到显存主要是权重文件占了绝大部分空间。现在主流开源模型很多是 7B 这个量级如果用半精度表示权重每个参数大约占 2 字节7B 参数就是 14GB 左右。但权重加载完之后还有中间计算产生的前向激活值以及对话场景下的上下文缓存这一块会随着输入长度增长。粗略估算下来7B 模型做单机推理24GB 显存是进门线想跑长上下文或者开大 batch就要考虑 40GB 甚至更高。如果是几十 B 参数的大模型那基本就是 80GB 级别的单卡或者多卡并行。训练场景更吃显存。除了权重优化器还要额外保存状态常见的优化算法对每个参数要保存一阶动量和二阶动量这部分经常是参数量的好几倍。一个 7B 模型的全参数微调哪怕用了混合精度单卡几乎不可能完成一般要分布式多卡。如果你用微调这类相对轻量的方案情况会好很多因为只训练新增的少量参数显存需求可以降到单卡可以承受的范围。所以我的建议很直接先搞清楚你要做的到底是推理、全参数训练还是参数高效微调再决定租什么卡而不是按价格倒着选。1.2 计费方式和时长策略别被账单吓到云 GPU 平台的计费看起来大同小异无非是按小时、按天、包月这几类。但真正影响账单的往往是一些细节。按小时计费适合调试和临时任务。我一开始做环境验证时就喜欢先按小时起一台便宜的机器把镜像和脚本都跑通了再决定要不要换更大的机器长租。包日和包月则适合持续训练任务算下来单价通常比按小时便宜但缺点是不灵活如果中途任务提前结束剩余时长也很难退掉。这里有个非常关键的坑很多平台把关机和释放实例分得很清楚。关机只是停止计算磁盘还在系统盘和挂载的数据盘仍然占用存储空间费用照收。释放实例才是把机器彻底删掉。所以如果你只是临时不跑任务记得看平台的费用结构别让一堆关机状态下的实例白白扣钱。另外不是所有平台都支持在关机状态下保留自定义镜像的修改。有些平台你改了系统盘内容关机不释放下次开机还在有些平台一旦释放系统盘写入的内容全部丢失只有你正式保存为镜像的那部分才能复用。所以我的习惯是重要环境一定先做镜像重要数据一定放数据盘或外部存储绝不指望系统盘在实例释放后还替你保留东西。1.3 公共镜像、自定义镜像、实例快照三条起步路线怎么选第一次租卡的人打开创建实例页面通常会看到几个公共镜像很多是平台预置的开发环境预装了浏览器界面和一堆基础工具。这种镜像的好处是省事起完就能进图形界面操作坏处是版本和依赖不一定符合你的需求通常还要自己再装一串东西。所以更省心的做法是建立自己的自定义镜像。你可以把一套完整环境——操作系统基础配置、GPU 驱动、并行计算库、深度学习框架、常用工具——全部打包进镜像。之后每次租卡直接选这个镜像起起来的实例就是一台已经配置好的机器省掉了每次重装环境的重复劳动。对于团队协作这种镜像的价值更大大家用同一个镜像复现环境时不再有我这边跑得通你那跑不通的扯皮。还有一条路线是用实例快照。有些平台允许把当前正在运行的实例直接保存为镜像这适合你已经在一台机器上手动把环境调通了、想把这台机器的状态整体带走的情况。快照做镜像的特点是状态还原度很高但镜像体积通常也大而且里面可能会带着当前实例的运行日志、临时文件等杂物。我自己的经验是需要快速复现时用快照需要长期复用或团队分发时还是专门做干净的自定义镜像。三条路线的对比可以看下面这张表方式制作成本镜像体积复用性适合场景公共镜像零成本小一般临时尝鲜、快速起一台机器自定义镜像中等可控高长期复用、团队统一环境实例快照低通常较大中想把当前机器状态整体带走2. 自定义镜像到底是什么怎么做得又好又小2.1 镜像的分层结构用装机备份来理解很多人第一次接触镜像时容易把它当成一个黑盒子其实理解它并不难。你可以把镜像想象成一台电脑的完整装机备份里面有操作系统、有驱动程序、有各种软件你拿到这个备份就可以在任何一台同样规格的机器上快速还原出一个能直接用的系统。在云 GPU 场景里镜像一般分成几层来看。底层是操作系统层常见的是各种 Linux 发行版这一层决定了基础命令和包管理方式。往上是 GPU 驱动层负责让系统识别显卡、提供底层计算接口驱动不对上层框架再新也白搭。再往上是并行计算库这一层很多深度学习框架都依赖这套底层库来做 GPU 加速。最上层才是你自己的应用环境比如 Python 版本、深度学习框架、各种依赖包、代码和配置。公共镜像通常只覆盖了下面两层甚至有些平台连驱动层都是按机型动态加载的。你要做的就是把自己的运行环境和应用层加进去。理解了这个分层结构你就能明白为什么不要往镜像里堆乱七八糟的东西每一层变大都会拖慢镜像上传和实例启动的速度。而且镜像体积太大平台侧的资源占用也高没人是来给你白存文件的。2.2 制作镜像的两种路线我更推荐哪一种制作自定义镜像市面上主流做法有两条路线。第一条路线是先用公共镜像起一台临时实例登录进去手动安装你要的依赖配置环境变量调试到项目能正常跑起来然后通过平台的保存为镜像功能把当前系统盘打包成自定义镜像。这条路线最直观适合第一次做镜像的人也适合那种只需要一次落地、不打算反复重建的环境。缺点是如果你中间手误装了不该装的东西或者系统里留下大量缓存文件镜像就会又大又脏。第二条路线是脚本化构建你提前写一个环境安装脚本把统一系统更新、安装指定版本的运行库、安装深度学习框架、清理临时文件这些步骤全部固化在脚本里。每次需要做镜像时起一台临时实例执行脚本等它跑完再保存为镜像。这比手动一条条敲命令靠谱得多。因为你今天手动敲的命令明天不一定记得全换个人来操作更不可能一模一样脚本放在仓库里所有人都能看到环境是怎么构建出来的出了问题也能通过改动脚本再重新构建一遍。我自己在机器上常用的制作流程大致是这样先起一台临时实例上传写好的脚本执行脚本然后做一次清理动作删除包管理器和 Python 缓存、清空临时目录最后再保存镜像。这样做出来的镜像体积能控制在合理范围内。你可以把脚本里的关键步骤想象成下面这个样子# 登录到临时实例后执行 bash prepare_env.sh # 清理各种缓存保持在较小体积 pip cache purge rm -rf /tmp/*实际脚本里当然还会有版本锁定、配置写入等步骤但核心思路就是把环境构建从手工操作变成可重复执行的过程。这是我在反复重装环境之后最大的体会。2.3 版本搭配是最大的隐形坑镜像做得出来只是第一步做出来能不能用才是关键。我见过太多人栽在版本搭配上镜像里装的框架和底层计算库版本对不上实例一启动就报错完全跑不起来。这里要特别提醒GPU 驱动、并行计算库、深度学习框架、Python 版本四者之间存在明确的对应关系。驱动支持什么样的计算库版本计算库支持什么样的框架版本框架又要求什么 Python 版本这是一条完整的链条。你单独看每个软件的最新版本都很正常但把最新版本强行拼在一起经常会出现接口对不上的情况。较稳妥的做法是以一个你实际验证过的组合为准所有组件都锁定到指定版本不要随手装最新版。起好实例之后第一时间检查 GPU 是否被正确识别、框架能否正常调用加速计算。检查命令也很简单比如执行nvidia-smi看显存和驱动信息是否正常再写一段很小的矩阵运算代码跑一下确认计算设备可以被驱动。如果这两关过了镜像里的环境才有基本可信度。做好的这套组合建议直接写进镜像的标签或描述里免得过了几周连自己都忘了镜像里到底是什么版本。3. 把镜像上传到平台再用它创建实例的完整实操流程3.1 做镜像之前先确认平台侧的几个准备项镜像做得再好上传和创建实例时也会遇到一些平台相关的细节提前准备好能省很多事。第一步是账号和权限准备。大多数云 GPU 平台都要求你先完成实名认证然后在控制台里开启密钥管理或者镜像管理权限。这里说的密钥主要是 SSH 密钥用来之后登录实例。提前生成一对密钥把公钥配置到平台里创建实例时就能直接注入免去密码登录的麻烦。我的习惯是每台实例都用独立密钥或至少按项目分组管理方便出问题时定位和回收。第二步是确认镜像仓库和命名空间。在平台的镜像管理界面里一般会有命名空间或者仓库的概念有点类似给镜像文件分门别类的文件夹。你需要提前创建好并给镜像起一个清晰的名字。比如要做目标检测训练环境可以取类似detect-train:v2.3这样的名字带上用途和版本号。最忌讳的就是起最终版新镜像1测试这种名字过两周你自己都分不清哪个是哪个。版本号建议遵循简单递增规则比如 v1.0、v1.1每次有改动就升一个小版本这样回溯问题的时候有个参照。3.2 打包、校验、上传三步走上传镜像之前先把本地镜像文件整理好。如果你是在本地用容器方式做好的镜像可以先用容器命令把镜像导出成文件如果你是在平台临时实例上做好的就直接用平台的保存功能。不管哪种方式最后你都会得到一个镜像文件。我通常会先做一次文件校验生成校验值和镜像文件一起保存。这一步看着多余但在网络环境不那么顺畅的时候非常有用——文件传上去之后可以再校验一次确保平台收到的文件和自己手里的完全一致避免上传损坏导致实例启动失败。上传方式一般有两种。一种是在平台控制台直接上传本地镜像文件适合文件较小、操作频率低的场景。另一种是通过平台提供的命令行工具在本地推送镜像适合批量操作和自动化发布。上传大文件时我建议留意平台的断点续传支持如果网络中断不需要从头再来。上传完成后回到控制台的镜像列表里确认状态只有显示状态正常、可用的镜像才能用来创建实例。整个过程可以总结为导出镜像、生成校验值、上传、二次校验、确认状态。3.3 用自定义镜像创建实例关键选项怎么填镜像确认无误后就可以进入创建实例的步骤了。以我常用的流程为例大致是这样的先在控制台选择创建实例在镜像来源里选自定义镜像然后从下拉列表里选中你要用的镜像版本。接着选择机型和数量这里要回到前面说的显存估算按任务需求选而不是按预算上限硬上。接下来是数据盘配置。我的建议非常简单系统盘只用来放系统和软件所有数据放数据盘并且把数据盘挂载到一个固定目录。这样做的好处是即使实例被释放只要数据盘或外部存储还在数据就还在。创建时如果平台允许设置数据盘挂载点记得填你要的目录比如/workspace。同时确认数据盘的计费方式有些平台的数据盘即使实例关机也继续计费你要心里有数。然后是 SSH 密钥和登录方式。前面准备好的公钥在这一步选上实例创建后你就可以用私钥免密登录。最后选计费方式确认当前是按小时、包日还是包月再点创建。创建过程中如果你怀疑自己选错了镜像或配置也有些平台允许在实例创建成功但尚未初始化完成前取消可以灵活使用。3.4 实例启动后的标准检查清单实例从创建到可以正常干活中间通常有几分钟初始化时间。我不建议一看到状态变成运行中就直接开始跑任务先花两分钟做一次检查能避免后面一连串的报错。下面是我每次新实例起来后都会过一遍的清单。检查项操作方法预期结果GPU 是否被识别执行nvidia-smi能列出显卡型号和显存容量深度学习框架是否可用运行一个简单的矩阵运算确认计算设备代码能够调用 GPU 加速数据盘是否挂载执行df -h查看挂载点数据盘出现在预设目录下镜像版本是否符合预期查看环境变量或镜像说明文档版本号与记录一致基础网络连通性执行ping命令访问一个公共地址网络请求能正常返回这里面最容易出错的是挂载路径。我之前有次创建实例时忘记指定挂载点结果数据盘变成了另一个目录代码怎么都找不到文件。后来我把挂载路径固化在镜像的环境变量里并在启动脚本中做了一次自动检查问题才算根治。你也可以参照这个思路把启动检查做进脚本里省得每次手动敲命令。4. 租卡使用中最容易踩的坑问题排查与解决4.1 镜像太大上传时反复失败怎么办这是新手最常遇到的情况。镜像动不动十几个 GB传到一半断掉或者平台提示文件超过大小限制非常让人崩溃。先说原因镜像大通常是因为系统里有大量缓存、旧日志、无用依赖或者你把训练数据和代码也打包进去了。我见过有人把几十 GB 的数据集直接放在系统盘里做成镜像上传了几个小时。排查方向就是做减法把代码库和数据放到独立数据盘或外部存储不要在镜像里塞清理包管理器缓存和 Python 缓存删除系统临时文件如果镜像里确实需要某些大文件考虑在实例启动后的初始化脚本里从外部存储拉取而不是打进镜像。解决方法分两种。一种是把镜像体积降下来重新导出一份压缩包上传。另一种是借助平台支持的分片上传或者命令行推送减少中断造成的重传成本。上传完成后一定要记得做校验不要只看文件到了 100% 就认为成功。4.2 实例创建成功了GPU 却用不了这个坑非常经典实例启动成功系统能登录但一跑深度学习相关的代码就提示找不到计算设备或者nvidia-smi执行报错。原因往往出在驱动层不匹配。镜像里固化的驱动版本和当前租到的机型不兼容驱动没有正确加载上层框架自然用不了 GPU。有些平台会按机型动态加载匹配的驱动但你在做自定义镜像时如果覆盖了驱动相关配置就容易破坏这种动态加载机制。排查思路是先看驱动是否加载成功再检查并行计算库和框架的依赖是否齐全最后用一段最简单的矩阵运算代码验证能实际调用加速设备。如果确认是镜像驱动和机型不匹配优先换一个和新机型匹配的基础镜像重新做环境而不是在原镜像上反复修补。我在实践中发现花在修补环境上的时间往往比重新构建镜像的时间还要长。4.3 实例重启后文件不见了数据去哪了这个场景我遇到不止一次跑了一晚上的训练代码还在模型输出和数据集却凭空消失。归根结底是没搞清楚系统盘和数据盘的定位。很多平台在释放实例时会默认删除系统盘上的所有内容因为系统盘通常是临时性的。你通过 SSH 写进系统盘的文件比如/root下的文件都会随实例一起消失。避免这个问题的方法很明确所有数据、代码、模型输出一律放数据盘或外部存储。数据盘在实例释放时可以手动勾选是否保留或者直接挂载公用的共享存储盘这样换一台实例还能读到同一份数据。如果把重要文件放在系统盘里就等于默认接受了实例没了数据就没了的风险。4.4 SSH 连不上十有八九是这几个原因SSH 连接不上是最让人抓狂的问题因为报错信息往往不够具体。常见原因有几个实例还没初始化完成系统里 SSH 服务没起来你用的私钥和平台记录的公钥不匹配本地网络访问不了实例的地址或者连接信息里面填错了地址和端口。排查的时候我习惯按顺序来。先到平台控制台看实例状态和运行日志确认系统已经正常启动。然后用控制台提供的网页终端登录网页终端能通说明系统本身没问题问题大概率出在密钥或本地网络。接着检查你本地用的私钥文件路径和权限很多时候是复制密钥时多了一个换行或者空格。如果网页终端也登录不进去再看实例的初始化日志驱动加载失败、磁盘挂载失败之类的问题都会在日志里留下线索。这里的关键是不要把时间浪费在反复尝试同样的命令上换一个登录途径往往能快速二分定位问题。5. 反复租卡后我总结出的几条实用经验5.1 把环境做成可重复构建的脚本而不是一次性操作我最初做镜像时也是靠手动敲命令确实能用但没有可复制性。后面有一次镜像误删我只能凭记忆重建结果漏掉了一个依赖版本程序跑出完全不同的结果。从那以后我把所有环境构建步骤都写成了安装脚本和维护文档放在独立的仓库里。现在我的做法是环境里所有组件都要有明确版本号脚本执行之后自动打印一份环境信息清单包括驱动版本、计算库版本、框架版本、Python 版本。这样镜像即使出了问题我也可以从脚本重新构建出一个几乎一致的环境而不是靠微调去碰运气。这条经验对团队协作尤其重要你要让每个成员都能从零构建出相同环境而不是依赖某个人手里的镜像文件。5.2 镜像做小做精比什么都重要镜像体积这件事值得多说几句。一个精简的镜像带来的好处是连锁的上传更快、创建实例更快、出问题后排查范围更小。我给自己定过一条规则基础环境部分尽可能保持干净不装浏览器、不装无关图形界面、不保留任何大型缓存。用不到的依赖也尽量不要装因为依赖之间可能互相打架最后排查起来很头疼。另外我还会在镜像里放一个环境检查脚本实例起来后自动运行把关键信息打印到日志里。这样新实例是不是正常一眼就能看出来而不是登录进去再慢慢摸索。这个习惯帮我在很多次快速排障中省了大把时间。5.3 成本控制的核心是及时释放和避免浪费租卡成本说高也高说低也低关键看你怎么用。我发现不少人申请了一台大显存实例调试一下午真正用满 GPU 的时间不到一半账单照样按小时计费。要避免这种浪费有几个小习惯开发调试阶段用最小可用的卡型把代码逻辑跑通正式训练才换大卡不跑任务时及时释放实例而不是只关机释放之前确认数据已经备份到数据盘或外部存储。还有一个容易被忽视的点同时开着多台闲置实例。你可能会为了图省事把几个实例都放着不释放等到月底一看账单才后悔。我在控制台上会定期检查实例列表凡是处于空闲状态的机器都会问自己一句这台还留着有什么用没有明确用途就直接释放。5.4 数据分层放永远不要只存在实例本地最后一条经验也是我付出过代价才学会的代码放代码仓库原始数据放外部存储中间产物放数据盘只有正在处理的临时文件才放实例本地。这样做看起来多了一步数据同步操作但能带来很大的自由度。我今天在这台机器上跑一半明天换一台更大显存的机器数据还在那里直接挂载继续跑就行。如果不做分层数据全部堆在实例的系统盘里那每次释放实例都是一场赌博我不知道下一次还能不能找回之前的产出。现在我已经把所有训练任务的输出路径统一到一个固定目录并同步到外部存储即便实例意外释放损失也控制在很小的范围内。这套租卡和镜像的组合拳我也不敢说已经用得完美但至少从一个频繁重装环境的人变成了能在几分钟内起一台合手环境的人。你如果也被重复配置环境折磨过不妨从做一个自己的镜像开始慢慢把整个流程固化下来后面会发现云上干活原来可以这么利索。