企业官网建设流程全解析

上个月帮 A 同学看一份微调脚本，他开口第一句是“我先买张 4090 吧”。我把他拦下来了：一个只想跑两周实验、之后大概率吃灰的需求，买卡是最贵的选择。真正划算的做法是租——按小时算钱，跑完就关，卡型还能换。这篇就把AutoDL 算力云这类 GPU 租用平台从注册到跑通第一个训练任务的全流程讲透，包括卡型怎么挑、镜像怎么选、数据盘怎么规划、钱怎么省、坑怎么躲。适合三类人：手上只有轻薄本但要做深度学习实验的学生、需要临时算力跑微调或推理的个人开发者、以及要给团队做小规模验证但不想走采购流程的工程师。不管你是第一次接触云 GPU，还是已经在用但总觉得账单偏高，下面这些内容应该都能对上你的痛点。

1. 租算力之前先想清楚：为什么是算力云而不是自己攒机

1.1 自建 GPU 机器的隐性成本拆解

很多人算自建成本只算显卡钱，这是最容易踩的思维陷阱。一张消费级旗舰卡加上配套的主板、电源、内存、机箱、散热，整机落地往往要两万上下；专业卡方案更贵。但真正的成本大头在后面的三项：电费、折旧和闲置率。

电费这块，一张 350W 到 450W 的卡满载跑训练，整机功耗轻松上到 600W 以上。按每天满负荷 10 小时算，一个月就是一百八十度电上下，一年两千多度。夏天还得算上空调制冷的额外负载。折旧这块，显卡的二手残值衰减速度跟使用强度强相关，连续高温满载跑一年，残值可能腰斩。闲置率是最容易被忽略的：一个典型的个人项目，真正的训练时间可能只占你拥有这台机器的总时长的 5% 到 10%，剩下 90% 的时间它在待机、在吃灰、在占着你桌上的空间。

把这三项摊到实际有效的 GPU 小时上，自建机器的“真实时租”往往远高于云平台的挂牌价。这是我建议绝大多数个人和小团队优先选算力云的根本原因——你只为有效计算时间付费，把闲置、折旧、运维、驱动折腾全部外包出去。

当然自建也有不可替代的场景：需要长期独占、需要特殊硬件接口、数据合规要求不能出内网、或者要跑几个月的连续任务。判断标准很简单：如果一个月内的有效 GPU 使用时长低于 150 小时，租一定比买划算；高于这个数，再考虑自建。

1.2 三类计费模式的适配场景

主流算力云平台一般提供三种计费形态，理解它们的差异能省下不少钱。

第一种是按量计费，开一个小时算一个小时，关机就停。这是最灵活也最常用的模式，适合实验期、调试期、不确定要跑多久的场景。价格最高，但风险最低。

第二种是长周期包用，按周或按月锁定一张卡。单价通常比按量低三到五成，适合已经确定要连续跑几天甚至几周的确定性任务。判断依据是：如果你的预计连续占用时间超过包用周期的 60%，包用就比按量划算。低于这个比例就是在为闲置付费。

第三种是闲时或竞价型实例，平台把空闲资源以折扣价放出，代价是可能被随时回收。这类实例适合两类任务：可以频繁保存断点、随时中断随时续跑的长时间训练；以及本来就短平快的批处理任务。价格能压到按量的三到五折，但对工程习惯要求高——你必须把 checkpoint 机制做扎实，否则被回收一次就白跑。

实际操作里我常用的组合是：调试和写代码阶段用最低配的按量实例甚至无卡模式；小规模验证用按量；确认超参没问题、要跑正式训练了，切到闲时实例并开好自动存档。

1.3 挑平台要看的五个硬指标

市面上算力平台不少，宣传页都在讲卡多便宜，但真正影响体验的是另外几个维度。

卡型齐全度排第一。你需要的是“能按任务挑卡”，而不是“只有一种卡爱要不要”。小模型调参用 24G 显存的消费卡就够，真要跑大模型全量微调才需要 80G 的专业卡，中间还有 40G、48G 档位。卡型越全，你越不会为用不上的显存付费。

镜像生态排第二。一个平台如果预置了大量开箱即用的深度学习镜像，你能省掉半天配环境的时间。自己从裸系统装 CUDA、cuDNN、PyTorch 那一套，光是版本对齐就够折腾的。

存储策略排第三。要看清楚系统盘给多大、数据盘怎么计费、关机后数据盘是否继续收费、有没有对象存储做冷备。这一项直接决定你的长期持有成本。

计费粒度排第四。按秒计费和按小时计费，在频繁开关机的调试场景下差距很明显。同时要看清楚“关机”和“停止”是不是一回事。

