-
Notifications
You must be signed in to change notification settings - Fork 998
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
高性能插件部署通用版面解析产线v1报错 #3514
Comments
你好,你观察到的情况是正常且符合预期的。实际上高性能推理插件结合当前运行环境信息与储存的先验知识为每个模型自动选择“最优”的推理后端(推理引擎),当选中TensorRT后端时,在第一次运行时将构建引擎,这可能需要较长时间。从第二次运行开始,将使用缓存的引擎,通常就不再需要等待这么长时间了。 |
你好,我的这个情况是已经进行过第一次运行,然后我关了服务之后(ctrl+c),再重启服务paddlex --serve --pipeline layout_parsing.yaml --use_hpip(没有删除第一次运行保存的文件),测试依然非常慢,一张图片要6 7分钟~ |
可以确认一下模型存储的位置是否生成了 |
有可能是SLANet_plus模型在当前环境中自动选择的后端并不是trt类的后端,也就不需要生成构建缓存。实际上,在加载模型时,你应该可以在程序打印的日志中看到实际选择的后端的信息。 如果缓存文件存在,但仍发现一张图片要6 7分钟,很可能是因为模型输入的尺寸超出了预设的动态范围,触发了重新构建引擎。如果你能确定实际需要处理的输入的形状范围,可以参考高性能推理文档中的相关说明,通过修改产线配置文件调整构建引擎使用的动态形状范围(再重新执行程序前记得清空缓存);如果不能,你可以多找一些数据,对服务进行预热,这些数据应该尽可能与实际接近,这样经过几次重新构建后,各个模型的动态形状范围应该会被自动更新到满足实际数据的要求。 |
好的,谢谢~有个问题我想确认下,如果我多找一些数据,对服务进行预热之后,然后我通过ctrl+c关了服务之后,再马上重启服务paddlex --serve --pipeline layout_parsing.yaml --use_hpip,那我之前的预热还有用吗?还是说只要断了服务,下一次重启都需要重新预热? |
正常情况下,通过预热更新的信息会被写入到缓存文件中,这样下一次启动服务不再需要重新预热。如果你发现程序的实际行为不符合预期,欢迎向我们汇报bug~ |
您好,我的操作如下: E0305 09:13:44.520833 269715 helper.h:131] 3: [builder.cpp::~Builder::307] Error Code 3: API Usage Error (Parameter check failed at: optimizer/api/builder.cpp::~Builder::307, condition: mObjectCounter.use_count() == 1. Destroying a builder object before destroying objects it created leads to undefined behavior. INFO: xxxxxxxxxxxx:52405 - "POST /layout-parsing HTTP/1.1" 200 OK 我第二次和第三次输入的是相同图片,那是不是就不会存在输入尺寸动态变化的问题? |
如果在第二次运行的时候,使用相同的图片重复请求,可以观察到缓存生效吗? |
在第二次运行的时候,使用相同的图片重复请求,缓存应该是生效的,因为时间快了很多,基本上1-2秒一张图。 |
这样的话,这看起来是一个bug,辛苦 @zhang-prog 看看这个问题呢 |
感谢~期待可以尽快解决这个问题~ |
您好,我这边没有复现您的问题,我是按如下步骤去测试的:
麻烦您先贴一下您的paddlex和ultra-infer版本,然后试试把官方模型都删除之后( |
这个问题也辛苦 @zhang-prog 确认一下是不是bug |
感谢,我的paddlex版本是paddlex3.0.0rc0,ultra-infer的版本是'1.0.0'。我是通过下面的方式构建镜像和容器,并启动服务的 paddlex --serve --pipeline layout_parsing.yaml --use_hpip 另外想问下, 我想先完全按照您的去复现,看看是否有问题~ |
您好,我应该定位到bug在哪里了。需要你们解决下~~首先默认的预设动态shape是最小[1, 3, 128, 64], 最大 [8, 3, 512, 278]。具体情况如下: 1、启动新服务。 4、结束服务。 8、结束服务。 从以上的情况看,好像只要出现以下报错信息,当前更新的缓存就不会保存下来。不清楚是不是paddlex现在的tensorrt构建有问题~ |
好的,感谢您的定位,目前和我们发现的问题一致。这个问题我们已经在修复中,晚些会给您解决方法~@Danee-wawawa |
您好,我们已经修复了这个问题,麻烦重新装下高性能推理所需要的包即可。执行以下指令:
|
好的,我明天试一下,感谢~ |
您好,想先确认下,需要把之前按照这个安装的插件paddlex --install hpi-cpu卸载掉吗? |
另外关于上面这个问题,我按照您的修改对 但是依然无法奏效,必须去修改每个模型文件夹里的inference.yaml文件里面的参数才行,对应参数如下图所示: 麻烦您再确认下~ |
您好,按照上述步骤重新装高性能推理所需要的包之后,依然遇到了相同的问题,并没有解决BUG~~辛苦看下 |
您需要本地安装PaddleX才可以哈,不然本地的改变无法影响到您安装的PaddleX。
配置文件可以参考这一段,如果您要修改
|
首先请确保您成功重装了那两个包,可以观察下有没有下载包并且 reinstall。 一般超出尺度会使得trt重新构建一次,但可以保留下缓存,之后相同的图片的请求不会再重建引擎。昨天我测试是可以的,您多试几次看看哈。 我们修复后的测试流程:
|
您好,您说的本地安装是指不通过直接拉取镜像的方式,而是通过git clone https://github.com/PaddlePaddle/PaddleX.git之后,然后 安装PaddleX是吗? |
是的,使用release/3.0-rc分支 |
好的,因为我们的项目必须要在docker环境下进行,那我是不是可以先拉取一个paddlepaddle3.0.0rc0版本的docker,如下: 然后在上面构建的容器里面进行paddlex的release/3.0-rc分支的安装呢? |
完全可以的 |
好咧,感谢~我下午重新构建下环境再试下~ |
我已经将这部分修改同步到了release/3.0-rc分支,您进容器,然后切到这个分支,拉下最新代码, |
好的👌 |
|
好的👌 |
那我还需要执行上面的三个指令不? |
需要的,留意一下是否重新安装了哈 |
要安装服务化部署插件噢,指令:
另外,你是新开了一个容器吗?新开容器的话安装高性能推理包的时候不用加
|
好的,忘记执行paddlex --install serving了, |
您好,我在执行这个命令 是我的环境不对吗? |
这个信息不用管的,提示信息 |
您好,环境我都配置好了,然后运行paddlex --serve --pipeline layout_parsing --use_hpip,可以启动服务,然后我测试了一张图片,但还是出现和之前一样的情况,报了之前的错误~ |
我把我两次启动服务的log放在这里,您看下,第二次就启动不起来了,一直卡在最后那里~
|
您好,第一次是会构建引擎,这是符合预期的。 您发现的问题是:使用同一张图片多次推理,每次都需要重新构建引擎,说明没有保留缓存。 我们解决的是这个问题,麻烦使用相同图片多推理看看会不会再次重新构建引擎。您现在只推理一次,我们看不出来是否生效哈 |
如果确定了是在新开的容器里执行了如下语句: paddlex --install serving
paddlex --install hpi-gpu
# 或者手动安装那两个wheel包 在启动服务时,即使遇到形如
的错误,只要程序最终能够完成引擎构建(没有报错退出),可以忽略这些错误。这些错误是paddle框架调用TensorRT API进行优化时出现的,不一定影响最终结果。 另外建议测试时先使用默认的产线配置文件(即,不手动调整高性能推理配置),如果有其他需求可以在基本的情况测试成功后再尝试。 |
15分钟才启动起来不太正常,建议提供一下日志,我们看看可能是什么原因。 测试卡住,从日志来看可能是在重新构建引擎。看起来你所使用的测试数据很可能具有多样变化的尺寸,并且尺寸范围和该产线常见的数据不太一样。对于这种情况,我建议可以修改产线配置文件,将动态形状修改到一个较大的范围,使得实际数据超出预设范围的情况尽可能少出现。 |
好的,无高性能推理插件的服务化部署变慢有些奇怪,因为我理解我们这次并没有对这部分进行修改;不使用高性能推理->使用高性能推理的响应时间从168s->147s我觉得是有可能的,比如这条产线的主要耗时的地方不在模型推理或与模型推理关联的前后处理,这样就可能出现这种情况;如果使用的 |
好的👌 |
您好,我换了一个服务器重新部署,但是它默认给我走到了CPU,想问下是什么原因,和显卡占用有关嘛? |
显卡驱动有正确安装吗 |
嗯嗯,正常安装了,我发现必须加个--gpu才行,即paddlex --serve --pipeline layout_parsing.yaml --use_hpip --gpu,但是很奇怪,我在另外一台机器上直接运行paddlex --serve --pipeline layout_parsing.yaml --use_hpip它是直接调用gpu的,这是怎么回事? |
paddlex使用了GPUtils库来判断GPU是否可用,可能是在某些环境下GPUtil无法正确识别到GPU。如果方便的话可以提供一下出现这种情况的环境吗?我们看看是不是做一下特殊处理。
|
好的,您说的环境主要包括哪些呢? |
主要是显卡型号、驱动版本以及CUDA版本 |
1、采用官方提供的docker环境部署,docker run --gpus all --name paddlex -v $PWD:/paddle --shm-size=8G --network=host -it ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddle:3.0.0rc0-gpu-cuda11.8-cudnn8.6-trt8.5 /bin/bash
2、然后采用高性能启动服务:paddlex --serve --pipeline layout_parsing.yaml --use_hpip
3、上传图片之后界面显示如下报错信息:
E0304 01:51:21.861023 190774 helper.h:131] 3: [builder.cpp::~Builder::307] Error Code 3: API Usage Error (Parameter check failed at: optimizer/api/builder.cpp::~Builder::307, condition: mObjectCounter.use_count() == 1. Destroying a builder object before destroying objects it created leads to undefined behavior.
4、但是流程并没有暂停,在等待很久之后也返回了版面解析结果,我的图片大小是1190*1684,花了6分多钟才返回结果
想问下高性能插件怎么会这么慢?是不是我哪里处理错了,麻烦帮忙看下,谢谢~
The text was updated successfully, but these errors were encountered: