征程6上的Occupancy Grid预测：3D语义占用网络部署经验

Occupancy Grid（占据栅格）预测是自动驾驶感知的新方向，比传统的3D目标检测更细粒度，能描述不规则障碍物（如倾倒的锥桶、悬挂的树枝）。我在一个园区无人车项目里把Occupancy Network部署到征程6M上，踩了不少坑。这篇把模型结构、量化策略和部署经验记下来。

一、Occupancy Network架构

典型的Occupancy Network包含：

1. 图像编码器：ResNet/VoVNet backbone，提取多尺度特征

2. 3D特征提升：把2D图像特征提升到3D体素空间（通常用深度估计或Lift-Splat-Shoot）

3. 3D编码器：3D CNN或Transformer，在体素空间做特征增强

4. Occupancy Head：对每个体素输出"是否被占据"+"语义类别"的二分类/多分类预测

征程6部署的难点在3D特征提升和3D编码器：

· Lift-Splat-Shoot：需要生成深度分布，内存占用大

· 3D卷积：BPU对3D卷积的支持不如2D卷积成熟，某些算子可能fallback到CPU

二、3D特征提升的内存优化

Lift-Splat-Shoot把每帧图像生成一个深度分布（D个深度bin），然后按深度把像素"溅射"到BEV平面。内存占用：

```

图像分辨率：1280×720

深度bin数：64

特征通道：64

单帧Lift内存 = 1280 × 720 × 64 × 64 × 4字节 ≈ 14.7GB

```

14.7GB显然放不下。实际部署时的优化：

1. 降低分辨率：把1280×720降到640×384，内存降为1/4

2. 减少深度bin：从64降到32，精度损失

3. 稀疏Lift：只对有物体的区域做深度估计，背景区域跳过

优化后单帧内存约400MB，可以接受。

三、3D编码器的BPU适配

3D CNN在BPU上的主要问题：

1. Kernel size限制：BPU对3D卷积核的尺寸有要求（通常3×3×3可以，5×5×5可能不支持）

2. Stride/Padding对齐：3D数据的通道数、深度维度都要满足对齐要求

3. 内存布局：3D数据的内存排布（NCDHW vs NDHWC）要和BPU期望的一致

解决方案：

```python

# 修改3D卷积配置，确保BPU兼容

self.conv3d = nn.Conv3d(

in_channels=64,

out_channels=64,

kernel_size=(3, 3, 3), # BPU支持

stride=(1, 1, 1),

padding=(1, 1, 1),

groups=1

)

# 确保通道数是8的倍数

assert in_channels % 8 == 0 and out_channels % 8 == 0

```

如果3D卷积核不支持，可以拆解成2D+1D的组合：

```python

# 5×5×5拆解为3×3×3 + 1×1×3

self.conv3d_1 = nn.Conv3d(64, 64, (3, 3, 3), padding=(1, 1, 1))

self.conv3d_2 = nn.Conv3d(64, 64, (1, 1, 3), padding=(0, 0, 1))

```

四、Occupancy Head的量化策略

Occupancy Head对每个体素输出两类预测：

1. 占据二分类：int8足够，因为只需要判断"占据/空闲"

2. 语义多分类：如果对某些细分类别（如"可行驶区域"vs"人行道"）精度要求高，建议用int16

校准策略：

· 占据二分类的校准数据集要平衡正负样本（空闲体素远多于占据体素，容易样本不均衡）

· 语义分类的校准数据集要覆盖所有类别，特别是稀有类别（如"动物"、"施工区域"）

五、踩坑记录

· 坑1：Lift-Splat-Shoot的"splat"操作涉及ScatterND（把像素按深度位置写入BEV特征图），BPU不支持。解决：把splat改成index_select+add的组合，或把splat拆出来在CPU上做。

· 坑2：3D CNN的batchnorm在int8量化后，某些层的输出出现"棋盘格"伪影。后来发现是3D卷积的padding模式不对，改成了"replicate"后问题解决。

· 坑3：Occupancy Grid的体素分辨率通常是0.2m×0.2m×0.2m，200×200×16的grid覆盖40m×40m×3.2m的空间。如果车辆行驶速度快（>30km/h），3.2m的高度范围不够（桥洞、限高架）。解决：增加高度维度到32（6.4m），或做自适应高度范围。

· 坑4：3D CNN的推理延迟比2D CNN高很多。在J6M上，Occupancy Network的延迟约50-80ms，帧率只有12-20fps。如果要实时（30fps），建议上6P或降低体素分辨率。

六、顺便提一嘴

· Occupancy Grid的标注成本比3D bbox高很多（每个体素都要标），训练数据集通常比较小。建议用半监督学习或自监督预训练（如深度估计预训练）来减少对标注数据的依赖。

· 征程6的BPU对3D运算的支持还在持续优化，OE 3.5.0+对3D卷积的支持比3.4.x好很多。建议保持工具链更新。

· 如果项目对实时性要求高，可以考虑用2.5D方案（BEV+高度回归）替代纯3D Occupancy，延迟可以降低50%以上。

数据来源：本文Occupancy Network部署经验基于J6M实测；3D卷积BPU适配方案参考地平线开发者社区官方博客《【地平线J6工具链进阶教程】算子优化方案集锦-v1.1》。