网络与端口排第五。能不能开自定义端口、能不能从公网直连、上传下载走的是内网还是公网、有没有流量限制。训练数据动辄几十上百 G，上传速度能直接决定你一天能不能开工。

2. 账号、充值与计费规则的前置动作

2.1 注册认证与首次充值的节奏

注册流程各家大同小异，一般需要手机号加实名认证。这里提醒一句：实名信息一旦绑定不好改，如果是团队共用账号，最好一开始就用负责人信息注册，避免后面发票、权限、余额归属扯皮。

充值策略上，我的建议是小额多次，不要一次性充大额。原因有三个：一是新平台你需要先验证网络质量、卡的实际可用性、客服响应速度，充多了万一不合适退起来麻烦；二是余额放在平台里没有收益，还容易被“反正有钱”的心理带着乱开机；三是很多平台有首充优惠或代金券，分批次充值往往能薅到更多。

第一笔充值建议控制在够跑十到二十个小时的量。够你把整个流程走通一遍，又不至于肉疼。

2.2 必须搞清楚的三个计费概念

这块是新手最容易吃亏的地方，我见过太多人以为关了机就不花钱，结果月底一看账单傻眼。

概念一：关机不等于停止计费。大多数平台的规则是：实例关机后，GPU 计算资源释放、不再收算力费，但数据盘仍然占用存储、继续按容量收费。也就是说你的实例虽然“关着”，每天仍然在产生几毛到几块的存储费用。这本身是合理的（人家确实给你留了盘），但你要知道它存在。

概念二：无卡模式是省钱神器。一些平台提供“无卡模式开机”——实例能启动、能 SSH 进去、能装包、能改代码、能传数据，但没有分配 GPU，费用极低（通常是按量价格的几十分之一）。这个功能对调试阶段太有用了：写代码、配环境、下模型权重这些完全不烧 GPU 的活儿，全在无卡模式下干完，真正要跑训练了再切回有卡模式。

概念三：数据盘容量是可以选的。创建实例时通常会让你选数据盘大小，从几十 G 到几百 G。选大了每月多花钱，选小了中途扩容麻烦。经验值：纯代码和小数据集给 50G 够用；要放模型权重和中等数据集给 100G；要处理图像、视频、多模态数据集直接上 200G 以上。

2.3 余额告警与自动关机

这条是保命的：一定要把余额告警开起来，并且设置一个心理阈值。原因很现实——训练跑起来之后人是会松懈的，尤其是挂了 overnight 的任务，第二天醒来发现余额被扣穿、实例被强制停止、checkpoint 没存下来，那种感觉相当难受。

我自己的习惯是留出至少够跑 2 倍预计时长的余额，同时给训练脚本加超时保护：预估总时长的 1.2 倍还没跑完就自动保存退出。双保险。

3. GPU 卡型怎么选：从显存倒推而不是从型号排名倒推

3.1 显存是硬门槛，算力是软约束

新手选卡最常见的错误是盯着“哪个卡算力高”或者“哪个卡新”。正确的顺序完全相反：先用显存卡死下限，再在满足显存的卡里挑性价比最高的。

为什么显存是硬门槛？因为算力不够你只是慢，显存不够是直接跑不起来，报一个 CUDA out of memory 就把你挡在门外了，没有任何回旋余地（除非改模型结构或降精度，那可能影响效果）。

显存需求怎么估？分推理和训练两种情况。

推理的粗略公式：显存 ≈ 参数量 × 每参数字节数 × 1.3 到 1.6 的冗余系数。冗余来自 KV cache、中间激活、框架本身的显存池。比如一个 7B 参数模型用 FP16 推理，权重是 7×2 = 14G，加上冗余大概 18 到 22G，一张 24G 的卡刚刚好，序列长度拉到 8K 以上就要 40G 起了。如果做 4bit 量化，权重降到 3.5G 左右，一张 12G 的卡也能跑起来。

训练的公式复杂一些。全量微调用 Adam 优化器时，每个参数大约要占 16 到 20 字节：FP16 权重 2 字节、FP16 梯度 2 字节、FP32 主权重 4 字节、Adam 的一阶动量 4 字节、二阶动量 4 字节，合计 16 字节，再算上激活值就更多。所以一个 7B 模型全量微调，光优化器状态和权重就要 112G 以上，单卡根本放不下，必须多卡加 ZeRO 之类的分片策略。

