AutoDL搭配阿里云OSS：从数据迁移到训练结果回传的完整实践-代码聚汇网

AutoDL搭配阿里云OSS：从数据迁移到训练结果回传的完整实践

AutoDLOSS对象存储

|难度：普通|阅读约 35 分钟

提到AutoDL，大家第一反应都是显卡够用、价格香。但真正跑起大型模型来，数据集、模型权重、输出结果这仨文件怎么搬，才是让人头疼的事。每次上传几百GB的数据到实例，要么本地带宽顶不住，要么传输到一半断了重来，折腾一晚上心态直接崩。OSS（对象存储服务）就是用来解决这个问题的——把数据放在云端，按需拉到实例，训练完再把结果传回去，既省钱又省时间。

这篇文章以阿里云OSS为例，完整梳理一遍在AutoDL上配置OSS的全流程。从一个空白的Bucket开始，到创建子账号、配置AccessKey、安装命令行工具、日常上传下载、最后到常见报错排查，每一步都给出可直接复制的命令和配置。整个过程我已经在多个实例上反复跑过，照着抄基本不会出大问题。

1. 整体思路：为什么是OSS，以及工具选型

1.1 AutoDL自带数据卷的痛点

AutoDL自带的数据盘和数据卷，用起来确实方便，但有几个绕不开的问题：

数据盘容量有限，大模型权重和数据集动辄几十上百GB，扩容要额外花钱。
数据卷本质上还是绑定在那一台机器上，换实例就得重新挂载，数据迁移麻烦。
多人协作时，A训练好的结果想给B用，先下载再上传，中间多了一道中转。
资源释放后，数据卷如果没有及时保存，容易丢失，风险不小。

OSS就不一样了。Bucket里的数据独立存在云端，和实例生命周期无关。今天用A100，明天用4090，数据还是那个数据，拉下来就能继续训练。而且OSS的存储单价远低于云盘，冷数据还能转低频或归档存储，长期持有成本更低。

1.2 常见工具的定位与选择

OSS客户端非常多，这里整理一下主流的几种：

工具	类型	适合场景
ossutil	命令行工具	服务器上批量上传下载、同步、巡检，自动化脚本首选
ossbrowser	图形客户端	一次性查看、在线预览、少量文件手动上传
ossfs	文件系统挂载	把Bucket挂载为本地目录，像读写本地文件一样操作
SDK（Python/Go/Java）	代码库	训练脚本中直接调用接口，做数据预处理或结果回传
s3cmd/rclone	通用对象存储工具	多平台存储迁移，兼容S3协议的服务也能用

在AutoDL上我主要推荐ossutil和ossfs。原因很简单：

ossutil是纯命令行工具，SSH进实例就能用，写脚本方便，配合cron可以做定时数据同步。
ossfs可以让你把数据集挂载成目录，然后直接 /mnt/oss/data 这种路径读取，许多框架不用改代码就能跑起来。

至于rclone，它更通用，但如果只是用阿里云OSS，直接用官方工具更稳定，排障资料也多。

1.3 用到的收费项和免费额度

配置之前建议先搞清楚费用，避免月底账单吓一跳：

存储费用：Bucket存放数据占用的空间，按GB/月计费，标准存储价格可以查官方定价。
流量费用：从OSS下载文件到公网会产生下行流量费，上传一般免费。在AutoDL实例里访问OSS的Endpoint使用公网Endpoint，所以下载数据会产生下行流量，这是主要开销。
请求费：PUT/GET等API调用次数，量不大时可以忽略。

省钱技巧：如果只是临时下载数据训练，可以先把数据下载到本地实例的数据盘，训练结束后把结果传回OSS，然后立刻释放实例。不要长时间让实例挂着，按量计费的GPU实例每个小时都是钱。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 准备工作：开通OSS与创建最小权限账号

2.1 开通OSS并创建Bucket

打开阿里云控制台，如果没有开通OSS就先开通。开通后进入OSS控制台，点击“创建Bucket”，需要填几个关键参数：

Bucket名称：全局唯一，例如 autodl-dataset-2024，只能用小写字母、数字和短横线。
地域：选离AutoDL实例最近的区域。AutoDL的实例一般有多个区域可选，比如上面提到可以选北京或上海，建议选华东或华北，延迟低。个人经验是选华东2（上海），晚高峰的网络稳定性更好，当然不同时间可能不一样。
存储类型：默认“标准存储”就行，如果要放备份可以选“低频访问”。
读写权限：默认“私有”，后期通过授权管理控制访问，千万别选“公共读”，否则别人知道URL就能下载你的数据。
版本控制：如果不需要多版本备份，建议关闭，否则会产生额外存储费用。

