最近帮一个做多模态检索的小团队看训练环境他们原本的计划是买两台八卡整机自己搭。我把他们近三个月的任务日志拉出来一看真正满载的时间加起来不到 240 小时剩下时间机器就在那儿吃灰还得有人盯着机房温度、驱动版本和硬盘寿命。聊了两个小时最后方案改成按需租用 GPU 租赁算力把买机器的预算压到原来的两成剩下的钱全砸在数据标注和评测上。这件事让我觉得有必要把 GPU 租赁这件事从头到尾讲清楚它不是没钱买卡的替代方案而是一套完全不同的成本结构和工程习惯。这篇文章会讲清楚 GPU 租赁适合谁、不适合谁成本临界点怎么算显存怎么估账单为什么会超,以及从开机到释放资源的完整操作流程。做过模型训练、推理部署、渲染农场、教学实训的读者都能对号入座刚接触这一块的新手也能照着抄。1. GPU租赁到底在解决什么问题1.1 三类负载的算力画像完全不同很多人一上来就问租什么卡好这个问题没法回答因为不同负载对硬件的偏好差异极大甚至互相冲突。训练类负载吃的是显存容量、卡间互联带宽和显存带宽。全参数微调一个大模型时显存不够就是跑不起来没有降级方案卡间通信带宽不够多卡并行的加速比会迅速衰减八卡可能只跑出三卡的效率。这类负载还特别怕中断跑到一半节点被回收如果没有断点续训前面几小时的算力费就白花了。推理类负载的画像完全不同。它更在意单卡的性价比、显存够不够塞下 KV Cache、以及网络出入带宽。一个在线服务的响应延迟很大程度上取决于批次大小和上下文长度怎么配而不是单卡峰值算力有多高。很多团队用消费级卡做小模型推理单位成本比训练卡低一大截就是因为这类任务根本用不上高带宽互联。渲染、转码、科学计算这类负载又是另一套逻辑。它们往往对显存要求不算极端但对任务并行度和抢占容忍度高——反正一帧一帧渲染中断了重新排就行。这类任务最适合用价格更低的可中断实例成本能砍掉一半以上。所以说选卡之前先给自己的任务归个类是必须一次跑完、中断就要重来的训练是长期常驻、按请求计费的推理还是可切片、可重排的批处理。这个判断直接决定了你该关注哪些参数也决定了你能不能用低价实例。1.2 自建和租赁的成本临界点我用一个公式算给你看这是我觉得最值得写的一节因为绝大多数团队在决策时都凭感觉而不是算账。自建一台八卡训练整机的成本大致可以拆成四块整机采购含卡、主板、电源、交换一次性投入按三年折旧摊到月机房电费八卡整机满载功耗通常在 6 到 8 千瓦按每度电一元、每天满载 12 小时算一个月电费接近三千元如果全天满载则翻倍网络和存储训练数据的读写对本地 NVMe 和对象存储都有要求最后是人力这部分最容易被忽略驱动升级、故障换卡、系统重装都要人。假设一台八卡整机采购加配套花 120 万三年折旧每月折旧成本约 3.3 万电费按满载 7 千瓦、每天 12 小时、每度一元算约 2500 元机房托管和带宽约 3000 元半个运维人力的分摊算 8000 元。合计每月固定成本约 4.7 万元。租赁侧同档八卡整机的市场时价区间很宽从每小时 80 元到 200 元都有取中位数 120 元算满载 720 小时是 8.64 万元。设月利用率为 U那么自建成本恒定为 4.7 万租赁成本为 8.64 万 × U。令两者相等得 U ≈ 54%。结论很直白月利用率低于 54%租比买便宜高于 54% 且任务形态长期不变自建才划算。这里的利用率指的是卡真的在算的时间占比不是机器开着的时间。我见过太多团队把开机时间当利用率实际 GPU 使用率常年在 5% 以下那种情况自建就是纯亏。注意这个临界点对卡型非常敏感。越是高端、越难买到的卡租赁的相对优势越大越是中低端卡自建的临界点越低。算自己那笔账的时候把所有数字换成你实际询到的价格别用我这组示例值。1.3 市场上的供给形态别只盯着单价同样是租卡形态差别很大用错形态的代价远高于单价差的那点钱。第一种是整机租用一台八卡机器整租给你独占可以自己装驱动、改内核、配 RDMA。适合多机多卡的大规模训练。缺点是起租粒度粗短任务不划算。第二种是按卡租用从共享的机器上切一到几张卡给你价格比整机低但可能受同机其他租户的影响卡间互联不一定能用上。适合单卡能跑完的微调、推理和调试。第三种是容器实例给你一个带 CUDA 环境的容器开箱即用不用管驱动。启动最快适合跑脚本、做评测、做演示这类短平快任务。缺点是自定义能力弱改内核参数、装特定版本驱动的活儿干不了。第四种是可中断实例价格通常是常驻实例的三到五成代价是随时可能被回收通常只给几十秒的预警。适合渲染、批量推理、超参搜索这种丢了自己能捡起来的任务。用它跑没有断点续训的训练就是拿钱打水漂。第五种是托管式服务你提交任务平台帮你排队、调度、重试你只看结果。省心但单位算力价格最高适合偶尔跑一两次、不想折腾环境的团队。我的经验是先按任务形态排除掉不合适的形态再在剩下的里比价格。用可中断实例跑长训练的团队账单往往会因为反复重跑而比常驻实例还贵。2. 选型把租什么卡翻译成三个硬指标2.1 显存是硬门槛其余都是软指标在 GPU 租赁里最常见的决策顺序错误是先看算力TFLOPS再看显存。实际顺序应该反过来显存决定你能跑什么带宽决定你跑多快算力决定你跑多久。显存不够模型直接起不来或者要靠梯度检查点、CPU offload、ZeRO 切分这些手段硬挤代价是速度掉一大截有时候掉到还不如换一张大显存的卡。而算力不够只是慢一点慢可以等起不来就只能换方案。显存的量级可以粗略分成几档我用一句话概括各自的典型用途16 到 24 GB 档小模型微调、7B 级模型量化推理、图像生成、教学实验。40 到 48 GB 档中等规模微调、长上下文推理、多路并发服务。80 GB 档大模型全参数训练和多卡并行的基本单位也是长上下文推理的舒适区。多卡整机参数量再往上就必须靠卡数和互联带宽堆。提示租卡时一定要确认显存是独享还是共享。有些低价方案标称 80 GB实际是同机多租户共享显存池你的可用显存会随邻居波动跑大模型时会在莫名其妙的时刻 OOM。2.2 训练显存估算一个 7B 模型的完整账显存估算这件事方法比公式重要。训练阶段显存大致由四部分组成模型参数、梯度、优化器状态、激活值。前三个是固定开销第四个随批次大小和序列长度线性增长。以混合精度加 Adam 类优化器为例每参数的开销是参数本身 2 字节fp16/bf16梯度 2 字节优化器的一阶和二阶动量各 4 字节fp32fp32 主权重副本 4 字节合计 12 字节。加上激活值工程上常按 16 到 20 字节每参数估算。一个 7B 模型全参数训练7 × 10⁹ × 16 字节 ≈ 112 GB。这意味着一张 80 GB 卡装不下必须多卡切分。这也解释了为什么很多团队第一次尝试全参微调时会发现明明模型只有 14 GB怎么就 OOM 了——14 GB 只是权重剩下 98 GB 全是训练状态。再看 LoRA 或冻结大部分层的微调可训练参数可能只有几十到几百万优化器状态几乎可以忽略显存主要就是权重加激活7B 模型在 24 到 32 GB 显存内就能跑起来批次和序列长度要压一压。这就是为什么 LoRA 这么流行——它把硬件门槛从多卡整机降到了单卡。激活值这部分的估算容易翻车。它大致正比于 层数 × 批次 × 序列长度 × 隐藏维度序列长度从 2K 提到 8K激活值直接四倍。做长上下文微调时先拿小批次跑通再用nvidia-smi观察峰值显存比纸面计算可靠得多。2.3 推理显存估算与 KV Cache 这笔隐形账推理的显存账更隐蔽因为权重只是起点真正吃显存的是 KV Cache。权重的显存占用等于参数量乘以每参数字节数。7B 模型用 fp16 是 14 GB用 int8 量化约 7 GB用 int4 约 3.5 GB。KV Cache 的每 token 占用量可以用这个式子估2K 和 V× 层数 × 隐藏维度 × 每元素字节数。以一个 32 层、隐藏维度 4096 的模型为例fp16 下每 token 约 0.5 MB。这时如果上下文 8192 token、并发 8 路Cache 总量就是 8192 × 8 × 0.5 MB ≈ 32 GB。也就是说一个权重只占 14 GB 的模型在长上下文高并发场景下实际要吃掉 46 GB 显存。这就是为什么很多团队核算推理成本时会算错按权重估显存买卡上线后发现并发一提高就 OOM。现在的模型普遍用分组查询注意力GQAKV 头数远少于查询头数Cache 能压到原来的几分之一估算时要把这个折算系数算进去。实操上我习惯这样定容量先确定目标上下文长度和并发路数算出 KV Cache加上权重和框架开销通常留 2 到 4 GB再向上取整到卡型档位最后留 20% 余量。留余量不是浪费是因为真实流量的长度分布是长尾的偶尔来一个超长请求就能把你打崩。2.4 带宽、存储、网络这些非卡因素这三样东西不影响你能不能跑只影响你跑得多难受但难受起来非常要命。卡间互联单卡任务不用管多卡并行必须确认。租用共享机器时物理上卡在同一台机器但虚拟化层可能没把高速互联透传给你多卡通信走 PCIe 甚至走网络效率掉一半以上。判断方法很简单跑一次多卡 all-reduce 基准测试看带宽是否接近该卡型的理论值。存储训练数据的读取速度经常是真正的瓶颈。我见过数据放在网络存储上、每个 batch 都要拉几秒的情况GPU 使用率看着是 90%实际都在等 IO。稳妥做法是把数据集预先拷贝到实例的本地盘或者用平台提供的高速缓存层。另外要注意本地盘通常是临时的实例释放就没了中间产物必须回传。出入带宽往实例上传几十 GB 的数据集、或者从实例下载模型权重走公网带宽可能比算力费还贵。租之前确认内网是否免费、公网流量怎么计费把大文件走对象存储中转通常比直传便宜。3. 账单为什么总是超预期3.1 关机不等于不收费这是新手最容易踩的坑而且几乎人人踩一次。很多平台区分关机和释放两个动作。关机只是停掉计算实例本身、挂载的云盘、分配的公网地址仍然占用资源仍然计费只是单价低一些。真正停止计费要做的是释放或者销毁实例同时把不再需要的云盘和快照一并删除。更隐蔽的是最小计费粒度。有些方案按秒计费但设了一小时的最小计费单位你跑十分钟也按一小时收有些整机租用是按天起租。这些规则通常写在计费说明的角落里不看就会觉得明明只用了半天怎么收这么贵。我的做法是给自己定一条死规矩任务结束的同一分钟就释放绝不过夜。因为过夜意味着你可能忘了一周后发现账单翻了好几倍。3.2 隐性成本清单把常见的隐性成本列出来对照着自查一遍能省下的往往比砍单价更多成本项触发条件规避方式云盘存储实例释放后云盘未删建立释放即清盘习惯中间产物及时回传公网流量大量上传下载数据集、权重走对象存储中转优先用内网快照与镜像每次调试都存镜像只保留一个基线镜像其余定期清理闲置实例关机但未释放设置自动释放时间或到期提醒反复重跑用可中断实例跑长任务无断点续训的任务不用可中断实例环境重装镜像没做好每次重配把依赖固化进自定义镜像这张表里的每一项我都真实见过造成账单翻倍的案例其中闲置实例和反复重跑是最常见的两个。3.3 一个完整的月度账单复盘拿一个典型小团队举例四人团队主要做 7B 级模型的 LoRA 微调和离线评测偶尔跑一次全参微调。上个月账单 2.1 万元。拆开看常驻的单卡实例 720 小时占 5800 元临时开的八卡整机累计 46 小时占 5500 元可中断实例做批量评测累计 300 小时占 3200 元云盘和快照 2200 元公网流量 1800 元剩下的零碎是镜像存储和几笔忘记释放的实例。优化空间在哪云盘 2200 元是最冤的因为其中大部分是三个月前的旧快照忘记释放的实例 1500 元纯粹是管理问题公网流量走内网能省一半。三项加起来能省 4000 元左右占账单的 19%比跟平台谈折扣容易得多。我把这个复盘写成固定动作每月初拉一次账单明细按实例类型 / 存储 / 流量 / 其他四类归类找出去重和清理的空间。做了三个月之后账单波动就变得可预测了。4. 从零到跑通第一个训练任务4.1 开卡前必须先想清楚的三件事第一件是任务会不会中途被打断。如果会就必须先写断点续训逻辑再去开卡。这个顺序不能反反了就是拿算力费做实验。第二件是数据放在哪。数据集有多大、要不要每次都传、能不能缓存。超过 20 GB 的数据集强烈建议先传到对象存储实例启动后再用内网高速拉取。第三件是跑完怎么收尾。产物回传到哪、实例什么时候释放、镜像要不要留。这三件事在开卡前写成一行清单贴在记事本上比事后补救省事得多。4.2 环境与镜像这一步能省掉后面一半的坑租来的机器第一件事是确认环境别急着跑代码。nvidia-smi # 看卡型、显存、驱动版本、当前占用 nvcc --version # 看 CUDA 编译器版本 python -c import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())这三条命令能定位八成的环境问题。重点看两个匹配关系驱动版本支持的 CUDA 上限以及 PyTorch 编译时的 CUDA 版本是否与之兼容。经常出现的情况是驱动太旧装最新版 PyTorch 后cuda.is_available()返回 False或者反过来驱动很新但框架版本太老跑不起来。我的做法是把调通的环境固化成自定义镜像。第一次花半小时装依赖、配环境变量、装常用工具存成镜像之后每次开实例都用这个镜像启动到能跑代码不超过两分钟。这一步的投入产出比极高尤其是团队多人协作时能避免在我机器上是好的这种经典问题。依赖锁定也要做pip freeze requirements.txt是基本操作。我吃过一次亏某个库的小版本更新后改了默认行为同一个脚本在两周后重跑结果对不上排查了一整天才发现是版本漂移。4.3 代码和数据怎么上去代码建议走版本管理实例里直接克隆不要用 FTP 或手工上传否则改一版传一版很快就分不清哪个是最新的。数据量大时用rsync断点续传它支持增量同步中断后重连只传差异部分rsync -avzP --exclude*.tmp ./dataset/ userhost:/data/dataset/-P这个参数同时开启进度显示和断点续传大文件传输必备。如果平台提供对象存储的内网端点优先用平台自带的命令行工具速度通常比走公网快好几倍而且不计流量费。数据落盘之后先做一次完整性校验算一下文件数量和总大小或者对关键文件做哈希比对。我遇到过一次传输中断导致最后一个分片损坏训练跑到第 3 个 epoch 才报错前面几小时全废。4.4 启动、监控、断点续训训练脚本绝对不能在 SSH 会话里直接前台跑连接一断任务就没了。用tmux或者nohup挂后台tmux new -s train python train.py --config configs/lora.yaml 21 | tee logs/train_$(date %m%d_%H%M).logtee这一步别省日志既输出到屏幕又落盘出问题时有据可查。tmux的好处是断线重连后还能看到现场比nohup更友好。监控要盯三个数GPU 使用率、显存峰值、吞吐每秒处理的样本数或 token 数。GPU 使用率长期低于 70%说明瓶颈在数据加载或 CPU 预处理显存峰值逼近上限就要提前减小批次别等 OOM吞吐突然掉一半通常是遇到了长样本或者存储抖动。断点续训的实现方式很朴素每隔 N 步存一次 checkpoint启动时检查目录里有没有可恢复的文件。要存的不只是模型权重还包括优化器状态、学习率调度器的进度、当前的步数和 epoch。只存权重会导致恢复后学习率从头开始训练曲线出现明显抖动。ckpt { model: model.state_dict(), optimizer: optimizer.state_dict(), scheduler: scheduler.state_dict(), step: global_step, epoch: epoch, } torch.save(ckpt, fckpt/step_{global_step}.pt)存 checkpoint 的频率要权衡太频繁拖慢训练且占存储太少丢的进度多。经验值是每 500 到 1000 步存一次同时只保留最近三个自动删旧的避免把云盘塞满——云盘塞满也是要额外花钱的。4.5 收尾动作清单任务跑完到释放实例之间有一串动作要做漏一步就可能丢产物或者多花钱把模型权重、日志、评测结果回传到对象存储或本地回传后核对文件大小。把这次用的环境和关键配置记下来写进项目笔记下次直接复用。停止所有后台进程确认没有残留任务在跑。卸载并删除不再需要的云盘删除临时快照。释放实例确认控制台状态变成已释放而不是已关机。这五步我做成了一张纸质清单贴在显示器边上刚开始靠它后来成了肌肉记忆。5. 踩坑实录常见问题与排查速查表5.1 环境与驱动类问题这类问题的特征是代码没动过昨天能跑今天不能跑八成是环境差异。最常见的是 CUDA 版本不匹配。报错信息通常是CUDA driver version is insufficient for CUDA runtime version意思是运行时要求的 CUDA 版本高于驱动支持的版本。解决办法有两条升级驱动或者装一个与该驱动匹配的框架版本。租用场景下驱动往往不能随便升级所以通常是降框架版本。第二常见的是多卡训练起不来报 NCCL 相关的错误。先确认可见的卡数CUDA_VISIBLE_DEVICES环境变量再确认卡间通信是否可用。共享机器上这个错误出现频率明显更高因为虚拟化层可能没透传互联能力。第三是磁盘写满导致的各种诡异报错训练脚本在存 checkpoint 时失败有时报的是 IO 错误有时直接进程被杀。开跑前df -h看一眼余量成本极低。5.2 性能类问题卡在跑但吞吐上不去现象可能原因排查动作GPU 使用率低但显存占用高数据加载瓶颈提高 dataloader 工作进程数检查存储读取速度多卡加速比远低于卡数互联带宽不足或通信比例过高跑 all-reduce 基准调大每卡批次减少通信频次吞吐随训练进行逐渐下降内存泄漏或显存碎片观察显存曲线检查是否有张量持续累积首个 batch 极慢之后正常编译和缓存预热属正常现象不要误判为故障相同配置不同实例速度差很多邻居干扰或降频换实例重试看是否可复现这张表里最值得说的是邻居干扰。共享机器上同机其他租户跑满负载时你的卡可能因为功耗墙或散热被降频速度掉 20% 到 30% 都有可能。判断方法是同一份代码在同一卡型的两个不同实例上各跑一次基准差距超过 10% 就要怀疑是环境问题。对性能敏感的长期任务宁可多花点钱用整机独占。5.3 数据与账务类问题数据方面的坑主要是两个。一是权限从别处拷来的数据集文件属主不对训练脚本读不了报的却是文件不存在容易误判。二是软链接打包上传时软链接断掉文件变成空壳训练跑起来才发现样本是空的。账务方面的坑前面说过这里补两个具体的一是忘记关掉的调试实例我建议给所有临时实例设一个自动释放时间比如 12 小时到点强制释放宁可被打断也不要被忘记二是镜像越存越多每次调试都存一个镜像半年后存储费能占到账单的两成。我的规则是只保留一个基线镜像加一个当前开发镜像其余全删。还有一条容易被忽略的跨区域传输费用。数据集存在 A 区实例开在 B 区拉数据走公网流量费可能比算力费还高。开实例前确认区域一致这个动作花十秒能省几百块。6. 应用场景哪些事真的适合租着干6.1 模型微调与实验迭代这是 GPU 租赁最典型的场景。微调任务的形态是短时高强度——跑几个小时到几天然后停下来看结果、改配置、再跑。这种形态和自建的高固定成本天然不匹配和租赁的按需付费完美契合。更关键的是实验的并行性。调超参时你可能要同时跑五组配置自建的话要么排队要么买五台机器租赁的话开五个实例跑完就释放成本是线性的而且随时能扩到二十组。这种弹性在自建模式下根本做不到。实操建议把实验配置全部外置成配置文件每组一个文件用脚本批量提交。日志和指标统一落到对象存储最后拉下来做对比。这样一次能跑十组一天迭代三轮比手工一组一组跑快一个数量级。6.2 推理服务的灰度与压测线上推理服务不适合长期跑在租赁的按需实例上成本不可控但非常适合用来做压测和容量验证。典型做法是在真实流量到来之前租几台目标卡型的实例用压测工具模拟目标并发测出单卡能扛多少路、P99 延迟是多少、显存余量有多大。测完之后按这个数据反推需要多少张卡再决定是自建还是包年租用。这个验证过程只花几天却能避免上线后因为容量不足导致的连环故障也能避免过度采购。压测时要注意几个点用真实的输入长度分布不要全用等长样本逐步加压而不是一步到位观察拐点在哪记录显存峰值而不是平均值峰值决定你会不会崩。6.3 渲染、转码与批量离线任务这类任务的特点是可切片、可重排、可容忍中断正好是可中断实例的完美用户。一部几分钟的三维动画渲染拆成几百帧每帧独立渲染某台机器被回收了就把那几帧重新排进队列。用可中断实例的成本可能只有常驻实例的三到五成而且任务队列会自动填满所有空闲算力不存在买了机器却闲置的问题。批量离线推理也是同理。给几百万条数据打分、做 embedding、做内容审核这类任务没有实时性要求完全可以让它在低价的时段、低价的实例上慢慢跑。我见过一个团队把一批离线任务从常驻实例迁到可中断实例同样的工作量成本降了六成。6.4 教学实训与短期项目教学场景的需求很特殊一年里可能只有几周需要大量算力其余时间完全没有。自建的话机器在剩下四十多周里就是纯成本还要人维护。租赁模式下课程期间开一批实例配好统一镜像学生每人一个环境课程结束全部释放。环境一致性也解决了——所有人用同一个镜像不会出现我的环境跑不了的问题。同理比赛、短期项目、科研复现实验都适合这种临时大批量、用完即释放的模式。6.5 结论不急着下先说边界说句实在话GPU 租赁不是万能的。如果你的任务长期高负载、对延迟极其敏感、或者数据出于安全考虑不能出本地那自建或者专有环境仍然是更合适的选择。租用最大的价值在于把固定成本变成可变成本它适合的是波动型、实验型、短周期型的算力需求。判断标准就一条你的算力需求曲线是平的还是抖的。平的往上走就自建抖的、有峰的、说不准什么时候要的就租。7. 我个人的选型决策清单踩过的坑多了之后我总结了一张开卡前必看的清单五条每条都能对应到一次真实的教训第一条先算利用率再谈价格。别一上来比每小时的单价先估自己一个月真正满载多少小时套那个临界点公式算一下再决定租还是买。单价低但你要闲置就是贵。第二条显存按峰值估不按均值估。权重、KV Cache、框架开销、长尾请求四样加起来再留两成余量。按均值估出来的配置上线必崩。第三条没有断点续训就不用可中断实例。这条是硬规矩违反它的团队最后都付出了更高的代价。第四条环境必须固化成镜像。这是唯一一项花半小时省几十小时的投入越早做越好团队协作时更是刚需。第五条释放动作写进流程。关机不等于不收费任务结束到释放之间的每一个小时都是纯支出。设自动释放时间做月度账单复盘把这张表当体检报告看。这五条之外我个人在实际操作中最深的一个体会是租用算力之后工程习惯的重要性会突然放大。自建的时候机器是你的浪费一点没人心疼租用之后每一小时都在计费你会开始认真对待数据加载效率、checkpoint 频率、日志可读性这些以前觉得不重要的细节。这种压力其实是好事它逼着团队把训练流程工程化而这套能力最终是带得走的跟机器是谁的没关系。后来那个把自建改成租用的团队训练脚本的可复现性和实验管理水平比之前强了一大截这大概是省钱之外的另一个收获。