而 LoRA 这类参数高效微调就友好得多，冻结的主干不存梯度和优化器状态，每参数只占 2 到 4 字节。同样 7B 模型做 LoRA，序列长度 2048、batch 为 1 的情况下，单张 24G 的卡可以跑，24G 到 48G 是比较舒服的区间。

3.2 常见卡型的定位对比

下面这张表是我按实际使用感受整理的，价格是写作时的常见区间，务必以平台实时计价页为准，各家差异和促销活动影响很大。

有一点要说清楚：80G 卡的单位算力单价其实比 24G 卡低，也就是说同样跑一个能塞进 24G 的任务，用 80G 卡是浪费；但跑一个需要多卡 24G 才能完成的任务，单张 80G 往往更快更省。选卡的本质是“让显存利用率尽可能接近 100%”。

3.3 训练、推理、生成三类任务的选卡逻辑

训练任务看的是显存和卡间互联。单卡能装下就优先单卡，因为多卡并行的通信开销在小任务上经常吃掉并行收益。非要上多卡，优先选同机内 NVLink 互联的方案，跨机通信在普通以太网下损耗很明显。

推理任务看的是显存带宽，不是纯算力。大模型推理是典型的访存密集型负载，每生成一个 token 都要把权重从显存读一遍。这时候高带宽的卡优势会非常明显，标称算力高但带宽一般的卡反而不占优。这是很多人选卡时的盲区。

图像生成类任务相对均衡，显存是第一约束（分辨率和 batch 直接吃显存），算力影响出图速度。24G 的卡在这个场景下性价比极高，除非要做视频生成或者超大分辨率，否则没必要上专业卡。

3.4 多卡不是越多越好

我见过有人一上来就开八卡，结果跑的模型连单卡都塞不满，纯属烧钱。多卡并行的收益曲线是严重递减的：两张卡理想情况 1.8 倍加速，四张卡可能只有 3 倍，八卡能到 4.5 倍就不错了，具体取决于模型大小和并行策略。

判断要不要上多卡的简单方法：如果单卡能跑，但你觉得太慢，那就先优化单卡效率（混合精度、梯度累积换大 batch、数据加载并行、算子融合）。这些优化往往能带来 1.5 到 2 倍的提升，而且不额外花钱。等单卡优化到瓶颈了，再考虑加卡。

4. 创建实例的完整实操：镜像、存储、端口、开机

4.1 镜像怎么选才不返工

镜像是整个流程里最影响后续体验的一步。平台一般提供三类：基础系统镜像（干净的 Ubuntu 加驱动）、框架镜像（预装 CUDA 和 PyTorch 等）、社区镜像（其他用户保存的完整环境）。

新手直接用框架镜像，挑一个 CUDA 版本和 PyTorch 版本符合你代码要求的。判断方法：看你的项目依赖里 torch 的版本，然后去查这个 torch 版本官方编译时用的 CUDA 版本，尽量对齐。版本错配的典型症状是装某些需要编译的扩展包时报错，或者运行时报 “no kernel image is available for execution on the device”。

社区镜像要谨慎。好处是可能已经装好了你要的一切，开机即用；坏处是你不知道里面被改过什么，可能有残留的环境变量、可能有奇怪的 pip 源配置、可能预装了一堆用不上的包把系统盘占满。用之前先pip list和df -h看一眼。

有长期项目的话，最终一定要沉淀成自己的自定义镜像。流程是：开一台实例，把环境和代码都配好，验证能跑通，然后在控制台保存为自定义镜像。下次开新实例直接选这个镜像，五分钟进入工作状态。这个习惯能省掉你未来每一次重装环境的时间。

4.2 系统盘和数据盘的规划原则

系统盘和数据盘的分工要明确：系统盘放环境，数据盘放一切会变大的东西。

代码、配置、conda 环境放系统盘（默认位置就行）；数据集、模型权重、训练日志、checkpoint 全部放数据盘。原因很实在：系统盘容量有限（一般 30 到 50G），被数据集塞满之后系统会出各种诡异问题，而且系统盘扩容往往要重建实例；数据盘是独立挂载的，容量可以选大，清理也方便。

一个具体做法：开机后第一件事是建目录结构，比如/root/autodl-tmp是很多平台约定的数据盘挂载点，然后ln -s把常用的数据路径软链过去，避免代码里到处改路径。

4.3 端口与网络配置

平台一般会给你一个 SSH 端口和一个 JupyterLab 端口。SSH 用来做终端操作和文件传输，JupyterLab 用来做交互式调试和看图片结果。

如果要做 Web 演示（比如起一个 Gradio 界面看模型效果），需要用平台提供的“自定义服务”功能把内部端口映射出去。注意这类映射通常有有效期和访问限制，不适合做正式对外服务，自己看效果足够了。

