🎯 **环境依赖与模型适配是挑战：** 在进行智能驾驶感知模型的性能对比测试时，经常会遇到环境依赖冲突（如mmcv版本与torch不兼容）和源代码适配问题（如local_rank参数处理、NCCL P2P通信设置），这需要仔细排查官方文档并进行版本调整或代码修改才能顺利运行。

⚡ **CPU与数据预处理的优化至关重要：** 对于计算节点数相对较少的智能驾驶小模型，CPU在数据预处理阶段可能成为瓶颈。通过使用进程池加速CPU并行计算，并配合共享内存提高内存读写效率，可以显著提升整体训练速度。

🚀 **PyTorch应用加速提升训练效率：** 利用PyTorch内置的优化功能，如`pin_memory`加速CPU到GPU的数据传输，增加`num_workers`并行化数据加载和预处理，以及使用`torch.compile`优化模型计算图，能够有效提升训练过程的吞吐量和效率。

☁️ **存储挂载区性能对模型训练影响显著：** 存储系统的读写性能直接影响模型训练中的checkpoint保存和数据加载速度。选择支持高速eRDMA网络的CPFS，并确保其可用区（如乌兰C区）能够发挥最佳网络性能，是解决因存储延迟导致算力卡性能瓶颈的关键。

李德 2025-07-30 08:30 浙江

在智能驾驶技术快速发展的背景下，车辆对周围环境的实时感知和决策能力成为系统性能的关键。目标检测、语义分割、多传感器融合等任务构成了智能驾驶系统的核心感知模块，这些算法通常依赖于大规模深度学习模型的训练与部署。随着自动驾驶等级从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模型测试中，遇到了严重的环境依赖问题，执行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 -c '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 1, in <module>
      File "/tmp/pip-build-env-xxxx/overlay/lib/python3.8/site-packages/setuptools/__init__.py", line 16, in <module>
        import ez_setup
      File "/tmp/pip-build-env-xxxx/overlay/lib/python3.8/site-packages/ez_setup.py", line 139, in <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 2, in <module>
      File "/tmp/pip-install-xxxx/flash-attn/setup.py", line 10, in <module>
        import torch
      File "/home/user/.local/lib/python3.8/site-packages/torch/__init__.py", line 197, in <module>
        _load_global_library('libtorch_cpu.so')
      File "/home/user/.local/lib/python3.8/site-packages/torch/_utils_internal.py", line 85, in _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。

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

local rank处理

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

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

train.py: error: unrecognized arguments: --local_rank=0
E0522 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被禁用，让多卡状态共享不再通过高速网络，会让训练效率略微下降。

实际在对比测试中，可以采用一些优化性能的方法，让算力卡发挥尽可能多的算力优势；以下介绍从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存储，并选择合适的可用区。

阅读原文

跳转微信打开