1. 算清楚每小时有效成本，再谈租还是买

先说一个我见过好几次的场景：某个团队为了一个季度的模型微调任务，走完审批流程买了整机，机器上架、装驱动、调环境花了两周。结果任务比预期顺利，三周就跑完了，剩下八个多月机器基本在机房里吃灰，偶尔被拉去跑个数据清洗。另一拨人做法完全相反，任务开始当天开通实例，跑完当天释放，账单清清楚楚。这两拨人的差别不在预算多少，也不在技术水平，而在“算力和时间到底怎么对齐”这件事上有没有想明白。GPU租赁服务说到底就是把“买算力”变成“租算力”，把一笔固定资产投入换成一笔可变成本，但这一步转换到底是省钱还是多花钱，取决于一个很多人懒得算的指标：每小时的有效成本。

1.1 自建整机的成本不只是那张卡的价格

大多数人算自建成本，只算整机采购价除以折旧年限，得出一个“每月多少”的数字，然后就拿去和租赁报价比。这个算法漏掉的项非常多。一台整机的全生命周期成本，至少包含这么几块：硬件采购（卡、主板、内存、盘、电源、机箱）、机房空间或托管费用、电费、网络带宽、备件与维保、装机和环境调试的人工、故障停机损失，以及三年后这台机器还剩多少残值。其中电费这一项，很多人凭感觉估，实际差距很大。一张功耗三百多瓦的卡，八卡整机加上CPU、内存、风扇，整机功耗轻松到四千瓦以上，按每天二十四小时跑、每度电八角算，一个月电费就在两千多块；如果是功耗更高的训练卡，整机八千瓦，一个月电费接近五千块，这还没算机房的制冷成本，而托管报价里通常会把制冷摊进机柜费。

下面这张表是我自己做测算时用的一个简化框架，数字是示例，实际要换成你所在地的电价和托管报价。

把这些月成本除以每月的卡时总量，八卡跑满一个月是 8×730 等于 5840 卡时，中端整机满负荷约 2.4 元/卡时，高端整机满负荷约 10 元/卡时。看到这个数字，很多人会得出“自建真便宜”的结论。问题在于，这个数字的前提是跑满。

1.2 利用率才是那个决定性的分母

真实的团队里，GPU 不可能二十四小时满负荷。数据清洗阶段用不上卡，标注和评审阶段用不上卡，周末和夜间大概率闲着，项目之间的空档期更是常态。行业里一个比较普遍的经验值是，中小团队的自建 GPU 平均利用率在 30% 到 50% 之间，能做到 70% 以上持续跑满的，通常是专门做训练平台的团队。

用刚才的高端整机举例，月成本 5.92 万固定不变，利用率 50% 时有效卡时是 2920，折合 20 元/卡时；利用率 30% 时折合 33 元/卡时。而同期市场上同档卡的按量租赁报价，行情波动大，但大致在十几到二十几元/卡时的区间，包月长租还能再往下压。也就是说，利用率一旦掉到一半以下，自建的成本优势基本就没了，掉到三成以下就是明显的亏。

反过来推，可以得出一个大致的临界判断：如果你的团队能保证同一批卡在一年里持续跑满六到七成以上的时间，周期稳定在两年以上，自建在账面上更划算；如果利用率在四成上下浮动，或者项目周期本身就不确定，租赁的综合成本更低，而且省掉了迭代贬值的风险——三年后那批卡在二手市场上的价格，往往比线性折旧算出来的残值低得多。

1.3 时间成本和机会成本也要折算进去

有一项经常被完全忽略的成本是时间。自建从立项到能跑训练，中间要经过审批、采购、到货、上架、装驱动、调环境、跑通第一个 demo，顺利的话三到六周，卡型紧俏的时候更久。租赁把这个周期压到十几分钟。如果你的项目有明确的时间窗口，比如某个比赛截止日、某次投放节点、某个汇报时间，这几周的时间成本折算成人力，往往比省下的那点租金高得多。我在做技术方案评审的时候有个习惯，凡是“算力需求在半年内可能翻倍或者腰斩”的项目，一律建议先租，原因很简单：买错了改不了，租错了第二天就能换卡型。

2. 租赁真正卖的是弹性，不是单价便宜

把租赁理解成“便宜一点的算力”，是很多人用错这类服务的起点。它的核心价值在于让算力规格随任务阶段变化，而自建只能被迫用最贵的那一档卡去跑所有阶段。这个差异在实际项目里非常明显。

2.1 一个项目的算力需求本来就是脉冲式的

