GPU 租赁、云端 GPU 算力租用平台最近讨论非常多但很多人的第一个问题不是“哪个型号更强”而是“我到底该不该租、怎么租才不会花冤枉钱”。这类平台解决的核心问题其实很直接你不需要买一台几十万的服务器也能按小时用上 A100、A800、H20、4090、5090 这类显卡跑深度学习训练、大模型微调、Ollama 推理或者科学计算。下面按实际使用顺序拆一遍不重复官网功能介绍重点回答先判断任务是否适合租 GPU再选型号再跑通 PyTorch最后控制成本和排查问题。准备租 GPU 跑 AI 项目、做模型微调以及正在纠结本地和云端到底选哪个的开发者可以按这个路径看。1. 租 GPU 之前先判断你的任务是不是真的需要1.1 按小时租 GPU 最划算的场景不是所有 AI 项目都需要立刻买卡。按小时租 GPU 比较划算的场景通常有三个共同特征任务有明确结束点、对硬件要求波动大、不想承担长期运维成本。模型微调和跑实验今天要微调一个模型跑完就停买一台服务器长期闲置不划算。复现论文和做基准测试需要固定型号比如 A100 或 4090跑几轮结果验证完就能释放。临时性科学计算或渲染周末集中处理一批数据下一周没有同类任务。这类场景的核心指标是“总卡时数”。我一般会先估算单次任务需要多少小时需要几张卡连续跑多少天。把总卡时数乘以单价再和包月或自建成本对比。如果一个月只跑 50 个小时按小时租一定比买服务器省。另外云端 GPU 对本地电脑配置不高的人也很友好。笔记本只有 CPU 或小显存显卡装不了大模型也跑不动 14B 以上的量化模型这时租一张 4090 或 A100环境完全隔离不折腾本地驱动。1.2 不建议租 GPU 的情况反过来以下场景按小时租反而更贵24 小时在线推理服务。API 请求随时进来实例不能停按小时成本会累计到很高。这种更适合包月、预留实例或者自己维护固定 GPU 服务器。高频异步训练任务。团队每天都在训练多个模型长期算力需求稳定按小时租的单价反而可能比包机贵。数据敏感度极高的项目。训练数据不能出本地或者有行业合规要求时租公网 GPU 平台就需要额外评估必要时选择私有化部署或本地机房。判断标准很简单先算“持续负载时长”。持续负载超过一定比例时固定资源更便宜负载波动大、峰值明显的按小时租更灵活。还有一类人我劝退只是想体验一下 GPU 有多快连 PyTorch 环境都没跑通过。这种情况建议先在本地用 CPU 版把代码流程走一遍再上云端否则第一个小时大概率花在装环境和排错上反而不划算。2. 型号怎么选3090、4090、5090、A100、A800、H20 到底差在哪2.1 消费级显卡和专业计算卡的本质差异3090、4090、5090 属于消费级显卡A100、A800、H20 属于专业计算卡。它们之间的差异不只是“贵不贵”而是设计目标和可靠性。消费卡性价比高单卡性能很强很多深度学习任务都能跑。但消费卡在持续满载、多卡互联、显存校验方面不如专业卡。专业计算卡通常显存更大支持 ECC 内存纠错多卡互联带宽更高更适合大模型训练和长时间稳定运行。在云端 GPU 平台上这个差异会被放大。因为你不知道同一台物理机上是否还有别的租户专业卡一般配套更成熟的多卡方案和散热设计适合长时间训练消费卡更便宜适合短任务、推理、中等规模训练。选型时也不用迷信“越新越好”。5090 看起来参数很漂亮但很多公共训练框架和算子库未必第一时间完成适配。跑 PyTorch 大模型时成熟型号反而踩坑少。2.2 选型号时真正要看的四个指标很多人一上来就问“哪个显卡 Tops 算力表排名最高”其实算力只是其中一个维度。选型号时更值得关注的是这四项显存容量决定你能否把模型放进去。大模型微调时模型权重、优化器状态、梯度都要占显存。显存带宽决定数据搬运速度。训练中每步都要读取参数和中间结果带宽低会明显拉慢训练。算力类型和精度不同任务对 FP16、BF16、FP32、INT8 的支持不同。PyTorch 默认常用 FP32混合精度常用 FP16/BF16。多卡互联如果计划用多卡并行需要关注平台是否支持 NVLink 或高速互联。普通 PCIe 互联也是可行方案但同步开销比较高。这些参数以平台实际标注为准不要只看宣传页上的“算力很强”这种描述。跑同一个模型A100 和 4090 的差距在显存带宽和互联上会比单卡算力更明显。大模型场景里大家经常提“token 吞吐量”这个数字其实也受显存带宽和 batch size 影响。只看显卡 Tops 算力表不一定能判断真实推理速度。2.3 按任务类型给一个保守选型建议没有万能型号只有适合任务的型号。任务类型推荐参考型号主要关注点PyTorch 学习和入门实验RTX 3090、RTX 4090性价比、单卡算力中小规模模型微调RTX 4090、RTX 5090显存容量、显存带宽大模型全量微调/预训练A100、A800、H20显存、带宽、多卡扩展推理服务/在线部署H20、4090、5090单卡推理吞吐、显存容量科学计算/渲染A100、5090精度、驱动生态、稳定性如果你跑的是 7B 到 14B 规模的模型只想做 LoRA 微调那么 4090 或 5090 通常够用。如果你要微调 30B 以上模型或者追求稳定长时间训练A100、A800 这类专业卡更合适。H20 主要用于兼顾算力和显存的场景不同平台配置差异较大还是要以实际任务验证为准。另外昇腾这类国产加速卡在部分平台也有资源但框架兼容性和算子支持需要单独测试不能照搬 CUDA 经验。3. 创建实例到跑通 PyTorch云端 GPU 的标准路径3.1 创建实例前先确认三件事在酷虎云这类云端 GPU 算力租用平台上创建实例不要上来就选最高配。先确认三件事镜像、数据入口、释放策略。第一镜像。平台一般提供 PyTorch、CUDA、TensorFlow 等预装镜像。新手建议选择带 PyTorch 的官方镜像省去装框架的步骤。但不要盲目追求最新版本因为最新框架对驱动和 CUDA 版本有最低要求反而容易报错。如果目标是复现别人的项目最好先看项目要求的 PyTorch 和 CUDA 版本。第二数据入口。训练数据在哪里决定了要不要先把数据传到云端。一般有两种方式从本地直接上传或者通过对象存储中转。大数据集建议先放到对象存储或平台网盘再挂载到实例避免实例创建和释放时反复传数据。第三释放策略。建议在创建实例时就设置自动释放时间或者至少记录实例 ID。很多用户创建完实例跑完任务忘记删除账单一直累积就是这个环节没做好。3.2 用一段代码确认 GPU 真正可用创建实例后第一步不是直接跑训练而是确认 GPU 环境可用。用 Python 执行import torch print(PyTorch version:, torch.__version__) print(CUDA available:, torch.cuda.is_available()) print(GPU count:, torch.cuda.device_count()) if torch.cuda.is_available(): print(GPU name:, torch.cuda.get_device_name(0)) total, used torch.cuda.mem_get_info(0) print(fMemory total: {total / 1024**3:.2f} GB) print(fMemory used: {used / 1024**3:.2f} GB)如果torch.cuda.is_available()返回True说明 PyTorch 能识别到 GPU。如果返回False不要急着换实例先检查两件事驱动是否正常、PyTorch 是不是装成了 CPU 版本。运行nvidia-smi看驱动和显卡状态再确认 PyTorch 安装包带的是 CUDA 版本还是 CPU 版本。很多时候不是平台问题是安装源没选对。3.3 让 Ollama 使用指定 GPU最近很多人用 Ollama 跑本地大模型在云端 GPU 上也一样。Ollama 默认会自动选择可用 GPU但当机器有多张卡时默认选择不一定是你想要的那张。最简单的控制方式是用CUDA_VISIBLE_DEVICES环境变量指定设备编号。# 先看有哪些卡 nvidia-smi # 指定第 0 张卡给 Ollama CUDA_VISIBLE_DEVICES0 ollama serve # 在另一个终端启动模型 ollama run qwen2.5:7b启动后建议跑nvidia-smi查看显存占用确认模型加载到了目标卡。如果显存占用不对先看环境变量是否生效再看 Ollama 版本对多模型加载的支持情况。如果同时开多个模型要注意显存总量。比如 4090 是 24GB 显存加载一个 7B 量化模型可能占 6 到 8GB再加载一个 13B 模型总占用很容易超过 24GB导致 OOM。3.4 先跑单任务再跑多卡我在任何云端 GPU 上都坚持同一套顺序先跑一段最小样例确认数据能读、模型能算、结果能写再放大到全量数据或多卡并行。很多初学者直接写一个完整训练脚本跑出来的第一个报错往往不是模型问题而是数据读取路径、权限或者输出目录不存在。先跑通最小样例能把这些前置问题都过滤掉。多卡并行时也建议先在一张卡上测一个 batch 的耗时再逐步增加卡数。不要一上来就整机 8 卡全开很多任务在 1 卡变 2 卡时有收益但从 4 卡变 8 卡收益可能断崖式下降因为通信开销上来了。4. 按小时计费的成本控制钱花在哪里4.1 计费从什么时候开始按小时计费听起来简单实际存在不少隐藏细节。首先要弄清楚计时起点是从创建实例开始还是从实例真正开通可登录开始还是从任务执行开始。不同平台规则不同稍微粗心就会多算几个小时。我的做法是创建实例后立刻花几分钟做环境验证然后挂起或销毁不需要的资源。如果中间要隔几个小时再跑宁愿先释放实例重新创建并不麻烦但能省下不少闲置费。另外还要确认最低计费单位。有的平台按小时计费不足一小时按一小时算有的按分钟计费。短任务多的场景最低计费单位直接决定成本差异。4.2 存储和镜像也会产生费用实例关机不代表所有费用都停止。很多平台在实例关机后仍会收取存储费用比如系统盘和数据盘占用费。如果只是暂停任务保存代码和模型持续占用几块上百 GB 的存储一天下来也是一笔费用。更理性的做法是代码提交到 Git模型权重保存到对象存储数据放到持久化网盘临时盘可以不保留。这样实例销毁后重新创建的恢复成本很低。自定义镜像也需要关注。把常用依赖打包成镜像省时间但镜像是保存在平台侧的会产生存储费用。镜像数量别留太多用不到的删掉。4.3 能明显降低费用的几种方法第一个是先用小数据量验证。训练脚本、数据预处理和模型结构没有确认之前不要直接跑最大数据集。我先用 100 条样本跑通再增到 1 万条最后才全量。这一步几乎每次都能避免“跑到一半发现逻辑写错”的浪费。第二个是批量任务排队而不是手动盯屏。如果脚本支持命令行参数就把多组参数写成队列任务按顺序执行。平台支持任务队列的话一个实例跑完一个任务后再拉取下一个空闲时间会更少。第三个是关注平台有没有竞价实例或低峰优惠。部分算力平台在资源空闲时会给更低折扣但实例可能被回收适合可中断任务。用这种模式跑训练前提是脚本支持断点续训或者训练结果能自动保存到外部存储。第四个是任务结束立即释放实例。很多残留账单来自“忘了删实例”。可以通过平台控制台设置定时释放或者人工定好结束时间。批量跑实验中最好在任务脚本最后统一发送完成通知由负责的人确认后再释放。5. 多卡训练、批量任务和资源隔离的落地经验5.1 多卡并行不是越多越好很多用户看到平台上有 8 卡甚至更多卡的实例就认为“卡越多训练越快”。实际要看任务类型。数据并行适合单卡放得下模型、但数据量很大的场景模型并行适合单个模型太大、一张卡放不下的场景。如果模型一张卡能放下核心瓶颈又不在 batch size强行上多卡反而要处理多卡同步开销速度提升有限。我一般这样判断先用一张卡跑一个 batch记录耗时和显存占用。如果 batch size 已经很大且还有显存余量多卡收益可能主要是吞吐如果单卡显存吃紧才考虑数据并行或梯度累积。PyTorch 里用nn.DataParallel可以快速验证多卡效果但大规模训练最好使用更成熟的分布式方案。遇到“三个 GPU 同时测试”这类需求时也别只盯着卡是否能被识别要看每张卡的负载是否均衡。一张卡跑满、另一张卡空闲说明数据并行切分有问题。5.2 批量任务必须有失败重试和日志我见过不少人在云端 GPU 上跑一批实验时写一个for循环直接把所有任务丢进去最后某一组参数出问题整个任务提前结束前面跑的结果也没有完整日志。这个习惯在本地单机上问题不大在按小时计费的云端却非常浪费。建议每个独立实验都单独建输出目录把日志、指标、模型权重分开存。脚本里要捕获异常单条任务失败时记录错误并继续下一条而不是直接中断。任务结束后至少保留一份包含参数、耗时、误差和硬件利用率的汇总信息方便事后复盘。断点续训也很重要。跑大模型微调时训练中断是常态。每隔固定步数保存 checkpoint重启后从最近一次 checkpoint 继续能省下大量重跑时间。5.3 多人共享实例时的资源隔离如果是团队共用一台 GPU 实例比“分卡”更麻烦的是“抢显存”。A 用户加载一个大模型后B 用户再加载就直接 OOM。最直接的办法是约定用CUDA_VISIBLE_DEVICES切分或者在代码里限制显存占用。如果平台支持容器化实例也可以给每个成员独立容器限制 GPU 和内存配额。这样即使一个人跑崩了任务影响也被限制在容器内。观察资源占用时nvidia-smi一定是第一步。看到显存被占满不要猜测是谁的任务先看进程号再找对应人员确认。如果多人都有分布式训练需求建议还是按人创建独立实例省去互相排查的时间。虽然成本高一些但比后期排障更省心。尤其是训练任务时间敏感的时候资源隔离做不好整个团队都会受影响。6. 常见报错排查驱动、显存和训练速度问题6.1 NVML 初始化失败和驱动访问被阻止有用户拿 WSL 跑 CUDA 时会看到类似failed to initialize NVML: GPU access blocked by the operating system的报错在云端容器里也可能出现驱动加载失败或权限不足的问题。看到这个报错第一反应不是重装 PyTorch而是按顺序排查实例类型是否带 GPU有没有被分配 GPU 资源。容器是否加上了 GPU 设备参数比如 NVIDIA 容器是否正常启动。宿主机的nvidia-smi是否正常驱动版本是否匹配。当前系统用户是否有权限访问/dev/nvidia*设备。如果nvidia-smi本身无法输出说明驱动层有问题此时重装 PyTorch 没有意义。如果nvidia-smi正常但 PyTorch 和 Ollama 检测不到 GPU再检查框架和驱动的 CUDA 版本匹配关系。6.2 显存不足和显存泄漏怎么定位显存不足通常报CUDA out of memory日志里会写清楚是多少显存剩余、多少被占用。排查顺序先看nvidia-smi有没有残留进程占着显存再减少 batch size 或开启梯度累积最后检查代码里有没有不断累积中间张量。显存泄漏更隐蔽。训练刚开始正常跑几千步后显存缓慢上涨最后 OOM。这种通常和代码实现有关比如在循环里重复创建计算图、把验证集结果累积到列表且没有清理、某些算子没有释放中间结果。定位方法是用固定步数跑几次观察显存曲线逐步注释可疑代码。如果只是跑推理想降低 GPU 占用可以考虑减小并发数、关闭不需要的上下文窗口、使用量化版本模型。这些优化不是模型能力问题是资源分配问题。6.3 训练速度慢不一定是显卡的问题GPU 利用率低、训练速度上不去是云端租卡最典型的问题。很多人第一时间怀疑显卡型号不够实际上很多时候瓶颈在 CPU 数据加载、磁盘 IO 或网络读取。我的排查顺序是先看nvidia-smi里的 GPU-Util 和显存占用。GPU-Util 很低但 CPU 跑满通常数据加载和预处理是瓶颈可以开多进程加载、用内存缓存或者换成更高效的数据格式。GPU-Util 高但每步耗时波动很大就要看数据读取是否偶尔卡顿。如果模型不大、数据也小但速度还是很慢再检查是不是跑在 CPU 版本的 PyTorch 上。这种情况下代码不会报错就是慢很容易误判成显卡性能不足。7. 云端 GPU 新手最容易忽略的边界和习惯7.1 不要迷信“显存越大跑得越快”显存决定的是“能不能装下”而不是“跑多快”。跑同一个模型显存大但带宽低训练速度可能反而不如显存小但带宽高的卡。选型号时不要只看显存数字尤其在大模型推理和训练场景显存带宽、算子优化、多卡互联都会影响实际速度。同理“这个平台写了支持某型号 GPU”不等于“所有框架都能直接使用”。CUDA 版本、PyTorch 编译方式、容器内驱动限制都会影响最终表现。落地时先跑 benchmark比看宣传页更靠谱。7.2 把代码和数据当成“随时会丢”来管理云端 GPU 实例本质上是一个临时环境。实例释放后本地没备份的代码和模型权重都会消失。我现在的习惯是代码实时推 Git模型权重每隔一段时间传到对象存储数据文件放在持久化盘或网盘。这样即使实例突然被回收损失也只是当前训练进度而不是全部资产。在批量任务场景里输出命名也要规范。比如按任务参数加时间戳命名避免多轮实验互相覆盖。因为云端存储空间通常有容量限制旧任务输出不清后面任务可能因为磁盘写满而失败。7.3 定期复盘算力账单和任务耗时按小时租 GPU 最大的风险不是单价高而是“零散支出像撒钱”。每次创建实例时花几分钟记一下任务名称、型号、卡数、预计时长和结束时间月底就能知道哪些任务真正消耗了大量算力哪些根本没有必要。对经常跑实验的个人或团队这一步比调参更能省钱。如果发现某个常用镜像每次都要手动安装依赖就把它固化成自定义镜像如果发现某个任务经常跑十几个小时不中断就考虑换成包时套餐或预留实例。云端 GPU 的核心价值就是弹性。弹性用得越熟练成本才越可控。先学会从一个小任务开始租、跑、验、删再逐步扩大规模这是最稳妥的路径。 云端GPU租用实操指南：从选型到成本控制
GPU 租赁、云端 GPU 算力租用平台最近讨论非常多但很多人的第一个问题不是“哪个型号更强”而是“我到底该不该租、怎么租才不会花冤枉钱”。这类平台解决的核心问题其实很直接你不需要买一台几十万的服务器也能按小时用上 A100、A800、H20、4090、5090 这类显卡跑深度学习训练、大模型微调、Ollama 推理或者科学计算。下面按实际使用顺序拆一遍不重复官网功能介绍重点回答先判断任务是否适合租 GPU再选型号再跑通 PyTorch最后控制成本和排查问题。准备租 GPU 跑 AI 项目、做模型微调以及正在纠结本地和云端到底选哪个的开发者可以按这个路径看。1. 租 GPU 之前先判断你的任务是不是真的需要1.1 按小时租 GPU 最划算的场景不是所有 AI 项目都需要立刻买卡。按小时租 GPU 比较划算的场景通常有三个共同特征任务有明确结束点、对硬件要求波动大、不想承担长期运维成本。模型微调和跑实验今天要微调一个模型跑完就停买一台服务器长期闲置不划算。复现论文和做基准测试需要固定型号比如 A100 或 4090跑几轮结果验证完就能释放。临时性科学计算或渲染周末集中处理一批数据下一周没有同类任务。这类场景的核心指标是“总卡时数”。我一般会先估算单次任务需要多少小时需要几张卡连续跑多少天。把总卡时数乘以单价再和包月或自建成本对比。如果一个月只跑 50 个小时按小时租一定比买服务器省。另外云端 GPU 对本地电脑配置不高的人也很友好。笔记本只有 CPU 或小显存显卡装不了大模型也跑不动 14B 以上的量化模型这时租一张 4090 或 A100环境完全隔离不折腾本地驱动。1.2 不建议租 GPU 的情况反过来以下场景按小时租反而更贵24 小时在线推理服务。API 请求随时进来实例不能停按小时成本会累计到很高。这种更适合包月、预留实例或者自己维护固定 GPU 服务器。高频异步训练任务。团队每天都在训练多个模型长期算力需求稳定按小时租的单价反而可能比包机贵。数据敏感度极高的项目。训练数据不能出本地或者有行业合规要求时租公网 GPU 平台就需要额外评估必要时选择私有化部署或本地机房。判断标准很简单先算“持续负载时长”。持续负载超过一定比例时固定资源更便宜负载波动大、峰值明显的按小时租更灵活。还有一类人我劝退只是想体验一下 GPU 有多快连 PyTorch 环境都没跑通过。这种情况建议先在本地用 CPU 版把代码流程走一遍再上云端否则第一个小时大概率花在装环境和排错上反而不划算。2. 型号怎么选3090、4090、5090、A100、A800、H20 到底差在哪2.1 消费级显卡和专业计算卡的本质差异3090、4090、5090 属于消费级显卡A100、A800、H20 属于专业计算卡。它们之间的差异不只是“贵不贵”而是设计目标和可靠性。消费卡性价比高单卡性能很强很多深度学习任务都能跑。但消费卡在持续满载、多卡互联、显存校验方面不如专业卡。专业计算卡通常显存更大支持 ECC 内存纠错多卡互联带宽更高更适合大模型训练和长时间稳定运行。在云端 GPU 平台上这个差异会被放大。因为你不知道同一台物理机上是否还有别的租户专业卡一般配套更成熟的多卡方案和散热设计适合长时间训练消费卡更便宜适合短任务、推理、中等规模训练。选型时也不用迷信“越新越好”。5090 看起来参数很漂亮但很多公共训练框架和算子库未必第一时间完成适配。跑 PyTorch 大模型时成熟型号反而踩坑少。2.2 选型号时真正要看的四个指标很多人一上来就问“哪个显卡 Tops 算力表排名最高”其实算力只是其中一个维度。选型号时更值得关注的是这四项显存容量决定你能否把模型放进去。大模型微调时模型权重、优化器状态、梯度都要占显存。显存带宽决定数据搬运速度。训练中每步都要读取参数和中间结果带宽低会明显拉慢训练。算力类型和精度不同任务对 FP16、BF16、FP32、INT8 的支持不同。PyTorch 默认常用 FP32混合精度常用 FP16/BF16。多卡互联如果计划用多卡并行需要关注平台是否支持 NVLink 或高速互联。普通 PCIe 互联也是可行方案但同步开销比较高。这些参数以平台实际标注为准不要只看宣传页上的“算力很强”这种描述。跑同一个模型A100 和 4090 的差距在显存带宽和互联上会比单卡算力更明显。大模型场景里大家经常提“token 吞吐量”这个数字其实也受显存带宽和 batch size 影响。只看显卡 Tops 算力表不一定能判断真实推理速度。2.3 按任务类型给一个保守选型建议没有万能型号只有适合任务的型号。任务类型推荐参考型号主要关注点PyTorch 学习和入门实验RTX 3090、RTX 4090性价比、单卡算力中小规模模型微调RTX 4090、RTX 5090显存容量、显存带宽大模型全量微调/预训练A100、A800、H20显存、带宽、多卡扩展推理服务/在线部署H20、4090、5090单卡推理吞吐、显存容量科学计算/渲染A100、5090精度、驱动生态、稳定性如果你跑的是 7B 到 14B 规模的模型只想做 LoRA 微调那么 4090 或 5090 通常够用。如果你要微调 30B 以上模型或者追求稳定长时间训练A100、A800 这类专业卡更合适。H20 主要用于兼顾算力和显存的场景不同平台配置差异较大还是要以实际任务验证为准。另外昇腾这类国产加速卡在部分平台也有资源但框架兼容性和算子支持需要单独测试不能照搬 CUDA 经验。3. 创建实例到跑通 PyTorch云端 GPU 的标准路径3.1 创建实例前先确认三件事在酷虎云这类云端 GPU 算力租用平台上创建实例不要上来就选最高配。先确认三件事镜像、数据入口、释放策略。第一镜像。平台一般提供 PyTorch、CUDA、TensorFlow 等预装镜像。新手建议选择带 PyTorch 的官方镜像省去装框架的步骤。但不要盲目追求最新版本因为最新框架对驱动和 CUDA 版本有最低要求反而容易报错。如果目标是复现别人的项目最好先看项目要求的 PyTorch 和 CUDA 版本。第二数据入口。训练数据在哪里决定了要不要先把数据传到云端。一般有两种方式从本地直接上传或者通过对象存储中转。大数据集建议先放到对象存储或平台网盘再挂载到实例避免实例创建和释放时反复传数据。第三释放策略。建议在创建实例时就设置自动释放时间或者至少记录实例 ID。很多用户创建完实例跑完任务忘记删除账单一直累积就是这个环节没做好。3.2 用一段代码确认 GPU 真正可用创建实例后第一步不是直接跑训练而是确认 GPU 环境可用。用 Python 执行import torch print(PyTorch version:, torch.__version__) print(CUDA available:, torch.cuda.is_available()) print(GPU count:, torch.cuda.device_count()) if torch.cuda.is_available(): print(GPU name:, torch.cuda.get_device_name(0)) total, used torch.cuda.mem_get_info(0) print(fMemory total: {total / 1024**3:.2f} GB) print(fMemory used: {used / 1024**3:.2f} GB)如果torch.cuda.is_available()返回True说明 PyTorch 能识别到 GPU。如果返回False不要急着换实例先检查两件事驱动是否正常、PyTorch 是不是装成了 CPU 版本。运行nvidia-smi看驱动和显卡状态再确认 PyTorch 安装包带的是 CUDA 版本还是 CPU 版本。很多时候不是平台问题是安装源没选对。3.3 让 Ollama 使用指定 GPU最近很多人用 Ollama 跑本地大模型在云端 GPU 上也一样。Ollama 默认会自动选择可用 GPU但当机器有多张卡时默认选择不一定是你想要的那张。最简单的控制方式是用CUDA_VISIBLE_DEVICES环境变量指定设备编号。# 先看有哪些卡 nvidia-smi # 指定第 0 张卡给 Ollama CUDA_VISIBLE_DEVICES0 ollama serve # 在另一个终端启动模型 ollama run qwen2.5:7b启动后建议跑nvidia-smi查看显存占用确认模型加载到了目标卡。如果显存占用不对先看环境变量是否生效再看 Ollama 版本对多模型加载的支持情况。如果同时开多个模型要注意显存总量。比如 4090 是 24GB 显存加载一个 7B 量化模型可能占 6 到 8GB再加载一个 13B 模型总占用很容易超过 24GB导致 OOM。3.4 先跑单任务再跑多卡我在任何云端 GPU 上都坚持同一套顺序先跑一段最小样例确认数据能读、模型能算、结果能写再放大到全量数据或多卡并行。很多初学者直接写一个完整训练脚本跑出来的第一个报错往往不是模型问题而是数据读取路径、权限或者输出目录不存在。先跑通最小样例能把这些前置问题都过滤掉。多卡并行时也建议先在一张卡上测一个 batch 的耗时再逐步增加卡数。不要一上来就整机 8 卡全开很多任务在 1 卡变 2 卡时有收益但从 4 卡变 8 卡收益可能断崖式下降因为通信开销上来了。4. 按小时计费的成本控制钱花在哪里4.1 计费从什么时候开始按小时计费听起来简单实际存在不少隐藏细节。首先要弄清楚计时起点是从创建实例开始还是从实例真正开通可登录开始还是从任务执行开始。不同平台规则不同稍微粗心就会多算几个小时。我的做法是创建实例后立刻花几分钟做环境验证然后挂起或销毁不需要的资源。如果中间要隔几个小时再跑宁愿先释放实例重新创建并不麻烦但能省下不少闲置费。另外还要确认最低计费单位。有的平台按小时计费不足一小时按一小时算有的按分钟计费。短任务多的场景最低计费单位直接决定成本差异。4.2 存储和镜像也会产生费用实例关机不代表所有费用都停止。很多平台在实例关机后仍会收取存储费用比如系统盘和数据盘占用费。如果只是暂停任务保存代码和模型持续占用几块上百 GB 的存储一天下来也是一笔费用。更理性的做法是代码提交到 Git模型权重保存到对象存储数据放到持久化网盘临时盘可以不保留。这样实例销毁后重新创建的恢复成本很低。自定义镜像也需要关注。把常用依赖打包成镜像省时间但镜像是保存在平台侧的会产生存储费用。镜像数量别留太多用不到的删掉。4.3 能明显降低费用的几种方法第一个是先用小数据量验证。训练脚本、数据预处理和模型结构没有确认之前不要直接跑最大数据集。我先用 100 条样本跑通再增到 1 万条最后才全量。这一步几乎每次都能避免“跑到一半发现逻辑写错”的浪费。第二个是批量任务排队而不是手动盯屏。如果脚本支持命令行参数就把多组参数写成队列任务按顺序执行。平台支持任务队列的话一个实例跑完一个任务后再拉取下一个空闲时间会更少。第三个是关注平台有没有竞价实例或低峰优惠。部分算力平台在资源空闲时会给更低折扣但实例可能被回收适合可中断任务。用这种模式跑训练前提是脚本支持断点续训或者训练结果能自动保存到外部存储。第四个是任务结束立即释放实例。很多残留账单来自“忘了删实例”。可以通过平台控制台设置定时释放或者人工定好结束时间。批量跑实验中最好在任务脚本最后统一发送完成通知由负责的人确认后再释放。5. 多卡训练、批量任务和资源隔离的落地经验5.1 多卡并行不是越多越好很多用户看到平台上有 8 卡甚至更多卡的实例就认为“卡越多训练越快”。实际要看任务类型。数据并行适合单卡放得下模型、但数据量很大的场景模型并行适合单个模型太大、一张卡放不下的场景。如果模型一张卡能放下核心瓶颈又不在 batch size强行上多卡反而要处理多卡同步开销速度提升有限。我一般这样判断先用一张卡跑一个 batch记录耗时和显存占用。如果 batch size 已经很大且还有显存余量多卡收益可能主要是吞吐如果单卡显存吃紧才考虑数据并行或梯度累积。PyTorch 里用nn.DataParallel可以快速验证多卡效果但大规模训练最好使用更成熟的分布式方案。遇到“三个 GPU 同时测试”这类需求时也别只盯着卡是否能被识别要看每张卡的负载是否均衡。一张卡跑满、另一张卡空闲说明数据并行切分有问题。5.2 批量任务必须有失败重试和日志我见过不少人在云端 GPU 上跑一批实验时写一个for循环直接把所有任务丢进去最后某一组参数出问题整个任务提前结束前面跑的结果也没有完整日志。这个习惯在本地单机上问题不大在按小时计费的云端却非常浪费。建议每个独立实验都单独建输出目录把日志、指标、模型权重分开存。脚本里要捕获异常单条任务失败时记录错误并继续下一条而不是直接中断。任务结束后至少保留一份包含参数、耗时、误差和硬件利用率的汇总信息方便事后复盘。断点续训也很重要。跑大模型微调时训练中断是常态。每隔固定步数保存 checkpoint重启后从最近一次 checkpoint 继续能省下大量重跑时间。5.3 多人共享实例时的资源隔离如果是团队共用一台 GPU 实例比“分卡”更麻烦的是“抢显存”。A 用户加载一个大模型后B 用户再加载就直接 OOM。最直接的办法是约定用CUDA_VISIBLE_DEVICES切分或者在代码里限制显存占用。如果平台支持容器化实例也可以给每个成员独立容器限制 GPU 和内存配额。这样即使一个人跑崩了任务影响也被限制在容器内。观察资源占用时nvidia-smi一定是第一步。看到显存被占满不要猜测是谁的任务先看进程号再找对应人员确认。如果多人都有分布式训练需求建议还是按人创建独立实例省去互相排查的时间。虽然成本高一些但比后期排障更省心。尤其是训练任务时间敏感的时候资源隔离做不好整个团队都会受影响。6. 常见报错排查驱动、显存和训练速度问题6.1 NVML 初始化失败和驱动访问被阻止有用户拿 WSL 跑 CUDA 时会看到类似failed to initialize NVML: GPU access blocked by the operating system的报错在云端容器里也可能出现驱动加载失败或权限不足的问题。看到这个报错第一反应不是重装 PyTorch而是按顺序排查实例类型是否带 GPU有没有被分配 GPU 资源。容器是否加上了 GPU 设备参数比如 NVIDIA 容器是否正常启动。宿主机的nvidia-smi是否正常驱动版本是否匹配。当前系统用户是否有权限访问/dev/nvidia*设备。如果nvidia-smi本身无法输出说明驱动层有问题此时重装 PyTorch 没有意义。如果nvidia-smi正常但 PyTorch 和 Ollama 检测不到 GPU再检查框架和驱动的 CUDA 版本匹配关系。6.2 显存不足和显存泄漏怎么定位显存不足通常报CUDA out of memory日志里会写清楚是多少显存剩余、多少被占用。排查顺序先看nvidia-smi有没有残留进程占着显存再减少 batch size 或开启梯度累积最后检查代码里有没有不断累积中间张量。显存泄漏更隐蔽。训练刚开始正常跑几千步后显存缓慢上涨最后 OOM。这种通常和代码实现有关比如在循环里重复创建计算图、把验证集结果累积到列表且没有清理、某些算子没有释放中间结果。定位方法是用固定步数跑几次观察显存曲线逐步注释可疑代码。如果只是跑推理想降低 GPU 占用可以考虑减小并发数、关闭不需要的上下文窗口、使用量化版本模型。这些优化不是模型能力问题是资源分配问题。6.3 训练速度慢不一定是显卡的问题GPU 利用率低、训练速度上不去是云端租卡最典型的问题。很多人第一时间怀疑显卡型号不够实际上很多时候瓶颈在 CPU 数据加载、磁盘 IO 或网络读取。我的排查顺序是先看nvidia-smi里的 GPU-Util 和显存占用。GPU-Util 很低但 CPU 跑满通常数据加载和预处理是瓶颈可以开多进程加载、用内存缓存或者换成更高效的数据格式。GPU-Util 高但每步耗时波动很大就要看数据读取是否偶尔卡顿。如果模型不大、数据也小但速度还是很慢再检查是不是跑在 CPU 版本的 PyTorch 上。这种情况下代码不会报错就是慢很容易误判成显卡性能不足。7. 云端 GPU 新手最容易忽略的边界和习惯7.1 不要迷信“显存越大跑得越快”显存决定的是“能不能装下”而不是“跑多快”。跑同一个模型显存大但带宽低训练速度可能反而不如显存小但带宽高的卡。选型号时不要只看显存数字尤其在大模型推理和训练场景显存带宽、算子优化、多卡互联都会影响实际速度。同理“这个平台写了支持某型号 GPU”不等于“所有框架都能直接使用”。CUDA 版本、PyTorch 编译方式、容器内驱动限制都会影响最终表现。落地时先跑 benchmark比看宣传页更靠谱。7.2 把代码和数据当成“随时会丢”来管理云端 GPU 实例本质上是一个临时环境。实例释放后本地没备份的代码和模型权重都会消失。我现在的习惯是代码实时推 Git模型权重每隔一段时间传到对象存储数据文件放在持久化盘或网盘。这样即使实例突然被回收损失也只是当前训练进度而不是全部资产。在批量任务场景里输出命名也要规范。比如按任务参数加时间戳命名避免多轮实验互相覆盖。因为云端存储空间通常有容量限制旧任务输出不清后面任务可能因为磁盘写满而失败。7.3 定期复盘算力账单和任务耗时按小时租 GPU 最大的风险不是单价高而是“零散支出像撒钱”。每次创建实例时花几分钟记一下任务名称、型号、卡数、预计时长和结束时间月底就能知道哪些任务真正消耗了大量算力哪些根本没有必要。对经常跑实验的个人或团队这一步比调参更能省钱。如果发现某个常用镜像每次都要手动安装依赖就把它固化成自定义镜像如果发现某个任务经常跑十几个小时不中断就考虑换成包时套餐或预留实例。云端 GPU 的核心价值就是弹性。弹性用得越熟练成本才越可控。先学会从一个小任务开始租、跑、验、删再逐步扩大规模这是最稳妥的路径。