---
title: Atlas 900 A2 Mindspeed-MM数据预处理缓慢-官方技术文章-昇腾社区
description: 在基于 Atlas 900 A2 PoD 平台进行大模型微调开发时，数据预处理阶段的性能表现直接影响整体训练流程的效率与稳定性。尤其在处理大规模多模态数据集（如 COCO 15 万样本）时，预处理耗时过长可能导致同步超时、进程退出等异常问题。本文记录一次在使用 Mindspeed-MM 框架对 Qwen2.5vl-72B 模型进行微调过程中，遇到数据预处理速度异常缓慢的问题，并通过深入排查与调优，
keywords: Atlas,Mindspeed,MM,数据预处理缓,官方技术文章,昇腾社区,背景概述,问题现象
url: https://www.hiascend.com/developer/techArticles/20260603-5?envFlag=1
section: (其他)
---

# Atlas 900 A2 Mindspeed-MM数据预处理缓慢-官方技术文章-昇腾社区

URL: https://www.hiascend.com/developer/techArticles/20260603-5?envFlag=1
描述: 在基于 Atlas 900 A2 PoD 平台进行大模型微调开发时，数据预处理阶段的性能表现直接影响整体训练流程的效率与稳定性。尤其在处理大规模多模态数据集（如 COCO 15 万样本）时，预处理耗时过长可能导致同步超时、进程退出等异常问题。本文记录一次在使用 Mindspeed-MM 框架对 Qwen2.5vl-72B 模型进行微调过程中，遇到数据预处理速度异常缓慢的问题，并通过深入排查与调优，
关键词: Atlas,Mindspeed,MM,数据预处理缓,官方技术文章,昇腾社区,背景概述,问题现象

官方技术文章 [了解详情](https://www.hiascend.com/zh/developer/techArticles)

Atlas 900 A2 Mindspeed-MM数据预处理缓慢

Atlas 900 A2 Mindspeed-MM数据预处理缓慢

MindSpeed

发表于: 2026/06/03

## 背景概述

在基于 Atlas 900 A2 PoD 平台进行大模型微调开发时，数据预处理阶段的性能表现直接影响整体训练流程的效率与稳定性。尤其在处理大规模多模态数据集（如 COCO 15 万样本）时，预处理耗时过长可能导致同步超时、进程退出等异常问题。本文记录一次在使用 Mindspeed-MM 框架对 Qwen2.5vl-72B 模型进行微调过程中，遇到数据预处理速度异常缓慢的问题，并通过深入排查与调优，最终定位到绑核配置不当为根本原因，提出有效解决方案。

## 问题现象

在使用 Mindspeed-MM 框架对 Qwen2.5vl-72B 模型进行微调时，数据预处理阶段处理速度仅为 5–30 samples/s，处理 8 万样本预计耗时约 3 小时。而相同环境下，Qwen2.5vl-7B 和 32B 模型的预处理速度正常，仅需数分钟即可完成 15 万样本处理。

该问题导致训练流程在数据加载阶段频繁超时，进程被强制终止，严重影响开发效率与任务稳定性。

## 排查过程与分析

### 1. 确认问题存在性

与框架开发团队确认，标准测试环境下使用 15 万 COCO 数据集，预处理耗时不超过半小时。结合客户实测数据，确认当前场景存在明显性能异常。

### 2. 尝试调大 num_workers

为提升并行处理能力，尝试将 num_workers 从默认值 16 调整至 32。然而处理速度未见明显改善，排除了线程数不足导致的瓶颈。

注：num_workers 过大可能引发 OOM，需根据内存资源合理配置。

### 3. 检查脚本与配置文件

对比 7B 与 72B 模型的配置文件（model_xx.json、data_xx.json、finetune_xx.sh），未发现参数配置差异。7B 模型在相同脚本下运行正常，进一步排除配置错误的可能性。

### 4. 排查存储性能瓶颈

检查数据集是否部署于共享存储，确认已切换至本地 SSD 硬盘。

使用 dd 命令测试写入带宽：

```
dd if=/dev/zero of=/path/to/test_file.img bs=1M count=1024 oflag=direct
```

实测写入速度达 3 GB/s，无 I/O 瓶颈。

预处理输出缓存目录（cache）写入速率正常，排除存储层问题。

### 5. 排查进程资源抢占

观察日志发现，数据处理速率波动剧烈：快时可达 30+ samples/s，慢时仅 5+ samples/s。使用 top 命令查看 CPU 占用，发现存在非业务进程突发占用高 CPU 资源的情况。

尽管非独占机器，但 7B 和 32B 模型未出现类似问题，说明问题具有模型规模相关性，需进一步分析运行时调度行为。

### 6. 定位关键配置差异

深入对比 32B 与 72B 模型的启动脚本，发现关键差异：

72B 脚本中设置：CPU_AFFINITY_CONF=2

32B 脚本中设置：CPU_AFFINITY_CONF=1

CPU_AFFINITY_CONF 为 Ascend PyTorch 扩展提供的 CPU 亲和性控制变量：

1：粗粒度绑核，允许系统自动调度线程至空闲核心。

2：细粒度绑核，强制线程绑定至指定核心。

将 CPU_AFFINITY_CONF 修改为 1 后，预处理速度立即恢复至正常水平，处理效率显著提升。

## 问题根因

在非独占运行环境下，细粒度绑核（CPU_AFFINITY_CONF=2）导致数据预处理进程被强制绑定至特定 CPU 核心。当该核心被其他非业务进程抢占时，预处理线程无法及时获取 CPU 资源，造成处理速率剧烈波动，严重拖慢整体流程。

而使用粗粒度绑核（CPU_AFFINITY_CONF=1）后，系统可动态将进程调度至空闲核心，有效规避资源争抢，从而恢复稳定高效处理。

### 关键结论：

在非独占环境中，建议优先使用 CPU_AFFINITY_CONF=1 以避免核心抢占。

在独占机器上，细粒度绑核可带来更优性能，但需确保无其他干扰进程。

## 解决方案与建议

### 临时修复方案（快速上线）

修改启动脚本，强制设置粗粒度绑核：

```
export CPU_AFFINITY_CONF=1
```

该配置适用于单机单卡场景，可快速缓解预处理瓶颈。

### 推荐最佳实践（长期优化）

为避免资源争抢并提升稳定性，建议在微调任务中采用以下配置：

1. 强制单机单卡运行预处理

避免多卡并行导致的同步等待与资源竞争。

在 model_xx.json 中设置：

```
"num_layers": 1
```

防止因模型层数过多导致 OOM。

2. 调整并行配置为单机单卡

确保训练流程不被多节点/多卡配置干扰：

```
"NPUS_PER_NODE": 1,
"NNODES": 1,
"TP": 1,
"PP": 1
```

适用于数据预处理阶段，确保资源独占。

## 总结

本次问题源于 绑核策略不当 导致的 CPU 资源争抢。通过对比不同模型配置，定位到 CPU_AFFINITY_CONF 的设置差异，最终通过切换为粗粒度绑核（=1）成功解决性能瓶颈。

### 核心建议：

在非独占环境中，优先使用 CPU_AFFINITY_CONF=1 以提升容错性与稳定性。

大模型微调任务应尽量运行在独占资源环境，避免外部进程干扰。

预处理阶段可考虑单机单卡执行，简化调度逻辑，提升可靠性。

参考文档：CPU_AFFINITY_CONF [了解详情](https://www.hiascend.com/document/detail/zh/Pytorch/710/comref/Envvariables/Envir_033.html)

本页内容