您好,感谢您使用MindSpeed MM!
该报错一般由存储问题引起,可能是磁盘空间不足,或者共享磁盘写入存在问题。请先确认磁盘剩余空间后,再改用本地磁盘进行测试验证。


您好,该问题当前已确认由共享存储引起,改用本地磁盘存储可以解决保存报错问题。
当前PR先关闭,如果后续有其他问题,请继续提交issue联系,感谢您的使用!


您好,感谢您使用MindSpeed MM!
该报错一般由存储问题引起,可能是磁盘空间不足,或者共享磁盘写入存在问题。请先确认磁盘剩余空间后,再改用本地磁盘进行测试验证。
是的,我用ClaudeCode定位出这个问题了,就是共享存储磁盘的问题,改成本地存储磁盘就能保存成功了。
在保存checkpoint时,使用共享目录保存会报错,需要使用本地目录才能保存成功。
之前的报错是unexpected pos 704 vs 598,后来不知道为啥报错变成了OSError:Bad address,但都可以通过保存到本地存储磁盘的方式来解决该问题。



您好,当前Issue标记为resolved且有一段时间未进一步更新,因此我们将其标记为'stale'(闲置)状态。若您认为这是误操作,可通过添加任意评论来去除'stale'标签。标记为stale的Issue在4天内无更新活动将自动关闭。


初步判断问题根因在共享文件系统的并发 I/O:DCP 多 rank 并行写 checkpoint 时,共享存储出现底层写入异常,导致 torch.save 的文件 offset 状态不一致,最终报 unexpected pos 或 Bad address。本地磁盘正常进一步说明 checkpoint 数据及 DCP 保存逻辑本身基本正常;HCCL 更可能通过改变 rank 间执行时序、提高并发 I/O 压力而放大该问题,而非直接导致 checkpoint 数据异常。


问题原因分析
初步定位该问题与 共享文件系统上的并发 I/O 有关,而非 FSDP2/DCP checkpoint 数据或模型参数本身异常。
从现象来看:
- 使用本地磁盘保存 checkpoint,可以正常完成;
- 使用共享目录保存时出现
unexpected pos 704 vs 598,部分场景出现OSError: Bad address; - Gloo + CPU 通信方式保存正常,而 NPU + HCCL 通信方式更容易触发。
从调用栈看,异常最终发生在:
DCP FileSystemWriter -> torch.save() -> PyTorchStreamWriter -> write_end_of_file()
其中 unexpected pos 表示 PyTorch serialization 内部维护的文件 offset 与底层文件写入过程中实际返回的 offset 不一致。类似的 unexpected pos 通常是底层文件写入失败后,在 torch.save() finalize 阶段暴露出来的二次错误,而不一定是 checkpoint 数据或 offset 计算本身存在问题。PyTorch 中也存在 file write failed 随后出现 unexpected pos 的类似案例。
DCP 本身采用多 rank 并行保存,每个 rank 会写入自己的 checkpoint shard,因此共享目录下会形成较高的并发文件 I/O。
因此当前更可能的原因是:
共享文件系统在多 rank 并发写入 checkpoint 时出现了底层 I/O 异常,导致 PyTorch serialization 的文件位置状态与预期不一致,最终表现为 unexpected pos 或 Bad address。
HCCL 更可能是该问题的触发/放大因素,而不是 checkpoint 数据错误的直接原因。相比 Gloo,HCCL/NPU 场景下各 rank 的 collective 通信速度和执行时序不同,可能导致多个 rank 更集中地进入 DCP checkpoint 写入阶段,从而提高共享存储的瞬时并发 I/O 压力,使共享文件系统潜在的并发写入/一致性问题更容易暴露。
因此目前问题可以归纳为:
FSDP2
↓
DCP 多 rank 并行 checkpoint
↓
多个 rank 同时写共享文件系统
↓
共享存储发生异常 I/O
↓
torch.save()/PyTorchStreamWriter 文件 offset 状态异常
↓
unexpected pos / Bad address
而保存到本地磁盘时,由于不存在跨节点共享存储的并发访问和网络文件系统 I/O 路径,因此可以正常完成。
建议后续通过 多 rank 直接调用 torch.save() 写共享目录 的最小复现进一步确认。如果能够在脱离 FSDP2/DCP 的情况下复现,则可以进一步确认问题位于共享文件系统/客户端 I/O 层,而非 FSDP2 checkpoint planner 或 HCCL 数据通信本身。


您好,此issue已经超过一周没有更新,现先将issue关闭,有需要可以重新打开,谢谢!


在提交新问题之前,请确保您已经在社区中搜索过相关问题,并使用了社区中提供的资源/工具后,仍未找到满意的解决方式。
环境信息
1.昇腾910C单机16卡
2.Docker容器镜像:swr.cn-south-1.myhuaweicloud.com/ascendhub/cann:8.5.0-a3-openeuler24.03-py3.11
使用场景及问题
参考官方链接:https://gitcode.com/Ascend/MindSpeed-MM/tree/master/examples/qwen3omni
1. 权重转换
convert_weights.sh
2. 数据集
qwen3omni_minimal.json
3. 数据目录配置
data_8c.json
4. 微调脚本:
finetune_qwen3omni_8c_910c.sh
5. 训练日志报错现象:
train_8c_20260508_131037.log
欢迎加入社区,感谢您对社区的贡献 🎉!