支持私有化部署
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


150%训练效率提升:感知检测小模型训练优化方法

发布日期:2025-07-24 08:35:47 浏览次数: 1565
作者:阿里云开发者

微信搜一搜,关注“阿里云开发者”

推荐语

阿里团队分享智能驾驶感知检测小模型训练优化方法,150%效率提升助力行业突破。

核心内容:
1. 智能驾驶场景下感知检测小模型的训练挑战
2. 不同算力卡上的性能对比测试方案
3. 四大典型模型的优化实践与效果验证

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

一、背景

在智能驾驶技术快速发展的背景下,车辆对周围环境的实时感知和决策能力成为系统性能的关键。目标检测、语义分割、多传感器融合等任务构成了智能驾驶系统的核心感知模块,这些算法通常依赖于大规模深度学习模型的训练与部署。随着自动驾驶等级从L2向L3乃至L4演进,模型复杂度和数据量呈指数级增长,这对计算平台提出了更高的要求,尤其是在算力、内存带宽、并行处理能力和能效比等方面。  当前,行业内主流的高性能计算平台包括高速GPU集群,整体提供极高的内存容量和带宽,支持高效的大批量数据处理和分布式训练,可以满足更复杂的模型架构和更大的训练批次需求。因此,在典型智能驾驶场景中,如高精度目标检测、点云感知以及多模态融合感知任务中,对不同的算力卡进行全面的性能对比测试,为客户在选择合适的算力资源时提供有力的数据支撑。

测试环境配置

  • 环境:mmdet3d、mmcv、flash-attn、nuscenes-devkit、torchrun分布式训练框架;

  • 算力:两种不同的算力卡,用机器一和机器二表示;

  • 模型:maptr、sparsedrive、qcnet、Gaussianformer;

  • 数据集:nuScenes、Agoverse。

二、技术架构

整体的对比测试基于PAI DSW实例进行,在dsw机器上进行训练实验,以下是整体的训练步骤:

以maptr模型为例:

1.先选择dsw镜像,要对应合适的py、cuda版本,尽量和模型要求的配置相同,选择autodrive镜像,里面预装了必要mmcv等依赖。

2.然后根据模型的github官方文档安装必要的依赖,如果碰到报错,重新选择不同的版本,这一步可能需要多次实验配置。

3.创建dsw时会指定一个cpfs挂载点,在dsw挂载的cpfs中下载模型文件和数据集做持久化存储。

4.然后执行训练命令,log记录训练时间和吞吐量。

以下是该项目中测试的四个模型,全部是目标检测和感知领域的小模型,适用于智能驾驶场景:

类型

模型

主要依赖

官方地址

感知-地图构造

maptr v1

mmdet3d 0.17.2

mmcv 1.4.0

https://github.com/hustvl/MapTR

感知-端到端

sparsedrive

mmcv 1.7.1

flash-attn 2.3.2

https://github.com/swc-17/SparseDrive

感知-预测

QCNet

mmdet3d 0.17.2

https://github.com/ZikangZhou/QCNet

感知-目标检测

GaussianFormer

mmcv 2.0.1

mmdet3d 1.1.1

https://github.com/huang-yh/GaussianFormer

三、问题&解决方法

3.1 环境依赖冲突

mmengine和torch

在maptr模型测试中,遇到了严重的环境依赖问题,执行pip install mmcv==1.4.0,build wheels时失败。

Collecting mmcv-full==1.4.0  Using cached mmcv_full-1.4.0.tar.gz (2.8 MB)  Preparing metadata (setup.py): started  Preparing metadata (setup.py): finished with status 'done'Building wheels for collected packages: mmcv-full  Building wheel for mmcv-full (setup.py): started  Building wheel for mmcv-full (setup.py): still running...  error: command '/usr/local/cuda/bin/nvcc' failed with exit code 1  Complete output from command /usr/bin/python3 -c "import setuptools, tokenize;__file__='.../mmcv_full-1.4.0/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d :

