专栏算法工具链模型部署时报错

模型部署时报错

已解决
cbeibieq2026-02-25
152
15

利用j6工具链部署时报错

../../hbdk/lib/transforms/codegenpass/tiling.cpp:867: in function 'runtiling': assert: !allocresult && "l1m allocation cannot fail in codegen replaying"
illegal instruction (core dumped)
这是什么原因🧐
算法工具链
技术深度解析征程6
评论1
0/1000
  • HuangHui
    Lv.5

    你好，请问这个错误是在什么情况下报出的，可以简单描述一下你所处的环境和所执行的活动吗？

    2026-02-25
    0
    14
    • cbeibieq回复HuangHui:

      compile编译的时候，是不是内存不够导致的？

      2026-02-25
      0
    • HuangHui回复cbeibieq:

      就是说，你是在x86的docker进行模型编译然后报的这个错误是吧，走的PTQ链路吗？可以分享一下你的onnx，我这边也做一下编译试试，如果我这边OK的，那就是环境问题。这个也是最快的验证方法了

      2026-02-25
      0
    • HuangHui回复cbeibieq:

      a3是啥？

      2026-02-25
      0
    • cbeibieq回复HuangHui:

      额，所以这个问题是啥呢

      2026-02-25
      0
    • HuangHui回复cbeibieq:
      还是需要先了解你的使用环境，才能具体定位问题，从目前你给到的信息还无法判断工具链的使用流程是不是对的，避免错误的排查方向。工具链的正确使用如下，这个你还得麻烦你先确定一下：
      1. 在X86架构的ubuntu22.04系统上通过docker使用工具链。
      2. 在docker容器中，工具链中的PTQ示例可以正常完成校准数据准备、模型量化和编辑
      3. 自己的模型跟PTQ示例一样，也是在docker容器中进行编译是报的错。
      4. 初步看这个错误（ illegal instruction）不像是常规内存不足问题，更像是编译环境 CPU 指令集的问题。可以麻烦在编译环境下执行以下命令确认一下吗：
      2026-02-25
      0
    • HuangHui回复cbeibieq:

      另外，你说a3上是OK的，也麻烦说一下a3这台机器的系统和 CPU 信息哈？

      2026-02-25
      0
    • HuangHui回复cbeibieq:

      好的，不同芯片和工具链的硬件约束和设计有差异这个是正常的，我们还是回到地平线工具链上。我上面说的使用环境的正常性确认还是需要你确认double check的。我们会尽量通过报错和环境定位问题，如果信息不足，还是需要提供更多数据（比如模型）用于问题复现和排查的哈。

      2026-02-25
      0
    • cbeibieq回复HuangHui:

      使用370版本的工具链没有遇到这个错误，后面遇到了一个输入张量不匹配的问题不知道怎么解决，一个add的两个输入分别是8w_16c、4w_8c，期望输出为8w_16c，这个应该怎么处理

      2026-02-27
      0
    • HuangHui回复cbeibieq:

      这个add操作在原始浮点模型模型是OK的？看看是那个阶段引入的不一致：PTQ分为了结构优化optimized，校准伪量化calibration，量化quantized，和编译hbm bin这些阶段；另外，如果可以尽量用截图的方式分享错误提示，避免信息疏漏。

      2026-02-27
      0
    • cbeibieq回复HuangHui:
      是在compile model阶段，进度已经100%，但是后面报错了
      2026-02-27
      0
    • HuangHui回复cbeibieq:

      您好，

      从当前日志来看，报错位置确实在/map_head/transformer/query_decoder/.../Add_1，原因为：binary_eltwise op has invalid layout blocks。被加的两个数都是[1, 2656, 256]，shape匹配没有问题，Add 两个输入的底层 block layout 不一致 导致错误。

      当前日志中可以看到和你同步的一样：

      • 一路输入 block = 8W_16C

      • 另一路输入 block = 4W_8C

      在 J6 BPU 上的 Eltwise(Add) 算子要求两个输入 block 完全一致，不会自动做 layout 转换，这也是编译失败的直接原因。

      请确认您协助确认一下：

      1. 使用 Netron 查看该 Add 的两个输入来源：

        • 是否来自 ConstantOfShape 或 calibration 分支

        • 是否存在 broadcast 操作

      2. Add 节点前后 2～3 层的 ONNX 结构截图麻烦分享一下呢
      另外，Add是支持f16/fp32的， 可以设置一下不同的量化类型看看是不是可以编译通过呢，设置参考如下：
      2026-02-27
      0
    • cbeibieq回复HuangHui:

      这是产出的ptq模型的结构，右上角1x600x256就是/map_head/ConstantOfShape_output_0_hzcalibration的输出

      2026-02-27
      0
    • HuangHui回复cbeibieq:

      从您提供的 Netron 截图看，当前报错节点为：/transformer/query_decoder/_layers.1/transformer_layers.0/Add_1， 该节点的两个输入分别来自：

      • 一路为 Concat → HzCalibration
      • 另一路为 HzCalibration 分支
      逻辑 shape 看起来是一致的（1×2656×256），但由于两个输入来自不同分支，并且中间经过了 HzCalibration 节点，在编译阶段可能会推导出不同的 block layout，因此在该 Add 上触发约束。
      从目前信息无法仅根据截图确认具体是哪一路分支或哪个 operand 引入了 layout 不一致，还需要进一步验证。

      建议尝试几个方向协助定位：

      1. 尝试使用 fast-perf 编译模式重新编译一次
        有时不同编译策略下 layout 推导会有所不同，可以先验证是否仍然报错。
      2. 临时将该 Add_1 节点配置为 float16 路径进行验证
        Add是支持f16/fp32， 尝试设置不同的量化类型看看是不是可以编译通过呢，如果这样可以编译通过。
      如果上述尝试后问题仍然存在，看看是不是可以提供模型（或最小复现版本）。

      我们这边可以尝试本地复现并进一步与研发一起定位具体原因。
      2026-03-09
      0
    • HuangHui回复HuangHui:

      客户您好，长时间未收到你的答复，相信问题已解。如对此尚存疑问欢迎新帖讨论，感谢您的参与！

      2026-03-17
      0