ModelArts训练部署闭环：从数据OBS治理到在线服务高可用

1. 为什么ModelArts不是“另一个云平台”，而是训练部署闭环的实操加速器

很多人第一次看到“华为云ModelArts”时，下意识会把它归类为“又一个AI开发平台”，和市面上其他名字带“Studio”“Platform”“Hub”的工具划进同一堆——点开控制台，扫一眼界面，觉得无非是把Jupyter Notebook搬上云、加几个拖拽组件、再配个模型管理页。我最初也这么想，直到在某高校实验室协助一个图像分割项目时被现实狠狠教育了一次：本地GPU服务器跑通ResNet50只要2小时，但把同样代码迁移到ModelArts后，训练任务卡在“资源调度中”长达17小时；更讽刺的是，等终于跑完，导出的模型在本地推理时精度掉了3.2个百分点，而团队没人能说清问题出在数据预处理Pipeline的哪一环、模型导出时的ONNX版本兼容性，还是服务部署时的TensorRT优化开关没关对。

这件事让我彻底放下“平台只是换了个地方写代码”的轻视心态。ModelArts真正的价值，根本不在它长得像不像Jupyter，而在于它把从原始数据上传→自动标注→分布式训练→模型评估→一键部署→在线/批量推理→性能监控这一整条工业级AI流水线，用一套统一的身份认证、存储路径、日志体系和API契约串了起来。它不解决“怎么写loss函数”这种算法问题，但它死死卡住“数据版本和代码版本不一致导致复现失败”“训练环境和推理环境CUDA驱动差异引发NaN输出”“模型服务上线后QPS突降却查不到是CPU打满还是内存泄漏”这些让工程师半夜爬起来改配置的硬伤。

举个最典型的例子：你在Notebook里用cv2.imread()读图，本地没问题；但ModelArts默认挂载OBS桶作为工作目录，路径是s3://bucket-name/data/train/，你直接写cv2.imread("s3://...")会报错。这时候ModelArts提供的obsutil命令行工具和moxingPython SDK就不是可选项，而是必经之路——它强制你把“数据访问”这个动作显式封装成moxing.file.copy_parallel("s3://...", "/cache/")，再用本地路径读取。表面看多写了两行，实际却把数据加载逻辑和存储后端解耦了。后续你把训练任务从按需规格（p3.2xlarge）切换到竞价实例（spot instance），或者从华东-上海一区迁移到华南-广州三区，只要OBS桶权限配置正确，代码一行不用改。这种“约束即自由”的设计哲学，才是ModelArts区别于纯计算平台的核心。

所以这篇笔记不叫“ModelArts入门教程”，而叫“学习笔记”——因为它的使用过程本身就是一场对AI工程化思维的重塑。你会反复遇到“为什么这里不能直接用torch.load()”“为什么评估指标在训练日志里显示正常，但部署后接口返回全是0”这类问题。答案往往不在文档第几章，而在你是否理解ModelArts把“环境”“数据”“模型”“服务”这四个实体，用OBS桶、训练作业、模型包、在线服务这四个原子对象进行了强绑定。接下来的内容，我会带着你亲手走完一个完整闭环：从零准备数据集，到最终用curl调通一个返回JSON格式分割掩码的HTTP接口。所有步骤都基于真实踩坑记录，包括那些官方文档里不会写的细节，比如OBS桶的跨区域复制延迟、训练作业中断后的断点续训陷阱、以及为什么在线服务的“实例规格”选错会导致504超时而非500错误。

2. 数据准备阶段：OBS桶不是网盘，而是模型生命周期的“唯一真相源”

很多新手在ModelArts上栽的第一个跟头，不是代码写错，而是数据放错了地方。他们习惯性地把标注好的COCO格式JSON文件和图片文件夹，用浏览器上传到OBS控制台的某个文件夹里，然后在Notebook里写os.listdir("/home/ma-user/work/data/")——结果返回空列表。这是因为ModelArts的Notebook实例默认挂载的是临时存储卷（/home/ma-user/work），它只在实例运行期间存在，重启即清空；而OBS桶是独立的、持久化的对象存储服务，两者之间没有自动同步关系。你上传到OBS的数据，必须通过显式操作才能“拉”进Notebook环境。

2.1 OBS桶结构设计：用路径即Schema的工程实践

ModelArts对OBS路径有强约定，这不是为了增加复杂度，而是为了支撑后续自动化流程。以一个语义分割项目为例，我在OBS中创建了如下结构：

