最近好几个朋友都跑来跟我吐槽：实验室的卡只有6G显存，跑个预训练语言模型都要看它脸色，再往上做点生成式模型的微调，内存和显存直接爆掉。学生党想认真做深度学习模型训练，最现实的路径还真不是攒钱买卡，而是学会云算力租借，把SSH连接这套基本功练熟。这篇文章我就以“学生做深度学习模型训练”为场景，从选平台、省钱、配密钥、免密登录、传代码、挂训练任务，一条龙讲清楚，把那些踩过的坑和规避方式一次性说完。这篇文章适合谁？适合本地没卡或者显存不够、又不想靠抢实验室机器度日的学生，也适合刚入门分布式训练但还不会在远端Linux环境里生存的新手。你不需要有很强的运维基础，只要按着下面的步骤走，基本能在半小时内把一台云端GPU机器变成你的专属训练机。1. 先想明白一点：你是需要买卡，还是需要租算力？很多人一上来就纠结要不要买个显卡自己跑，我特别理解，因为读研前我也觉得买一张卡是一劳永逸的事。但现实不是这样。你得先搞清楚本地机器的瓶颈到底在哪，才知道云算力对你来说到底值不值。1.1 本地机器的三个真正瓶颈第一个瓶颈是显存。现在的深度学习模型对显存的要求几乎没有上限，单卡16G在训练一个稍微像样的Transformer时都紧巴巴。显存不够的时候，只能缩batch size，batch太小又会导致训练不稳定，BatchNorm失效，loss曲线像心跳。这不是靠堆CPU或者内存能解决的。第二个瓶颈是算力峰值和持续供电。学校实验室的桌面机器，散热和电源设计并不适合长时间满载跑GPU。我自己见过不少案例：显卡明明不错，跑两天之后温度顶到90度，频率下降，训练速度反而比低端卡还慢。这属于环境问题，不是卡的问题。第三个瓶颈是环境隔离。本地机器上装了一堆CUDA、驱动、依赖，每个人都有自己的环境需求，改一次全局版本可能把别人跑得好好的代码搞崩。云端机器是按需创建的，环境随便折腾，坏了就删掉重建，这一点对做实验的学生来说实在太舒服了。1.2 云算力适合哪些项目，不适合哪些项目适合用云算力的场景很明确：第一，你的任务需要单卡显存超过本机，比如跑大模型微调、做长文本训练；第二，你需要在多个GPU上做并行实验，比如同一份代码分别验证几个不同策略，云上开三台卡比在本地轮流跑快得多；第三，比赛、毕设、论文返修有明确截止时间，需要在短时间内把算力拉满。不适合的场景也很多。如果你每天都在做小规模的数据清洗、小模型调参、debug代码，那流量花费和上传下载的时间成本偏高，不如在本地跑。另外如果你的数据非常敏感，不适合传到第三方平台，那云算力这个选项从一开始就不该考虑。云算力解决的是算力问题，不是数据安全和个人隐私问题。1.3 一台GPU按小时租，到底比买卡省在哪有人会算一笔账：一张主流显卡一万多，云上按小时租大卡一小时可能就要十几块钱，跑两百个小时就够买张卡了，为什么不买？这个账不能这么算。买卡是一次性付出一万五，还不算配套的电源、机箱、散热，如果你要上两张卡做分布式训练，还得考虑主板通道和带宽，开销直接翻倍。云算力按量付费的好处是弹性：你只在真正训练的时候付费，写代码、看论文、调参的时候一分钱不花。平时用一张便宜的卡或者直接用CPU验证逻辑，确认代码没毛病之后再开昂贵的大卡跑正式训练，综合成本往往只有买卡的十分之一。而且很多学生毕业之后根本用不上那张高价卡，二手转卖折价又非常厉害，租算力等于把硬件折旧风险转嫁给了平台。2. 云算力平台怎么选：GPU型号、计费模式与隐藏费用平台选型不复杂，但要学会看穿文字游戏。市面上能租GPU算力的渠道大致可以分为通用云GPU实例、专业算力租借平台、还有部分免费/教育算力计划。先说结论：学生自用，优先选按小时计费、支持镜像保存、方便SSH直连的平台，不要只看网页上写着“4090/3090”就觉得是白菜价。2.1 三种平台类型怎么区分通用云厂商的性能和稳定性最好，但价格往往偏高，适合对网络稳定性和数据可靠性要求高的任务。专业算力租借平台更贴近学生场景，通常提供一个网页控制台，里面有现成的深度学习镜像，选了GPU型号和镜像就能开机，价格更便宜，但网络、存储和共享状态需要自己多留个心眼。免费教育计划适合入门体验，但算力规模、运行时长和排队机制都有限制，用来跑竞赛可以，用来做固定周期的实验则不太靠谱。我的建议是不要一上来就囤一堆平台的券，先把一个平台用熟。因为你之后所有绕坑经验都跟平台的控制台界面和文件路径有关，换来换去只会增加学习成本。2.2 GPU型号选择的“显存优先”逻辑选什么型号的卡，先看你的训练任务对显存的需求，而不是只看算力表。常见型号里，显存从16G到80G不等。如果你只是做常规的图片分类、目标检测，16G到24G足够；如果你要做大模型的指令微调或者长序列Transformer，建议直接上40G以上显存的卡，免得OOM之后换机器浪费时间。要注意的是，显存和算力并不完全正相关。有的卡参数很猛，但显存带宽受限，跑大数据集时会成为瓶颈。对单机单卡场景，你需要关心的是：显存够不够、是否支持你需要的精度格式（FP16/BF16）、驱动版本和CUDA版本是否容易适配。你不用追求双卡性能翻倍，因为消费级卡互联带宽不够，双卡训练可能只比单卡快一点，但显存翻倍这件事很值。这些信息在租用页面的详情里都能看到。2.3 计费模式：按量、包机时和抢占式怎么搭配大多数平台提供三种计费模式：按量计费、包时段/包天、抢占式。按量计费适合不确定要跑多久的情况，跑完就释放。包时段适合你已经确定要连续训练三天，价格通常能打七八折。抢占式算力价格最低，但可能随时被收回，适合可以容忍中断的实验，比如你做了checkpoint，随时能恢复训练。我个人的搭配策略是：调参和debug用最小的按量实例，正式训练用包时段或者便宜时段，跑大量重复seed实验时用抢占式。设置好每隔几步保存一次checkpoint，这样即使机器被收回，也可以从最近一次保存点继续，不至于白跑。2.4 隐藏费用：存储、公网IP和快照最容易超支很多学生看到GPU价格便宜就下单，最后账单出来发现超支了，超支部分往往来自三个地方。第一是存储费用，平台给你的系统盘可能只有30G，但你的数据集和conda环境很容易超过，扩展数据盘是按容量和时长收费的。第二是公网IP费用，有些平台不赠送公网IP，或者只给一个临时IP，你反复开关机可能会导致IP变化，而保留一个固定IP是按月额外收费的。第三是快照和镜像费用，你保存一个自定义镜像，平台会按镜像占用的存储空间收费，保存得越多越贵。所以租机器之前必须看清计费文档里的三个数字：GPU单价、存储单价、公网IP单价。再有一个容易被忽略的细节是“整点计费”。有些平台只要开机不足一小时也按一小时算，频繁开关机反而浪费钱，建议一个训练阶段稳定跑满至少半小时以上再关机释放。3. SSH连接从零到顺手：密钥配置、连接命令与防掉线云GPU机器不像你在教室开个软件敲代码，它本质是一台千万里之外的Linux服务器，你需要通过SSH连过去进行操作。学会SSH是这个流程里最重要的一项基本功，它比模型本身更值得你花半小时掌握。3.1 先花两分钟做一对密钥很多平台在创建实例时会让你选择登录方式，最常见的是密码登录和密钥登录。强烈建议选密钥方式。在你本地电脑终端执行一条命令：ssh-keygen -t ed25519 -C "your_comment"一路回车，就会在~/.ssh/目录下生成两个文件：私钥id_ed25519和公钥id_ed25519.pub。私钥就好比你的家门钥匙，绝对不能外传；公钥是锁，交给服务器。创建实例时，平台通常会要求你粘贴公钥内容，你把id_ed25519.pub里的内容复制进控制台即可。如果你已经在服务器上设了密码登录，也可以手动把公钥追加到服务器的~/.ssh/authorized_keys文件里，然后重启SSH服务。第一次配置密钥之后，一定要记得把本机私钥权限改成600，否则SSH会嫌弃权限太开放而拒绝使用：chmod 600 ~/.ssh/id_ed255193.2 第一次登录，逐参数看懂这条命令拿到云服务器的公网IP、端口和用户之后，你的第一条SSH登录命令大概是这样的：ssh -i ~/.ssh/id_ed25519 root@8.8.8.8 -p 22-i指定私钥路径，root是登录用户，8.8.8.8换成你的机器IP，-p 22是SSH端口。有些平台不是默认22端口，比如自定义端口22022，那就要改这个数字。第一次连接很大概率会提示Host key verification failed，这是因为本地还没有保存这台服务器的主机指纹。常见的处理方式是执行一次ssh-keygen -R 8.8.8.8清掉旧指纹，再重新连接，然后输入yes确认指纹。如果提示Permission denied (publickey,password)，一般不是服务器坏了，而是你的私钥路径不对，或公钥没有正确写入服务器的authorized_keys。逐个排查，别一上来就怀疑是平台的问题。3.3 用SSH config管理多台云机器如果你只租一台机器，直接敲长命令还过得去。但学生党经常是A100一台、便宜卡一台、还要连实验室工作站，每台机器都记IP和密钥路径谁都得疯。配置一个~/.ssh/config文件，问题直接解决。在本地~/.ssh/config里写：Host mygpu HostName 8.8.8.8 User root Port 22 IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 30 ServerAliveCountMax 3保存之后，以后登录只需要输入ssh mygpu，再也不用记那一长串。ServerAliveInterval 30和ServerAliveCountMax 3的意思是每30秒发一次心跳包，连续3次没有回应才断开，能有效避免你挂着终端去吃饭，回来发现SSH已经断开的情况。我还会在~/.ssh/config里给不同项目设置不同的Host，比如训练、评估、实验，一目了然。这个文件本身是纯文本，你可以备份到自己的git私有仓库里，换电脑时直接恢复。3.4 训练不会因SSH断开而中断：tmux的保命用法很多人第一次用云GPU都会发生一个惨案：本地SSH窗口不小心关掉，远程训练进程跟着消失，白跑几个小时。SSH断开导致终端程序收到挂断信号退出，这是新手最容易踩的坑。解决办法是用tmux在远端开一个会话，把训练命令放进去跑，SSH断开也不影响。登录服务器之后执行：tmux new -s train你会进入一个独立的终端会话，在里面运行你的训练命令。然后按Ctrl+b，再按d，这个会话就会回到后台，但训练程序不会停止。下次登录服务器，执行：tmux attach -t train就能重新看到训练进程的输出。如果训练太久想多个任务并行，可以开多个不同名字的会话，比如train、data_process、monitor。如果你用的平台没有预装tmux，先apt update && apt install -y tmux装上再开跑。也有一些同学喜欢用nohup，但我觉得tmux的交互体验好得多，尤其可以随时切回来看日志，强烈推荐。4. 本地与云端的数据流转：文件传输、端口转发和远程开发服务器连上之后，你马上会面对一个现实问题：本地代码和数据怎么放到云端，训练日志和权重怎么弄回来。这个环节看似工具琐碎，效率差距却非常大。4.1 传文件优先用rsync，别用scp硬传很多人一开始用scp传文件，在小文件场景下没什么问题，传大数据集时几次中断会让你怀疑人生。scp不支持断点续传，中断就得重来；rsync支持增量传输，尤其是代码改了几行，只想把改动同步上去，rsync会是更好的选择。常用命令：rsync -avz --progress -e "ssh -i ~/.ssh/id_ed25519" ./local_dir/ mygpu:/workspace/dir/-a是归档模式，保留权限和时间戳；-v显示过程；-z传输时压缩。后面-e指定使用SSH并带上私钥。如果你不想每次输密码，前面配好SSH密钥和~/.ssh/config之后就一步到位。有一点要提醒：往云服务器传大量数据会消耗公网流量，而流量通常是额外计费的。所以先把本地数据压缩成单个压缩包，传到服务器后解压，比传一堆零散小文件更省钱，也更快。4.2 一条SSH命令把Jupyter和TensorBoard拉到本地你在云端跑实验，有时候需要打开Jupyter Notebook或者TensorBoard看看曲线。如果直接在云端浏览器端口开放，你得在安全组/防火墙里开一个公网端口，既不安全又容易被扫描。其实不用那么麻烦，SSH端口转发就可以把远端服务安全地映射到本地。假设云端Jupyter跑在8888端口，本地想用8899端口访问，执行：ssh -L 8899:localhost:8888 -N -f mygpu-L表示把远端localhost:8888映射到本地8899，-N不执行远程命令，-f放到后台。然后打开本地浏览器访问http://localhost:8899，就跟本地开Jupyter一样。TensorBoard默认端口6006，命令改成ssh -L 16006:localhost:6006 -N -f mygpu，访问http://localhost:16006。这种方式的好处在于是加密流量，而且没有把服务暴露到公网，只有你能通过SSH隧道访问，安全性高得多。注意本地端口不要和已有服务冲突，如果提示地址已被占用，换个本地端口就行。4.3 VS Code Remote-SSH：把云端当本地开发机如果你习惯在本地写代码，建议装一个VS Code，使用Remote-SSH扩展。装好扩展后，按Ctrl+Shift+P输入Remote-SSH: Connect to Host...，选择你配置好的mygpu，VS Code就会重新连接到远程服务器，左侧文件树直接变成远程目录，终端也是远端终端，还可以直接调试运行代码。这个体验最关键的一点是，插件能让你保留本地编辑器手感，但实际代码和数据都在云端。你直接打开云端/workspace/train.py修改并运行，省去我每次用rsync同步的麻烦。要注意：Remote-SSH首次连接会在远端下载VS Code Server，如果你的服务器网络不好或者存储空间太小，可能失败。可以检查/root/.vscode-server目录是否有足够空间，必要时清理一下旧版本。另外，远程安装插件时，Python和相关语言插件要安装在SSH远程端，不是本地端，否则无法生效。4.4 我常用的git+rsync工作流我不太建议把整个训练过程完全依赖Remote-SSH，因为训练中的大数据集同步和模型权重下载，最终还是要回到命令行工具。我的固定流程是这样：代码用git管理，在本地开发，每次改动后git commit推到一个私有仓库；在云服务器上git pull拉下来。这样代码版本清楚，回滚也方便。大数据集和模型权重这类不适合进git的大文件，用一个统一的sync_data.sh脚本通过rsync同步。好处是：换实例、换平台时，我在服务器上只需要重新clone一次代码，数据用rsync续传即可。这套流程在学生项目中特别适合，因为你经常需要换一台更便宜的机器继续实验，或者把现有机器释放掉再开一台新的。5. 云端训练避开崩溃现场：显存、多卡与数据存储连接和传数只是准备工作，真正让人崩溃的往往是训练过程中的事故。云端环境既不是你熟悉的本地环境，也不是实验室那台别人维护好的机器，很多问题需要你自己处理。5.1 刚租来的机器，先做这三件事再跑训练第一件事是敲nvidia-smi，确认驱动状态和显卡型号是否跟下单页描述一致，顺便看显存有没有被别人占满。如果你买的是整机独占，一般不会有人抢，但如果是共享实例，显存在开机时被其他容器占住的情况并不少见。第二件事是df -h，看清楚数据盘挂载在哪里。很多平台的镜像盘和二三十G的小系统盘是分开的，数据盘可能叫/data或者/workspace，你如果不看，很容易把数据集写到系统盘，很快塞满导致系统异常。第三件事是检查Python版本和包管理。建议直接创建一个干净的虚拟环境，按项目生成的requirements.txt安装依赖。别看平台镜像里预装了一堆库，版本组合很可能跟你的代码冲突。把这几件事在训练前做完，后面能省掉很多排查时间。5.2 OOM、训练卡死和版本不匹配的排查OOM（显存不足）是云端新手最常见的问题。它不一定是你的模型太大，也可能是batch size设高了，或者PyTorch在默认情况下给每个算子预留了较多显存。解决路径是：先减半batch size，看能否跑通；如果不行，把输入pin_memory、num_workers调低，减小数据加载峰值；再不行，用混合精度训练，开启和微调torch.cuda.amp.autocast和GradScaler。对Transformer类模型还可以开启梯度检查点，用一部分计算换显存。训练卡死不一定是死机。如果CPU数据加载太慢，GPU会一直在等待，看起来像卡住，实际是数据没跟上。这种问题的特征是GPU利用率很低，CPU利用率却很高。解决办法是调大num_workers、把数据放到更快的本地盘，而不是在训练循环里做耗时的数据预处理。版本不匹配的坑很隐蔽。云端驱动不同，PyTorch需要的CUDA版本也不同。你在本地用CPU跑得好好的代码，放到云端直接用pip install torch装最新版，很可能会遇到CUDA driver version is insufficient。正确做法是nvidia-smi看驱动支持的最高CUDA版本，再去PyTorch官网选对应CUDA版本的安装命令。5.3 多卡训练时最容易忽略的通信与数据问题学生做实验经常会尝试多卡并行。如果你在单机多卡上使用PyTorch DDP，启动命令通常是这样：torchrun --nproc_per_node=4 train.py --config config.yaml这里隐藏着一个问题：DDP需要所有进程能通过localhost通信，一般没问题；但如果你用的是机器上的多个进程，而不是多台机器，默认情况能跑通。如果你要跨两台云主机做分布式训练，那就要设置MASTER_ADDR、MASTER_PORT，并保证两台机器的数据目录和数据内容完全一致，这个复杂度明显更高，不建议新手一上来就尝试。多卡训练另一个常忽视的问题是数据加载的随机性。如果每个进程都用不同的随机种子或者数据增强采样方式，会导致数据分布不一致，训练结果不可复现。建议在主进程里统一设置随机种子，或在Dataset里用worker_init_fn来控制每个数据加载进程的随机状态。5.4 训练完先别关机：权重、日志和镜像都要留训练跑完，心情一激动容易直接关机释放实例。但云服务器的本地盘或临时盘在释放后会消失，你的权重文件如果没有另存，直接人间蒸发。所以训练结束后要养成三个动作：先把模型权重和日志rsync回本地或者上传到对象存储；再把重要的依赖环境保存成自定义镜像；最后才释放实例。保存镜像也有讲究。镜像会包含整个系统盘当前状态，如果系统盘里塞了很多无关缓存，镜像会又大又慢。建议在保存镜像之前清理缓存和临时文件，比如/tmp、pip cache、~/.cache等。镜像越小，下次开机越快，存储费用也越低。如果不想每次手动处理，可以在训练命令里嵌套一个自动关机的hook：python train.py && sudo poweroff。这样训练完成后会自动关机，但不会释放实例，数据和环境都保留着，等你确认结果后再手动操作释放。这个做法对我这样丢三落四的人特别有用。6. 学生党的成本控制纪律：把每块钱花在刀刃上最后聊聊钱。学生做实验没有无限预算，控制成本不是抠门，而是把省下来的钱花在真正需要的实验规模上。我自己见过不少同学在云算力上花了很多冤枉钱，其实都是小习惯问题。6.1 低成本训练的五种具体姿势第一，能用小卡就别开大卡。先在小显存卡上做参数规模缩小的smoke test，确认模型能正常收敛，再上大卡跑完整实验。第二，尽量用混合精度训练，显存占用大约能降三分之一，很多平台对FP16的训练速度还有额外加成。第三，抽空时段跑任务，很多平台在白天高峰和深夜闲时价格不同，训练任务不紧急的时候，把大任务安排在闲时能省一大截。第四，利用抢占式实例。这种实例大概率能省一半钱，代价是有可能被抢占。只要你把checkpoint保存频率调好，抢占就抢占，恢复训练也快。第五，不要同时开一堆机器跑相同实验。如果只是调超参，串行跑比并行开机器更省钱，也更利于复盘。6.2 自动关机和账单提醒设置成本控制最关键的一条：离开电脑前，设置好自动关机。我最常写的命令就是训练命令后面拼一个&& sudo shutdown -h +10，意思是训练成功结束后10分钟自动关机。这样即使你忘记手动释放，机器的计费也会很快停止。同时建议在云平台控制台开启费用告警和余额提醒。不要小看这个步骤，我见过不少同学余额突然变成负数，就是因为实验跑太久没注意。设置一个 “超过10元/20元就发邮件提醒” 的阈值，至少能让你在被账单吓到之前收到预警。6.3 省钱还要省时间：先小规模试跑再上大机器省时间往往比省钱更重要。我现在的习惯是，任何大实验都先在本地CPU或者小卡上跑两三百个step，确认数据加载、模型forward和loss计算都正常，再上云端大显卡。直接在云上调试代码是最贵的，因为调试阶段机器一直在跑，却没有产生有效实验结果。另外，云端跑长任务时，每隔一段时间就看一眼日志，不要等训练到一半再发现loss恒为NaN。如果发现异常，及时停掉、修改、重跑，而不是任由机器继续烧钱。最后分享一个我自己的小经验：把~/.ssh/config、rsync同步脚本、tmux常用命令和训练启动模板都整理成一个私有仓库。这样无论换机器、换平台还是借别人的电脑，我都能在五分钟内把远程训练环境重新搭起来。你在云算力上踩过的坑，其实大部分都是这种“环境搭建”层面的坑，把这些流程固化下来，训练本身反而会变成一件很轻松的事情。
最近好几个朋友都跑来跟我吐槽：实验室的卡只有6G显存，跑个预训练语言模型都要看它脸色，再往上做点生成式模型的微调，内存和显存直接爆掉。学生党想认真做深度学习模型训练，最现实的路径还真不是攒钱买卡，而是学会云算力租借，把SSH连接这套基本功练熟。这篇文章我就以“学生做深度学习模型训练”为场景，从选平台、省钱、配密钥、免密登录、传代码、挂训练任务，一条龙讲清楚，把那些踩过的坑和规避方式一次性说完。这篇文章适合谁？适合本地没卡或者显存不够、又不想靠抢实验室机器度日的学生，也适合刚入门分布式训练但还不会在远端Linux环境里生存的新手。你不需要有很强的运维基础，只要按着下面的步骤走，基本能在半小时内把一台云端GPU机器变成你的专属训练机。1. 先想明白一点：你是需要买卡，还是需要租算力？很多人一上来就纠结要不要买个显卡自己跑，我特别理解，因为读研前我也觉得买一张卡是一劳永逸的事。但现实不是这样。你得先搞清楚本地机器的瓶颈到底在哪，才知道云算力对你来说到底值不值。1.1 本地机器的三个真正瓶颈第一个瓶颈是显存。现在的深度学习模型对显存的要求几乎没有上限，单卡16G在训练一个稍微像样的Transformer时都紧巴巴。显存不够的时候，只能缩batch size，batch太小又会导致训练不稳定，BatchNorm失效，loss曲线像心跳。这不是靠堆CPU或者内存能解决的。第二个瓶颈是算力峰值和持续供电。学校实验室的桌面机器，散热和电源设计并不适合长时间满载跑GPU。我自己见过不少案例：显卡明明不错，跑两天之后温度顶到90度，频率下降，训练速度反而比低端卡还慢。这属于环境问题，不是卡的问题。第三个瓶颈是环境隔离。本地机器上装了一堆CUDA、驱动、依赖，每个人都有自己的环境需求，改一次全局版本可能把别人跑得好好的代码搞崩。云端机器是按需创建的，环境随便折腾，坏了就删掉重建，这一点对做实验的学生来说实在太舒服了。1.2 云算力适合哪些项目，不适合哪些项目适合用云算力的场景很明确：第一，你的任务需要单卡显存超过本机，比如跑大模型微调、做长文本训练；第二，你需要在多个GPU上做并行实验，比如同一份代码分别验证几个不同策略，云上开三台卡比在本地轮流跑快得多；第三，比赛、毕设、论文返修有明确截止时间，需要在短时间内把算力拉满。不适合的场景也很多。如果你每天都在做小规模的数据清洗、小模型调参、debug代码，那流量花费和上传下载的时间成本偏高，不如在本地跑。另外如果你的数据非常敏感，不适合传到第三方平台，那云算力这个选项从一开始就不该考虑。云算力解决的是算力问题，不是数据安全和个人隐私问题。1.3 一台GPU按小时租，到底比买卡省在哪有人会算一笔账：一张主流显卡一万多，云上按小时租大卡一小时可能就要十几块钱，跑两百个小时就够买张卡了，为什么不买？这个账不能这么算。买卡是一次性付出一万五，还不算配套的电源、机箱、散热，如果你要上两张卡做分布式训练，还得考虑主板通道和带宽，开销直接翻倍。云算力按量付费的好处是弹性：你只在真正训练的时候付费，写代码、看论文、调参的时候一分钱不花。平时用一张便宜的卡或者直接用CPU验证逻辑，确认代码没毛病之后再开昂贵的大卡跑正式训练，综合成本往往只有买卡的十分之一。而且很多学生毕业之后根本用不上那张高价卡，二手转卖折价又非常厉害，租算力等于把硬件折旧风险转嫁给了平台。2. 云算力平台怎么选：GPU型号、计费模式与隐藏费用平台选型不复杂，但要学会看穿文字游戏。市面上能租GPU算力的渠道大致可以分为通用云GPU实例、专业算力租借平台、还有部分免费/教育算力计划。先说结论：学生自用，优先选按小时计费、支持镜像保存、方便SSH直连的平台，不要只看网页上写着“4090/3090”就觉得是白菜价。2.1 三种平台类型怎么区分通用云厂商的性能和稳定性最好，但价格往往偏高，适合对网络稳定性和数据可靠性要求高的任务。专业算力租借平台更贴近学生场景，通常提供一个网页控制台，里面有现成的深度学习镜像，选了GPU型号和镜像就能开机，价格更便宜，但网络、存储和共享状态需要自己多留个心眼。免费教育计划适合入门体验，但算力规模、运行时长和排队机制都有限制，用来跑竞赛可以，用来做固定周期的实验则不太靠谱。我的建议是不要一上来就囤一堆平台的券，先把一个平台用熟。因为你之后所有绕坑经验都跟平台的控制台界面和文件路径有关，换来换去只会增加学习成本。2.2 GPU型号选择的“显存优先”逻辑选什么型号的卡，先看你的训练任务对显存的需求，而不是只看算力表。常见型号里，显存从16G到80G不等。如果你只是做常规的图片分类、目标检测，16G到24G足够；如果你要做大模型的指令微调或者长序列Transformer，建议直接上40G以上显存的卡，免得OOM之后换机器浪费时间。要注意的是，显存和算力并不完全正相关。有的卡参数很猛，但显存带宽受限，跑大数据集时会成为瓶颈。对单机单卡场景，你需要关心的是：显存够不够、是否支持你需要的精度格式（FP16/BF16）、驱动版本和CUDA版本是否容易适配。你不用追求双卡性能翻倍，因为消费级卡互联带宽不够，双卡训练可能只比单卡快一点，但显存翻倍这件事很值。这些信息在租用页面的详情里都能看到。2.3 计费模式：按量、包机时和抢占式怎么搭配大多数平台提供三种计费模式：按量计费、包时段/包天、抢占式。按量计费适合不确定要跑多久的情况，跑完就释放。包时段适合你已经确定要连续训练三天，价格通常能打七八折。抢占式算力价格最低，但可能随时被收回，适合可以容忍中断的实验，比如你做了checkpoint，随时能恢复训练。我个人的搭配策略是：调参和debug用最小的按量实例，正式训练用包时段或者便宜时段，跑大量重复seed实验时用抢占式。设置好每隔几步保存一次checkpoint，这样即使机器被收回，也可以从最近一次保存点继续，不至于白跑。2.4 隐藏费用：存储、公网IP和快照最容易超支很多学生看到GPU价格便宜就下单，最后账单出来发现超支了，超支部分往往来自三个地方。第一是存储费用，平台给你的系统盘可能只有30G，但你的数据集和conda环境很容易超过，扩展数据盘是按容量和时长收费的。第二是公网IP费用，有些平台不赠送公网IP，或者只给一个临时IP，你反复开关机可能会导致IP变化，而保留一个固定IP是按月额外收费的。第三是快照和镜像费用，你保存一个自定义镜像，平台会按镜像占用的存储空间收费，保存得越多越贵。所以租机器之前必须看清计费文档里的三个数字：GPU单价、存储单价、公网IP单价。再有一个容易被忽略的细节是“整点计费”。有些平台只要开机不足一小时也按一小时算，频繁开关机反而浪费钱，建议一个训练阶段稳定跑满至少半小时以上再关机释放。3. SSH连接从零到顺手：密钥配置、连接命令与防掉线云GPU机器不像你在教室开个软件敲代码，它本质是一台千万里之外的Linux服务器，你需要通过SSH连过去进行操作。学会SSH是这个流程里最重要的一项基本功，它比模型本身更值得你花半小时掌握。3.1 先花两分钟做一对密钥很多平台在创建实例时会让你选择登录方式，最常见的是密码登录和密钥登录。强烈建议选密钥方式。在你本地电脑终端执行一条命令：ssh-keygen -t ed25519 -C "your_comment"一路回车，就会在~/.ssh/目录下生成两个文件：私钥id_ed25519和公钥id_ed25519.pub。私钥就好比你的家门钥匙，绝对不能外传；公钥是锁，交给服务器。创建实例时，平台通常会要求你粘贴公钥内容，你把id_ed25519.pub里的内容复制进控制台即可。如果你已经在服务器上设了密码登录，也可以手动把公钥追加到服务器的~/.ssh/authorized_keys文件里，然后重启SSH服务。第一次配置密钥之后，一定要记得把本机私钥权限改成600，否则SSH会嫌弃权限太开放而拒绝使用：chmod 600 ~/.ssh/id_ed255193.2 第一次登录，逐参数看懂这条命令拿到云服务器的公网IP、端口和用户之后，你的第一条SSH登录命令大概是这样的：ssh -i ~/.ssh/id_ed25519 root@8.8.8.8 -p 22-i指定私钥路径，root是登录用户，8.8.8.8换成你的机器IP，-p 22是SSH端口。有些平台不是默认22端口，比如自定义端口22022，那就要改这个数字。第一次连接很大概率会提示Host key verification failed，这是因为本地还没有保存这台服务器的主机指纹。常见的处理方式是执行一次ssh-keygen -R 8.8.8.8清掉旧指纹，再重新连接，然后输入yes确认指纹。如果提示Permission denied (publickey,password)，一般不是服务器坏了，而是你的私钥路径不对，或公钥没有正确写入服务器的authorized_keys。逐个排查，别一上来就怀疑是平台的问题。3.3 用SSH config管理多台云机器如果你只租一台机器，直接敲长命令还过得去。但学生党经常是A100一台、便宜卡一台、还要连实验室工作站，每台机器都记IP和密钥路径谁都得疯。配置一个~/.ssh/config文件，问题直接解决。在本地~/.ssh/config里写：Host mygpu HostName 8.8.8.8 User root Port 22 IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 30 ServerAliveCountMax 3保存之后，以后登录只需要输入ssh mygpu，再也不用记那一长串。ServerAliveInterval 30和ServerAliveCountMax 3的意思是每30秒发一次心跳包，连续3次没有回应才断开，能有效避免你挂着终端去吃饭，回来发现SSH已经断开的情况。我还会在~/.ssh/config里给不同项目设置不同的Host，比如训练、评估、实验，一目了然。这个文件本身是纯文本，你可以备份到自己的git私有仓库里，换电脑时直接恢复。3.4 训练不会因SSH断开而中断：tmux的保命用法很多人第一次用云GPU都会发生一个惨案：本地SSH窗口不小心关掉，远程训练进程跟着消失，白跑几个小时。SSH断开导致终端程序收到挂断信号退出，这是新手最容易踩的坑。解决办法是用tmux在远端开一个会话，把训练命令放进去跑，SSH断开也不影响。登录服务器之后执行：tmux new -s train你会进入一个独立的终端会话，在里面运行你的训练命令。然后按Ctrl+b，再按d，这个会话就会回到后台，但训练程序不会停止。下次登录服务器，执行：tmux attach -t train就能重新看到训练进程的输出。如果训练太久想多个任务并行，可以开多个不同名字的会话，比如train、data_process、monitor。如果你用的平台没有预装tmux，先apt update && apt install -y tmux装上再开跑。也有一些同学喜欢用nohup，但我觉得tmux的交互体验好得多，尤其可以随时切回来看日志，强烈推荐。4. 本地与云端的数据流转：文件传输、端口转发和远程开发服务器连上之后，你马上会面对一个现实问题：本地代码和数据怎么放到云端，训练日志和权重怎么弄回来。这个环节看似工具琐碎，效率差距却非常大。4.1 传文件优先用rsync，别用scp硬传很多人一开始用scp传文件，在小文件场景下没什么问题，传大数据集时几次中断会让你怀疑人生。scp不支持断点续传，中断就得重来；rsync支持增量传输，尤其是代码改了几行，只想把改动同步上去，rsync会是更好的选择。常用命令：rsync -avz --progress -e "ssh -i ~/.ssh/id_ed25519" ./local_dir/ mygpu:/workspace/dir/-a是归档模式，保留权限和时间戳；-v显示过程；-z传输时压缩。后面-e指定使用SSH并带上私钥。如果你不想每次输密码，前面配好SSH密钥和~/.ssh/config之后就一步到位。有一点要提醒：往云服务器传大量数据会消耗公网流量，而流量通常是额外计费的。所以先把本地数据压缩成单个压缩包，传到服务器后解压，比传一堆零散小文件更省钱，也更快。4.2 一条SSH命令把Jupyter和TensorBoard拉到本地你在云端跑实验，有时候需要打开Jupyter Notebook或者TensorBoard看看曲线。如果直接在云端浏览器端口开放，你得在安全组/防火墙里开一个公网端口，既不安全又容易被扫描。其实不用那么麻烦，SSH端口转发就可以把远端服务安全地映射到本地。假设云端Jupyter跑在8888端口，本地想用8899端口访问，执行：ssh -L 8899:localhost:8888 -N -f mygpu-L表示把远端localhost:8888映射到本地8899，-N不执行远程命令，-f放到后台。然后打开本地浏览器访问http://localhost:8899，就跟本地开Jupyter一样。TensorBoard默认端口6006，命令改成ssh -L 16006:localhost:6006 -N -f mygpu，访问http://localhost:16006。这种方式的好处在于是加密流量，而且没有把服务暴露到公网，只有你能通过SSH隧道访问，安全性高得多。注意本地端口不要和已有服务冲突，如果提示地址已被占用，换个本地端口就行。4.3 VS Code Remote-SSH：把云端当本地开发机如果你习惯在本地写代码，建议装一个VS Code，使用Remote-SSH扩展。装好扩展后，按Ctrl+Shift+P输入Remote-SSH: Connect to Host...，选择你配置好的mygpu，VS Code就会重新连接到远程服务器，左侧文件树直接变成远程目录，终端也是远端终端，还可以直接调试运行代码。这个体验最关键的一点是，插件能让你保留本地编辑器手感，但实际代码和数据都在云端。你直接打开云端/workspace/train.py修改并运行，省去我每次用rsync同步的麻烦。要注意：Remote-SSH首次连接会在远端下载VS Code Server，如果你的服务器网络不好或者存储空间太小，可能失败。可以检查/root/.vscode-server目录是否有足够空间，必要时清理一下旧版本。另外，远程安装插件时，Python和相关语言插件要安装在SSH远程端，不是本地端，否则无法生效。4.4 我常用的git+rsync工作流我不太建议把整个训练过程完全依赖Remote-SSH，因为训练中的大数据集同步和模型权重下载，最终还是要回到命令行工具。我的固定流程是这样：代码用git管理，在本地开发，每次改动后git commit推到一个私有仓库；在云服务器上git pull拉下来。这样代码版本清楚，回滚也方便。大数据集和模型权重这类不适合进git的大文件，用一个统一的sync_data.sh脚本通过rsync同步。好处是：换实例、换平台时，我在服务器上只需要重新clone一次代码，数据用rsync续传即可。这套流程在学生项目中特别适合，因为你经常需要换一台更便宜的机器继续实验，或者把现有机器释放掉再开一台新的。5. 云端训练避开崩溃现场：显存、多卡与数据存储连接和传数只是准备工作，真正让人崩溃的往往是训练过程中的事故。云端环境既不是你熟悉的本地环境，也不是实验室那台别人维护好的机器，很多问题需要你自己处理。5.1 刚租来的机器，先做这三件事再跑训练第一件事是敲nvidia-smi，确认驱动状态和显卡型号是否跟下单页描述一致，顺便看显存有没有被别人占满。如果你买的是整机独占，一般不会有人抢，但如果是共享实例，显存在开机时被其他容器占住的情况并不少见。第二件事是df -h，看清楚数据盘挂载在哪里。很多平台的镜像盘和二三十G的小系统盘是分开的，数据盘可能叫/data或者/workspace，你如果不看，很容易把数据集写到系统盘，很快塞满导致系统异常。第三件事是检查Python版本和包管理。建议直接创建一个干净的虚拟环境，按项目生成的requirements.txt安装依赖。别看平台镜像里预装了一堆库，版本组合很可能跟你的代码冲突。把这几件事在训练前做完，后面能省掉很多排查时间。5.2 OOM、训练卡死和版本不匹配的排查OOM（显存不足）是云端新手最常见的问题。它不一定是你的模型太大，也可能是batch size设高了，或者PyTorch在默认情况下给每个算子预留了较多显存。解决路径是：先减半batch size，看能否跑通；如果不行，把输入pin_memory、num_workers调低，减小数据加载峰值；再不行，用混合精度训练，开启和微调torch.cuda.amp.autocast和GradScaler。对Transformer类模型还可以开启梯度检查点，用一部分计算换显存。训练卡死不一定是死机。如果CPU数据加载太慢，GPU会一直在等待，看起来像卡住，实际是数据没跟上。这种问题的特征是GPU利用率很低，CPU利用率却很高。解决办法是调大num_workers、把数据放到更快的本地盘，而不是在训练循环里做耗时的数据预处理。版本不匹配的坑很隐蔽。云端驱动不同，PyTorch需要的CUDA版本也不同。你在本地用CPU跑得好好的代码，放到云端直接用pip install torch装最新版，很可能会遇到CUDA driver version is insufficient。正确做法是nvidia-smi看驱动支持的最高CUDA版本，再去PyTorch官网选对应CUDA版本的安装命令。5.3 多卡训练时最容易忽略的通信与数据问题学生做实验经常会尝试多卡并行。如果你在单机多卡上使用PyTorch DDP，启动命令通常是这样：torchrun --nproc_per_node=4 train.py --config config.yaml这里隐藏着一个问题：DDP需要所有进程能通过localhost通信，一般没问题；但如果你用的是机器上的多个进程，而不是多台机器，默认情况能跑通。如果你要跨两台云主机做分布式训练，那就要设置MASTER_ADDR、MASTER_PORT，并保证两台机器的数据目录和数据内容完全一致，这个复杂度明显更高，不建议新手一上来就尝试。多卡训练另一个常忽视的问题是数据加载的随机性。如果每个进程都用不同的随机种子或者数据增强采样方式，会导致数据分布不一致，训练结果不可复现。建议在主进程里统一设置随机种子，或在Dataset里用worker_init_fn来控制每个数据加载进程的随机状态。5.4 训练完先别关机：权重、日志和镜像都要留训练跑完，心情一激动容易直接关机释放实例。但云服务器的本地盘或临时盘在释放后会消失，你的权重文件如果没有另存，直接人间蒸发。所以训练结束后要养成三个动作：先把模型权重和日志rsync回本地或者上传到对象存储；再把重要的依赖环境保存成自定义镜像；最后才释放实例。保存镜像也有讲究。镜像会包含整个系统盘当前状态，如果系统盘里塞了很多无关缓存，镜像会又大又慢。建议在保存镜像之前清理缓存和临时文件，比如/tmp、pip cache、~/.cache等。镜像越小，下次开机越快，存储费用也越低。如果不想每次手动处理，可以在训练命令里嵌套一个自动关机的hook：python train.py && sudo poweroff。这样训练完成后会自动关机，但不会释放实例，数据和环境都保留着，等你确认结果后再手动操作释放。这个做法对我这样丢三落四的人特别有用。6. 学生党的成本控制纪律：把每块钱花在刀刃上最后聊聊钱。学生做实验没有无限预算，控制成本不是抠门，而是把省下来的钱花在真正需要的实验规模上。我自己见过不少同学在云算力上花了很多冤枉钱，其实都是小习惯问题。6.1 低成本训练的五种具体姿势第一，能用小卡就别开大卡。先在小显存卡上做参数规模缩小的smoke test，确认模型能正常收敛，再上大卡跑完整实验。第二，尽量用混合精度训练，显存占用大约能降三分之一，很多平台对FP16的训练速度还有额外加成。第三，抽空时段跑任务，很多平台在白天高峰和深夜闲时价格不同，训练任务不紧急的时候，把大任务安排在闲时能省一大截。第四，利用抢占式实例。这种实例大概率能省一半钱，代价是有可能被抢占。只要你把checkpoint保存频率调好，抢占就抢占，恢复训练也快。第五，不要同时开一堆机器跑相同实验。如果只是调超参，串行跑比并行开机器更省钱，也更利于复盘。6.2 自动关机和账单提醒设置成本控制最关键的一条：离开电脑前，设置好自动关机。我最常写的命令就是训练命令后面拼一个&& sudo shutdown -h +10，意思是训练成功结束后10分钟自动关机。这样即使你忘记手动释放，机器的计费也会很快停止。同时建议在云平台控制台开启费用告警和余额提醒。不要小看这个步骤，我见过不少同学余额突然变成负数，就是因为实验跑太久没注意。设置一个 “超过10元/20元就发邮件提醒” 的阈值，至少能让你在被账单吓到之前收到预警。6.3 省钱还要省时间：先小规模试跑再上大机器省时间往往比省钱更重要。我现在的习惯是，任何大实验都先在本地CPU或者小卡上跑两三百个step，确认数据加载、模型forward和loss计算都正常，再上云端大显卡。直接在云上调试代码是最贵的，因为调试阶段机器一直在跑，却没有产生有效实验结果。另外，云端跑长任务时，每隔一段时间就看一眼日志，不要等训练到一半再发现loss恒为NaN。如果发现异常，及时停掉、修改、重跑，而不是任由机器继续烧钱。最后分享一个我自己的小经验：把~/.ssh/config、rsync同步脚本、tmux常用命令和训练启动模板都整理成一个私有仓库。这样无论换机器、换平台还是借别人的电脑，我都能在五分钟内把远程训练环境重新搭起来。你在云算力上踩过的坑，其实大部分都是这种“环境搭建”层面的坑，把这些流程固化下来，训练本身反而会变成一件很轻松的事情。