根据mmcv官方文档排查,发现该1.4.0版本的mmcv是比较旧的依赖,必须要求1.9.1<=torch<=1.10.0,在dsw官方自带的镜像中已经找不到满足要求的低版本torch,重新卸载torch安装低版本会导致大量的镜像自带库产生兼容错误。

mmcv1.4.0又是maptr的必须依赖。

针对maptr模型的解决方法是选择带py38+cu111版本的ubuntu裸镜像,重新安装合适的torch版本,然后再安装mmcv。

flash-attn和transformer

在sparsedrive模型测试时,需要安装flash-attn==2.6.1,setup时失败。

Collecting flash-attn  Using cached flash_attn-2.6.1.tar.gz (49 kB)  Preparing metadata(setup.py): started  Preparing metadata(setup.py): finished with status 'error'
  ERROR: Command errored out with exit status 1:   command: /usr/bin/python3 -'import io, os, sys, setuptools, tokenize; ...' bdist_wheel -d ...       cwd: /tmp/pip-install-xxxx/flash-attn/
  Complete output from command:
    Running from flash-attn source directory.    TORCH_CUDA_ARCH_LIST=8.0+PTX    Traceback (most recent call last):      File "<string>", line 1in <module>      File "/tmp/pip-build-env-xxxx/overlay/lib/python3.8/site-packages/setuptools/__init__.py", line 16in <module>        import ez_setup      File "/tmp/pip-build-env-xxxx/overlay/lib/python3.8/site-packages/ez_setup.py", line 139in <module>        raise RuntimeError("ez_setup cannot run as a namespace package")    RuntimeError: ez_setup cannot run as a namespace package
    During handling of the above exception, another exception occurred:
    Traceback (most recent call last):      File "<string>", line 2in <module>      File "/tmp/pip-install-xxxx/flash-attn/setup.py", line 10in <module>        import torch      File "/home/user/.local/lib/python3.8/site-packages/torch/__init__.py", line 197in <module>        _load_global_library('libtorch_cpu.so')      File "/home/user/.local/lib/python3.8/site-packages/torch/_utils_internal.py", line 85in _load_global_library        ctypes.CDLL(path)    OSError: /home/user/.local/lib/python3.8/site-packages/torch/lib/libtorch_cpu.so: undefined symbol: _ZN3c106detail15unchecked_inplace_False_aten_14_GLOBALS_INITIALIZED_for___nv_isnan

这个错误很复杂,看起来是cuda版本的错误,但查看flash的官方文档,又显示和torch123兼容,很难找到根因,后面查看了py3.8的torch/_utils_internal.py的源代码,里面调用了transformers库的一个函数,这个函数在高版本的transformers已经被废弃,只有该模型指定的transformers4.30.1在使用,因为缺少这个函数,导致这个undefined symbol错误。

解决方法是transformers库降级,pip install transformers==4.30.1。

3.2 源代码适配

由于不同算力卡底层编译环境的差异,在进行模型测试一般需要对源代码做处理。

local rank处理

local_rank是指定GPU序号的参数变量,在多卡并行训练时需要传入local_rank默认值,目前大部分的模型,包括本项目测试的四个模型,默认以Nvidia算力作为模型训练和推理的环境,因此会在启动脚本中硬编码传入参数--local_rank,但不同的算力卡调度逻辑不一样,可能会采用不用的GPU序号变量。

比如sparsedrive在机器一执行启动命令会出现变量错误:

train.py: error: unrecognized arguments: --local_rank=0E0522 17:29:16.787000139811472776256 torch/distributed/elastic/multiprocessing/api.py:826] failed (exitcode: 2) local_rank: 0 (pid: 100906) of binary: /usr/local/bin/python3

该问题的解决方法是在训练脚本中修改代码parser.add_argument('--local-rank',type=int,default=0)

NCCL P2P处理

DDP多卡并行训练时,会默认使用多卡的点对点通信,多张卡之间共享模型权重和数据集,实现并行训练;点对点通信直接使用卡之间的内部通信网络,不经过主机内存中转。

