从本地到云端：ModelArts 模型训练与部署全流程实战

1. 从一台笔记本到云端算力：为什么我最终选了 ModelArts 做模型训练与部署

做深度学习这行的朋友大概都有过类似的经历：本地机器上跑个小模型还行，一旦上到 ResNet 或者 RoBERTa 这种量级的网络，显卡风扇就开始像直升机一样起飞，训练一个 epoch 要等半天，调参更是煎熬。我最早是用自己那台带 L20 显卡的工作站硬扛，后来发现显存根本不够用，batch size 只能压到 8，训练速度慢得让人怀疑人生。再后来试过各种免费 GPU 训练模型的平台，要么排队排到天荒地老，要么环境配半天跑不起来，要么训练到一半突然断连，模型文件全丢。

折腾了一圈之后，我把目光转向了 ModelArts。原因很简单：它把“模型训练”和“模型部署”这两件事串成了一条流水线，不用我在本地和云端之间来回倒腾数据、配环境、写推理服务。从数据上传、代码调试、训练任务提交，到模型注册、在线服务部署、接口调用，整个链路在一个平台里就能闭环。这篇文章就是把我这段时间踩过的坑、总结出来的实操经验完整地分享出来，适合那些手头算力有限、但又想正经跑通“训练+部署”全流程的开发者。不管你是刚接触深度学习模型部署的新手，还是已经用过其他平台想换个方案的老手，应该都能从里面找到能直接抄作业的东西。

2. 整体方案设计与核心思路拆解

2.1 为什么不是本地训练加手动部署

先说说我为什么放弃了“本地训练+手动部署”这条路线。最直接的原因是硬件成本。一张能扛住 ResNet 预训练模型微调的显卡，加上配套的主板、电源、散热，整套下来少说也要大几千甚至上万。而且本地部署 AI 模型还有个很现实的问题：你训练出来的模型，怎么对外提供服务？用 Flask 写个接口？那并发一上来就崩。用 Triton 或者 TorchServe？配置复杂度直接翻倍。更别提还要考虑内网穿透、域名备案、HTTPS 证书这些跟模型本身毫无关系的事情。

ModelArts 的思路是把这些脏活累活全部接管。训练侧，它提供按需使用的 GPU 算力，用完就释放，不用为闲置时间买单。部署侧，它把模型包装成在线服务，自动处理负载均衡、弹性伸缩、健康检查。我只需要关心两件事：模型结构对不对，推理逻辑有没有 bug。其余的运维层面的事情，平台兜底。

2.2 训练与部署的链路设计

整个流程我把它拆成四个阶段：数据准备、训练配置、模型训练、部署上线。每个阶段在 ModelArts 上都有对应的功能模块。

数据准备阶段，我把原始数据传到对象存储里，然后在 ModelArts 的数据管理模块做标注和格式转换。训练配置阶段，我选择用自定义脚本模式，因为我的模型结构有一些定制化的改动，用预置算法不够灵活。训练阶段就是提交任务、监控日志、等结果。部署阶段把训练产出的模型文件注册成模型，然后创建在线服务，拿到一个可以调用的 API 地址。

这个链路的好处是每个环节都有日志和版本记录。比如我训练了三个版本的模型，每个版本的超参数、损失曲线、评估指标都能查到，部署的时候可以指定用哪个版本。这在做 A/B 测试或者回滚的时候特别有用。

2.3 关键选型背后的考量

在训练框架上，我选的是 PyTorch。原因有两个：一是社区生态好，ResNet、RoBERTa 这些预训练模型的官方实现和第三方实现基本都是 PyTorch 版本最全；二是调试方便，动态图机制让我在写自定义层的时候能像写普通 Python 代码一样逐步调试。ModelArts 对 PyTorch 的支持也很成熟，预置镜像里常用的版本都有。

在部署方式上，我选的是在线服务而不是批量服务。因为我的场景是需要实时响应的，用户上传一张图片或者一段文本，期望在几百毫秒内拿到结果。在线服务支持自动扩缩容，流量高峰时自动增加实例，低谷时自动缩减，成本可控。

还有一个容易被忽略的选型点是模型格式。训练产出的 PyTorch 模型文件是 .pth 或者 .pt 格式，但部署的时候 ModelArts 需要把它转成推理框架能识别的格式。我试过直接部署 .pth 文件，也试过转成 ONNX 再部署。实测下来，对于 ResNet 这类结构规整的模型，转 ONNX 之后推理速度有大概 15% 到 20% 的提升，因为 ONNX Runtime 在算子融合和内存复用上做了不少优化。但对于有自定义算子的模型，转 ONNX 可能会失败，这时候就只能用原生格式部署。

