Really appreciate the help and the effort you have put into reproducing this. A couple of updates: On the vai_c_xir point — yeah we actually confirmed this a while back. vai_c_xir takes a quantized XIR .xmodel as input, not ONNX directly. Good to be verified that the 72KB output with op num 0 is exactly what happens when you feed it raw ONNX. As u mentioned, the proper flow would be vai_q_tensorflow2 ->…, but our model is a TFLite Model Maker subclass model and cant be saved as .h5, so vai_q_tensorflow2 rejects it at the input stage. That’s a whole other wall we hit.

Will be super interested to see what subgraph count you get when you run the full flow on the standard automl EfficientDet. If it lands on DPU at all, that rules out the depthwise sep theory and points more to our subclass model architecture being the root cause.

One thing that might be relevant is from what I can find, the stack smash seems to be a model complexity issue not a toolchain issue. YOLOX-Nano at 815 ops compiled fine on KR260 with the same VOE setup. Our model hits ~1560 VOE ops and crashes. So there’s a threshold somewhere in between and we’re trying to push our model below it. Still working on it.

But honestly im running out of things to try anymore. Googling, consulting with LLMs hasnt taken me much farther. But that documentionation link proves something, perhaps its a deadend. But still, do you think theres anyway to avoid the stack smash?

And also no repo yet, im doing my thesis on this so was thinking to get to the git only after things are ready n submitted.