另外一个常被忽略的点：下载外部资源的速度。有些平台对公网出口有限速，下模型权重会非常慢。解决办法是优先用平台内网的对象存储或者预置的模型库，实在要从公网下就挂后台慢慢跑，别在前台干等。

5. 连上实例后的头三十分钟：环境自检与第一跑

5.1 三种连接方式的选择

SSH 终端是最常用的，适合跑训练脚本、装包、看日志。命令形式大致是ssh -p <端口> root@<平台给的地址>，首次连接要确认指纹。建议配置好 SSH 免密登录，把公钥传到实例上，后面传文件、开多个终端都方便。

JupyterLab适合探索性工作：看数据样本长什么样、画训练曲线、调试单个函数的输出。它的文件浏览器也很好用，可以直接上传下载小文件。

编辑器远程连接（VS Code 这类）适合写代码。通过 SSH 连上去之后，本地编辑、远端运行，体验接近本地开发。要注意的是这类连接会占一定内存，实例配置很低的时候可能卡。

三种方式可以同时用，不冲突。我的习惯是：编辑器和 JupyterLab 常开，SSH 用来跑长任务。

5.2 开机必跑的自检清单

连上之后别急着跑代码，先花两分钟做这几项检查，能提前发现 90% 的环境问题。

# 1. 确认 GPU 被正确识别，看型号和显存 nvidia-smi # 2. 确认驱动和 CUDA 版本 nvcc --version # 3. 确认 PyTorch 能看到 GPU python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.device_count())" # 4. 确认磁盘空间和挂载点 df -h # 5. 确认内存大小 free -h

重点看三件事：torch.cuda.is_available()必须是 True；df -h里数据盘挂载点有充足空间；free -h里的系统内存别太小（有些平台显存给得足但内存抠门，数据加载会成为瓶颈）。

注意：如果torch.cuda.is_available()返回 False，九成是镜像里的 torch 是 CPU 版本，或者 CUDA 版本和驱动不匹配。别急着怀疑硬件，先pip list | grep torch看装的是不是+cu结尾的版本。

5.3 数据上传的几种姿势与速度对比

数据集上传是最耗时的环节，方法选对了能省好几个小时。

小文件（几百 M 以内）：直接用 JupyterLab 的拖拽上传，或者编辑器的拖拽，最省事。

中等文件（几个 G）：用scp或rsync从本地推。rsync的好处是支持断点续传和增量同步，命令大致是：

rsync -avP --partial -e "ssh -p <端口>" ./local_data/ root@<地址>:/root/autodl-tmp/data/

-P会显示进度并且允许断点续传，网络不稳的时候这个参数能救命。

大文件（几十 G 以上）：强烈建议先压缩再传，图片数据集打成 tar 包体积能小一半以上，而且传一个大文件比传十万个小文件快得多（小文件的问题是每个文件都要建连接、确认、关闭，开销巨大）。传到之后再在实例上解压。

最佳实践：如果平台提供对象存储或者网盘类功能，优先走那条路。通常是内网传输，速度快且不计流量。把数据先传到对象存储，再从实例内网拉取，比从家里宽带上行快一个数量级。

5.4 先跑通 baseline 再动手改代码

这条经验值一整个章节：不要在环境还没验证的情况下直接跑你的完整训练。

正确顺序是：先用一个极小的数据集（比如 100 条样本）跑 10 到 20 个 step，确认整个流程能走通——数据加载不报错、前向反向不报错、loss 有变化、checkpoint 能存能读。这个过程五分钟就够，但能拦住大量低级错误。

然后再上完整数据。同时先用小模型或小配置跑一轮，比如把层数减半、把 max_length 减半，跑通之后再放大。这个习惯能让你在花大钱之前先发现逻辑问题。

6. 成本控制实战：把每小时单价真正压下来

6.1 无卡模式：调试阶段的白嫖姿势

前面提过，无卡模式下实例照常运行但不占 GPU，费用极低。这个功能的价值在于把“非计算时间”从计费里剥离出去。

具体怎么用：开机先用无卡模式，把代码同步上去、装依赖、下载模型权重（这一步可能就要一两个小时）、跑通数据处理脚本、用小样本验证前向逻辑。这些都做完，确认下一步就是纯训练了，关机、切有卡模式、开机、启动训练。

一个真实的对比：如果全程用有卡模式做这些准备工作，按 24G 卡算，两小时大概几块钱；用无卡模式，成本是几毛。单次看着不多，但一个月下来做十几次就是几十上百块的差距。