在测试实验中会偶发出现以下的错误,rank0和rank1的参数不一样:

Traceback (most recent call last):  File "train_ddp.py", line 42, in <module>    model = DDP(model)  File "/usr/local/lib/python3.10/site-packages/torch/nn/parallel/distributed.py", line 610, in __init__    _check_same_numel(self.module.parameters(), self.device_ids[0])  File "/usr/local/lib/python3.10/site-packages/torch/nn/parallel/distributed.py", line 587, in _check_same_numel    assert torch.distributed.is_initialized(), "Distributed process group is not initialized"RuntimeError: DDP expects same model across all ranks, but Rank 0 has 1012 params, while rank 1 has inconsistent 0 params.

这个错误原因在rank1没有读取到rank0的状态,多卡通信失败;这个时候禁用点对点通信,可以解决这个错误,解决方法是在训练脚本加入EXPORT NCCL_P2P_DISABLE=1该参数可以禁用点对点通信。

但P2P被禁用,让多卡状态共享不再通过高速网络,会让训练效率略微下降。

3.3 性能优化

实际在对比测试中,可以采用一些优化性能的方法,让算力卡发挥尽可能多的算力优势;以下介绍从cpu、应用、外部挂载三个方面的优化点。

3.3.1 cpu处理加速

在maptr模型测试中,发现实际算力卡的显存使用率和显存占用量都比较低,从以下监控中显示训练进程大量在CPU核心上执行,GPU上的运算很短时间就结束,然后等待CPU执行完毕再执行。

由于该模型是小模型,本身的模型的计算节点数远小于大模型,根据其源码显示,GPU用于模型本身的梯度计算和参数更新,CPU用于读取图片数据做预处理tensor,而进程监控的结果是CPU的处理时间很长,GPU在等待CPU处理数据完毕后再进行计算,因此算力卡肯定无法全部发挥算力,需要对CPU的计算做优化来提升效率。

进程池

进程池(Process Pool) 是一种用于并行执行任务的机制,主要用于在多核 CPU 环境下提高程序的运行效率。它通过预先创建一组工作进程,将多个任务分配给这些进程并发地执行,从而充分利用计算机的硬件资源。使用进程池可以避免频繁创建和销毁进程所带来的性能开销,因为进程池中的进程是复用的。

当主程序向进程池提交任务时,进程池会根据当前可用的工作进程数量自动调度任务,可以在提升执行速度的同时,避免资源竞争和系统过载。

对cpu计算要求高的小模型可以使用进程池来加速计算,进程数一般设置成cpu核心数:

from multiprocessing import Pool
def image_process(image):    ...    return tensor
if __name__ == '__main__':    with Pool(processes=n) as pool:  # 创建一个包含n个进程的池        results = pool.map(image_process, image_list)  # 进程池并行计算        print(results)

共享内存

共享内存是一种进程间通信机制,它允许多个进程访问同一块内存区域,从而实现数据的高效交换和同步。相比于其他 IPC 机制,共享内存具有极低的通信开销,因为不需要在内核与用户空间之间频繁复制数据;多个进程可以通过标识符或名称映射到同一块物理内存地址空间上。一旦某个进程将数据写入该共享内存区域,其他进程可以立即读取这些数据,而无需通过复杂的序列化或网络传输过程。

这种机制特别适用于多进程之间的频繁数据交换和并发操作。

对于小模型在处理数据时,需要大量使用cpu对内存的读取写入,前面启用了进程池,共享内存可以配合多进程使用,加快cpu的处理速度,对于共享内存的大小,一般设置成实例的分配内存;当数据占用量很大时,需要增加共享内存。

3.3.2 torch应用加速

用torch做模型训练时,有一些torch内置的方法,能够对batch数据做高效处理,对模型本身做图处理,加速训练过程,以下介绍三种不同的方法:

pin_memory