拿一个典型的模型微调项目拆开看，它大致分四个阶段。第一个阶段是数据准备，清洗、去重、格式转换、质量打分，这部分主要吃 CPU 和内存，GPU 参与很少，用一张小卡做抽样验证就够了。第二个阶段是试跑，用小批量数据验证流程、调超参、确认显存能不能撑住，这时候需要目标卡型，但只跑几十分钟。第三个阶段是全量训练，多卡并行，持续几天到几周，这是唯一真正需要大算力的阶段。第四个阶段是评测和对比，单卡或者双卡就够，但要反复跑很多轮。

如果自建，你买的八卡整机在第一个阶段闲着，第四个阶段只用两张卡，只有第三个阶段是满负荷的。如果租赁，你可以第一阶段开一台便宜的 CPU 型实例加一张小卡，第二阶段临时开一张目标卡试跑两小时，第三阶段开八卡训练集群，第四阶段缩到单卡。同样一个项目，租赁方案的有效算力成本可能只有自建的三分之一，差别不在单价，在没有为不需要的算力付费。

2.2 三类团队的适配判断

我把接触过的团队大致分成三类，适配策略不太一样。

第二类是最好好设计的。常驻部分按业务低谷期的基线负载买，比如四张卡跑常驻推理服务，遇到活动峰值或者大任务，临时从外部开卡扩到十六张，跑完释放。这种“基线自建 + 峰值租赁”的组合，比纯自建省掉大量闲置成本，又比纯租赁的单价低。我见过一个做内容生成的团队就是这么干的，日常四张卡托底，每逢版本发布前一周临时扩到十二张做批量生成，账单曲线非常好看。

2.3 有些场景确实不该租

也要说反面。如果你的数据体量在几十 TB 级别，每次任务都要把数据搬到外部环境，搬运时间和流量费用会吃掉所有弹性带来的收益；如果你的任务对延迟极度敏感，需要和本地设备强绑定，网络往返会成为瓶颈；如果你的团队已经有一批卡并且长期跑在高利用率上，那外部租赁只是补充，不是替代。判断标准很简单：把数据搬运成本和时间成本加进去之后，租赁还有优势吗。这个账一定要算，不能只看卡时单价。

3. 挑卡别只盯着算力数字

新手挑卡最常犯的错，是只看算力峰值那个数字，觉得越高越好。实际用起来，先把你卡住的往往不是算力，而是显存、互联和存储这几项。我把几个容易被忽略的指标按重要性排了序，下面的判断基于我这几年的实操经验，不同框架和模型会有偏差。

3.1 显存是硬门槛，带宽决定你能不能喂饱它

显存不够，程序直接报内存溢出，没有任何折中余地。所以选卡第一件事是估显存需求，而不是看算力。一个粗略的估算方式是：模型参数量乘以每个参数的字节开销。全参微调的情况下，权重、梯度、优化器状态三部分加起来，混合精度下每个参数的开销大致在十几个字节的量级，一个 7B 参数的模型，粗算下来就要一百多 GB，单张 80G 的卡放不下，必须上分布式切分或者改用低秩适配。改成低秩适配之后，可训练参数大幅减少，显存需求能压到二十 GB 以内，一张 24G 的卡就能跑。

下面这个表是我自己常用的粗略对照，具体数值要按你的框架和 batch 大小实测。

显存够了之后，下一个瓶颈是显存带宽。带宽不够，算力单元会一直等数据，实测吞吐可能只有理论值的一半甚至更低。这也是为什么同样标称算力的两张卡，跑同一个模型的速度能差出一大截。挑卡的时候，如果平台把带宽参数藏着不写，可以直接问，这个数字比算力数字更能反映实际体验。

3.2 卡间互联：多卡训练的隐形天花板

单机多卡训练的时候，梯度同步要走卡间通道。如果卡之间只有普通的 PCIe 通道，通信开销会随着卡数增加迅速放大，八卡并行的加速比可能只有五到六倍，甚至更低。如果卡之间有高速互联通道，加速比能接近线性。租赁的时候一定要问清楚三件事：这几张卡是不是在同一台物理机上、卡间是不是高速互联、跨机之间有没有高速网络。有些平台的多卡实例是跨机拼出来的，标称八卡，实际通信走的是普通网络，跑小模型看不出来，跑大模型慢得让人怀疑人生。

还有一个细节：同一张卡型，不同批次的机器互联配置可能不一样。我遇到过同一个实例规格，第一次开出来是高速互联，第二次开出来是普通通道，跑同一个任务的耗时差了四成。后来养成的习惯是，开卡之后先跑一个多卡通信的基准测试，几十秒的事，确认加速比正常再开始正式训练。

3.3 存储 IO 和出口带宽：最容易被算漏的两项