s3://my-ai-project/ ├── data/ │ ├── raw/ # 原始未标注图片（jpg/png） │ ├── annotated/ # 标注文件（COCO JSON / VOC XML / 自定义CSV） │ └── processed/ # 预处理后数据（resize后的图片、mask二值图） ├── code/ │ ├── train.py # 训练脚本 │ ├── infer.py # 推理脚本 │ └── utils/ # 公共函数 ├── models/ │ └── checkpoints/ # 训练保存的.pth文件（由ModelArts自动写入） └── logs/ └── train/ # 训练日志（ModelArts自动收集）

关键点在于data/processed/这个目录。ModelArts的“自动学习”功能和部分预置算法，要求训练数据必须符合特定目录结构（如train/images/和train/masks/并列）。但如果你直接在OBS里手动建这两个文件夹，会发现训练作业启动后报错：“找不到images子目录”。原因在于ModelArts在启动训练容器时，会执行一个cp -r s3://my-ai-project/data/processed/* /cache/dataset/操作，它只递归拷贝一级子目录下的内容。也就是说，s3://my-ai-project/data/processed/train/images/会被拷贝成/cache/dataset/images/，而/cache/dataset/train/images/这个路径根本不存在。解决方案是把数据组织成扁平结构：

s3://my-ai-project/data/processed/ ├── images/ │ ├── 001.jpg │ └── 002.jpg └── masks/ ├── 001.png └── 002.png

这样cp -r后，/cache/dataset/下直接就是images/和masks/两个文件夹，训练脚本能正常读取。这个细节在官方文档的“数据集准备”章节里提了一句，但没强调其底层机制，导致大量用户卡在这里超过半天。

2.2 数据预处理：在Notebook里完成，但要为训练作业留好“钩子”

预处理不能在训练脚本里做，因为ModelArts的分布式训练会启动多个Worker，每个Worker都会重复执行一遍cv2.resize()，造成巨大I/O开销。正确做法是在Notebook里一次性处理好，存回OBS。但这里有个陷阱：OBS的上传是分块进行的，大文件（>100MB）上传可能超时。我处理一个12GB的医学影像数据集时，用moxing.file.copy_parallel()直接上传整个文件夹，结果在98%进度卡住，重试三次都失败。

最终方案是拆解为“小文件+校验”：

import moxing as mox from pathlib import Path # 1. 本地预处理（resize, normalize等） input_dir = Path("/home/ma-user/work/raw_data") output_dir = Path("/home/ma-user/work/processed_data") # ... 执行预处理逻辑 ... # 2. 分批上传，每批不超过500个文件 file_list = list(output_dir.rglob("*")) for i in range(0, len(file_list), 500): batch = file_list[i:i+500] # 上传前生成MD5校验文件 with open(f"/tmp/batch_{i}.md5", "w") as f: for p in batch: if p.is_file(): md5 = mox.file.get_md5(p) f.write(f"{md5} {p.name}\n") # 上传文件+校验文件 mox.file.copy_parallel( str(output_dir), "s3://my-ai-project/data/processed/", num_threads=32 )

上传完成后，在OBS控制台检查batch_0.md5文件是否成功写入，再对比本地MD5。这比盲目重试高效得多。另外提醒：ModelArts的Notebook实例默认磁盘空间只有100GB，处理大型数据集时，务必在/cache/目录（约200GB）下操作，否则/home/ma-user/work/写满会导致实例崩溃。

2.3 数据版本管理：用OBS的“多版本”功能替代Git LFS

团队协作时，常有人问：“怎么回滚到上周的数据集？”如果靠人工重命名data_v1/data_v2/，很快就会陷入混乱。OBS原生支持多版本控制（Versioning），这才是正解。开启后，每次覆盖同名文件，OBS会自动保存旧版本，并生成唯一版本ID。在ModelArts训练作业配置里，你可以指定data_path为s3://my-ai-project/data/processed/?versionId=CAEQARiBgIDR6vLXmxciIDQyZjYzNzU5LTc1MjQtNDQyYS1iYjE1LWQxZDkxZjA5ZTg1MQ==，确保训练永远基于确定版本的数据。这个功能在ModelArts控制台的“数据管理”页面不可见，必须通过OBS控制台或obsutil命令行开启：

obsutil cp -r /local/path/ s3://bucket-name/path/ --version-id

提示：开启OBS多版本后，存储费用会略微增加（因保留历史版本），但相比因数据不一致导致的模型效果波动带来的损失，这笔投入绝对值得。我们曾因误用新标注数据训练旧模型，导致线上服务准确率下降，排查耗时两天。