3. 核心细节解析与实操要点

3.1 数据准备：别小看这一步

数据准备看起来简单，但实际上是最容易出问题的环节。我遇到过好几次训练报 nan 的情况，排查到最后发现是数据里混进了损坏的图片文件，解码出来是空数组，送进网络之后梯度直接爆炸。

在 ModelArts 上，我通常把数据放在对象存储的桶里，目录结构按照类别分好。比如做图像分类，就是 train/class_a/、train/class_b/ 这样的结构。然后在数据管理里创建一个数据集，选择图像分类的标注类型，平台会自动扫描目录结构生成标签。

这里有个细节：ModelArts 的数据集支持版本管理。我建议每次对数据做增删改之后都创建一个新版本，这样训练的时候可以明确指定用哪个版本的数据。不然过了一段时间回头看，根本记不清当时用的是哪批数据。

对于文本类任务，比如用 RoBERTa 中文预训练模型做分类，数据格式通常是 JSON Lines，每行一个样本，包含 text 和 label 两个字段。上传之前最好用脚本检查一遍，确保没有空文本、没有非法字符、标签分布没有严重倾斜。

注意：数据上传到对象存储之后，ModelArts 的数据集创建不会自动同步更新。如果后续往桶里加了新文件，需要手动触发数据集的重新扫描，否则训练时用的还是旧数据。

3.2 训练脚本的编写要点

ModelArts 的自定义脚本训练模式要求代码入口是一个 Python 文件，平台会通过命令行参数把数据路径、模型输出路径、超参数传进来。我一般用 argparse 来接收这些参数，然后在脚本里根据参数决定行为。

一个典型的训练脚本结构是这样的：先解析参数，然后初始化分布式环境（如果用多卡的话），接着构建数据加载器、模型、优化器、学习率调度器，最后写训练循环和验证循环。每个 epoch 结束后把模型 checkpoint 保存到指定的输出目录，平台会自动把这些文件收集起来。

这里有几个容易踩的坑。第一，日志输出要用 print 或者 logging，但不要用 tqdm 这种进度条库，因为平台收集日志的方式可能导致进度条刷屏，把有用的信息淹没。第二，模型保存路径一定要用平台传进来的参数，不要硬编码成本地的某个路径，否则训练完了模型文件找不到。第三，如果用了预训练模型，比如 ResNet 预训练模型，要确保加载权重的时候设置正确的参数，不然可能因为类别数不匹配报错。

import argparse import torch import torch.nn as nn from torchvision import models def parse_args(): parser = argparse.ArgumentParser() parser.add_argument('--data_url', type=str, default='./data') parser.add_argument('--train_url', type=str, default='./output') parser.add_argument('--epochs', type=int, default=10) parser.add_argument('--batch_size', type=int, default=32) parser.add_argument('--lr', type=float, default=0.001) return parser.parse_args() def main(): args = parse_args() device = torch.device('cuda' if torch.cuda.is_available() else 'cpu') model = models.resnet50(pretrained=True) num_features = model.fc.in_features model.fc = nn.Linear(num_features, 10) model = model.to(device) criterion = nn.CrossEntropyLoss() optimizer = torch.optim.Adam(model.parameters(), lr=args.lr) for epoch in range(args.epochs): model.train() running_loss = 0.0 # 训练循环省略具体数据加载逻辑 print(f'Epoch {epoch+1}, Loss: {running_loss:.4f}') torch.save(model.state_dict(), f'{args.train_url}/model_epoch_{epoch+1}.pth') if __name__ == '__main__': main()

3.3 超参数的选择与调优

超参数这块我踩过的坑最多。学习率设大了，损失直接飞上天；设小了，训练半天不收敛。batch size 受显存限制，不能无限大。还有权重衰减、学习率预热、余弦退火这些策略，组合起来能调出一堆花样。

我的经验是，先用一个比较保守的配置跑通全流程，确认数据和代码没问题，然后再逐步调优。比如 ResNet 微调，初始学习率从 0.001 开始，batch size 设成 32，用 Adam 优化器。跑几个 epoch 看损失曲线，如果下降太慢就把学习率调大一点，如果震荡厉害就调小一点。

ModelArts 支持超参数自动搜索，可以指定一组候选值，平台会自动组合跑多个训练任务，最后根据指定的指标选出最优的一组。这个功能在调参阶段能省不少时间，但要注意控制搜索空间的大小，不然任务数量会爆炸式增长。

3.4 模型部署的格式转换

训练产出的模型文件要部署上线，中间有一个格式转换的步骤。ModelArts 的模型管理支持多种推理框架，包括 TensorFlow、PyTorch、ONNX、MindSpore 等。我一般优先考虑转 ONNX，因为通用性好，推理性能也不错。

