1. 从零到一为什么我选择在云上跑通第一个模型很多刚接触机器学习的朋友包括我自己最开始都卡在同一个地方本地环境。装CUDA、配cuDNN、折腾Python版本冲突一套流程走下来模型还没开始训练热情已经被消磨掉大半。更别提本地机器那点显存稍微大一点的模型直接给你甩一个OOM内存溢出错误连调参的机会都不给。我这次要分享的就是如何利用华为云ModelArts平台完成一个完整模型的训练与部署。整个过程不需要你本地有显卡不需要你手动配置深度学习环境甚至不需要你写复杂的部署脚本。你只需要准备好数据和代码剩下的脏活累活平台帮你干了。这篇文章适合谁看如果你是刚入门机器学习的学生或者是一个想快速验证算法效果的后端开发者又或者你手头只有一台轻薄本但想跑一个图像分类或者文本分类的模型那这篇学习笔记就是为你准备的。我会把我在使用过程中踩过的坑、绕过的弯路以及那些官方文档里不会明说但实际用起来很关键的细节全部摊开来聊。核心关键词就几个ModelArts、模型训练、模型部署、云端开发环境、推理服务。我会围绕这几个点把从数据上传到最终得到一个可调用API的完整链路讲清楚。2. 动手之前ModelArts到底帮你省掉了哪些事2.1 本地训练与云端训练的账得算明白先算一笔时间账。假设你要训练一个ResNet50做图像分类本地用一张消费级显卡从装驱动到跑通第一个epoch顺利的话半天不顺利的话两天。这中间包括确认显卡型号、下载对应版本的CUDA、安装cuDNN、创建虚拟环境、安装PyTorch或TensorFlow、解决各种依赖冲突。每一步都可能遇到版本不匹配的问题比如PyTorch 1.8需要CUDA 11.1但你系统里装的是CUDA 10.2那就得重来。而在ModelArts上你创建 Notebook 实例的时候直接选一个预置的镜像比如“PyTorch-1.8.0-cuda11.1”环境就已经配好了。你打开JupyterLab就能直接import torch不会报错。这省下来的时间够你把模型结构改三遍了。再算一笔硬件账。本地一张RTX 306012GB显存市场价大概两千多。但如果你想训练一个稍微大点的模型比如BERT-basebatch size稍微大一点就爆显存。而在ModelArts上你可以按小时租用V100或者A100的实例训练完了就释放按需付费。对于学生或者个人开发者来说这比买一张高端显卡划算得多尤其是当你只是偶尔跑一次训练的时候。2.2 那些容易被忽略的隐性成本除了时间和硬件还有一些隐性成本是新手容易忽略的。比如数据管理。本地训练的时候数据就放在硬盘上读写速度快但一旦数据量大了比如几十个G的图像数据集硬盘空间就紧张了。而且如果你换一台机器数据还得重新拷贝。ModelArts提供了对象存储服务OBS你可以把数据上传到OBS桶里然后在Notebook里直接挂载使用。这样数据是独立于计算资源的你换实例、换规格数据都在那里不用重新上传。而且OBS的存储费用很低比你把数据一直放在云硬盘上要便宜。还有一个隐性成本是环境复现。本地训练的时候你今天跑通了过两个月想重新跑一遍发现环境变了或者某个库更新了代码跑不通了。在ModelArts上你可以把整个Notebook环境保存下来或者用镜像的方式固化环境下次直接启动同样的镜像保证结果可复现。提示虽然ModelArts省去了很多环境配置的麻烦但并不意味着你可以完全不懂Linux和Python。基本的命令行操作、pip安装包、查看日志这些技能还是需要的。平台只是帮你把最繁琐的部分自动化了不是帮你写代码。3. 数据准备与上传别小看这一步坑都在细节里3.1 数据集的组织结构决定了你后面顺不顺我见过很多新手数据往OBS桶里一扔文件夹结构乱七八糟结果在Notebook里写数据加载代码的时候路径对不上找文件找半天。所以第一步先把数据结构理清楚。以图像分类为例推荐的结构是这样的dataset/ ├── train/ │ ├── class_1/ │ │ ├── img_001.jpg │ │ └── ... │ ├── class_2/ │ └── ... ├── val/ │ ├── class_1/ │ └── ... └── test/ └── ...这种结构的好处是你可以直接用PyTorch的ImageFolder或者TensorFlow的image_dataset_from_directory一行代码就能加载数据不需要自己写解析逻辑。如果你把图片全放在一个文件夹里然后用一个CSV文件来标注那也行但代码量会多不少而且容易出错。对于文本分类通常是CSV或者JSON Lines格式每行一条数据包含文本和标签。这种格式在Notebook里用pandas读进来就行比较简单。3.2 上传数据到OBS的正确姿势ModelArts的Notebook实例不能直接访问你本地的硬盘所以数据必须先上传到OBS。上传的方式有几种通过OBS控制台网页上传适合小数据集几百兆以内直接拖拽就行。但大文件上传慢而且容易断。通过OBS Browser客户端上传适合大数据集支持断点续传速度也快一些。我一般用这个。通过命令行工具obsutil上传适合批量上传和自动化脚本。如果你经常需要更新数据建议学一下obsutil的基本命令。我个人的习惯是先在本地把数据整理好压缩成一个zip包然后上传到OBS再在Notebook里解压。这样比一个个文件上传快得多尤其是小文件多的时候。比如一个图像数据集有几万张小图片一个个上传会非常慢打包成一个zip上传一个文件然后在Notebook里用unzip命令解压效率高很多。注意OBS桶的区域要和ModelArts实例的区域一致否则跨区域访问会有延迟甚至可能访问不了。创建桶的时候区域选择和你Notebook实例相同的区域比如“华北-北京四”。3.3 在Notebook里挂载OBS数据数据上传到OBS之后在Notebook里怎么访问有两种方式第一种是直接在代码里用OBS的路径比如s3://your-bucket/dataset/但这种方式需要配置访问密钥比较麻烦而且读写速度受网络影响。第二种是使用ModelArts提供的数据挂载功能把OBS桶挂载到Notebook的本地目录比如/home/ma-user/work/dataset/。这样你访问数据就像访问本地文件一样速度快而且代码里不用写OBS路径移植性也好。挂载的方法很简单在创建Notebook实例的时候或者实例运行之后在设置里找到“数据存储”或者“挂载OBS”选择你的桶和挂载路径就行。挂载之后你在Notebook里cd到那个目录就能看到你的数据文件。我实测下来挂载方式的读写速度比直接访问OBS路径快不少尤其是训练的时候需要频繁读取小文件挂载方式优势明显。4. 训练代码的编写与调试在Notebook里像本地一样开发4.1 用JupyterLab写代码的体验ModelArts的Notebook实例默认提供JupyterLab界面和本地的JupyterLab几乎一样。你可以新建Notebook文件写代码运行看输出。对于调试代码来说这比在本地终端里跑脚本方便多了因为你可以分块运行随时查看中间变量的值。我一般会先在Notebook里写一个小的数据加载测试确认数据能正确读进来图片能正常显示标签对应关系没错。然后再写模型定义跑一个前向传播确认输出维度对得上。最后再写训练循环先用少量数据跑几个epoch确认loss在下降没有报错。这个过程和本地开发是一样的但因为环境是配好的省去了很多折腾。有一个小技巧在Notebook里可以用!nvidia-smi命令查看当前实例的GPU信息确认GPU是否可用。如果显示没有GPU那可能是你选的实例规格不对需要重新创建一个带GPU的实例。4.2 把代码从Notebook迁移到训练作业Notebook适合调试但真正跑长时间训练的时候我建议用ModelArts的训练作业功能。为什么呢因为Notebook实例如果你关掉浏览器或者网络断了内核可能会断开训练就中断了。而训练作业是提交到后台跑的即使你关掉电脑训练还在继续而且训练作业支持自动停止、失败重试、日志查看等功能更适合生产级别的训练。从Notebook迁移到训练作业需要做几件事把代码整理成脚本把Notebook里的代码整理成一个或多个.py文件比如train.py、model.py、data_loader.py。入口脚本一般是train.py里面包含参数解析、数据加载、模型定义、训练循环等。指定启动命令在创建训练作业的时候需要指定启动命令比如python train.py --epochs 10 --batch_size 32。这里的参数可以通过训练作业的“超参”功能传入方便调参。配置数据输入和输出路径训练作业需要指定数据来源一般是OBS路径。输出路径也是OBS路径训练过程中产生的模型文件、日志文件会保存到那里。选择计算规格根据模型大小和数据集大小选择合适的GPU规格。如果只是测试代码能不能跑通可以先用CPU规格跑一两个epoch确认没问题再换GPU。我踩过的一个坑是在Notebook里跑的时候数据是挂载到本地目录的代码里写的是本地路径。但迁移到训练作业的时候数据是通过OBS路径传入的代码里的路径需要改成从环境变量或者参数获取。所以写代码的时候最好把数据路径、输出路径都做成可配置的参数不要硬编码。4.3 训练作业的日志查看与问题定位训练作业提交之后你可以在ModelArts的控制台看到作业的运行状态。如果失败了可以查看日志。日志里会显示标准输出和标准错误包括你代码里print的内容以及框架本身的报错信息。常见的错误有几种路径错误比如数据路径写错了或者输出路径没有权限。日志里会显示FileNotFoundError或者PermissionError。显存不足日志里会显示CUDA out of memory。这时候需要减小batch size或者换更大的GPU规格。代码bug比如维度不匹配、类型错误等。日志里会显示具体的报错堆栈根据堆栈定位到代码行。我一般会在代码里加一些日志输出比如每个epoch结束后打印loss和准确率这样即使训练失败了也能看到失败前跑到哪一步了。另外ModelArts的训练作业支持TensorBoard你可以把训练过程中的指标写到TensorBoard日志里然后在控制台查看可视化曲线比看文本日志直观得多。5. 模型部署从训练产物到可调用API5.1 模型转换与保存的注意事项训练完成之后你得到的是一个模型文件比如PyTorch的.pth文件或者TensorFlow的.h5文件。但要把这个模型部署成在线服务还需要做一些转换和配置。首先模型保存的时候建议保存整个模型结构加权重而不仅仅是权重。因为部署的时候平台需要知道模型的结构才能加载。对于PyTorch可以用torch.save(model, model.pth)保存整个模型或者用torch.save(model.state_dict(), model.pth)只保存权重但后者需要在部署代码里重新定义模型结构。其次需要提供一个推理脚本告诉平台怎么加载模型、怎么做预处理、怎么做后处理。这个脚本一般叫customize_service.py里面需要定义一个类继承自ModelArts的推理基类实现_preprocess、_inference、_postprocess三个方法。我一开始觉得这个脚本很麻烦但后来发现它其实很灵活。比如你可以在预处理里做归一化、resize在推理里调用模型在后处理里把输出转换成JSON格式。这样你的API返回的就是直接可用的结果不需要调用方再做额外的处理。5.2 部署配置选对规格省心又省钱部署的时候需要选择计算规格。如果只是测试可以选CPU规格便宜但推理速度慢。如果是对延迟敏感的应用比如实时图像识别那就需要选GPU规格。还有一个重要的配置是自动扩缩容。你可以设置最小实例数和最大实例数当请求量大的时候平台会自动增加实例请求量小的时候自动减少实例。这样既能保证服务稳定性又能节省成本。我建议在测试阶段先把最小实例数和最大实例数都设为1确认服务能正常调用之后再根据实际压力调整。另外部署的时候可以开启“预测”功能上传一张测试图片或者一段测试文本直接在控制台看返回结果不用写代码调用很方便。5.3 调用在线服务的几种方式部署成功之后你会得到一个API地址和认证信息。调用方式有几种用Python的requests库调用这是最通用的方式适合集成到你的应用里。需要构造请求头带上认证token然后把数据POST到API地址。用ModelArts SDK调用如果你在ModelArts的Notebook里可以直接用SDK调用不用手动处理认证。用Postman或者curl调用适合快速测试确认API是否正常工作。我一般先用curl测试一下确认API能通返回结果符合预期然后再写Python代码集成。调用的时候要注意请求体的格式要和推理脚本里的预处理对应。比如你的预处理期望的是base64编码的图片那请求体里就要传base64字符串不能传文件路径。提示在线服务部署之后如果一段时间没有请求实例可能会被自动停止取决于你的配置。如果你需要服务一直在线可以在部署配置里关闭自动停止或者设置一个较长的空闲时间。6. 那些官方文档没细说但很关键的实操经验6.1 关于Notebook实例的自动停止ModelArts的Notebook实例如果长时间不操作会自动停止这是为了帮你省钱。但有时候你正在跑一个长时间的训练中间去开了个会回来发现实例停了训练白跑了。所以如果你要在Notebook里跑长时间任务记得在设置里把自动停止时间调长或者干脆关闭。不过关闭之后即使你不使用实例也会一直计费所以用完记得手动停止。我自己的习惯是调试代码的时候用Notebook自动停止时间设为1小时。真正跑训练的时候用训练作业不依赖Notebook。6.2 关于OBS的存储费用OBS的存储费用很低但也不是完全免费。如果你上传了大量数据长期不用建议定期清理。另外OBS有几种存储类型标准存储、低频访问存储、归档存储价格依次降低但访问速度也依次变慢。对于训练数据一般用标准存储就行因为训练的时候需要频繁读取。对于训练完的模型文件如果不经常用可以转成低频访问存储省钱。6.3 关于训练作业的断点续训如果你的训练时间很长比如要跑几十个小时万一中间因为某种原因中断了从头开始跑就太浪费了。ModelArts的训练作业支持断点续训但需要你在代码里实现检查点checkpoint的保存和加载。具体做法是每隔几个epoch把模型权重和优化器状态保存到OBS的输出路径。训练作业重新启动的时候先从输出路径加载最新的checkpoint然后继续训练。这个功能很实用但需要你提前在代码里写好逻辑。我建议不管训练时间长短都加上checkpoint保存养成习惯。6.4 关于模型部署的冷启动问题在线服务部署之后第一次调用可能会有几秒钟的延迟这叫冷启动。因为平台需要加载模型、初始化环境。如果你的应用对首次调用延迟很敏感可以考虑保持一个最小实例数让服务一直处于热状态。或者用“模型预热”功能提前加载模型。另外如果你的模型很大加载时间很长可以考虑用模型压缩技术比如量化、剪枝减小模型体积加快加载速度。不过这会稍微影响精度需要根据实际场景权衡。7. 从一次完整的项目经历中提炼出的方法论7.1 先跑通链路再优化细节我刚开始用ModelArts的时候总想把所有细节都调好再跑。比如数据增强要加多少种、学习率要设多少、模型结构要不要改。结果折腾了好几天连一个完整的训练都没跑完。后来我改变策略先用一个极简的配置把数据上传、训练、部署整个链路跑通。哪怕模型精度很低哪怕只训练一个epoch只要链路通了心里就有底了。然后再在这个基础上逐步优化数据、调参、换模型。这个方法适用于任何新平台的学习。先跑通再优化不要一开始就追求完美。7.2 把配置参数化方便复现和调参不管是Notebook里的代码还是训练作业的脚本我都建议把所有的配置参数抽出来放在一个配置文件里或者用命令行参数传入。比如数据路径、输出路径、batch size、学习率、epoch数这些都不要硬编码在代码里。这样你换一个数据集或者想调参的时候只需要改配置不用改代码。在ModelArts的训练作业里你可以用“超参”功能来管理这些参数。每个超参有一个名字和默认值提交作业的时候可以覆盖。这样你可以在控制台看到每次训练用的超参是什么方便对比不同参数的效果。7.3 善用日志和可视化别靠猜训练过程中不要只盯着loss看。建议把loss、准确率、学习率等指标写到TensorBoard然后在ModelArts控制台查看曲线。这样你可以直观地看到模型是否在收敛有没有过拟合学习率是不是太大了。另外训练日志要保存好万一训练失败了日志是排查问题的唯一依据。我一般会在代码里加一个日志文件把所有的print输出同时写到文件里这样即使控制台的日志被刷掉了你还能在OBS里找到完整的日志文件。7.4 成本控制该省省该花花云上训练虽然方便但也是要花钱的。我的原则是调试用CPU训练用GPU部署按需选规格。调试代码的时候用CPU实例就够了便宜。训练的时候根据模型大小选GPU不要盲目选最贵的。部署的时候如果QPS不高用CPU实例也能扛住没必要上GPU。另外记得及时停止不用的实例和作业。ModelArts的Notebook实例和训练作业都是按小时计费的不用的时候一定要停止。我见过有人忘了停止一个月下来账单吓一跳。8. 写在最后一些个人体会用ModelArts做模型训练和部署最大的感受就是“省心”。它把那些重复的、繁琐的、容易出错的环境配置工作都封装好了让你可以专注于算法和业务逻辑。但这并不意味着你可以完全不懂底层原理。相反当你遇到问题的时候如果你懂Linux、懂Python、懂深度学习框架你就能更快地定位和解决问题。另外云平台的功能更新很快今天没有的功能明天可能就上线了。所以遇到问题的时候除了查文档也可以看看社区的帖子或者直接提工单。我提过几次工单响应速度还挺快的技术支持会帮你排查问题。最后分享一个小技巧如果你在Notebook里安装了一个包但训练作业里用不了那是因为训练作业用的是另一个镜像。你可以在训练作业的启动命令里加上pip install xxx或者把依赖写到一个requirements.txt里在启动命令里先安装依赖再跑训练。这个坑我踩过折腾了半天才发现是环境不一致导致的。希望这篇学习笔记能帮你少走一些弯路。云上做机器学习门槛比想象中低但细节比想象中多。动手试一次比看十篇教程都有用。