创建完成后，进入Bucket详情页，能看到它的Endpoint和Bucket域名。这个地址后面配置要用，记下来。

2.2 创建RAM子账号和最小权限策略

直接用阿里云主账号的AccessKey配置到服务器上，风险极高。一旦Key泄露，别人就有你整个账号的操作权限，所有Bucket数据都保不住。正确做法是在RAM（访问控制）里创建子账号，只授权OSS相关权限，甚至只授权某一个Bucket。

步骤：

在控制台搜索“RAM”，进入RAM访问控制台。
点击“用户”——“创建用户”，登录名随意，比如 autodl-oss，访问方式勾选“OpenAPI调用访问”，系统会生成AccessKey ID和AccessKey Secret，把Secret下载保存好，只显示这一次。
创建完用户后，点击用户名称进入详情，选择“权限管理”——“添加权限”。
在系统策略里搜索 AliyunOSSFullAccess 或 AliyunOSSReadOnlyAccess。如果想让子账号只能操作某个特定Bucket，不要直接给全局策略，改用自定义策略。

自定义策略示例，限制只允许操作指定Bucket：

code复制{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:ListBuckets",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "oss:*",
      "Resource": [
        "acs:oss:*:*:autodl-dataset-2024",
        "acs:oss:*:*:autodl-dataset-2024/*"
      ]
    }
  ]
}

第一段允许列出所有Bucket，因为控制台和工具需要先列举Bucket列表。第二段限定仅操作 autodl-dataset-2024 这个Bucket下的一切对象。实际使用中，代码、脚本的权限尽量小，避免误操作删除其他生产数据。

2.3 关于AccessKey的安全管理

AccessKey一旦创建，就要当成密码一样对待。个人经验有几个习惯：

不要把AccessKey写在代码仓库里，哪怕私有仓库也不行，万一哪天仓库公开了呢。
在服务器上可以放到 ~/.ossutilconfig 或环境变量里，并设置文件权限为600。
如果发现AccessKey疑似泄露，立刻在RAM控制台禁用或删除该Key，然后重新生成。
每隔几个月轮换一次Key，运维成本不高，但安全性提升明显。

另外，如果是在多人共用的AutoDL实例里操作，建议不要在公共盘里留下包含密钥的配置文件。可以放到 ~/ 的个人目录，或者直接在命令里临时通过环境变量注入。

3. 安装配置工具：ossutil与ossfs

3.1 在AutoDL实例上安装ossutil

AutoDL实例默认是Ubuntu/CentOS类系统，通常有curl。安装ossutil最省事的方式是用官方一键安装脚本：

code复制curl -L https://gosspublic.alicdn.com/ossutil/install.sh | bash

这条命令会下载最新版ossutil并安装到 /usr/local/bin。安装完验证一下：

code复制ossutil version

如果提示找不到命令，可以手动下载。下载地址一般在官方文档里能找到，挑对应架构的Linux版本，解压后放到 /usr/local/bin 并加执行权限：

code复制# 以x86_64为例，如有更新以官方为准
wget https://gosspublic.alicdn.com/ossutil/v2/ossutil-v2.0.3-beta.09262024-linux-amd64.zip
unzip ossutil-v2.0.3-beta.09262024-linux-amd64.zip
mv ossutil-v2.0.3-beta.09262024-linux-amd64/ossutil /usr/local/bin/
chmod +x /usr/local/bin/ossutil
ossutil version

3.2 配置ossutil的访问凭证

ossutil支持交互式配置和手动配置。交互式配置：

code复制ossutil config

它会问你Endpoint、AccessKey ID、AccessKey Secret，按照提示填写。这里注意，Endpoint填的是外网Endpoint，例如 oss-cn-shanghai.aliyuncs.com，不要填内网Endpoint。因为AutoDL实例不在阿里云VPC内，内网Endpoint根本通不了。

配置完成后，可以用 ossutil ls 验证是否连通。如果能看到Bucket列表，说明配置成功。

手动配置的方式也很简单，编辑 ~/.ossutilconfig 文件，填入以下内容：

