1. 算清楚每小时有效成本再谈租还是买先说一个我见过好几次的场景某个团队为了一个季度的模型微调任务走完审批流程买了整机机器上架、装驱动、调环境花了两周。结果任务比预期顺利三周就跑完了剩下八个多月机器基本在机房里吃灰偶尔被拉去跑个数据清洗。另一拨人做法完全相反任务开始当天开通实例跑完当天释放账单清清楚楚。这两拨人的差别不在预算多少也不在技术水平而在“算力和时间到底怎么对齐”这件事上有没有想明白。GPU租赁服务说到底就是把“买算力”变成“租算力”把一笔固定资产投入换成一笔可变成本但这一步转换到底是省钱还是多花钱取决于一个很多人懒得算的指标每小时的有效成本。1.1 自建整机的成本不只是那张卡的价格大多数人算自建成本只算整机采购价除以折旧年限得出一个“每月多少”的数字然后就拿去和租赁报价比。这个算法漏掉的项非常多。一台整机的全生命周期成本至少包含这么几块硬件采购卡、主板、内存、盘、电源、机箱、机房空间或托管费用、电费、网络带宽、备件与维保、装机和环境调试的人工、故障停机损失以及三年后这台机器还剩多少残值。其中电费这一项很多人凭感觉估实际差距很大。一张功耗三百多瓦的卡八卡整机加上CPU、内存、风扇整机功耗轻松到四千瓦以上按每天二十四小时跑、每度电八角算一个月电费就在两千多块如果是功耗更高的训练卡整机八千瓦一个月电费接近五千块这还没算机房的制冷成本而托管报价里通常会把制冷摊进机柜费。下面这张表是我自己做测算时用的一个简化框架数字是示例实际要换成你所在地的电价和托管报价。成本项八卡中端整机示例八卡高端训练整机示例说明硬件采购约 20 万约 140 万含卡、主板、内存、盘、电源折旧年限3 年3 年按线性折旧实际贬值更快月折旧约 5550 元约 46600 元采购价除以 36月电费约 2300 元约 4600 元按 0.8 元/度估算月托管/机柜约 4000 元约 5000 元按整机功耗和空间计月运维分摊约 2000 元约 3000 元装环境、修故障、盯监控月合计约 1.39 万约 5.92 万不含网络与备件把这些月成本除以每月的卡时总量八卡跑满一个月是 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 大小实测。训练方式7B 模型显存粗估13B 模型显存粗估适配卡型全参微调100 GB200 GB多张 80G 卡低秩适配18–24 GB30–40 GB单张 24G / 48G推理半精度14–16 GB26–30 GB单张 24G / 48G推理量化后4–8 GB8–14 GB单张 16G显存够了之后下一个瓶颈是显存带宽。带宽不够算力单元会一直等数据实测吞吐可能只有理论值的一半甚至更低。这也是为什么同样标称算力的两张卡跑同一个模型的速度能差出一大截。挑卡的时候如果平台把带宽参数藏着不写可以直接问这个数字比算力数字更能反映实际体验。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% 则关机 THRESHOLD5 MAX_IDLE6 idle_count0 while true; do util$(nvidia-smi --query-gpuutilization.gpu \ --formatcsv,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_count0 fi if [ $idle_count -ge $MAX_IDLE ]; then echo $(date) 长时间空闲执行关机 sync shutdown -h now fi sleep 300 done提示这个脚本适合调试机和个人实例。生产环境或者正在跑长任务的机器不要挂容易误杀。更稳妥的做法是用平台自带的生命周期策略或者定时任务配合预算告警一起用。5. 从零开一台训练机的完整链路这一节把实操流程走一遍。不同平台的控制台布局不一样但核心步骤是一致的。下面的命令以常见的 Linux 环境为例。5.1 开卡之前先过一遍清单开卡三分钟配环境三小时这是常态。所以开卡之前花五分钟把下面这张表填一遍能省掉大量返工。检查项要确认的内容卡型与卡数显存是否够、是否同机、是否高速互联镜像公共镜像的驱动和框架版本是否匹配或选自定义镜像系统盘容量是否够装环境和代码通常 50G 起步数据盘类型普通/高速、容量、是否随实例释放网络是否需要公网 IP、出口带宽上限、流量是否计费计费方式按量/包时/包月/竞价以及最小计费粒度区域离数据源最近的区域减少传输时间自动释放是否设置到期自动释放避免遗忘其中“数据盘是否随实例释放”这一项特别容易踩。默认配置下实例释放时数据盘可能一起被删除如果你的模型权重存在上面释放的那一刻就没了。开卡时就把这个选项关掉或者养成释放前先确认数据已备份的习惯。5.2 环境初始化与数据落位连上实例之后第一步不是急着跑训练而是确认驱动和硬件状态。nvidia-smi # 看驱动版本、卡数、显存、当前占用 nvidia-smi topo -m # 看卡间互联拓扑确认是不是高速通道 df -h # 确认数据盘挂载点和剩余空间 free -g # 确认内存确认硬件没问题再建独立的环境。用虚拟环境或者容器都行核心目的是把依赖锁死在一个版本组合上避免和系统自带的环境冲突。conda create -n train python3.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. 几个长期用得上的稳态做法用得久了会形成一些习惯这些习惯不涉及什么高深技术但确实能省事。第一条把配好的环境做成自定义镜像每次开新实例都用同一个镜像启动环境一致性问题一次性解决。第二条把开卡流程脚本化用命令行工具或者接口把“开实例、拉代码、拉数据、启动训练、上传结果、释放实例”串成一条链需要人工参与的环节越少忘事的概率越低。第三条数据分层。热数据放本地高速盘温数据放对象存储的标准层冷数据归档。训练的时候不跨层读用完把产出同步回对象存储本地盘随实例一起销毁。第四条预算告警一定要开设一个自己心理能承受的日消耗上限超了就收通知。第五条给自己的每个任务记一笔账卡型、卡数、时长、实际花费、跑出了什么结果。记上十几条之后你对“这类任务大概要花多少钱”会有一个非常准的直觉下次做方案估算的时候就不会凭感觉拍数字。我个人在实际操作中的体会是租赁算力这件事的门槛不在技术在习惯。技术层面的东西装环境、调参数、写断点搜一下就有答案真正拉开差距的是那些“每次都记得做”的小事比如开卡前过一遍清单、跑完立刻备份、释放前再确认一遍账单。把这几件事变成肌肉记忆租赁这套模式用起来会非常顺手而且成本会稳定在一个可预测的范围内。 
长河君 · 2026/10/30 3:43:23 · 阅读 1.2k GPU租赁成本怎么算：有效成本、利用率与弹性算力选择
1. 算清楚每小时有效成本再谈租还是买先说一个我见过好几次的场景某个团队为了一个季度的模型微调任务走完审批流程买了整机机器上架、装驱动、调环境花了两周。结果任务比预期顺利三周就跑完了剩下八个多月机器基本在机房里吃灰偶尔被拉去跑个数据清洗。另一拨人做法完全相反任务开始当天开通实例跑完当天释放账单清清楚楚。这两拨人的差别不在预算多少也不在技术水平而在“算力和时间到底怎么对齐”这件事上有没有想明白。GPU租赁服务说到底就是把“买算力”变成“租算力”把一笔固定资产投入换成一笔可变成本但这一步转换到底是省钱还是多花钱取决于一个很多人懒得算的指标每小时的有效成本。1.1 自建整机的成本不只是那张卡的价格大多数人算自建成本只算整机采购价除以折旧年限得出一个“每月多少”的数字然后就拿去和租赁报价比。这个算法漏掉的项非常多。一台整机的全生命周期成本至少包含这么几块硬件采购卡、主板、内存、盘、电源、机箱、机房空间或托管费用、电费、网络带宽、备件与维保、装机和环境调试的人工、故障停机损失以及三年后这台机器还剩多少残值。其中电费这一项很多人凭感觉估实际差距很大。一张功耗三百多瓦的卡八卡整机加上CPU、内存、风扇整机功耗轻松到四千瓦以上按每天二十四小时跑、每度电八角算一个月电费就在两千多块如果是功耗更高的训练卡整机八千瓦一个月电费接近五千块这还没算机房的制冷成本而托管报价里通常会把制冷摊进机柜费。下面这张表是我自己做测算时用的一个简化框架数字是示例实际要换成你所在地的电价和托管报价。成本项八卡中端整机示例八卡高端训练整机示例说明硬件采购约 20 万约 140 万含卡、主板、内存、盘、电源折旧年限3 年3 年按线性折旧实际贬值更快月折旧约 5550 元约 46600 元采购价除以 36月电费约 2300 元约 4600 元按 0.8 元/度估算月托管/机柜约 4000 元约 5000 元按整机功耗和空间计月运维分摊约 2000 元约 3000 元装环境、修故障、盯监控月合计约 1.39 万约 5.92 万不含网络与备件把这些月成本除以每月的卡时总量八卡跑满一个月是 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 大小实测。训练方式7B 模型显存粗估13B 模型显存粗估适配卡型全参微调100 GB200 GB多张 80G 卡低秩适配18–24 GB30–40 GB单张 24G / 48G推理半精度14–16 GB26–30 GB单张 24G / 48G推理量化后4–8 GB8–14 GB单张 16G显存够了之后下一个瓶颈是显存带宽。带宽不够算力单元会一直等数据实测吞吐可能只有理论值的一半甚至更低。这也是为什么同样标称算力的两张卡跑同一个模型的速度能差出一大截。挑卡的时候如果平台把带宽参数藏着不写可以直接问这个数字比算力数字更能反映实际体验。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% 则关机 THRESHOLD5 MAX_IDLE6 idle_count0 while true; do util$(nvidia-smi --query-gpuutilization.gpu \ --formatcsv,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_count0 fi if [ $idle_count -ge $MAX_IDLE ]; then echo $(date) 长时间空闲执行关机 sync shutdown -h now fi sleep 300 done提示这个脚本适合调试机和个人实例。生产环境或者正在跑长任务的机器不要挂容易误杀。更稳妥的做法是用平台自带的生命周期策略或者定时任务配合预算告警一起用。5. 从零开一台训练机的完整链路这一节把实操流程走一遍。不同平台的控制台布局不一样但核心步骤是一致的。下面的命令以常见的 Linux 环境为例。5.1 开卡之前先过一遍清单开卡三分钟配环境三小时这是常态。所以开卡之前花五分钟把下面这张表填一遍能省掉大量返工。检查项要确认的内容卡型与卡数显存是否够、是否同机、是否高速互联镜像公共镜像的驱动和框架版本是否匹配或选自定义镜像系统盘容量是否够装环境和代码通常 50G 起步数据盘类型普通/高速、容量、是否随实例释放网络是否需要公网 IP、出口带宽上限、流量是否计费计费方式按量/包时/包月/竞价以及最小计费粒度区域离数据源最近的区域减少传输时间自动释放是否设置到期自动释放避免遗忘其中“数据盘是否随实例释放”这一项特别容易踩。默认配置下实例释放时数据盘可能一起被删除如果你的模型权重存在上面释放的那一刻就没了。开卡时就把这个选项关掉或者养成释放前先确认数据已备份的习惯。5.2 环境初始化与数据落位连上实例之后第一步不是急着跑训练而是确认驱动和硬件状态。nvidia-smi # 看驱动版本、卡数、显存、当前占用 nvidia-smi topo -m # 看卡间互联拓扑确认是不是高速通道 df -h # 确认数据盘挂载点和剩余空间 free -g # 确认内存确认硬件没问题再建独立的环境。用虚拟环境或者容器都行核心目的是把依赖锁死在一个版本组合上避免和系统自带的环境冲突。conda create -n train python3.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. 几个长期用得上的稳态做法用得久了会形成一些习惯这些习惯不涉及什么高深技术但确实能省事。第一条把配好的环境做成自定义镜像每次开新实例都用同一个镜像启动环境一致性问题一次性解决。第二条把开卡流程脚本化用命令行工具或者接口把“开实例、拉代码、拉数据、启动训练、上传结果、释放实例”串成一条链需要人工参与的环节越少忘事的概率越低。第三条数据分层。热数据放本地高速盘温数据放对象存储的标准层冷数据归档。训练的时候不跨层读用完把产出同步回对象存储本地盘随实例一起销毁。第四条预算告警一定要开设一个自己心理能承受的日消耗上限超了就收通知。第五条给自己的每个任务记一笔账卡型、卡数、时长、实际花费、跑出了什么结果。记上十几条之后你对“这类任务大概要花多少钱”会有一个非常准的直觉下次做方案估算的时候就不会凭感觉拍数字。我个人在实际操作中的体会是租赁算力这件事的门槛不在技术在习惯。技术层面的东西装环境、调参数、写断点搜一下就有答案真正拉开差距的是那些“每次都记得做”的小事比如开卡前过一遍清单、跑完立刻备份、释放前再确认一遍账单。把这几件事变成肌肉记忆租赁这套模式用起来会非常顺手而且成本会稳定在一个可预测的范围内。