系统盘默认通常只有几十 GB，装完驱动和框架就剩不下多少，模型权重和数据必须另挂数据盘。数据盘的类型也有讲究，普通盘和高速盘的读取速度差好几倍，训练时数据加载跟不上，GPU 就会周期性空转。

公网出口带宽是另一笔容易被忽略的钱。很多平台的入流量免费、出流量计费，训练时把模型权重下载下来问题不大，但如果你的流程里涉及大量数据在外部和本地之间来回搬，流量费用会悄悄累积。我做过一个测算，一百 GB 的数据集，按十兆每秒的上传速度，光传就要将近三个小时，这还没算中途断线重传的时间。所以数据集一定要提前规划好放在哪，尽量做到一次上传、多次复用。

3.4 镜像和驱动版本，比性能更折磨人

这一项不体现在任何参数表里，但它是实际使用中最耗时间的部分。驱动版本、CUDA 版本、深度学习框架版本、以及框架依赖的算子库版本，这四者之间有严格的对应关系，错一个就可能出现编译失败、算子找不到、或者跑起来结果不对。平台提供的公共镜像通常是通用配置，未必有你需要的那个组合。

我的做法是，第一次在新平台上把环境调通之后，立刻把整个环境保存成自定义镜像。后续所有实例都用这个镜像启动，环境一致性问题一次性解决。这一步花二十分钟，能省掉后面无数次重新配环境的时间。另外要注意，镜像保存本身可能占存储空间并产生费用，定期清理旧版本。

4. 计费方式的选择，比选卡更容易花冤枉钱

同一个卡型，不同的计费方式单价能差出好几倍。选错了计费方式，比选错了卡型浪费得更多。

4.1 四种常见计费模型的成本曲线

选择逻辑其实很简单：先估任务时长，再算两条成本曲线在哪个点交叉。短任务一定选按量，因为包月的固定成本摊不下来；任务时长超过一周且基本确定不会中断，包月开始划算；任务可以被打断并且有完善的断点机制，竞价实例的性价比最高。

4.2 竞价实例的回收风险和工程应对

竞价实例的价格优势很大，但它随时可能被回收，而且回收通知的提前量通常很短，几十秒到几分钟，靠人工反应根本来不及。所以用竞价实例的前提是你的任务必须能承受随时中断。

具体要做三件事。第一，训练脚本必须支持从检查点恢复，而且要验证过恢复逻辑是真的能跑通，不是写了没测。第二，检查点的保存间隔要按“能接受的最大损失”来定，比如你最多能接受损失四十分钟的训练进度，那就每三十五分钟存一次。第三，检查点一定要写到持久化存储或者对象存储里，不能只留在实例本地盘上，实例被回收时本地盘的数据可能一起没了。

我吃过一次亏，检查点写在了实例的临时盘上，实例被回收之后重新开了一台，发现目录是空的，那一次的进度全丢了。从那以后我的脚本里加了一条硬性检查：每次保存完检查点，立刻把最新的那个文件同步到对象存储，同步失败就直接报错停下。

4.3 忘记关机是最大的浪费来源

这一条听起来很低级，但它是实际账单里出现频率最高的异常项。调试的时候开了一台卡，跑完去开会，回来忘了关，第二天发现扣了二十多个小时。八卡实例挂一晚上，账单能到四位数。

解决办法是把这件事自动化。最低成本的方案是写一个空闲检测脚本，在实例上定时跑，连续若干个检测周期 GPU 利用率都低于阈值就自动关机。下面这个脚本是个简化版本，思路可以直接抄。

#!/bin/bash # 每 5 分钟检查一次，连续 6 次（30 分钟）GPU 利用率低于 5% 则关机 THRESHOLD=5 MAX_IDLE=6 idle_count=0 while true; do util=$(nvidia-smi --query-gpu=utilization.gpu \ --format=csv,noheader,nounits | awk '{s+=$1} END {print s/NR}') if [ "${util%.*}" -lt "$THRESHOLD" ]; then idle_count=$((idle_count + 1)) echo "$(date) idle: $idle_count / $MAX_IDLE, util=$util%" else idle_count=0 fi if [ "$idle_count" -ge "$MAX_IDLE" ]; then echo "$(date) 长时间空闲，执行关机" sync shutdown -h now fi sleep 300 done

提示：这个脚本适合调试机和个人实例。生产环境或者正在跑长任务的机器不要挂，容易误杀。更稳妥的做法是用平台自带的生命周期策略或者定时任务，配合预算告警一起用。

5. 从零开一台训练机的完整链路