3. 模型训练：不只是提交脚本，而是理解ModelArts的“资源-代码-日志”三角约束

在ModelArts上启动一次训练，远不止是点“创建训练作业”按钮那么简单。它背后是一套精密的资源调度与生命周期管理机制。我见过太多人把本地能跑的PyTorch脚本，原封不动上传后提交训练，结果在Preparing environment阶段卡死，或者训练到一半报OOM Killed。问题根源在于，没有理解ModelArts对训练环境的三个硬性约束：镜像环境、启动命令、日志路径。

3.1 镜像选择：自定义镜像不是炫技，而是解决CUDA/cuDNN版本锁死的刚需

ModelArts提供预置镜像（如pytorch_1.8.1-cuda_11.1-cudnn8.0.5），看似省事，但隐患极大。某次我们用预置镜像训练一个基于Deformable DETR的检测模型，训练到第3个epoch时，torch.cuda.amp.autocast模块突然报RuntimeError: CUDA error: invalid device ordinal。查了三天才发现，该镜像的CUDA驱动版本（450.80.02）与ModelArts底层GPU节点的驱动（470.182.03）不兼容，导致AMP混合精度在某些显卡型号上失效。

解决方案是构建自定义镜像。核心原则：基础镜像必须与ModelArts GPU节点驱动完全匹配。通过ModelArts文档查到当前华东-上海一区GPU节点驱动为nvidia-driver-470.182.03，则Dockerfile应为：

FROM nvidia/cuda:11.4.2-runtime-ubuntu20.04 # 安装匹配的cuDNN RUN apt-get update && apt-get install -y libcudnn8=8.2.4.15-1+cuda11.4 # 安装PyTorch（必须指定CUDA版本） RUN pip3 install torch==1.10.2+cu113 torchvision==0.11.3+cu113 -f https://download.pytorch.org/whl/torch_stable.html # 复制代码 COPY . /home/ma-user/work/

构建后推送到华为云SWR镜像仓库，在训练作业中选择该镜像。虽然多花2小时，但换来的是训练稳定性。自定义镜像的另一个好处是预装私有库（如公司内部的my-vision-utils），避免每次训练都pip install -e .，节省启动时间。

3.2 启动命令：--model_dir参数是模型保存的“法律契约”

ModelArts要求训练脚本必须接受--model_dir参数，并将模型文件（.pth）、配置文件（.yaml）、字典（.pkl）全部保存到该路径下。这不是建议，而是强制规则。如果你在代码里写torch.save(model.state_dict(), "best_model.pth")，模型会保存在容器根目录，训练结束后被自动清理，你什么也拿不到。

正确写法是解析参数并构造绝对路径：

import argparse import os import torch parser = argparse.ArgumentParser() parser.add_argument("--model_dir", type=str, default="/cache/model") # 必须！ args = parser.parse_args() # 保存模型 torch.save(model.state_dict(), os.path.join(args.model_dir, "best_model.pth")) # 保存配置 with open(os.path.join(args.model_dir, "config.yaml"), "w") as f: yaml.dump(config, f)

/cache/model是ModelArts约定的模型输出目录，训练结束后，系统会自动将该目录下的所有文件打包为“模型包”，并注册到ModelArts的“模型管理”服务中。这个过程是原子性的——要么全成功，要么全失败。如果--model_dir指向不存在的路径，训练会直接失败；如果路径存在但无写入权限，会报Permission denied。因此，务必在训练脚本开头添加：

os.makedirs(args.model_dir, exist_ok=True)

3.3 日志解析：print()不是日志，logging.info()才是“可审计证据”

ModelArts的训练作业页面会实时展示日志流，但很多人误以为print("Epoch 1 loss: 0.23")就能被系统捕获。实际上，ModelArts只采集标准输出（stdout）和标准错误（stderr）流，且对日志格式有隐含要求：必须包含时间戳和级别标识，否则会被过滤掉。

推荐做法是使用Python内置logging模块，并配置为输出到stdout：

import logging import sys # 创建logger logger = logging.getLogger(__name__) logger.setLevel(logging.INFO) # 创建handler，输出到stdout handler = logging.StreamHandler(sys.stdout) handler.setLevel(logging.INFO) # 设置日志格式（必须包含%(asctime)s和%(levelname)s） formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s') handler.setFormatter(formatter) logger.addHandler(handler) # 使用 logger.info(f"Epoch {epoch} loss: {loss:.4f}")