转 ONNX 的核心是构造一个 dummy input，然后调用 torch.onnx.export。dummy input 的 shape 要和实际推理时一致，比如图像分类就是 (1, 3, 224, 224)。转换过程中要指定输入和输出的名字，部署的时候会用到。

import torch import torch.onnx model = models.resnet50(pretrained=False) model.fc = nn.Linear(model.fc.in_features, 10) model.load_state_dict(torch.load('model_epoch_10.pth')) model.eval() dummy_input = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, 'model.onnx', input_names=['input'], output_names=['output'], dynamic_axes={'input': {0: 'batch_size'}, 'output': {0: 'batch_size'}}, opset_version=11 )

这里有个细节：dynamic_axes 参数可以让模型支持动态 batch size，部署的时候能根据请求量自动调整。如果不设置，模型就固定了 batch size，请求多了会排队。

提示：转 ONNX 之前一定要把模型切到 eval 模式，否则 BatchNorm 和 Dropout 层的行为会和训练时一样，导致推理结果不稳定。

4. 实操过程与核心环节实现

4.1 从零搭建训练任务的完整流程

我第一次在 ModelArts 上跑训练任务的时候，光是搞清楚各个模块之间的关系就花了大半天。现在回头看，其实流程很清晰，只是当时不熟悉。

第一步是创建桶和目录。在对象存储服务里创建一个桶，然后在桶里建几个目录：data 放原始数据，code 放训练脚本，output 放训练产出。目录结构清晰了，后面配置的时候不容易搞混。

第二步是上传数据。小文件可以直接在网页上拖拽上传，大文件建议用命令行工具，支持断点续传。我一般把数据打包成 zip 上传，然后在训练脚本里解压，这样比传几万个小文件快得多。

第三步是创建训练作业。在 ModelArts 的控制台里选择“训练管理”->“训练作业”->“创建”，然后依次填写基本信息、参数配置、资源规格。基本信息里要指定代码目录和启动文件，参数配置里要填数据路径和输出路径，资源规格里选 GPU 型号和数量。

第四步是提交任务并监控。任务提交后可以在日志页面看到实时输出，包括每个 epoch 的损失、准确率、学习率等信息。如果发现异常，可以随时停止任务，修改代码后重新提交。

4.2 训练过程中的监控与调优

训练任务跑起来之后，监控是关键。我主要看三个东西：损失曲线、学习率变化、GPU 利用率。

损失曲线在 ModelArts 的 TensorBoard 集成里可以看到。如果训练损失下降但验证损失上升，说明过拟合了，需要加正则化或者早停。如果两条曲线都震荡得厉害，可能是学习率太大或者 batch size 太小。

GPU 利用率在资源监控页面能看到。如果利用率长期低于 50%，说明数据加载是瓶颈，需要增加 DataLoader 的 num_workers 或者把数据预处理放到 GPU 上做。如果利用率接近 100% 但训练速度还是慢，那就是模型本身计算量大，只能换更强的显卡或者优化模型结构。

学习率的变化曲线也很重要。我用余弦退火的时候，学习率会从初始值慢慢降到接近零，如果曲线形状不对，可能是调度器的配置有问题。

4.3 模型部署上线的详细步骤

训练完成之后，模型文件会保存在输出目录里。接下来就是把它部署成在线服务。

第一步是导入模型。在 ModelArts 的“模型管理”里创建模型，指定模型文件的来源（可以是训练作业的输出，也可以是手动上传的），选择推理框架和版本，配置输入输出的格式。

第二步是创建在线服务。在“部署上线”里选择“在线服务”，然后选择刚才创建的模型，配置计算节点规格和实例数量。如果流量不大，一个实例就够了；如果预期有并发，可以设置自动扩缩容策略。

第三步是测试服务。服务创建好之后会分配一个 API 地址，可以用 curl 或者 Python 的 requests 库发请求测试。我一般先用一张测试图片跑一遍，确认返回结果的格式和内容都正确，然后再做压力测试。

import requests import base64 import json with open('test.jpg', 'rb') as f: img_base64 = base64.b64encode(f.read()).decode() payload = { 'input': { 'image': img_base64 } } response = requests.post( 'https://your-service-endpoint/v1/infers/xxx', headers={'Content-Type': 'application/json'}, data=json.dumps(payload) ) print(response.json())

4.4 性能优化与成本控制

部署上线之后，性能和成本是两个需要持续关注的点。