这一节把实操流程走一遍。不同平台的控制台布局不一样，但核心步骤是一致的。下面的命令以常见的 Linux 环境为例。

5.1 开卡之前先过一遍清单

开卡三分钟，配环境三小时，这是常态。所以开卡之前花五分钟把下面这张表填一遍，能省掉大量返工。

其中“数据盘是否随实例释放”这一项特别容易踩。默认配置下，实例释放时数据盘可能一起被删除，如果你的模型权重存在上面，释放的那一刻就没了。开卡时就把这个选项关掉，或者养成释放前先确认数据已备份的习惯。

5.2 环境初始化与数据落位

连上实例之后，第一步不是急着跑训练，而是确认驱动和硬件状态。

nvidia-smi # 看驱动版本、卡数、显存、当前占用 nvidia-smi topo -m # 看卡间互联拓扑，确认是不是高速通道 df -h # 确认数据盘挂载点和剩余空间 free -g # 确认内存

确认硬件没问题，再建独立的环境。用虚拟环境或者容器都行，核心目的是把依赖锁死在一个版本组合上，避免和系统自带的环境冲突。

conda create -n train python=3.10 -y conda activate train pip install torch --index-url <对应版本的源> pip install -r requirements.txt

数据落位这一步有个原则：不要在对象存储上直接读数据训练。对象存储适合存冷数据和归档，随机读取的延迟比本地盘高一个数量级，训练时数据加载器会拖垮整体吞吐。正确做法是一次性把数据拉到本地数据盘，训练全程读本地。

# 小文件多的时候先打包，能显著加速传输 tar -cf dataset.tar /path/to/dataset # 传输完成后本地解包 tar -xf dataset.tar -C /data/

5.3 训练中的监控与断点策略

训练跑起来之后，至少要看三个东西：GPU 利用率、显存占用、数据加载速度。GPU 利用率如果长期在六成以下来回波动，说明瓶颈在数据侧，加数据加载的进程数或者换高速盘；显存占用如果贴近上限，把 batch 调小或者开梯度累积。

watch -n 2 nvidia-smi # 简单的实时监控 # 或者装 nvitop，界面更清楚 pip install nvitop && nvitop

检查点的策略在上一节讲过，这里补一个实操细节：检查点文件不要只保留一个，保留最近三到五个，按时间戳命名。原因是保存过程中如果被中断，最新那个文件可能是损坏的，这时候还能回退到上一个。

5.4 收尾：数据回流和实例释放

任务跑完，先把模型权重和日志同步到持久存储，确认文件大小正常、能正常加载，再释放实例。顺序反了就是事故。我见过有人先点了释放，才想起来权重还在实例上，只能重跑。

# 同步到对象存储，同步完对比一下文件大小 aws s3 cp /data/output/ s3://your-bucket/output/ --recursive # 或者用平台提供的命令行工具

释放之后隔一天再看一眼账单，确认没有遗留的快照、镜像、弹性 IP 在计费。这些东西单价不高，但会一直挂着。

6. 五个真实踩过的坑和排查路径

6.1 显存看着够，batch 就是起不来

现象是估算显存占用二十五 G，开了三十二 G 的卡，跑起来还是报内存不足。排查顺序是这样的：先看是不是峰值显存的问题，训练时的显存占用是动态的，前向传播的中间激活值在大 batch 下会突然冲高，nvidia-smi看到的是采样瞬间的值，不是峰值。用框架自带的显存分析工具看峰值，通常会发现比稳态高不少。第二个可能是显存碎片，反复创建销毁张量导致大块连续显存分配不出来，这时候设置一下显存分配策略通常能缓解。第三个可能是数据加载器在主进程里预取了太多 batch，把主机内存和显存都撑住了。

6.2 数据上云比训练本身还慢

这个坑的典型特征是：训练只要两小时，传数据要六小时。原因通常是数据集里全是小文件，几万个几十 KB 的样本，逐个传输的开销远大于数据本身。解决办法是先打包成单个大文件再传，传完在本地解包。如果数据要反复用，就做成压缩包放在对象存储里，每次开新实例直接拉压缩包。

另一个原因是没选就近的区域。数据在南方，实例开在北方，跨区域传输的速度和费用都会难看。开卡前看一眼数据存在哪个区域，实例就开在同一个区域。

6.3 竞价实例被回收，训练进度全丢

排查这类问题的顺序是：先确认检查点有没有真的写到持久存储，很多人以为写了，其实路径指向的是实例本地盘；再确认恢复逻辑有没有测过，光有检查点文件但加载代码有 bug，等于没有；最后确认检查点间隔是否合理，如果一小时存一次，被回收时最多损失一小时。三件事都做了，竞价实例的中断就只是一个需要重新排队的麻烦，不会造成实质损失。