这样，ModelArts的日志系统才能正确解析时间、级别和消息体，并在控制台按时间排序显示。更重要的是，这些日志会被自动上传到OBS的logs/train/目录，供后续审计。我们曾用这个特性定位一个偶发的梯度爆炸问题：通过分析连续5次训练的日志时间戳，发现异常发生在凌晨3:17:22，恰好是集群自动维护窗口，从而确认是硬件瞬时故障，而非代码缺陷。

注意：不要在训练脚本中使用logging.basicConfig()，因为它会覆盖ModelArts预设的日志处理器，导致日志无法上传到OBS。

4. 模型部署：从“能跑通”到“能扛住”，在线服务的三道生死线

模型训练成功，只是万里长征第一步。部署环节的挑战，往往比训练更隐蔽、更致命。我参与过一个OCR服务上线，训练准确率98.5%，但部署后线上请求的平均响应时间高达8.2秒，P99延迟突破15秒，用户投诉如潮。排查发现，问题不在模型本身，而在ModelArts在线服务的三个关键配置上：实例规格、并发数、健康检查路径。这三者构成一道“生死线”，任何一项失衡，服务就会从“可用”滑向“不可用”。

4.1 实例规格：GPU不是万能的，“CPU+内存”才是吞吐量的天花板

新手常犯的错误是：既然模型是GPU训练的，那部署当然选GPU实例（如pi2系列）。但这是巨大误区。ModelArts的GPU实例（如pi2.4xlarge）配备1张V100，但只有16核CPU和64GB内存。当你的服务需要同时处理100个并发请求时，GPU计算只占整个请求生命周期的30%，剩下的70%时间花在：HTTP请求解析、图片Base64解码、预处理（resize/normalize）、后处理（坐标转换/文本拼接）、JSON序列化、网络传输。这些全是CPU密集型任务。

我们实测过同一模型在不同规格下的QPS（每秒查询数）：

结果令人震惊：纯CPU实例的吞吐量反而是GPU实例的2.3倍。原因在于，GPU实例的CPU资源被严重争抢——当100个请求同时到达，32个线程能并行处理，而16核CPU在上下文切换上消耗巨大。最终方案是：用高配CPU实例（c3.8xlarge）做在线服务，GPU实例（pi2.4xlarge）专用于批量推理（Batch Inference）任务。后者适合处理离线图片队列，可以启用torch.backends.cudnn.benchmark=True和FP16加速，吞吐量提升4倍。

4.2 并发配置：max_batch_size不是越大越好，而是要匹配GPU显存与CPU缓存

ModelArts在线服务允许设置max_batch_size（最大批处理大小），很多人设为64甚至128，认为越大吞吐越高。但这是灾难性配置。以一个ResNet50分类模型为例，单张224×224图片在FP32下占用显存约1.2GB。max_batch_size=64意味着峰值显存需求为76.8GB，远超V100的32GB，必然触发OOM Killer，服务进程被强制终止。

正确做法是根据模型输入尺寸和精度，精确计算显存占用：

import torch from torch.cuda import memory_summary # 在训练脚本中加入显存分析 def estimate_memory(model, input_shape, dtype=torch.float32): dummy_input = torch.randn(*input_shape).to(dtype).cuda() model = model.cuda().to(dtype) with torch.no_grad(): output = model(dummy_input) print(memory_summary()) # 输出详细显存占用 return output # 示例：ResNet50, [1,3,224,224], FP16 estimate_memory(torchvision.models.resnet50(), [1,3,224,224], torch.half)

实测结果显示，该模型在FP16下，batch_size=16时显存占用28.5GB，安全余量仅3.5GB。因此在线服务的max_batch_size应设为8，留足余量应对梯度计算、中间激活缓存等动态开销。同时，min_scale（最小实例数）设为2，防止单点故障；max_scale（最大实例数）设为5，配合API网关的限流策略，避免突发流量压垮集群。

4.3 健康检查：/health接口不是摆设，而是服务弹性的“心跳传感器”

ModelArts在线服务默认每30秒向/health路径发送GET请求，检查服务是否存活。如果连续3次失败，系统会自动重启该实例。很多人忽略这个接口，或者简单返回{"status": "ok"}，结果导致服务“假死”：进程还在，但GPU显存被占满，新请求排队，健康检查却一直成功。

真正健壮的/health实现，必须检查三项核心资源：