性能方面，我做了几件事：一是把模型转成 ONNX 并用 ONNX Runtime 推理，速度提升了大概 18%；二是开启了批处理，把多个请求攒在一起送进模型，吞吐量翻了一倍多；三是调整了实例规格，从 CPU 换到 GPU 之后，单次推理延迟从 200ms 降到了 30ms 左右。

成本方面，我设置了自动扩缩容的上下限，最少 1 个实例，最多 3 个实例。平时流量小的时候只有一个实例在跑，费用很低；流量高峰时自动扩展到 3 个，扛过高峰后又缩回来。另外，训练任务我尽量用按需计费，跑完就释放，不长期占用资源。

5. 常见问题与排查技巧实录

5.1 训练报 nan 的排查思路

训练报 nan 是我遇到最多的问题，没有之一。排查思路可以按照数据、模型、超参数三个方向来。

数据方向：检查有没有损坏的文件、有没有标签越界、有没有数值异常大的特征。我写了一个简单的脚本，遍历所有样本，统计每个特征的均值和方差，发现异常就打印出来。

模型方向：检查有没有除零操作、有没有 log 负数、有没有梯度爆炸。可以在训练循环里加梯度裁剪，把梯度的范数限制在一个范围内。

超参数方向：学习率太大是最常见的原因。可以先把学习率调小一个数量级试试，如果 nan 消失了，再慢慢往上调。

5.2 部署服务启动失败的常见原因

部署服务启动失败，日志里通常会给出原因。我遇到过几种：模型文件路径不对、推理脚本有语法错误、依赖包版本不兼容、端口被占用。

模型文件路径不对是最容易解决的，检查一下模型管理里配置的路径和实际文件位置是否一致。推理脚本的语法错误需要看日志里的堆栈信息，定位到具体哪一行。依赖包版本不兼容比较麻烦，需要在推理脚本里明确指定版本，或者把依赖打包成自定义镜像。

5.3 推理结果不稳定的处理

推理结果不稳定，同一个输入两次调用返回不同的结果，这通常是模型没有切到 eval 模式导致的。PyTorch 的模型默认是 train 模式，BatchNorm 会使用当前 batch 的统计量，Dropout 会随机丢弃神经元。部署之前一定要调用 model.eval()。

还有一种可能是预处理不一致。训练时用的归一化参数和推理时用的不一样，导致输入分布偏移。解决办法是把预处理逻辑固化到推理脚本里，确保和训练时完全一致。

5.4 常见问题速查表

5.5 几个让我印象深刻的踩坑经历

有一次我训练一个文本分类模型，用的是 RoBERTa 中文预训练模型。训练集上准确率能到 95%，但验证集只有 70% 出头。我一开始以为是过拟合，加了 Dropout 和权重衰减，效果不明显。后来仔细检查数据，发现训练集和验证集的标签分布差异很大，训练集里某个类别的样本占了 60%，验证集里这个类别只有 20%。重新划分数据之后，验证集准确率直接上到了 88%。

还有一次部署图像分类服务，测试的时候发现单张图片推理要 500ms，远超预期的 50ms。排查了半天，发现是推理脚本里每次请求都重新加载了一遍模型。把模型加载移到初始化函数里，只加载一次，延迟直接降到了 40ms。

这些坑的共同点是：问题不在模型本身，而在数据和工程实现上。深度学习项目里，模型结构往往不是瓶颈，数据质量和工程细节才是。

6. 一些关于平台选择的个人看法

我用过不少训练平台，有本地的，有云端的，也有混合的。每个平台都有自己的定位和适用场景。ModelArts 给我的感觉是“全”和“稳”。全是指功能覆盖了从数据到部署的完整链路，不用在多个工具之间来回切换。稳是指训练和部署的稳定性不错，我跑了这么多次任务，没有遇到过平台层面的故障导致任务失败。

当然它也不是没有缺点。比如自定义镜像的构建速度有时候比较慢，冷启动需要等几分钟。再比如超参数搜索的并行度受限于配额，不能无限扩展。但这些在我看来都是可以接受的 trade-off，毕竟自己搭一套同等能力的系统，成本要高得多。

如果你手头有 GPU 资源，本地训练也不是不行。但如果你像我一样，不想在硬件和运维上花太多精力，想把时间集中在模型和数据上，那 ModelArts 这类平台是值得考虑的。特别是对于需要快速迭代、频繁部署的场景，平台提供的自动化能力能省下大量时间。

最后分享一个小技巧：训练任务提交之前，先用小样本数据跑一遍完整流程，确认代码没有低级错误。我一般会从训练集里抽 100 条数据，把 epoch 设成 1，跑通之后再提交全量任务。这样即使有问题，也能在几分钟内发现，不用等几个小时才知道失败。