结论
RDK-X5 的 BPU 硬件原生不支持 CenterPoint 中的：
点云体素化（Voxelization）算子- SparseConvolution（稀疏卷积，如 SubMConv3d）
- ScatterDense 算子
这些算子在工具链的算子支持列表中均未列出。
推荐的最佳做法
根据社区已有案例（PointPillars、CenterPoint 参考算法），推荐以下三种方案：
方案 1：架构替换为 PointPillars（
首选，已验证）
将 CenterPoint 的稀疏卷积架构改为 PointPillars 架构，使用地平线定制的 PointPillarsScatter 算子：
# 原始 CenterPoint 流程（不支持）
# 点云 → Voxelization → SubMConv3d → ScatterDense → 检测头
# 替代方案（支持）
# 点云 → Voxelization → PointPillarsScatter → Conv2d → 检测头
核心改动：
- 使用
horizon_plugin_pytorch.nn.PointPillarsScatter替代稀疏卷积 - 后续使用标准
Conv2d，BPU 完全支持 - 已在 J5/S100/RDK-X5 平台验证，性能约 25-30ms
参考实现：
- PointPillars 参考算法详解
- OE 包中
ddk/samples/ai_toolchain/horizon_model_train_sample
方案 2：算子替换 + 标准 3D 卷积
如果必须保留 CenterPoint 架构，将稀疏卷积改为稠密 3D 卷积：
# 修改前（spconv，不支持）
import spconv
self.conv1 = spconv.SubMConv3d(in_ch, out_ch, kernel_size=3)
# 修改后（标准卷积，支持）
import torch.nn as nn
# 1. 先将稀疏体素转换为稠密张量
# 2. 使用标准 3D 卷积
self.conv1 = nn.Conv3d(in_ch, out_ch, kernel_size=3, padding=1)
注意：
- 需要调整体素网格尺寸，避免显存/内存爆炸
- 会损失稀疏性带来的效率优势
方案 3：混合部署（折中方案）
┌─────────────────────────────────────────────────────┐
│ CPU/GPU │ BPU (地平线) │
├─────────────────────────────────────────────────────┤
│ 点云预处理 │ │
│ Voxelization │ │
│ SubMConv3d (enc0-2) │ │
│ GridPooling │ │
│────────────────────────────│────────────────────────│
│ │ 稠密特征 (enc3 之后) │
│ │ Transformer Block │
│ │ Decoder (标准卷积) │
│ │ Segmentation Head │
└─────────────────────────────────────────────────────┘
优点： 保留部分稀疏卷积架构
缺点： CPU-BPU 数据传输开销，整体性能可能不如纯 BPU
验证步骤
- 导出 ONNX 模型并检查算子支持
hb_compile --check-model your_model.onnx
# 查看报错的算子类型
- 查看官方算子支持列表
- 参考社区已有实现
建议
| 优先级 | 方案 | 适用场景 |
|---|---|---|
| 首选 |
改用 PointPillars 架构 | 快速落地，已有验证 |
 备选 |
混合部署 | 必须保留稀疏卷积 |
 长期 |
联系官方推动支持 | 商业项目，有出货量 |
如果你的项目是商业落地且有明确出货量，建议在原帖中补充说明：
- 项目背景（自动驾驶/机器人/工业检测等）
- 预期出货量
- 时间节点
- 为什么必须用稀疏卷积（精度/性能需求）
官方曾表示：“了解背景有助于协调内部资源支持”，可能获得定制化算子支持或优先级排期。
需要我帮你分析具体的网络结构修改方案，或查看 PointPillars 的完整实现细节吗？