code复制[Credentials]
language=EN
endpoint=oss-cn-shanghai.aliyuncs.com
accessKeyID=LTAI5t...
accessKeySecret=xxxxxxxx

然后执行 ossutil ls 同样能验证。

注意：ossutil更推荐用 ossutil config --loglevel debug 排查配置问题，如果出现 InvalidAccessKeyId 或 SignatureDoesNotMatch，优先检查密钥是否复制完整，特别是开头和结尾有没有多余空格。

3.3 安装ossfs并把Bucket挂载成目录

ossfs可以把OSS挂载成Linux本地目录。安装方式：

CentOS/RHEL系统：

code复制sudo yum install -y ossfs

Ubuntu/Debian系统需要下载对应的deb包，官方文档有具体地址。安装完成后，使用下面的命令将Bucket挂载到指定目录：

code复制mkdir -p /mnt/oss
ossfs autodl-dataset-2024 /mnt/oss -ourl=http://oss-cn-shanghai.aliyuncs.com -ouid=$(id -u) -ogid=$(id -g) -o allow_other

其中：

-ourl 必须是对应region的外网endpoint地址，注意用 http:// 开头也可以。
-ouid 和 -ogid 是为了让挂载的目录归当前用户所有，不然普通用户没有读写权限。
-o allow_other 允许其他用户访问，多用户共享实例时加这个参数更方便。

挂载后执行 df -h，如果能看到类似 ossfs 的挂载点，就说明成功了。之后可以像普通目录一样读写：

code复制cd /mnt/oss
ls -l

注意ossfs的读写性能比本地磁盘差不少，如果训练时频繁读取大量小文件，可能会成为瓶颈。这种情况建议把数据先拷贝到本地数据盘：

code复制cp -r /mnt/oss/dataset /root/dataset

训练脚本读 /root/dataset，而不是直接读 /mnt/oss/dataset。

4. 实操流程：上传、下载、同步与断点续传

4.1 常用上传下载命令

ossutil的日常操作主要就是 cp、sync、ls 这几个命令。简单列几个最常用的复制即用命令：

上传单个文件：

code复制ossutil cp /root/train_data.zip oss://autodl-dataset-2024/raw/

上传整个目录：

code复制ossutil cp -r /root/dataset/ oss://autodl-dataset-2024/dataset/ -u

下载单个文件：

code复制ossutil cp oss://autodl-dataset-2024/models/llama-7b.pt /root/models/llama-7b.pt

下载整个目录：

code复制ossutil cp -r oss://autodl-dataset-2024/dataset/ /root/dataset/ -u

-u 表示增量更新，只拷贝不存在的或md5不一致的文件。这个参数在重复同步时非常有用，能省下大把时间和流量。

4.2 大文件断点续传与并发调优

大文件传输最怕中断。ossutil默认会生成 checkpoint 文件，中断之后重新执行相同的命令，会从断点继续传，不需要从头开始。

不过要注意，cp命令默认并发数是5，带宽够高时有点浪费。可以通过 --jobs 和 --parallel 调高并发。例如：

code复制ossutil cp -r /root/dataset/ oss://autodl-dataset-2024/dataset/ -u --jobs 10 --parallel 20

这里的 --jobs 是并发任务数，--parallel 是单个文件内部的分片并发数。实测在10Gbps带宽的实例上，把两个参数调高后，上传速度能从200MB/s提升到600MB/s左右，提升明显。但如果带宽本身不高，调太高反而会增大失败概率，建议先跑一遍小文件测速再定。

4.3 用sync命令保持目录同步

如果每次训练前都要把数据拉到最新，用 sync 命令比 cp 更合适。sync 会对比本地和OSS的文件大小及修改时间，只传输变更部分：

code复制ossutil sync /root/dataset/ oss://autodl-dataset-2024/dataset/ -u

反向同步，把训练结果回传OSS：

code复制ossutil sync /root/output/ oss://autodl-dataset-2024/output/ -u

这个命令可以配合cron使用，每小时同步一次，相当于一个简单的自动备份。不过要小心双向同步造成的文件互相覆盖问题，建议明确一个方向为主，比如只从OSS往实例同步数据，训练结果另起一个目录定向回传。

4.4 在Python脚本中操作OSS

