HoratioJSY

关闭所有优化，只要开了collect_shape_range_info ，就会报错。 这个配置下是会报错的： ```python +--------------------------+-------------------------------------------------------------------------------+ | Option | Value | +--------------------------+-------------------------------------------------------------------------------+ | model_file | /ParallelismCodeTransformer/quant_panGu/saved_model_20/QuantPanGu.pdmodel | | params_file | /ParallelismCodeTransformer/quant_panGu/saved_model_20/QuantPanGu.pdiparams | +--------------------------+-------------------------------------------------------------------------------+ | cpu_math_thread | 1 | | enable_mkldnn |...

可能上面的观察不是很正确的，在保持训练和导出代码不变的情况下，我重新导出一次模型之后，gpu dnn handle is nullptr 的报错在开启collect_shape_range_info 的情况下一定会出现。而不开启collect_shape_range_info ，会随机出现这个报错，或者正常运行。 如果运行时配置`export GLOG_v=10`，所有日志也只有如下报错部分，会出现ERROR的字样： ```python W0805 06:52:14.390362 21907 operator.cc:284] softmax raises an exception paddle::PD_Exception, the gpu stream is nullptr. [/paddle/paddle/phi/backends/gpu/gpu_context.cc:377] I0805 06:52:14.390684 21907 executor.cc:67]...

嗯嗯，稍等，我更新了paddle 2.3.0 到develop分支，对应的paddle inference也是，之前的问题有的解决了（主要是TensorRT子图方面的），后面我会再测一遍while_loop，如果还是一样的我再提供一个测试模型

还是会出现这个问题，现在的现象是：while 算子在静态计算图的训练中都能正常输出结果，实现多步预测。但是当导出为inference模型，paddle inference 那边启动预测会随机出现三种异常：1. RuntimeError: the gpu stream is nullptr；2. Segmentation fault；3. 占GPU显存，不占GPU利用率，不报错一直等待。 第一种报错前面有，第二种报错是如下这种： ```python I0812 07:28:39.661653 23546 analysis_predictor.cc:1266] ======= optimize end ======= I0812 07:28:39.668598 23546 naive_executor.cc:110] --- skip [feed],...

下面两个函数大概是，构建predictor与执行predictor的代码，正式推断时会启动args.use_trt和args.int8。 ```python def create_predictor(self, args): model_files = os.listdir(args.model_dir) model_name = None for file in model_files: if file.endswith(".pdmodel") and not file.startswith("int8"): model_name = file[:-len(".pdmodel")] break if model_name is None or not...

嗯嗯，我们是通过量化训练，再转到trt推断，trt确实会运行一些INT8子图，在A100上速度上也挺快的，只看纯计算的时间，我觉得这些都是没问题。问题在于TRT子图外面，paddle原生算子显存与内存的拷贝占用了太多时间。如果去掉我知道的那些会产生大量CPU与GPU内存拷贝的代码，那么速度上就会有比较大的提升，但是实际上并不能去掉。所以想要了解一下，inference能不能将所有Paddle原生OP都移到GPU上，不让在CPU。

> 顺便问下: 目前trt int8的性能不满足需求？ 在什么GPU卡上，需要提升到多少才能满足需求？你们的业务场景是？ 在A100上纯计算的话性能是满足的，但实际还会有一些conditional_block和set_value，目前它们不能转化到trt子图，所以需要优化这部分时间。我们的业务场景是代码生成吧，大规模NLP模型需要保证单步解码速度大概在30ms左右。

> 方便提供下模型和简单运行的demo吗？ 能不能把op都放入trt子图需要具体针对op看下才能给你答复。 完整的模型特别大，百亿级参数量，不太好提供运行demo；如果实在需要的话，可以初始化一个几千万参数的小模型做测试。我们之前感觉主要产生计算的OP已经放入了TRT里面，paddle 原生OP到并不是一定要放进去，因为即使放进去应该收益也不会特别大。关于不同OP的耗时，这个后面提供了两份完整的profile。 > 你说的纯计算时间是统计了整个 predictor.run(copyfromcpu、copytocpu没统计) 还是说通过profile把各个op的计算时间加起来？ 没，只是简单的看profile中tensorrt_engine的耗时，它承担了模型backbone部分（在前一步做量化训练时只量化了matmul算子），它是最主要的耗时；其它的耗时主要就是GpuMemcpySync。 附一：在计算图内保存中间计算状态，即将一个大张量set_value到内部的一个Parameter变量，方便在下一次调用计算图时复用这个Parameter张量。 ```python ------------------------- Overhead Summary ------------------------- Total time: 566354 Computation time Total: 151833 Ratio: 26.8089% Framework overhead Total: 414521 Ratio:...

嗯嗯，感谢，paddle 版本是2.3.0，“_opt_cache” 里面最大的是27_ir_transpose_flatten_concat_fuse_pass.dot。之前尝试用过NVIDIA Nsight Systems，也能可视化计算时间，但好像有点看不懂，因为我知道哪一行代码会产生set_value，就没继续看了，我可以再试试。能问一下您的联系方式么。。

哦，我看错了，以为前面问有多少个.pdmodel，所以贴上了带数字的那个文件。能加一下您的联系方式么，效率高一些。。