from flask import Flask, jsonify import torch import psutil import GPUtil app = Flask(__name__) @app.route('/health') def health_check(): # 1. CPU使用率 < 90% cpu_percent = psutil.cpu_percent(interval=1) if cpu_percent > 90: return jsonify({"status": "unhealthy", "reason": "cpu_overload"}), 503 # 2. 内存使用率 < 85% mem = psutil.virtual_memory() if mem.percent > 85: return jsonify({"status": "unhealthy", "reason": "memory_overload"}), 503 # 3. GPU显存使用率 < 95%（如果有GPU） gpus = GPUtil.getGPUs() if gpus: gpu_util = gpus[0].memoryUtil * 100 if gpu_util > 95: return jsonify({"status": "unhealthy", "reason": "gpu_memory_full"}), 503 return jsonify({"status": "healthy"}), 200

这个接口让ModelArts能感知到“资源过载”级别的异常，而非仅仅“进程崩溃”。当GPU显存达95%时，健康检查失败，实例被重启，新实例启动后显存清空，服务自动恢复。我们曾用此机制将一次因内存泄漏导致的服务降级，从人工介入的45分钟，缩短到自动恢复的2分钟。

提示：/health接口的响应时间必须<1秒，否则会被ModelArts判定为超时。因此检查逻辑要极简，避免调用复杂模型或数据库。

5. 端到端验证：用curl和Postman完成“最后一公里”的可信交付

模型部署成功，控制台显示“服务状态：运行中”，但这只是万里长征的99%。最后1%——即外部系统能否稳定、正确、高效地调用你的服务——才是客户体验的终极裁判。我见过太多项目，开发人员在ModelArts控制台的“在线调试”里测试成功，就宣布“服务上线”，结果业务方集成时发现：返回的JSON字段名和约定不符、Base64图片编码后长度超限、批量请求时服务直接504超时。这些“最后一公里”问题，必须用生产环境等效的工具来验证。

5.1 curl实战：剥离UI干扰，直击HTTP协议本质

ModelArts控制台的“在线调试”是一个简化版Postman，它隐藏了HTTP头、重定向、连接复用等细节。真实业务调用（如Java Spring Boot的RestTemplate、Python的requests）会严格遵循HTTP协议。因此，必须用curl进行原子级验证。

以一个图像分割服务为例，其期望输入是JSON：

{ "image": "base64_encoded_string", "threshold": 0.5 }

在ModelArts控制台调试时，你只需粘贴Base64字符串。但curl命令必须精确构造：

# 1. 将图片转为Base64（注意：-w '' 去除换行符，否则Base64无效） IMAGE_BASE64=$(base64 -w '' ./test.jpg) # 2. 构造JSON payload（用单引号避免shell变量扩展） PAYLOAD='{"image":"'"$IMAGE_BASE64"'","threshold":0.5}' # 3. 发送POST请求（关键：-H指定Content-Type，-d传body） curl -X POST \ https://your-service-endpoint.com/v1/inference \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_TOKEN" \ -d "$PAYLOAD" \ -o response.json \ -w "\nHTTP Status: %{http_code}\nTime: %{time_total}s\n"

这个命令的输出会告诉你：

• HTTP Status: 200：服务返回成功状态码
• Time: 1.234s：端到端耗时（含DNS解析、TCP握手、TLS协商、请求发送、响应接收）
• response.json：原始响应体，可用于后续JSON Schema校验

如果Time超过2秒，说明服务有性能瓶颈；如果HTTP Status是504，说明网关超时，需检查后端实例的max_batch_size；如果是400，检查Base64字符串是否含非法字符（如换行符）。

5.2 Postman进阶：用Collection Runner模拟真实业务流量

单次curl只能验证“能不能用”，而Postman的Collection Runner能验证“能不能扛住”。我们为一个OCR服务创建了包含3个请求的Collection：

• Health Check：GET/health，验证服务存活
• Single Image：POST/v1/inference，传1张标准尺寸图片
• Batch Images：POST/v1/batch，传10张图片的Base64数组

然后用Runner运行100次迭代，设置Delay为100ms（模拟QPS=10），并勾选Keep variable values。运行后，Postman自动生成报告：

• 请求成功率：99.8%（2次504超时）
• 平均响应时间：320ms（P95=410ms）
• 最大内存占用：1.8GB（在Batch Images请求中）

这份报告比ModelArts控制台的“平均延迟”数字更有说服力，因为它包含了真实业务场景的请求模式。更重要的是，Runner会记录每次失败的完整请求/响应，我们可以直接定位那2次504：它们都发生在Batch Images请求的第78次和第92次，且时间戳集中在凌晨2:15左右——这与集群自动扩缩容的时间窗口吻合，从而确认是弹性策略配置过激，而非服务代码缺陷。