有些场景需要在训练代码里直接读取或写入OSS，比如动态下载checkpoint、实时上传日志。推荐使用阿里云官方SDK：

code复制pip install oss2

示例代码，上传和下载：

code复制import oss2

auth = oss2.Auth('LTAI5t...', 'xxxxxxxx')
bucket = oss2.Bucket(auth, 'http://oss-cn-shanghai.aliyuncs.com', 'autodl-dataset-2024')

# 上传
bucket.put_object_from_file('logs/train.log', '/root/train.log')

# 下载
bucket.get_object_to_file('models/llama-7b.pt', '/root/models/llama-7b.pt')

有一点需要注意：oss2 默认的下载方式是把整个对象读进内存，大文件容易OOM。建议用 bucket.get_object_to_file 或 resumable_download，后者支持断点续传：

code复制oss2.resumable_download(bucket, 'models/llama-7b.pt', '/root/models/llama-7b.pt')

上传同理，大文件用 resumable_upload：

code复制oss2.resumable_upload(bucket, 'models/llama-7b.pt', '/root/models/llama-7b.pt')

这两个方法底层会进行分片和并发，稳定性比直接put_object好很多。

5. 自动挂载与开机启动配置

5.1 写入fstab实现开机自动挂载

如果希望每次创建AutoDL实例后，ossfs自动挂载到指定目录，可以把挂载命令写进 /etc/fstab。但直接写fstab有一点风险：如果网络没有准备好，开机挂载会失败，可能影响系统启动。

推荐的做法是写一个systemd service或者启动脚本。以systemd为例：

创建 /etc/systemd/system/ossfs.service：

code复制[Unit]
Description=Mount OSS Bucket
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
ExecStart=/usr/local/bin/ossfs autodl-dataset-2024 /mnt/oss -ourl=http://oss-cn-shanghai.aliyuncs.com -ouid=0 -ogid=0 -o allow_other
ExecStop=/usr/bin/fusermount -u /mnt/oss
Restart=on-failure

[Install]
WantedBy=multi-user.target

注意把 -ouid 和 -ogid 改成实际运行时用户的uid和gid（root是0，普通用户可以用 id -u 查询），然后：

code复制systemctl daemon-reload
systemctl enable ossfs.service
systemctl start ossfs.service

这样每次开机就会自动挂载，省去手动敲命令的麻烦。

5.2 开机自启动脚本的另一种写法

在AutoDL实例上，用户目录下可以写一个shell脚本，放到 /etc/profile.d/ 或 ~/.bashrc 里，登录时自动执行。不过个人经验是systemd更干净，因为profile脚本在SSH登录时才执行，如果跑的是后台任务，可能还没挂载上去脚本就开始读数据，导致文件找不到。

如果觉得systemd配置麻烦，也可以写一个简单的启动脚本放在 ~/oss_mount.sh：

code复制#!/bin/bash
mkdir -p /mnt/oss
if ! mountpoint -q /mnt/oss; then
  /usr/local/bin/ossfs autodl-dataset-2024 /mnt/oss -ourl=http://oss-cn-shanghai.aliyuncs.com -o allow_other
fi

然后在AutoDL控制台的“自定义启动脚本”里调用它。不过AutoDL本身也支持自定义启动命令，直接在创建实例时填写也行，看个人习惯。

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

6.1 Endpoint或Bucket地址写错导致连接失败

症状：执行 ossutil ls 或 ossfs 挂载时报 Connection timed out 或 DNS 相关错误。

原因：最常见的是Endpoint填成了内网地址（带 internal），而AutoDL实例根本不在阿里云VPC内，内网Endpoint当然不通。另一个可能是不小心把Endpoint填成了Bucket域名。

排查思路：

先确认Endpoint格式是 oss-cn-<region>.aliyuncs.com，不带Bucket名。
在AutoDL终端里执行 curl -I http://oss-cn-shanghai.aliyuncs.com，看能不能通。
如果实例在海外区域，可以试试先把Endpoint换成海外的对应地址，或者检查是否有防火墙拦截。

6.2 报错NoSuchBucket或AccessDenied

症状：工具提示 NoSuchBucket 或 AccessDenied。

原因：

NoSuchBucket：Bucket名称填错，或者Bucket确实不存在，注意Bucket名称是全局唯一的，不是你的主账号ID。
AccessDenied：accessKey ID或Secret错误，或者子账号没有这个Bucket的操作权限。

