Triton inference about insightface-rest HOT 8 CLOSED

Thanks,
I will wait for such updates if it intersects with your interests.

close

I'm definitely interested in such updates, though it might take a while )

from insightface-rest.

I have quickly read your .ipynb, can't say anything right now, I'll check my local triton branch later.
Though I have noticed you are using strange image preprocessing in preprocess_image:

# HWC to CHW format:
image -= (104, 117, 123)

Such preprocessing isn't required for RetinaFace.

from insightface-rest.

I have quickly read your .ipynb, can't say anything right now, I'll check my local triton branch later.
Though I have noticed you are using strange image preprocessing in preprocess_image:
image -= (104, 117, 123)

del this row, I forgot.

I use https://netron.app for debug converted ONNX

from insightface-rest.

I'll upload up-to-date Triton backend in day or two, which you can use as reference for your experiments.

In your Triton config outputs seems to be ok, thought I 'd check that Triton returns outputs exactly in the same order as required for Retinaface

from insightface-rest.

I have updated Triton backend. Keep in mind that communication with Triton server from python introduces large delays and greatly reduces performance.
You may notice commented lines related to using CUDA shared memory, it may help you gain some performance back, though use it at your own risk )

from insightface-rest.

thank you

Potential delays can be attributed to several things

1. FP32 - I was unable to get triton to treat the converted model as FP16. I think int8 should speed up the inference but need to correctly convert and calibrate the model.
2. All processing needs to be transferred to Triton. For image preprocessing, I found DALI. Post-processing is more complicated because it requires transferring the NMS and something else for the retinaface. It seems that I found a plug-in from NVIDIA somewhere, but embedding it into the pipeline is not a trivial task for me, at the moment)
3. following from the last point, you need to immediately do in triton ensamble, so as not to drive data back and forth.

Here's what a performance study looks like to me. But this is a rather complicated process.

Have you tried any of these?

from insightface-rest.

1. I have noticed that Triton for some reason states that model is fp32, but if you compare actual performance of fp32 and fp16 models with Triton perf client difference is obvious.
2. I haven't tested it yet since it requires lot of changes to source code, but since now Triton supports python backend and DALI preprocessing it's really worth a try.
3. It'll be not trivial to put all face detection/recognition pipeline into Triton, but it's very promising, especially considering that some parts of pipeline could be replaced with c++.

from insightface-rest.

1. I have noticed that Triton for some reason states that model is fp32, but if you compare actual performance of fp32 and fp16 models with Triton perf client difference is obvious.
2. I haven't tested it yet since it requires lot of changes to source code, but since now Triton supports python backend and DALI preprocessing it's really worth a try.
3. It'll be not trivial to put all face detection/recognition pipeline into Triton, but it's very promising, especially considering that some parts of pipeline could be replaced with c++.

Thanks,
I will wait for such updates if it intersects with your interests.

close

from insightface-rest.