PyTorch 会将数据加载到 page-locked 内存,这种内存不会被操作系统交换到磁盘,因此可以更高效地通过 PCIe 总线传输到 GPU,直接由 GPU 异步访问,从而加快从 CPU 到 GPU 的数据拷贝速度。

CUDA 支持从 pinned memory 到 GPU 的异步数据传输,这可以与计算重叠,提升整体训练效率:

dataloader = DataLoader(    dataset,    batch_size=32,    shuffle=True,    num_workers=4,    pin_memory=True  # 启用 pinned memory)

num_workers

num_workers指定了用于数据预处理和加载的子进程数量,每个子进程负责从磁盘读取数据、进行预处理,并将处理好的 batch 数据传递给主进程。使用多个 workers 并行读取和处理数据,可以显著提升训练效率,在 GPU 进行模型训练的同时,workers 可以提前准备好下一个 batch 的数据,实现“GPU计算 + 数据加载”并行。

num_workers的原理和上文中提到的cpu进程池原理类似,都是通过多进程并发来提升速度,这个是torch自带的加速数据加载和处理的方法,进程池是cpu层面所有任务的加速方法。

num_workers的值一般设置成cpu核心数。

dataloader = DataLoader(    dataset,    batch_size=32,    shuffle=True,    num_workers=4, #cpu核心数    pin_memory=True  )

torch compile

torch compile使用torchdynamo对模型进行追踪,将其转换为Graph。这个过程会记录模型的计算路径,忽略掉非必要的控制流,并构建一个可优化的计算图。

然后对生成的计算图进行各种优化,例如:算子融合:将多个连续的操作合并成一个,减少内核启动次数。常量折叠:提前计算静态值。内存布局优化:减少数据拷贝,提高缓存命中率。

将优化后的图转换为目标平台的高效代码。PyTorch 默认使用 Inductor 编译器在后续的前向/反向传播中直接调用,绕过 Python 解释器,实现高速执行。

注意:compile无法编译非pytorch的指令,自定义 C/CUDA 扩展的模型可能会遇到兼容性问题。

model=torch.compile(    model,    backend='inductor',    dynamic=False,    fullgraph=False,)

3.3.3 cpfs优化加速

在maptr模型测试中,发现模型在写入checkpoint文件到cpfs时的时间存在很大差异,在同一地域乌兰察布下的cpfsA区的机器一时延比较长在2分钟左右,但机器二秒级就能写入完成,理论上同一套cpfs不应该有这么大的读写性能差异,根据后台的监控显示两台不同机器上的cpfs时延差了3倍。

机器一

机器二

后面分析cpfs的实例情况,发现挂载的cpfs都在乌兰A区,但根据智算CPFS的官方文档显示,cpfs使用高速eRDMA网络通信,目前只有乌兰C区支持,初步判断是因为可用区导致无法使用网速网络读写,使机器一读写效率很低。

重新新建一个C区的cpfs,重新训练后发现ppu的cpfs写入延迟大大降低,时延问题解决。

要启用cpfs的高速eRDMA网络读写,cpfs的可用区需要选择乌兰C区。

四、测试结果

从loss结果来看,机器一在100000 step时基本收敛,机器二在180000 step时基本收敛,基本符合预期的加速比,收敛趋势一致。

总结

如果在实际业务场景中需要训练感知检测类的小模型,可以按照如下的操作方法来优化性能,总体的性能优化可以从调度层、应用层、挂载区三个方面来考虑。

模型训练过程中的tensor计算会先进入底层cpu做数据预处理,然后处理完的tensor会用cuda gpu算力来做模型梯度计算,训练过程中产生的checkpoint会写入到挂载区cpfs,从三个阶段可以分别做三方面的优化:

1.调度层:创建进程池,提高cpu并行处理速度,增加共享内存,加快cpu读取内存的速度;

2.应用层:torch dataloader启用pin_memory,加快数据传输速度,增加num_workers,提高并行计算速度,用compile加速模型计算;

3.挂载区:使用有高速读写网络的CPFS存储,并选择合适的可用区。

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询