排查思路：

检查 ~/.ossutilconfig 里的accessKeyID和accessKeySecret是否正确。
检查RAM子账号权限是否包含这个Bucket。
在RAM控制台用“模拟用户操作”功能，用子账号身份测试 ListObjects 和 GetObject 权限。

6.3 ossfs挂载后读写权限不足

症状：挂载成功后，普通用户读取目录报 Permission denied。

原因：ossfs默认挂载时目录权限属于root，其他用户没有读权限。

解决：挂载命令里加 -ouid=<uid> -ogid=<gid> -o allow_other，其中uid/gid是你要用的用户ID。查询当前用户uid：

code复制id -u
id -g

然后重新挂载：

code复制fusermount -u /mnt/oss
ossfs autodl-dataset-2024 /mnt/oss -ourl=http://oss-cn-shanghai.aliyuncs.com -ouid=1000 -ogid=1000 -o allow_other

不过要注意，ossfs的权限控制是全局级别的，它不会严格按POSIX权限来区分文件和目录。如果容器内跑训练脚本用的不是挂载时的uid，还是会遇到权限问题。个人建议是把数据先拷贝到本地磁盘再跑训练，ossfs主要用于查看和传输。

6.4 传输速度慢，只有几MB/s

很多人第一次配置完，发现自己下载数据速度很慢。这个要多方面看：

AutoDL实例的带宽不一定高，先看看实例的带宽规格。如果是共享型带宽，晚上高峰时段可能被限速。
并发数太低，上传大文件时适当调高 --parallel。
Endpoint选的跨地域，比如实例在华北，但Bucket在上海，跨地域访问延迟高。最好把Bucket地域和实例地域选在同一个区域。
OSS连接池耗尽，短时间内大量请求导致掉速，可以在SDK里调大连接池或降低并发。

6.5 上传超大文件时进程被kill

如果数据集是几百GB的单个文件，直接 ossutil cp 或 oss2.put_object 可能因为内存占用过大被系统kill。解决方法是：

使用 ossutil cp 命令自带分片上传机制，它会按50MB或100MB分片，但如果内存还是不够，在命令里加 --part-size 调整分片大小：

code复制ossutil cp /root/big_file.bin oss://autodl-dataset-2024/raw/ --part-size 104857600

在Python SDK里使用 resumable_upload，也会分片。

6.6 文件传到一半断了，重启后没断点续传

ossutil cp 默认会生成 .ossutil_checkpoint 文件，通常放在源文件同目录下。如果传输中断，重新执行相同的命令即可自动续传。但如果源文件路径改变或Bucket对象名改变，checkpoint可能会失效。

另外一个坑是如果你手动kill了进程，有些老版本ossutil的checkpoint文件会保留，新版本可能不兼容，遇到这种问题直接删了checkpoint文件重新传，虽然慢一点但省心。

7. 个人经验与工作流建议

OSS在AutoDL上的用法，最终要结合自己的工作流。我这里分享一套自己用着顺手的模式：

在OSS上建三个目录：raw/（原始数据集）、models/（模型权重）、output/（训练结果）。
创建实例后，用一条命令把最新数据集拉下来：

code复制ossutil sync oss://autodl-dataset-2024/raw/ /root/dataset/ -u

训练期间每隔一段时间或者训练完一个epoch，把输出同步到OSS的 output/ 目录：

code复制ossutil sync /root/output/ oss://autodl-dataset-2024/output/ -u --jobs 10

训练结束后，把有价值的模型权重传到 models/，然后在AutoDL控制台释放实例。

这样下来，整个流程里实例的生命周期非常短，成本控制得很好。而且无论你换机器还是换项目组，数据永远在OSS里等着你，完全不用考虑“我上次的数据存在哪台机器上”这种问题。

关于安全性再啰嗦一句：AccessKey的权限能小则小，别图省事直接给主账号的Key。工具配置文件的权限也要收好，别人如果拿到了你的Key，轻则偷数据，重则把所有Bucket删光，到时候想哭都来不及。

最后分享一个小技巧：AutoDL实例通常是按量计费的，除了数据同步，很多耗时操作（比如数据集预处理、格式转换）其实可以在本地或便宜的CPU实例上做好，再传上GPU实例，能省不少GPU费用。OSS只是一个中转站，把它用好了，整个训练流程能顺滑非常多。