6.4 多卡并行反而比单卡慢

这个现象很反直觉，但出现频率不低。第一嫌疑是数据加载跟不上，卡多了之后每张卡都要喂数据，加载线程数没同比增加，卡全在等数据。第二嫌疑是通信开销，卡间没有高速互联的时候，梯度同步的时间可能超过计算时间。第三嫌疑是 batch 太小，单卡 batch 本来就小，切到多卡之后每卡分到的更少，通信占比更高。第四是学习率没随卡数调整，收敛看起来变慢，实际不是速度问题而是效果问题。

排查方法很简单，先固定其他变量，只把卡数从一变到二，看耗时是不是接近减半。如果没有减半甚至变慢，那问题就在数据或通信上，逐个排除。

6.5 账单比预期翻了一倍

这种情况我帮人排查过几次，原因基本集中在四个地方：实例忘记关机、公网出流量、快照和镜像堆积、多挂了一块没注意的数据盘。排查路径是打开账单明细，按资源类型分组看，找到金额异常的那一项。出流量异常通常是数据下载没走内网或者没做缓存，反复从公网拉同样的数据；快照异常是每次改环境都存一个新镜像，旧的不清。

7. 租来的卡还能干哪些活

大模型训练是这两年被讨论最多的场景，但租赁算力的用途远不止这一个。按我的观察，实际使用里训练只占一部分，剩下的是推理、渲染、科研计算和教学。

7.1 推理服务的峰值弹性

线上推理的负载曲线通常是白天高、夜间低，工作日高、周末低。如果全按峰值配置自建，低谷期的资源全是浪费。更合理的做法是常驻一小部分卡跑基线的稳定流量，遇到流量峰值自动从外部扩几台，峰值过去自动缩容。这个模式对业务团队特别友好，运维复杂度增加有限，峰值时的稳定性反而比硬扛更好。

7.2 渲染、转码与批处理

这类任务的特点是离线、可中断、对单帧延迟不敏感，非常适合用竞价实例跑。一批视频转码或者一批三维渲染任务，拆成小份分发到多台竞价实例上并行跑，中间任何一台被回收，把那一小份重新排队就行，整体成本能压到常驻机器的几分之一。我做渲染相关的活时基本都用这个模式，任务拆得越细，被回收的影响越小。

7.3 科研计算和小规模试错

很多研究方向的同学面临的问题不是算力不够，而是算力需求不确定。一个想法要先验证可行性，验证通过才谈得上大规模实验。这种场景下按小时租最合适，试一个想法花几个小时，验证不通就换方向，没有沉没成本。我见过一些同学为了一个可能不成立的想法先买卡，最后思路变了，卡就闲置了，很不划算。

7.4 模型评测和选型对比

同一个任务在不同卡型上的表现差异很大，做技术选型的时候需要横向对比。自建不可能为了对比买好几张不同的卡，租赁可以同一份评测脚本、同一个数据集，在两三种卡型上各跑一遍，拿到吞吐、延迟、显存占用的实测数据。这个数据比任何参数表都可靠，而且成本只有几十块钱的卡时费。

8. 几个长期用得上的稳态做法

用得久了会形成一些习惯，这些习惯不涉及什么高深技术，但确实能省事。第一条，把配好的环境做成自定义镜像，每次开新实例都用同一个镜像启动，环境一致性问题一次性解决。第二条，把开卡流程脚本化，用命令行工具或者接口把“开实例、拉代码、拉数据、启动训练、上传结果、释放实例”串成一条链，需要人工参与的环节越少，忘事的概率越低。

第三条，数据分层。热数据放本地高速盘，温数据放对象存储的标准层，冷数据归档。训练的时候不跨层读，用完把产出同步回对象存储，本地盘随实例一起销毁。第四条，预算告警一定要开，设一个自己心理能承受的日消耗上限，超了就收通知。第五条，给自己的每个任务记一笔账：卡型、卡数、时长、实际花费、跑出了什么结果。记上十几条之后，你对“这类任务大概要花多少钱”会有一个非常准的直觉，下次做方案估算的时候就不会凭感觉拍数字。

我个人在实际操作中的体会是，租赁算力这件事的门槛不在技术，在习惯。技术层面的东西，装环境、调参数、写断点，搜一下就有答案；真正拉开差距的是那些“每次都记得做”的小事，比如开卡前过一遍清单、跑完立刻备份、释放前再确认一遍账单。把这几件事变成肌肉记忆，租赁这套模式用起来会非常顺手，而且成本会稳定在一个可预测的范围内。