你的PR提交成功，感谢你对开源项目的贡献!
请关注后续CI自动化测试结果，详情请参考Paddle-CI手册。
Your PR has been submitted. Thanks for your contribution!
Please wait for the result of CI firstly. See Paddle CI Manual for details.

@RichardWooSJTU 吴哥麻烦帮忙看看

我目前这样实现把所有的 quant dequant op (包括不是在 matmul_v2 前面的) 都删掉再做融合这样是否有影响？

A: 有影响，对于含有conv算子的模型也都删掉了quant/dequant，但是并没有其他pass执行后续操作

我目前实现 matmul_v2 和 element_wise 算子的融合是针对了 matmul_v2 算子，没有考虑到 mul 算子，因为我看有一些其他的 pass 会有将 matmul_v2 转换为 mul 算子的行为，但是目前应该是只有这个 matmul_v2 算子有 int8 的实现，所以请问这样是否有影响？

A: 你的pass将matmul_v2已经删除了，并融合到了quant_linear里面。

我不大清楚哪些 attributes 是必须的

A: 每一个都是必须的，只不过会有默认值。这需要你理解每一个attr的含义及作用

我目前这样实现把所有的 quant dequant op (包括不是在 matmul_v2 前面的) 都删掉再做融合这样是否有影响？

A: 有影响，对于含有conv算子的模型也都删掉了quant/dequant，但是并没有其他pass执行后续操作

我目前实现 matmul_v2 和 element_wise 算子的融合是针对了 matmul_v2 算子，没有考虑到 mul 算子，因为我看有一些其他的 pass 会有将 matmul_v2 转换为 mul 算子的行为，但是目前应该是只有这个 matmul_v2 算子有 int8 的实现，所以请问这样是否有影响？

A: 你的pass将matmul_v2已经删除了，并融合到了quant_linear里面。

我不大清楚哪些 attributes 是必须的

A: 每一个都是必须的，只不过会有默认值。这需要你理解每一个attr的含义及作用

好的～

@RichardWooSJTU 吴哥麻烦再 review 一下

你好，有在具体的模型上测试下这个 pass 能带来的性能提升吗？

你好，有在具体的模型上测试下这个 pass 能带来的性能提升吗？

有在 bert 模型下测过 Paddle Inference 下原生 fp32 推理（不运行任何pass, 输入的大小为 (batch_size, 512)，测试方法为先进行三次的 warm up ，然后运行十次取平均结果）以及只运行这一个 pass 的运行时间对比：

你好，有在具体的模型上测试下这个 pass 能带来的性能提升吗？

有在 bert 模型下测过 Paddle Inference 下原生 fp32 推理（不运行任何pass, 输入的大小为 (batch_size, 512)，测试方法为先进行三次的 warm up ，然后运行十次取平均结果）以及只运行这一个 pass 的运行时间对比：

上面的问题不是说pass的运行时间 而是推理的运行时间，pass时间不算在内；

你好，有在具体的模型上测试下这个 pass 能带来的性能提升吗？

有在 bert 模型下测过 Paddle Inference 下原生 fp32 推理（不运行任何pass, 输入的大小为 (batch_size, 512)，测试方法为先进行三次的 warm up ，然后运行十次取平均结果）以及只运行这一个 pass 的运行时间对比：

上面的问题不是说pass的运行时间 而是推理的运行时间，pass时间不算在内；

我测的是推理时间应该没错，从 predictor.run() 前面计时再到 predictor.run() 结束再次计时，对比的是任何 Pass 都不用的推理时间和只用这一个 pass 之后的推理时间。

你好，有在具体的模型上测试下这个 pass 能带来的性能提升吗？

有在 bert 模型下测过 Paddle Inference 下原生 fp32 推理（不运行任何pass, 输入的大小为 (batch_size, 512)，测试方法为先进行三次的 warm up ，然后运行十次取平均结果）以及只运行这一个 pass 的运行时间对比：

上面的问题不是说pass的运行时间 而是推理的运行时间，pass时间不算在内；

我测的是推理时间应该没错，从 predictor.run() 前面计时再到 predictor.run() 结束再次计时，对比的是任何 Pass 都不用的推理时间和只用这一个 pass 之后的推理时间。

嗯嗯 所以说和pass的实现没有关系，性能只和算子相关。看起来在大batch下还不如fake量化？ 可能需要开启一下kernel选择用于算子加速

在python中 加入
paddle.base.core.enable_autotune()
paddle.base.core.update_autotune_status()

在环境变量上加入
export FLAGS_use_autotune=1
export FLAGS_cublaslt_exhaustive_search_times=10

你好，有在具体的模型上测试下这个 pass 能带来的性能提升吗？

有在 bert 模型下测过 Paddle Inference 下原生 fp32 推理（不运行任何pass, 输入的大小为 (batch_size, 512)，测试方法为先进行三次的 warm up ，然后运行十次取平均结果）以及只运行这一个 pass 的运行时间对比：

上面的问题不是说pass的运行时间 而是推理的运行时间，pass时间不算在内；

我测的是推理时间应该没错，从 predictor.run() 前面计时再到 predictor.run() 结束再次计时，对比的是任何 Pass 都不用的推理时间和只用这一个 pass 之后的推理时间。

嗯嗯 所以说和pass的实现没有关系，性能只和算子相关。看起来在大batch下还不如fake量化？ 可能需要开启一下kernel选择用于算子加速

在python中 加入 paddle.base.core.enable_autotune() paddle.base.core.update_autotune_status()

在环境变量上加入 export FLAGS_use_autotune=1 export FLAGS_cublaslt_exhaustive_search_times=10

好的

在python中 加入
paddle.base.core.enable_autotune()
paddle.base.core.update_autotune_status()

在环境变量上加入
export FLAGS_use_autotune=1
export FLAGS_cublaslt_exhaustive_search_times=10

添加环境变量后，分别测试在原生 fp32 和原生 int8 下的的测试结果如下：
模型：macbert-large-chinese（3.35亿参数)
测试环境：A100

由于原生 fp32 有一些例如 multihead_matmul_fuse 等额外加速推理的算子融合 pass 在当前这个 int8 融合算子后不支持，所以当前 int8 的加速只是纯算子运算速度层面的加速，后续还有很多 pass 层面的加速空间。