6.2 训练时长怎么预估才算得准

算钱的公式很简单：总费用 ≈ 单价 × 训练小时数 × 试错系数。难点在训练小时数怎么估。

不要凭感觉拍。可靠的做法是实测外推：跑 200 个 step，掐表算出每 step 的平均耗时，然后乘以总 step 数。

举个例子。假设你的数据集 5 万条，batch size 8，跑 3 个 epoch，总 step 数 = 50000 / 8 × 3 ≈ 18750。实测每 step 0.9 秒，总时长 = 18750 × 0.9 / 3600 ≈ 4.7 小时。假设卡的单位价格是每小时 X 元，算力成本就是 4.7X。

但别忘了试错系数。第一次跑总要出点问题：显存炸了要调 batch、loss 不收敛要调学习率、数据格式不对要重跑。经验值取 1.5 到 2.5，首次跑新任务取 2.5，跑熟了取 1.5。

还要加上数据上传时间和环境配置时间，这部分如果用的是无卡模式，成本可以忽略，但时间是实打实要花的。

把这几项加起来，你就能在开机之前知道自己大概要花多少钱。先算钱再开机，这个顺序很重要。

6.3 中断保护：checkpoint 是保命符

如果用的是按量实例，中断风险低；如果用闲时实例，必须把 checkpoint 做扎实。

具体要求：每隔 N 个 step 存一次模型和优化器状态，N 的取值让单次保存间隔在 15 到 30 分钟；保存到数据盘而不是系统盘；文件名带 step 编号，别覆盖；保留最近 3 个 checkpoint，防的是保存过程中被中断导致文件损坏。

# 简化示意：定期存档的核心逻辑 if global_step % save_every == 0: ckpt = { "step": global_step, "model": model.state_dict(), "optimizer": optimizer.state_dict(), "scheduler": scheduler.state_dict(), "loss": last_loss, } torch.save(ckpt, f"/root/autodl-tmp/ckpt/step_{global_step}.pt") # 只保留最近 3 个，避免磁盘爆掉 cleanup_old_checkpoints(keep=3)

另外建议训练日志重定向到文件并定期看尾部：

nohup python train.py > /root/autodl-tmp/train.log 2>&1 & tail -f /root/autodl-tmp/train.log

用nohup或者tmux的目的是防止 SSH 断连把训练进程带走。这一点在弱网环境下特别关键——我吃过一次亏，笔记本合盖断网，前台跑的六个小时训练直接没了。

6.4 实例冻结与镜像保存的时机

任务告一段落但还没完全结束时，不要急着删实例。多数平台支持把实例保存成镜像或者做某种形式的冻结，把当前环境完整保留下来，下次直接恢复。

判断标准：如果重建环境的成本超过 20 分钟，就该保存镜像。装了特殊依赖、编了自定义算子、配了复杂的推理环境，这些都值得存。如果只是标准镜像加几行 pip install，直接删掉更划算，别为存储付费。

7. 常见问题与排查速查表

8. 我在实际使用里攒下的几条硬经验

先说一个反直觉的：先花时间挑卡型，不如先花时间写一个能跑通的小脚本。我见过太多人卡在选卡、比价、看评测上耗掉一整天，代码一行没动。实际上你只需要知道自己的模型大概要多少显存，剩下的都可以边跑边调。有一台 24G 的卡在手，绝大部分个人项目都能起步，卡不合适随时换，租用的价值就在这个“随时”上。

第二条是关于数据管理的。永远假设实例随时会消失。重要的数据集、训练好的权重、关键的日志，都要有第二个落脚点——要么同步回本地，要么放到平台的对象存储里。不要觉得“我还没删实例呢”。账号余额告警、平台维护、误操作，任何一种情况都可能让你丢掉数据盘。

第三条是环境版本。同一台实例上别装两套不同版本的 CUDA，这是各种诡异报错的源头。换框架版本就重开实例，或者干脆保存新镜像。为了省几分钟去动系统级依赖，后面可能要花几个小时排查。

第四条是关于效率的：训练跑起来之后，别一直盯着 loss 看。用tail -f偶尔扫一眼日志，或者挂个监控把曲线画出来就够了。真正需要你关注的是：跑完一轮之后，loss 曲线的形状对不对、验证集指标有没有提升、显存占用有没有随训练推进缓慢上涨（内存泄漏的典型信号）。

最后一条最实用：每次开机前，先问自己三个问题——我这次要做什么？预计多久？怎么判断成功？三个问题答不上来就先别开机。算力云最贵的地方从来不是单价，是你开了机却不知道要干什么的那几个小时。