5.3 生产就绪检查清单：一份交付前必须签字的“死亡清单”

在把服务地址交给业务方之前，我坚持执行一份10项检查清单，任何一项不通过，都不允许上线。这份清单源于多次血泪教训：

这份清单不是形式主义，而是把“交付”从一个动作，变成一个可审计、可追溯、可问责的过程。每一次上线前，我和后端负责人、测试负责人一起逐项核对，签字确认。它让我们团队在过去18个月里，保持了99.95%的服务可用率，没有一次P0级事故。

6. 经验沉淀：那些ModelArts文档里不会写的“老司机手札”

写到这里，这篇笔记已远超一篇技术教程的范畴。它是我过去两年在多个项目中，用真金白银买来的教训、深夜调试的灵光、以及和华为云技术支持电话会议里抠出来的细节。这些经验，散落在无数个“为什么”之后，而文档往往只告诉你“怎么做”。以下是我整理的7条“手札”，每一条都对应一个曾让我抓狂的真实场景。

6.1 “断点续训”不是魔法，而是对--model_dir和--resume_from_checkpoint的双重信仰

训练一个大模型常需数天，中途因配额不足、节点故障中断是常态。ModelArts支持断点续训，但条件苛刻：

• 训练脚本必须接受--resume_from_checkpoint参数，并在代码中加载该路径的checkpoint.pth
• --model_dir必须与上次训练完全一致（路径、OBS桶、版本ID）
• 最关键的是：OBS桶的“多版本”功能必须开启。否则，--model_dir指向的路径下，checkpoint.pth文件会被新训练覆盖，旧版本丢失。

我曾因忘记开启OBS多版本，导致一次36小时的训练中断后，只能从头开始。后来形成铁律：创建OBS桶后第一件事，就是执行obsutil bucket-versioning -b bucket-name -s Enabled。

6.2 “模型包”不是ZIP，而是ModelArts的“宪法性文件”

当你在ModelArts控制台看到“模型包已注册”，别以为这只是个状态提示。这个“模型包”是一个严格定义的ZIP文件，其内部结构必须符合规范：

model.zip ├── model/ │ ├── 1/ # 版本号目录（必须是数字） │ │ ├── model.pb # TensorFlow SavedModel │ │ └── config.pbtxt # Triton配置（如果用Triton后端） │ └── custom/ # 自定义推理代码 │ ├── inference.py # 必须包含`model_fn`, `input_fn`, `output_fn` │ └── requirements.txt └── meta.json # 必须包含`framework`, `framework_version`, `input_shape`等字段

任何一项缺失，都会导致部署失败。meta.json中的input_shape字段尤其重要——它决定了ModelArts如何解析你的输入JSON。如果写[1,3,224,224]，但实际请求传了[3,224,224]，服务会直接返回400错误，且日志里不报具体原因。

6.3 “在线服务”和“批量服务”的基因差异：一个为低延迟而生，一个为高吞吐而活

很多人试图用同一个模型包，既部署在线服务又部署批量服务，结果在线服务P99延迟飙升。这是因为二者底层架构完全不同：

• 在线服务：基于Triton Inference Server，追求毫秒级响应，强制单实例单模型，CPU/GPU资源独占
• 批量服务：基于Kubernetes Job，追求吞吐量，可动态启停多个Pod，共享集群资源

因此，必须为二者准备不同的模型包：在线服务包精简（只含必要代码），批量服务包可包含数据清洗、结果聚合等重型逻辑。我们曾用同一包部署，导致批量任务的pandas.read_csv()吃光CPU，挤占在线服务资源，最终拆分为model-online.zip和model-batch.zip两个独立包。

6.4 “OBS跨区域复制”不是即时的，而是有15-30分钟的“薛定谔延迟”

当你的训练在华东-上海一区，而业务方在华南-广州三区，你可能会想：把OBS桶设置为跨区域复制，一劳永逸。但现实是，OBS的跨区域复制是异步的，且有可观测延迟。我们实测过，一个10GB的processed/目录，在开启跨区域复制后，广州桶的last_modified时间戳，比上海桶晚了22分钟。这意味着，如果你在上海桶上传完数据，立刻在广州区域提交训练作业，大概率会报“数据不存在”。解决方案是：在训练作业的启动命令中，加入OBS文件存在性检查：

# 在训练作业的“启动命令”中 if ! obsutil ls s