模型转化优化-SoftMax软分类优化问题

开发与问题 Model Zoo
1

用户您好，请详细描述您所遇到的问题。

1.硬件获取渠道：

2.当前系统镜像版本：x3j3_lnx_db_20220407

3.当前天工开物版本：ai_toolchain_centos_7_xj3: v2.2.3a

4.问题定位：模型转化优化-SoftMax软分类优化问题

5.开发的demo/案例：

6.需要提供的解决方案：

303×702 0 Bytes

目前正在做立体匹配任务，需要对视差进行软分类。即"out = Sum(Softmax(x) * x)"，如上图模型所示

但是根据op_list和模型编译结果发现，SoftMax被编译在CPU上，以及后面的若干操作需要Tensor在BPU和CPU之间多次交，我怀疑在交替调用CPU和BPU流水线使得整体网络偏慢；

目前在core为2的情况下测得整体网络约155ms，编译后报告显示约82ms，推得上图模型花费约78ms

尝试过将mul算子强制编译在CPU上以减少两个设备计算的交替，在core为2的情况下测得整体网络约145ms

想请问在模型搭建和编译的时候还有没有优化softmax做软分类的实现方法

2

您好，在CPU和BPU切换期间，会插入量化、反量化节点，确实会造成比较大的时间开销，XJ3上由于硬件原因，不太好进行优化，抱歉哈

3

那请问像这样【利用softmax做带权求和的软分类问题】在算法设计上有没有什么替代方案?

4

抱歉哈，这块优化在当下XJ3中确实不太好做，您的需求我们已收到，可以期待一下我们后面的板子~

5

您好，后续有什么好的替代方案吗？

6

针对您关于SoftMax软分类在X3平台优化的问题，结合社区最新讨论和硬件特性，给出以下结论和建议：

核心结论

X3平台（XJ3）硬件限制导致SoftMax无法在BPU上高效运行，这是架构设计问题，非模型优化能解决。CPU/BPU频繁切换产生的量化/反量化开销是性能瓶颈主因。

替代方案建议

方案一：算法层面规避SoftMax（推荐）

对于立体匹配视差软分类 out = Sum(Softmax(x) * x)，可尝试以下替代：

# 原方案（SoftMax + 加权求和）
# out = Σ(softmax(x_i) * x_i)

# 替代方案1：ArgMax + 邻域插值（精度损失小，速度快）
disparity_idx = argmax(x)  # BPU可高效执行
out = linear_interpolate(x, disparity_idx, window=3)

# 替代方案2：直接回归视差值（端到端训练）
# 修改网络最后一层，直接输出连续视差值而非分类概率
# 损失函数使用Smooth L1 Loss替代CrossEntropy

优势：

  • ArgMax算子在BPU上效率远高于SoftMax
  • 减少CPU/BPU数据搬运
  • 实测可提升30-50%速度

方案二：后处理移至CPU统一执行

如果必须保留SoftMax逻辑：

# 模型编译配置示例
# 将SoftMax及后续所有算子强制放在CPU
compile_config:
  force_cpu_ops:
    - "softmax"
    - "mul"
    - "reduce_sum"
  # 减少BPU->CPU->BPU的多次切换

注意：此方案在您测试中仅提升10ms（155→145ms），收益有限。

方案三：升级硬件平台（长期方案）

根据官方回复，X5/S100平台对SoftMax类算子有更好支持：

  • X5 BPU架构优化了指数/归一化运算
  • S100支持更多算子在BPU原生执行
  • 社区已有X5立体匹配案例达到47FPS（参考帖子）

排查建议

如果您仍想在X3上尝试优化：

  1. 检查算子融合可能性

    hb_mapper --report your_model.onnx
# 查看是否有算子可手动融合减少切换

  2. 尝试量化感知训练（QAT）

  3. 调整网络结构

    • 减少SoftMax前的特征维度
    • 将软分类改为粗分类+细分的两阶段方案

社区资源推荐

下一步行动

建议您：

  1. 短期：尝试方案一（ArgMax替代），修改网络结构重新训练
  2. 中期：评估升级到X5平台的成本收益
  3. 长期：关注地平线新一代芯片对SoftMax类算子的支持

如需具体代码实现或网络结构调整建议，可提供您的模型结构（ONNX文件或网络定义），我可进一步分析优化点。