云上租算力全指南：GPU选型、计费模式与LoRA微调实操

作为上云操作记录系列的第十篇来聊聊租算力。之前九篇折腾的都是云主机、存储、数据库、网络这些基础件唯独算力我一直压着没写。不是不想写而是租算力这件事表面看太简单——选个机型、点几下、开机但实际上手后坑比普通云主机多得多。我见过不少朋友第一次租GPU的经历有人买了一张跑大模型推理效率极低的卡有人开了包月机器结果一周都没跑起来还有人月底看账单才发现按量计费的钱够买两台整机了。这篇就把我踩过的坑和最后跑通的路子完整走一遍从需求评估、机型选择、实例创建到环境自检、跑一个微调任务、最终释放实例一次性说透。1. 先说清楚你缺的到底是算力还是别的1.1 算力不是租一台高配机器那么简单先纠正一个常见的直觉偏差。很多人觉得租算力就是租一台配置很高的服务器CPU好一点、内存大一点插上显卡就完事了。实际上云上租算力和租普通云主机是两条完全不同的逻辑线。普通云主机你关心的核心是核数、内存、磁盘IO、带宽这些参数在相同价格区间的差异不会太大选错了顶多慢一点问题不大。但算力资源不一样尤其是GPU决定实际体验的是几个不太显眼的技术参数显存容量、显存带宽、FP16/BF16吞吐、卡间互联方式甚至还包括驱动和CUDA版本是否匹配。同一片价格带里选错一张卡跑AI任务的性能差异能拉到好几倍而且这种差距不是靠多花钱能追回来的。举个具体例子同样是24GB显存档位的卡A型号打游戏、渲染很强但跑大模型的矩阵运算效率可能很低B型号每秒能处理的token数明显高出一截价格却差不多。所以第一步不是比价格而是先把需求拆成三个问题我要跑什么任务同时服务多少人任务要跑多久这三个问题的答案直接决定该租什么而不是平台页面上哪个选项顺眼。1.2 先算三个数再去看平台页面到现在为止我每次打开租算力平台还是会忍不住直接盯着配置列表看然后被各种茫茫多的机型吸引。这个习惯必须改。正确顺序是反着来的先在纸上算出三个数再拿着数字去选型。第一个数是显存下限。以推理为例一个7B参数量的模型FP16精度下光权重就要占14GB左右。注意这还只是底线推理过程中还要给KV Cache、激活值、输入序列长度留余量。跑一个常规的单用户推理任务单卡24GB是比较稳的起步配置。如果换到13B模型24GB就非常紧张了要么选40GB以上的卡要么用INT8或INT4量化把权重压缩到8GB上下再用CPU offload之类的手段换空间。我自己的经验是显存宁多勿少因为量化带来的是精度损失和推理复杂度上升这些成本加起来往往比每小时多出来的租金高。第二个数是吞吐目标也就是token算力需求到底是多少。这个热词这两年被讲得很玄其实算起来并不复杂。假设你的业务要求每秒输出100个token而当前模型在单卡上每生成一个token大约要花2ms的GPU时间那么单卡单并发就能提供500 token/s的能力完全够用。但如果是一个几十人同时在线的对话服务并发一上来要么排队严重要么就得换更强的卡或者上多卡推理。别只看模型能不能跑得动你真正要问的是在目标并发下响应延迟能不能接受。第三个数是训练还是推理。训练和推理对显存的需求差距很大训练要额外存反向传播的梯度、优化器状态粗略估计是纯推理的2到4倍。还是7B模型用LoRA这类参数高效微调方法显存吃到32GB很正常如果做全量微调即便40GB也紧巴巴。这也是为什么很多人第一次上车买低配卡最后全卡在显存不够上。首次租算力的人把这几个数写在一张小纸条上再打开平台能过滤掉一半的纠结选项。1.3 token算力需求很多人忽略的第二维度前面第二段把token算力需求简单带过了但这个词值得单独拆开讲一讲。评估算力需求时大多数人只做了模型能不能装进显存这一步却漏掉了每秒能生成多少token这个更关键的维度。token算力需求可以拆成两个部分峰值吞吐和平均吞吐。峰值吞吐决定系统最高能承受多大并发平均吞吐决定用户体验的流畅度。比如你在做一个内容总结工具用户上传一段长文本期望10秒内看到结果。这段文本大概3000个token如果模型的输出速度是每秒50个token那一次请求就要60秒用户显然等不了。这时候你需要的不是更便宜的卡而是吞吐更高的卡或者用推理优化框架把每秒token数提上去。还有一点经常被忽略——token算力需求和显存需求是有叠乘效应的。为了提升吞吐你会加大batch size而更大的batch size又会抬高显存占用。所以实际选型时显存和吞吐是一起考虑的显存决定你能跑多大模型吞吐决定你能服务多少并发。这两个数字都算清楚了机型的筛选范围就非常窄了。2. 选机型和计费方式第一次下单最容易在这两处翻车2.1 按需、竞价、包周包月三种计费模式的真实代价算力租赁平台的计费花样比云主机多得多跑了一圈下来核心其实就是三种按需计费、竞价型实例、包周包月。按需计费就是按小时甚至按秒扣钱优点是随时开、随时释放不存在沉没成本。这种模式最适合第一次试水你还没搞明白自己要跑多久、环境怎么配先用按需把全流程跑通成本可控。缺点是单价最贵放那里挂着不动账单会很难看。竞价型实例的价格由市场供需决定可能只有按需的三分之一甚至更低省钱效果立竿见影。但这个便宜是有代价的平台随时可能因为报价被抬高而回收资源。我见过有人用竞价实例跑了两天训练在要出结果的前一小时收到实例将被回收的通知心态当场崩掉。所以竞价实例适合做容错性强的批量推理任务不适合跑关键训练除非你写了完善的断点续训脚本书。包周包月相当于租一台固定机器长期给你用性价比在长时间跑任务时最高。比如一个模型训练要连续跑两周按需计费可能比包月多出两三倍的成本。缺点是灵活性差这一周里哪怕你机器在吃灰钱照样扣。我的建议是首次尝试先开按需最小配置跑通整个流程后再考虑切换计费模式。上来就买包月连环境都还没弄好那段时间就白付了。2.2 显存、卡间互联、IO容易被忽略的三个性能开关平台详情页通常会标注显存、显存带宽、算力TFLOPS、网络带宽这几个数字。大多数人只看显存和显卡型号但我建议多关注三个容易忽略的维度。第一是算力规格要看准精度。很多平台的宣传语会写XX TOPS这个数字往往是INT8精度的整数算力对推理有一些参考意义但训练任务真正依赖的是FP16/BF16精度下的TFLOPS。一张消费级卡的INT8 TOPS可能看起来很高但换算成FP16能力可能连专业加速卡的一半都不到。所以别被纸面数据带着走要找到对应精度那一列再比较。第二是卡间互联方式这是多卡场景最容易踩的坑。如果你打算跑多卡训练卡的通信方式直接决定扩展性。两张卡通过PCIe互联通信带宽远比不上NVLink这类专用互联。同样是两张24GB显存的卡走NVLink传输梯度的速度能和走PCIe拉开一个数量级。平台详情页里如果没有明确写卡间互联方式我建议直接问客服或者查文档别等任务跑起来才发现是假多卡。第三是存储IO。算力实例的数据盘如果是很便宜的普通云盘训练时读数据集的速度可能比GPU计算还慢GPU利用率被拖到20%、30%是常有的事。这种时候问题不在算力而在存储。宁可把数据集放到高性能云盘或者加载到内存里也别在普通盘上直接硬跑。判断方法很简单训练的时候开一个监控如果GPU利用率长期低于50%同时磁盘读速度打满说明IO就是瓶颈。2.3 别被TOPS排行榜带偏看规格表要看哪几列很多人刚接触AI算力时喜欢把市面上各家显卡的TOPS值拉出来排序,存一个显卡算力TOPS排行盯着看。说实话这个排行榜有一点参考价值但非常有限因为TOPS值的测试条件、精度设置各家并不完全一致跨品牌、跨代际直接横向对比很容易被误导。更实际的做法是只盯规格表里的四列显存容量、FP16/BF16算力、显存带宽、卡间互联方式。这四列决定了你这个任务跑得快不快、能不能跑起来。其他参数比如像素填充率、光栅单元数量对AI任务的影响很小忽略就好。还要提醒一点消费级卡和专业加速卡之间的差距往往不在纸面TFLOPS上而在显存、功耗、驱动生态和稳定性上。租算力作为生产环境我通常首选专业加速卡因为云平台对它的调优更成熟驱动和CUDA版本更可控消费级卡偶尔会出现掉驱动、温度墙降频的问题虽然租金便宜但出了问题排查成本一样不少。综合算下来省下的那点租金往往不够赔时间。3. 首次租算力的完整操作链路从创建实例到跑通一个微调任务3.1 创建实例的配置细节每个选项都不是随便填的既然前面把需求算清楚了创建实例的页面就不再是难题但依然有几个选项容易被忽略我逐个说一下。镜像选择。算力平台通常会提供预装了CUDA、PyTorch、TensorFlow的镜像。强烈建议第一次直接选预装镜像别从裸机开始配环境。裸机看起来自由但你至少得装显卡驱动、CUDA、cuDNN、Python、包管理器每一层都可能踩到一个跨版本不兼容的坑。预装镜像偶尔版本旧一点但胜在稳定很多环境问题平台已经替你踩平了。如果你的任务有特别框架要求也建议先找一个带该框架的镜像而不是手动装。密钥对。云算力实例默认只支持SSH密钥登录密码登录很少见。创建实例时平台让你生成一个密钥对私钥文件一定要保存到安全的地方。这个文件通常只允许下载一次丢了就只能重建实例。我习惯在本地单独建一个目录存放所有云平台的私钥按平台名实例名命名避免混用。磁盘。系统盘和数据盘分开是铁律。数据集和模型文件放到数据盘系统盘保持干净后面要释放实例时数据盘还能单独做快照或者打包带走。很多人贪方便直接全放系统盘一旦系统出问题数据和环境一起没了哭都来不及。安全组。如果只是自己远程连上去训练保持在默认端口即可如果要对外部提供服务再按需开放端口。开放端口越少越省心尤其是算力实例没必要给攻击者多余的可乘之机。3.2 实例起来之后的五分钟自检实例状态变成运行中别急着传数据先把下面这几条命令跑一遍确认环境真的可用。第一条看显卡识别nvidia-smi确认驱动正常、GPU被正确识别、显存没有被其他进程占满。如果有多个进程占着显存先查一下是不是别人共用实例残留下来的。第二条验证深度学习框架和CUDA是否打通python -c import torch; print(torch.__version__, torch.cuda.is_available())返回True说明环境正常。如果用的是预装镜像torch.cuda.is_available() 还是返回 False大概率是PyTorch版本和CUDA版本不匹配卸载重装对应版本就行。这里有个小技巧先看nvidia-smi里右上角的CUDA版本再对照PyTorch官方写的适配列表选版本能省下很多试错时间。第三条跑一个简单的矩阵计算测试python -c import torch; atorch.randn(1024,1024,devicecuda); baa; print(b.sum().item())能顺利打印出结果说明CUDA计算链路已经完全打通。到这里实例才算真的能用。这套自检流程我第一次操作花了十五分钟之后熟练了三分钟搞定但每次新建实例我都会跑一遍因为它能快速排除掉平台侧的环境问题后面再报错就能专注于业务代码本身。3.3 跑一个真实任务低资源LoRA微调全流程用7B模型的LoRA微调来演示整个过程这个任务很能说明租算力到底在租什么。你租的不是一堆金属而是确定能跑起来的一段时间。第一步获取基础模型。优先从平台提供的公共模型存储中拉取通常走内网速度快。没有的话就用官方下载工具从模型站拉注意模型的格式和版本兼容性。拉到本地后先检查文件完整性避免后面训练时读到一半报错。第二步准备数据。用一个简单的指令微调数据集按jsonl格式放好每条包含prompt和response字段。为了验证全链路先用几千条数据跑通再考虑加大数据量。很多时候问题出在数据格式上小数据量能快速暴露问题节省排查时间。第三步写微调脚本。核心参数包括模型路径和输出目录LoRA的秩r和缩放系数alpha常见组合是r8、alpha16batch size直接由显存容量决定显存不够就调小学习率微调一般用1e-4到1e-5保存checkpoint的间隔启动训练后用nvidia-smi看显存占用再观察loss曲线是否正常下降。第一次跑通后你会有一种很直观的感受所谓算力租赁付的是省去环境问题确保计算完成的确定性费用。环境一次性配好之后每个小时都在产出有效结果。3.4 任务收尾保存成果、清理进程、释放实例训练任务跑完第一件事绝对不是立刻关掉实例而是把成果保存好。权重文件、训练日志、配置文件打包上传到对象存储或者直接下载回本地。确认数据保存无误之后再去实例管理页面执行释放操作。释放之前过一遍固定清单有没有存在系统盘里的临时文件要拷走有没有挂载数据盘但快照没打有没有跑在后台的进程没停。这个动作我第一次释放时全部踩了一遍后来索性写成一个检查列表贴在笔记里每次释放前照着过。别嫌麻烦实例一旦释放所有未保存的本地数据就彻底没了。4. 文件传输、数据备份与实例释放算力用完不等于事情结束4.1 大模型文件的三种高效传输方案模型权重动辄几十GB用scp硬传速度感人还会因为网络中断前功尽弃。实际用下来比较靠谱的有三种方案。第一平台自带的对象存储或网盘。把模型文件先上传到平台的对象存储在算力实例里直接下载走的通常是内网链路速度极快。这是我最推荐的方式适合几十GB级别的数据迁入迁出。第二rsync断点续传。从本地往服务器传数据时用rsync而不是scp。rsync的特点是网络断了重跑一条命令会自动接着上次的进度传不会从头再来一次。rsync -avP --partial /local/model_dir/ userserver:/remote/model_dir/-P参数会显示进度并保留断点信息配合--partial使用长传大文件非常稳。第三公共模型走镜像站。很多常用模型在镜像站有托管直接在实例里用wget或官方下载命令拉取比自己打包上传快得多。注意先确认镜像的版本和hash是否和原版一致防止下载到损坏的权重。4.2 SSH连接和本地密钥管理的细节算力实例建得多了SSH连接信息会越攒越多。每个平台、每台机器都记IP和密钥路径很容易乱。到了这个阶段整理一个统一的SSH配置就很必要。在macOS/Linux下编辑~/.ssh/configWindows终端也有对应配置。每台机器起个简短别名配置好HostName、User和IdentityFile之后连接就变成一行命令ssh gpu1不用再每次打一长串IP和参数。考虑到安全私钥文件的权限要收紧权限太开放会导致SSH直接拒绝使用。在macOS/Linux下通常需要chmod 600私钥文件。这里提一个我踩过的坑不要在多个平台复用同一把私钥。一旦某个平台发生了泄露你就得同时更新所有平台。正确的做法是每个平台或者每一类安全级别单独生成密钥并在SSH config里严格对应。4.3 实例释放之前必须做的一次清单梳理算力实例和普通云主机最大的区别是它天生是用完即走的。释放前不做好数据转移损失是不可逆的。我的固定做法是三步走。第一步把训练过程中的checkpoint同步到对象存储或者本地至少保留最近一版第二步把最终的权重、日志、配置、训练脚本打包成压缩文件文件名带上日期和模型精度避免后面版本混淆第三步检查系统盘和数据盘上还有没有临时文件、数据集、中间产物需要带走然后才在平台上执行释放。这个过程看起来繁琐但它能换来一个非常宝贵的确定性以后任何时候翻出这套流程都不会假装数据应该还在服务器上。5. 多台算力服务器的统一管理从手工到半自动化5.1 什么场景下真的需要多台算力机器「怎么统一管理多台算力服务器」是个好问题但在动手之前先想清楚你到底需不需要多台。常见的需求场景有三种。第一是单卡显存不够需要多卡做分布式训练或者模型并行第二种是批量推理任务量大需要横向扩展多台机器分摊请求第三种是团队多个人同时跑不同的实验资源隔离需要多台机器。如果只是单机单卡跑一个任务别为了管理去折腾多机管理成本往往比算力成本还高。我要强调一个观点多机是解决问题的工具不是炫技的手段。机器数量越多网络、存储、运维的复杂度都会指数级上升。5.2 统一管理的最落地方案配置、巡检、任务分片先搭好连接层。所有机器的SSH配置统一放到本地终端里通过别名访问。在此基础上第二步是写一个简易巡检脚本批量查看每台机器的GPU占用和显存情况。for host in gpu1 gpu2 gpu3; do echo $host ssh $host nvidia-smi --query-gpuutilization.gpu,memory.used --formatcsv done这个脚本虽然简单但在只有几台机器时非常实用GPU利用率、显存余量一目了然。第三步是任务分片。先不引入重量级调度平台直接从任务特征入手把可并行的数据拆成多份每台机器负责其中一份最后合并结果。比如推理任务按文件或按ID区间切分分发给不同的机器并行处理最后收集输出。这种方式不需要额外的协调服务出错时只需重跑对应分片成本和心智负担都很低。5.3 管理多台机器时容易忽略的权限与安全细节机器多了最容易暴露的问题就是权限失控。最常见的坏习惯是所有机器用同一个账号、同一把密钥结果一个人拿到一台机器的权限等于拿到了全部机器。我的建议是分级管理。个人实验用的机器和小团队协作的机器分开密钥工具、脚本、模型文件的存放目录统一规划不要每台机器自成一套。前面提到的巡检脚本如果里面包含密钥路径注意别提交到公开仓库这个坑我已经见人踩过好几回了。如果你的机器数量继续增长再考虑接配置管理工具或者任务调度系统。但对绝大多数人来说统一的SSH配置加一个巡检脚本已经能解决90%的多机管理问题。6. 从租算力延伸出去边缘计算节点和物联网数据上云的协同6.1 边缘计算节点和中心云算力并不是替代关系最近总看到一个热门话题边缘计算节点在校园物联网设备数据上云传输中的应用。很多人会因此产生一个疑问既然边缘节点能做计算是不是可以替代云上租来的算力我的看法非常明确不能也不应该。边缘计算节点通常部署在靠近数据产生的地方优势是低时延、节省带宽、数据本地化缺点是单体算力有限、难以弹性扩展。中心云算力的优势恰好是强算力、弹性扩容、生态完善。两者不是替代关系而是分工关系——边缘负责快云负责重。拿校园物联网场景来举例。学校里大量传感器、摄像头产生的数据如果全部原始数据直接上云带宽和存储成本会非常惊人。更合理的链路是边缘节点先做数据清洗、压缩、脱敏只把有价值的结构化结果或关键片段上传到云端云端再用租来的算力做重模型的训练、复杂推理和长期存储。训练好的模型下沉到边缘节点形成闭环。这就是边缘预处理中心云算力的典型协作模式。6.2 物联网数据上云的真实成本计算思路算力租赁的钱花得值不值要放在整个数据链路上看。假设一个校园场景布置了几百个物联网终端每天产生500GB的原始数据。直接全量上云按流量和存储计费一个月下来是一笔不小的开支如果边缘节点先把数据压缩到十分之一甚至更低再上传云端算力的成本和带宽成本会同时下降。所以算力账单的正确算法不是单看每小时租金而是看单位有效结果成本。也就是说你把数据处理成有用的结果这个过程总共花了多少钱。边缘节点省下来的带宽和云存储费用往往能覆盖一部分云算力的租金整体方案反而更省。这也是为什么现在做物联网上云方案时我总会先问一个问题数据在上云之前已经做了多少处理6.3 什么时候该租算力什么时候该用边缘节点结合前几节的内容给出一个简单的判断框架需要处理的任务如果是模型训练、大规模批量推理、数据统计分析这类算力密集型的果断租中心云算力。任务如果是对实时性要求高、数据量大但单条处理逻辑简单、涉及隐私数据不想出本地域的优先考虑边缘节点处理。处于中间地带的任务可以设计成边缘初筛云上精算的两段式架构。以物联网数据为例设备状态异常检测这种逻辑简单但需要快速响应的放在边缘节点做而基于历史数据的趋势预测、模型重训练这种重活放到云上算。这样既控制了成本又保证了响应速度还给未来的算法升级留出了空间。最后顺手给个经验之谈租算力这件事最怕的不是花点钱而是开着机器不干活。按需计费的实例每小时都在扣钱我见过有人实例挂了一整天没跑任何任务那笔闲置费用够跑好几个正式实验。我的做法是立一条规矩按需开、跑完关、数据及时存。第一次租GPU时我因为跑完训练忘记释放实例多付了一整晚的闲置费用后来索性把所有自动化脚本的第一行都写成检查任务是否结束。这个习惯帮我省下的成本比任何选型技巧都多。算力是一种很特别的上云资源——它既是生产工具也是不断在消耗的钱包开口。把它当成真正按秒计费的生产资料来用你会发现整个上云操作都变得清爽很多。