我自己搭本地GPU环境折腾了大半年最后决定把模型训练和部署的流程整体挪到华为云ModelArts上跑这算是被逼出来的选择。这篇学习笔记把我从数据集上传、Notebook调试、训练作业配置到在线推理部署的完整过程记录下来也把中途踩过的坑一并整理了。如果你正准备在云上做一次完整的模型训练与部署或者已经被本地显卡驱动、显存、环境依赖折磨到怀疑人生这篇文章应该能帮你少走不少弯路。熟悉ModelArts的同学知道它不是一个单纯的训练服务器而是一套从数据处理、算法开发、模型训练到模型推理的托管平台。换句话说你不需要去关心显卡驱动、CUDA版本、容器环境这些底层琐事只需要把数据准备好把代码写好剩下的事情平台帮你处理。对我这种一半时间在写代码、一半时间在修环境的人来说这种托管感实在太重要了。1. 为什么我把模型训练从本地显卡搬到ModelArts1.1 本地训练的真实体验从驱动到显存的连环坑我本来有一台装了双显卡的机器16G显存跑一些推理任务绰绰有余可一旦真开始训练模型问题就接踵而至。先是CUDA版本和PyTorch的cuDNN不匹配接着发现项目多了以后conda环境互相打架这个项目要Python 3.8那个项目要Python 3.10换个项目就得重新部署一个环境时间全花在等包下载上。后来尝试跑ResNet50这类常见的预训练模型微调batch_size稍微调大一点就直接报CUDA out of memory。网上那些16G显存本地部署AI的攻略大多数讲的是推理场景真正跑训练完全是另一回事。更崩溃的是训练到一半机器风扇狂转温度飙到90度直接卡死几个小时的进度全废。这种经历让我明白本地显卡适合做小规模的实验和推理但要做认真训练硬件和管理成本远比想象中高。1.2 ModelArts解决了什么训练、推理一条龙的托管体验ModelArts能吸引我核心是托管两个字。它把整个流程拆成了几个标准模块数据管理、Notebook、训练作业、模型管理、推理服务。数据放OBS对象存储里代码在Notebook里调试训练的时候提交作业到资源池训练完再把模型打包成服务直接出API接口。对比自己在云服务器上搭环境这个优势非常直观。用普通ECS云主机你还得自己装驱动、装深度学习框架、做监控、处理训练进程意外退出。而ModelArts把这些都管了训练作业挂掉还能看日志、自动重启甚至可以做分布式训练资源从一张卡扩展到多张卡配置项改一下就行。1.3 适合谁用不适合谁用我自己的判断标准是这样的适合没有GPU硬件但想训练模型的人数据集很大的团队需要多人协作、版本管理的项目追求算力弹性今天训练、明天不训练的人。可能不适合只做小规模推理且数据非常敏感不允许出内网算力需求很小本机GPU完全够用长期高频跑推理服务且成本敏感这种场景本地部署可能更划算。一句话总结训练任务用云上弹性算力稳定推理服务可以考虑本地化两者不是对立关系而是按场景选择。2. ModelArts训练前的关键准备数据集、Notebook与代码调试2.1 数据进云OBS桶与数据集的正确姿势ModelArts训练作业读取数据走的是OBS对象存储。刚开始我以为随便建个桶、把文件传上去就行后来发现目录结构会影响整个训练流程的清晰度。我的习惯是在一个桶下建多个目录而不是一个桶塞一堆散文件obs://your-bucket/ model_data/ train/ val/ test/ output/ code/上传数据有几种方式。数据量小直接控制台拖拽上传就行操作直观。数据量大了建议用obsutil命令行工具支持同步、断点续传效率高很多。比如把本地数据同步到OBSobsutil cp ./local_data obs://your-bucket/model_data/train -r -f这里面有个很容易犯的错OBS桶的区域必须和ModelArts所在区域一致。我当时把桶建在华北、ModelArts资源用华东训练作业启动后一直提示找不到路径折腾半天才发现是跨区域访问导致的问题。区域一致这件事开始建桶之前就要确认清楚。如果你是做目标检测这类任务比如用YOLOv8/YOLO11做手套口罩检测想训练自己的数据集最麻烦的往往不是模型代码而是数据标注。ModelArts的数据管理功能支持图像分类、目标检测、语义分割标注会自动生成平台能识别的标注文件。如果你已经有YOLO格式或COCO格式的标注数据直接上传也行只是要确认训练脚本里读取的是哪种标注格式别把两种格式混在一起。2.2 Notebook调试先跑通再上训练作业训练作业是个偏黑盒的东西提交之后能看到的只有日志如果代码有问题一次调试可能要等好几分钟才能看到报错点。所以我的经验是先创建Notebook在交互式环境里把数据处理、模型定义、训练循环都跑通再提交训练作业。创建Notebook时选择镜像和规格。PyTorch、TensorFlow、MindSpore这些主流框架都有预置镜像选一个和你最后训练作业一致的版本避免Notebook里能跑、训练作业里报版本不兼容。规格可以先选CPU小实例做代码验证真要跑数据再开GPU。注意Notebook的存储盘是按量计费的不用的时候要把实例停止掉这个后面细说。在Notebook里做迁移学习很顺手比如用ResNet50预训练模型改造一个图像分类任务import torch import torch.nn as nn import torchvision.transforms as transforms from torchvision import datasets from torchvision.models import resnet50 transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) train_ds datasets.ImageFolder(data/train, transformtransform) train_loader torch.utils.data.DataLoader( train_ds, batch_size32, shuffleTrue, num_workers4 ) model resnet50(weightsIMAGENET1K_V1) model.fc nn.Linear(model.fc.in_features, 10) model model.to(cuda if torch.cuda.is_available() else cpu)这里有个细节值得注意预训练权重的填写方式在不同torchvision版本里略有差异有的版本用weightsIMAGENET1K_V1有的用pretrainedTrue。你在Notebook里实际执行时以当前环境的API文档为准跑一遍确认能加载再继续。调试阶段千万别急着把完整训练跑完先跑一个batch把输入输出的shape打出来看loss能不能正常下降。确认没问题后把代码整理成一个独立的训练脚本保存到OBS的code目录准备上训练作业。2.3 从Notebook到训练作业参数化是生产级玩法的第一步训练作业和Notebook最大的区别在于训练作业适合长周期、大规格、可重复的任务而且支持把训练代码、数据、输出路径都参数化。这样同一份代码改一下参数就能在多个数据集上反复跑。训练脚本里一般要有几个关键的参数import argparse parser argparse.ArgumentParser() parser.add_argument(--data_url, typestr, defaultNone, help训练数据OBS路径) parser.add_argument(--train_url, typestr, defaultNone, help模型输出OBS路径) parser.add_argument(--epochs, typeint, default20) parser.add_argument(--batch_size, typeint, default64) parser.add_argument(--lr, typefloat, default0.001) args parser.parse_args()然后提交训练作业时算法来源选择OBS里的这个脚本数据来源指向obs://your-bucket/model_data训练输出指向obs://your-bucket/output规格选择一个GPU实例。平台会把数据准备到执行环境脚本里通过args.data_url读取训练完把模型权重保存到args.train_url。第一次提交训练作业我会刻意把epochs设小一点比如正常跑20轮的先跑2轮。目标是验证整个链路能走通日志正常输出checkpoint能保存到OBS。这比直接跑完整训练然后发现最后一步模型保存失败要省太多时间。如果说用EasyOCR这类工具训练自己的模型时大家最常卡在数据处理和输出格式理解不透上那ModelArts训练作业其实也一样黑盒任务启动前的每一步验证都比想象中重要。3. 部署阶段最容易卡住的点模型打包、服务配置与API调用3.1 模型包结构与config平台不认散装模型训练作业跑完后你得到的是模型权重文件比如resnet50.pt。但部署在线服务时平台需要的是模型包一个包含模型文件、推理脚本、配置文件的目录。这一点是很多新手最容易忽略的以为把.pt文件上传就能出接口实际上中间还差了一层推理封装。自定义模型包的结构大概是这样的model/ resnet50.pt config.json customize_service.pyconfig.json里声明模型的基本信息和依赖。比如我自己的配置{ model_algorithm: image_classification, model_type: PyTorch, dependencies: [ { installer: pip, packages: [ torch1.10.0, torchvision0.11.0, Pillow ] } ] }依赖这一项非常容易出问题。平台部署推理服务时会按照dependencies安装Python包如果你训练时用的PyTorch版本和这里声明的版本不一致轻则加载模型失败重则服务启动后进程反复崩溃。所以写配置时一定要仔细核对训练环境的版本。customize_service.py里是推理的核心逻辑。不同的模型引擎基类写法有差异但核心流程就三块装载模型、预处理、后处理。我用自定义服务的方式实现时代码骨架基本是import os import torch import torchvision.transforms as transforms from PIL import Image import numpy as np class ModelService: def __init__(self, model_path): self.model load_resnet50() self.model.load_state_dict( torch.load(os.path.join(model_path, resnet50.pt), map_locationcpu) ) self.model.eval() self.transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) def preprocess(self, data): # data里是HTTP请求传来的图片字节流转成模型输入Tensor pass def predict(self, input_tensor): with torch.no_grad(): output self.model(input_tensor) return output def postprocess(self, output): # softmax后取top-5拼成JSON可序列化的结果 pass平台接收的HTTP请求是JSON格式你的图片要base64编码后放进请求体经过preprocess解码成图片数组再转Tensor进入模型。这个过程必须想清楚不然模型文件再准确也没办法对外提供服务。如果你觉得自定义推理脚本太麻烦ModelArts也提供从训练作业直接导入模型的方式平台会自动生成配套的模型包和推理脚本模板。拿模板改比自己从零写少踩很多坑。3.2 创建推理服务规格、实例数与启动过程模型包准备好之后进入模型部署环节。在线推理服务、批量推理服务、边缘服务三者的适用范围不同在线服务适合低延迟、实时响应的场景批量服务适合大量离线文件推理边缘服务适合把模型下发到边缘设备。创建在线服务时要选择模型版本、计算规格、实例数量。这里我说一句掏心窝的建议第一次跑通链路的时候选尽可能低的规格小实例能跑起来再升级。因为服务启动失败往往和规格大小没关系而是推理脚本或依赖有问题你开个大规格的GPU实例等半天报错信息还是一样的费用反而白白燃烧。服务启动需要几分钟状态从初始化变成运行中才算成功。这期间平台会做健康检查如果推理脚本没有对探活请求做出正确响应服务状态可能一直显示异常或反复重启。健康检查这个机制很容易被忽视。我见过不少人在Notebook里推理正常部署后却一直不健康原因是自定义服务没有处理平台发来的探活请求。所以推理脚本里最好明确处理一个空请求或健康检查请求返回一个200状态码让平台确认这个服务是活的。3.3 从本地脚本调用云端模型服务服务状态变成运行中之后就有一个独立的API地址。这时候我用Python脚本发起请求看整个链路是不是真的通了。import base64 import requests service_url https://xxxx.infer.cn-north-4.myhuaweicloud.com/v1/infers/xxxx headers {Content-Type: application/json} with open(test.jpg, rb) as f: img_base64 base64.b64encode(f.read()).decode() payload {images: [{data: img_base64}]} resp requests.post(service_url, headersheaders, jsonpayload) print(resp.status_code) print(resp.json())请求字段的具体结构要以你在控制台看到的API说明为准不同时期、不同模型引擎的字段名可能不一样。关键是理解思路图片转base64放进JSON请求体请求返回模型预测结果。我第一次调用成功后终于意识到模型部署不是一个抽象概念而是实实在在地多了一个可以通过HTTP访问的推理服务。这一步跑通后面无论是做小程序后端、Web应用还是集成到业务系统都只是对接方式的问题了。4. 绕开这些坑训练和部署报错的完整排查思路4.1 一例OBS路径不存在的排查从页面到CLI的验证链路训练作业启动失败报错信息里最常见的就是OBS path does not exist。我遇到过几次现象都一样但根因各不相同。第一次是桶名写错。控制台界面上路径填的是obs://your-bucket/model_data我为了省事复制了别的地方的路径把桶名改错了。这个比较好排查回控制台看一眼OBS列表就行。第二次是子账号权限问题。我用的是子账号登录ModelArtsAK/SK对应的权限只开了部分桶训练作业请求的那个桶恰好没授权平台不会因为权限问题给你清晰的错误提示而是同样报路径不存在。排查方法是先到OBS控制台看看能不能直接浏览这个路径再用obsutil命令行验证obsutil ls obs://your-bucket/model_data/train命令行能列出内容说明路径基本没问题接下来就要查AK/SK权限。如果命令行直接报AccessDenied那问题大概率出在权限上。第三次最乌龙数据还没上传完就启动了训练作业。我同步大文件时用了异步上传当时看命令行没报错就以为传完了实际上文件还在排队。训练作业启动后读取目录发现部分文件缺失也报路径相关的错误。从那以后我养成了习惯提交训练作业前先跑一次obsutil ls确认数据完整。4.2 部署后一直失败/请求404健康检查与启动配置的真相模型部署失败比训练失败更让人头疼因为涉及日志、配置、依赖、健康检查多个环节。我遇到过服务一直启动失败控制台状态是异常点进去看日志才发现压根没有模型加载相关的打印信息只有一行No module named torch。这个问题的根因就是config.json里的dependencies依赖没写对平台启动推理环境时没有安装PyTorch自然就加载不了模型。排查思路说穿了不值钱看生命周期日志定位到是依赖缺失还是代码异常再针对性修复。依赖缺失补依赖代码异常看堆栈模型文件找不到就检查os.path.join(model_path, resnet50.pt)里的文件名是不是拼错了。还有一个典型的情况服务能启动但请求接口一直返回404。这种情况多半是推理脚本里没有实现预期的路由或方法。平台请求的是某个固定的路径你的脚本里没有对应处理函数返回404就很正常。解决方法是参照平台给的推理脚本模板把对应接口实现完整。遇到部署类问题我推荐的排查顺序是先看服务生命周期日志定位启动阶段是否报错。再看业务日志看模型是否加载成功、请求是否进入推理函数。最后一次只改一个配置项不要同时改依赖、代码、规格三个变量否则出问题根本不知道是谁引起的。4.3 训练中途OOM与NaN Loss别急着调代码先检查这三件事模型训练报nan是讨论区里高频出现的问题。我自己的经历分几种第一种是显存不足。模型本身很大或者batch_size设置过高训练到某个step就崩了。解决办法很简单batch_size减半或者降低图片分辨率再看。如果在Notebook里跑还要检查是不是DataLoader的num_workers开太大把内存也吃满了。第二种是loss变成NaN。大多数情况下是学习率设置过大梯度更新直接冲爆了。我习惯在训练循环里加梯度裁剪把梯度范数限定在一个范围内torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0)然后把学习率调低比如从0.001降到0.0001试试。第三种输入数据里有异常值。比如图像数据没归一化像素范围是0到255和预训练模型的输入预期不一致导致非常规的数值分布。这时候不一定报错但loss就是降不下去偶尔也会出NaN。处理方法是把数据预处理环节严格对齐预训练模型的标准检查标准化用的mean和std是不是写错了。遇到NaN我建议按顺序排查先看数据预处理再看学习率最后看模型结构。千万不要一上来就改模型结构那样大概率是白忙活。4.4 账单与资源清理训练完忘记关实例第二天扣费的教训云上算力是按时计费的资源不停费用就持续产生。这里必须提醒一个细节Notebook实例停止和释放不完全是一回事。停止后如果挂了云硬盘存储费用还是会继续计费。推理服务也一样不主动下线实例资源就一直在那等着扣费。我自己犯过的错是训练作业提交后开了个GPU规格的Notebook等着看结果看完直接合上电脑走了第二天发现Notebook挂了整整一晚账单多出一截。这种事经历一次就长记性了。现在我的操作习惯是Notebook用完立即停止如果只是临时调试不保留自研环境存储盘也选最小规格。训练作业在提交时确认好输出路径训练完模型保存到OBS之后该释放就释放。推理服务只在验证阶段存在验证完马上删除或停用不要因为也许明天还要用就留着。云上资源的计费规则其实清晰透明控制台每一项都有明细账单。问题从来不是平台不透明而是使用者没有养成清理资源的习惯。5. 云端与本地怎么配合ModelArts和本地部署的选型参考5.1 不同部署方式的对比没有最好只有合适最近Ollama、DeepSeek这类本地部署大模型的话题很火很多人会问我有ModelArts了还需要本地部署吗我的观点是这是两条完全不同的路线解决的问题不一样。我自己整理过一个对比表供你参考维度ModelArts云上训练在线推理本地GPU服务器Ollama/DeepSeek本地推理边缘设备如RK3588部署YOLOv8算力弹性高按需扩缩容低硬件固定低极低性能受限大规模训练能力强支持分布式弱单机受限一般不用于训练不适用数据安全性取决于云上安全策略数据在本地最可控数据在本地最可控数据在本地最可控推理延迟取决于网络公网有消耗极低极低极低离设备最近前期门槛低开箱即用高环境配置麻烦中等但配置相对友好高需要交叉编译成本模型按量付费适合弹性和周期任务一次性硬件投入适合长期高频部署后推理几乎零边际成本硬件成本低适合固定场景运维成本低平台托管高自己维护低中等如果你只是想在本地跑通一个大语言模型对话服务Ollama确实方便几行命令就能把DeepSeek这类模型拉起来。但如果你想在大数据集上微调模型或者团队里多人同时做实验本地这点算力很快就会成为瓶颈。这时候ModelArts这类云上平台的弹性价值就体现出来了。5.2 混合路线云上训练本地/边缘推理我目前最常用的一套工作流其实是混合的用ModelArts做重活用本地或边缘设备做轻量推理。具体拆解下来是训练阶段数据量和模型规模上来后ModelArts用GPU资源池跑完整训练比如用YOLOv8/YOLO11微调一个检测模型云上几小时跑完。导出阶段训练完成得到模型权重文件下载到本地转成ONNX格式。本地推理阶段用ONNX Runtime或TensorRT在本地CPU/GPU上推理或者部署到RK3588这类边缘设备上延迟可以做到几十毫秒以内。封装阶段如果需要给业务系统提供接口可以用FastAPI或Flask包一层HTTP服务也可以集成进Dify这类应用编排平台。这套组合的好处很实在训练阶段按需付费不训练就不花钱推理阶段数据不出内网延迟低也没有按调用次数计费的压力。我认识一些做企业大模型私有化部署的团队思路也类似模型权重要么用开源预训练权重要么在云上微调好后同步到内网GPU服务器用Ollama或vLLM这类推理框架提供本地服务兼顾数据安全和响应速度。5.3 给新手的一条完整学习路径如果看完这篇文章你想自己上手走一遍我给你一个可以参考的路径在ModelArts创建一个Notebook选PyTorch镜像用公共数据集跑通一个简单的分类任务感受一下交互式调试的体验。上传你自己的小数据集按train/val分目录整理好放到OBS写一个参数化的训练脚本从Notebook切换到训练作业跑一遍。训练完成后把模型文件整理成模型包结构带config.json和customize_service.py部署在线服务用Python脚本调用一次。再把模型下载到本地转ONNX尝试本地推理形成云上训练、本地推理的完整闭环。这几个节点走完你对ModelArts的静态理解会变成真正的实操经验。过程中遇到问题优先看日志再查文档最后再问社区排查顺序对了大部分问题都能自己解决。最后分享一个我个人的小习惯任何训练任务开始前先在Notebook里把数据集的目录结构和每个batch的shape打印一遍确认无误再提交训练作业。这看起来多花十分钟实际能省下好几个小时的排错时间比任何技巧都实在。