CenterPoint 模型结构与输出语义解析

本文以地平线 Open ExplorerOE中的 CenterPoint 参考算法为主线系统梳理 CenterPoint 的模型结构设计、Head 与 box 语义拆分方式以及在工具链中从训练、导出到编译部署的完整工程语义。文末通过nuScenes → KITTI的一次实际配置修改作为参考算法“应用级改造”的示例帮助理解这些设计在真实项目中的影响范围。一、CenterPoint 是一个怎样的 3D 检测模型CenterPoint 是一种anchor-free、center-based的 3D 目标检测方法。 它的核心思想并不是“直接预测 3D 框”而是在BEV 平面上预测目标中心点center围绕 center 回归目标的几何属性因此CenterPoint 的输出天然拆分为多个 ​语义明确的回归分量​例如中心偏移x y高度z尺寸w l h朝向yaw速度vx vy可选这也是为什么在 CenterPoint 中​Head 的设计和 box 语义是强绑定的​而不是“随便接几个卷积头”。二、CenterPoint 的 Head 设计与 box 语义拆分在 OE 的 CenterPoint 配置中Head 通常通过 common_heads 定义例如common_heads dict( reg(2, 2), height(1, 2), dim(3, 2), rot(2, 2), vel(2, 2), )这里的每一项并不只是“网络输出通道数”而是​明确对应 box 的几何语义拆分​几个关键点需要强调rot 使用 sin / cos 表达这是为了避免角度回归的周期不连续问题因此训练回归维度中yaw 始终占用 2 个通道。Head 的 insertion order 很重要CenterPoint 在 deploy 模式下会按 Head key 的顺序扁平化输出这直接影响导出 HBIR 和最终推理输出 tensor 的语义顺序。三、box_size 的真正含义训练回归 vs 推理输出在 CenterPoint 中经常会看到如下配置postprocess dict( box_size9, )需要明确的是box_size 表示的是 postprocess 之后最终输出给下游使用的 box 物理维度而不是训练阶段的回归维度。3.1 nuScenes 场景box_size 9在 nuScenes 数据集中CenterPoint 通常开启 velocity因此最终输出 box 语义为[x, y, z, w, l, h, yaw, vx, vy]这 9 个量分别来自reg → x, yheight → zdim → w, l, hrot → yaw由 sin/cos 反解vel → vx, vy因此box_size9 是一个​语义必然结果​而不是经验值。3.2 训练回归维度code_size与 box_size 并不相同一个容易混淆的点是训练阶段回归维度code_size推理阶段输出维度box_size以 nuScenes 为例训练回归维度 10reg(2) height(1) dim(3) rot(2) vel(2)推理输出维度 9yaw 从 sin/cos 合并为 1 个角度四、deploy 模式下的输入与输出语义工具链视角4.1 is_deployFalse训练 / 评估路径在训练或评估阶段输入example[“points”]raw point cloud处理流程pre_process → reader → backbone → neck → head → target/loss 或 postprocess其中 pre_process 会完成体素化、点云归一化以及 pillar 特征编码这些过程包含动态点数非规则张量不适合直接导出为静态 IR4.2 is_deployTrue导出 / 部署路径在导出 HBIR 或部署推理时不再接收 raw 点云输入变为features coors流程变为reader → backbone → neck → head → flatten outputs原因很明确BPU / IR 编译需要静态、确定形状的输入点云体素化包含动态结构不利于导出将点云预处理放到外部流水线CPU / DSP更可控也更利于性能调优4.3 deploy_inputs 的语义约束在 OE 示例中deploy_inputs 通常形如features: [1, C, P, M]coors: [M 4]格式为 [batch_idx z y x]这两者必须与 CenterPointPreProcess 的输出严格一致否则导出或推理阶段会出现维度或 scatter 错误。五、编译阶段的输出语义output_layout 与 transpose_dim在模型编译配置中常见如下设置compile_cfg dict( output_layoutNHWC, transpose_dimdict( outputs{global: [0, 2, 3, 1]} ), )这里需要区分两个概念真正生效的是 ​transpose_dim工具链会在输出节点插入 transposeoutput_layout 更多是语义标注也就是说是否从 NCHW 转为 NHWC取决于 transpose_dim而不是 output_layout 字符串本身。工程上建议 output_layout​ 与 ​transpose_dim​​ 保持一致​避免下游推理或解析代码误读输出格式。六、参考算法的一次应用修改示例nuScenes → KITTI在理解了 CenterPoint 的模型结构与输出语义之后再来看一个非常典型的应用场景将 nuScenes 的 CenterPoint 配置修改为 KITTI 使用。6.1 目标差异KITTI 不定义 velocity最终推理输出 box 语义应为[x, y, z, w, l, h, yaw]即推理 box_size 7训练回归维度仍为 8rot 使用 sin/cos6.2 修改不是“改一个字段”而是系统性同步这类修改必须同步覆盖以下模块Head移除 velTarget / Loss不再生成或监督 velocityPostProcess / BBoxCoder不再 decode veldeploy flatten 输出顺序下游解析与评测逻辑一个实用的自检原则是训练回归维度 lencode_weights target anno_box dim​推理输出维度 ​​**postprocess.box​_size**二者必须分别自洽否则一定存在隐患。七、小结CenterPoint 在地平线工具链中并不是一个“只改配置就能安全迁移”的模型box 语义来自Head 设计训练与推理的维度并不等价deploy 模式下的输入、输出和编译布局都有严格约束一个看似简单的 with_velocity 开关实际影响的是跨模块的系统行为理解从模型结构 → 语义拆分 → 工具链部署的完整链路才能正确使用参考算法。