faster-generation有时候耗时会比较长

[zhanghaoie]

欢迎您反馈PaddleNLP使用问题，非常感谢您对PaddleNLP的贡献！
在留下您的问题时，辛苦您同步提供如下信息：

• 版本、环境信息
  1）PaddleNLP和PaddlePaddle版本：请提供您的PaddleNLP和PaddlePaddle版本号，例如PaddleNLP 2.3.3，PaddlePaddle2.3.0
  2）系统环境：系统版本为linux，python 3.8
• 复现信息：
  使用unified-transformer的faster-generation时候,大部分耗时都在30-50ms之间，但是有时候突然就达到了200ms

[zhanghaoie]

仅仅只是串行请求

[guoshengCS]

请问下 200ms 的时候是否有生成更长的回复内容呢，还是说没有生成更长怀疑是性能波动，可以提供部分测试的数据吗

[zhanghaoie]

请问下 200ms 的时候是否有生成更长的回复内容呢，还是说没有生成更长怀疑是性能波动，可以提供部分测试的数据吗

嗨，我设置的最长长度32，返回10条，看耗时长的时候（188ms）返回的最长长度是22，但是返回长度是32的时候，有时候耗时是在55ms，输入的长度都是一样的 长度是8

[zhanghaoie]

请问下 200ms 的时候是否有生成更长的回复内容呢，还是说没有生成更长怀疑是性能波动，可以提供部分测试的数据吗

由于内部的原因，电脑端不能传照片。对了，在请求的时候，显存在不断增大，怀疑跟拼batch相关 但是可以增加到11g左右

[zhanghaoie]

使用的v100, driver 418.126.02 cuda 10.1

[guoshengCS]

我设置的最长长度32，返回10条，看耗时长的时候（188ms）返回的最长长度是22，但是返回长度是32的时候，有时候耗时是在55ms，输入的长度都是一样的 长度是8

这个是稳定复现的吗，可否提供下这个数据来测试下呢

[guoshengCS]

对了，在请求的时候，显存在不断增大，怀疑跟拼batch相关 但是可以增加到11g左右

显存不断增大是会的，使用的是哪个模型多大的模型呢，看下增大的是否合理。另外也想请问下您那边的使用情况，是什么模型做什么任务呢

[zhanghaoie]

这个是稳定复现的，目前使用的模型是plato-mini，是6层的transformer, 是做生成任务，num_return_sequences=10，使用了top-k sampling， top-k=3

[zhanghaoie]

测试是使用的单轮， 你知道郑爽吗？ 目前看是稳定复现了，请求几次就会出现。

[guoshengCS]

你知道郑爽吗？

这个输入请求多次里面就会有部分推理时间到200ms的是吧

[guoshengCS]

这个请 @FrostML 验证看下呢

[FrostML]

性能测试是如何进行的呢？因 CUDA 是异步执行，是否有使用到 cuda_synchronize 的操作辅助计时？

[zhanghaoie]

我使用了 python streamer起了一个服务，然后手动请求，间歇性的耗时比较搞，没有用到cuda_synchronize

[zhanghaoie]

我使用了 python streamer起了一个服务，然后手动请求，间歇性的耗时比较搞，没有用到cuda_synchronize

目前想把服务迁移到triton-inference-server python backend上部署，两个都有间歇性的超时

[FrostML]

简单解释一下：GPU 上 CUDA 执行是异步的，可以简单理解成，比如是使用 time.time() 进行计时，可能到计时的代码的这个位置，之前的代码的底层 CUDA 的部分实际上还没有完成，所以需要加上同步操作 cuda_synchronize，同步操作本身会占用一定的时间，但是能确保之前运行在 GPU 上的部分已经结束。

此外，我理解可能 server 引入的性能的不确定性会高些，如果排除 server 的影响，单单仅执行 unified transformer 的 faster generation 部分是否也有波动的情况发生？另外想确认下，是否是同一时间，一张卡仅有一个 unified transformer 的生成的过程在执行呢？因为加速之后，GPU 利用率打满，如果单卡上有多个进程，比较容易造成生成性能上的不确定性。

[zhanghaoie]

简单解释一下：GPU 上 CUDA 执行是异步的，可以简单理解成，比如是使用 time.time() 进行计时，可能到计时的代码的这个位置，之前的代码的底层 CUDA 的部分实际上还没有完成，所以需要加上同步操作 cuda_synchronize，同步操作本身会占用一定的时间，但是能确保之前运行在 GPU 上的部分已经结束。

此外，我理解可能 server 引入的性能的不确定性会高些，如果排除 server 的影响，单单仅执行 unified transformer 的 faster generation 部分是否也有波动的情况发生？另外想确认下，是否是同一时间，一张卡仅有一个 unified transformer 的生成的过程在执行呢？因为加速之后，GPU 利用率打满，如果单卡上有多个进程，比较容易造成生成性能上的不确定性。

1.仅仅是打印了从输入模型，到输出结果的时间，没有打印底层内部实现的时间，使用的是你们的model.generate的方法。
2.目前卡（32g显存）上有多个其他服务，剩余显存大概26G，但是gpu使用率是0%，目前还有一个问题，gpu显存占用增长的会比较厉害。
3.目前使用faster-transformer 做nsp模型转成torchscript的话，在相同的卡上（有其他服务占用），耗时相对比较稳定，预测25-30条，一般都在20ms左右。

[FrostML]

我举个例子吧

while True:
    time.time()  # start
    model.generate(...)
    time.time()  # end

比如是按照如上方式打印时间，因为 GPU 计算是异步的，到 end 计时点的时候，model.generate() 的计算可能并没有完成。同理，没有显式同步的话，可能到 start 计时点的时候，前一个输入的计算也可能还未完成。这是 GPU 执行方式导致的。
可以通过同步，或是对 model.generate() 的输出做一个拷贝来保证当前 batch 的计算是完成了的。
所以其实就是想确认下 30-50ms 这个数字是否其实是小于单个 batch 实际计算时间，200ms 是否其实是大于了单个 batch 实际计算时间这个事情。

其次呢，因为加速的方式是通过提升 GPU 利用率，所以会比普通的前向比较容易收到其他进程的影响。也是想确认下，在仅使用 model.generate() 的单测里面，排除卡上有其他服务、server 通信的影响，是否也会出现这样的情况。

如果想要进一步分析变慢的原因，需要用到 NVIDIA 提供的 Nsight 工具，可以清晰看到变慢的计算是什么。

[zhanghaoie]

我举个例子吧

while True:
    time.time()  # start
    model.generate(...)
    time.time()  # end

比如是按照如上方式打印时间，因为 GPU 计算是异步的，到 end 计时点的时候，model.generate() 的计算可能并没有完成。同理，没有显式同步的话，可能到 start 计时点的时候，前一个输入的计算也可能还未完成。这是 GPU 执行方式导致的。 可以通过同步，或是对 model.generate() 的输出做一个拷贝来保证当前 batch 的计算是完成了的。 所以其实就是想确认下 30-50ms 这个数字是否其实是小于单个 batch 实际计算时间，200ms 是否其实是大于了单个 batch 实际计算时间这个事情。

其次呢，因为加速的方式是通过提升 GPU 利用率，所以会比普通的前向比较容易收到其他进程的影响。也是想确认下，在仅使用 model.generate() 的单测里面，排除卡上有其他服务、server 通信的影响，是否也会出现这样的情况。

如果想要进一步分析变慢的原因，需要用到 NVIDIA 提供的 Nsight 工具，可以清晰看到变慢的计算是什么。

ok，我们先尝试排除卡的因素以及GPU异步的因素看一下。

[zhanghaoie]

我举个例子吧

while True:
    time.time()  # start
    model.generate(...)
    time.time()  # end

比如是按照如上方式打印时间，因为 GPU 计算是异步的，到 end 计时点的时候，model.generate() 的计算可能并没有完成。同理，没有显式同步的话，可能到 start 计时点的时候，前一个输入的计算也可能还未完成。这是 GPU 执行方式导致的。 可以通过同步，或是对 model.generate() 的输出做一个拷贝来保证当前 batch 的计算是完成了的。 所以其实就是想确认下 30-50ms 这个数字是否其实是小于单个 batch 实际计算时间，200ms 是否其实是大于了单个 batch 实际计算时间这个事情。

其次呢，因为加速的方式是通过提升 GPU 利用率，所以会比普通的前向比较容易收到其他进程的影响。也是想确认下，在仅使用 model.generate() 的单测里面，排除卡上有其他服务、server 通信的影响，是否也会出现这样的情况。

如果想要进一步分析变慢的原因，需要用到 NVIDIA 提供的 Nsight 工具，可以清晰看到变慢的计算是什么。

Hi, 我们找到问题了，确实如果gpu上有其他进程对加速效果影响很大，即使进程不消耗gpu。换了一张没有任何服务的卡，目前没有问题了，多谢

[zhanghaoie]

我举个例子吧

while True:
    time.time()  # start
    model.generate(...)
    time.time()  # end

比如是按照如上方式打印时间，因为 GPU 计算是异步的，到 end 计时点的时候，model.generate() 的计算可能并没有完成。同理，没有显式同步的话，可能到 start 计时点的时候，前一个输入的计算也可能还未完成。这是 GPU 执行方式导致的。 可以通过同步，或是对 model.generate() 的输出做一个拷贝来保证当前 batch 的计算是完成了的。 所以其实就是想确认下 30-50ms 这个数字是否其实是小于单个 batch 实际计算时间，200ms 是否其实是大于了单个 batch 实际计算时间这个事情。

其次呢，因为加速的方式是通过提升 GPU 利用率，所以会比普通的前向比较容易收到其他进程的影响。也是想确认下，在仅使用 model.generate() 的单测里面，排除卡上有其他服务、server 通信的影响，是否也会出现这样的情况。

如果想要进一步分析变慢的原因，需要用到 NVIDIA 提供的 Nsight 工具，可以清晰看到变慢的计算是什么。

Hi, 发现有个问题，我替换成t4部署后，刚开始性能还可以，大概6层的模型20个返回， 可以压到40qps，平均响应时间在160ms，但是随着压测时间的增加，显存会明显增加，当显存在15g左右的时候，吞吐就大幅度下降，平均响应时间在280ms了。

[github-actions]

This issue is stale because it has been open for 60 days with no activity. 当前issue 60天内无活动，被标记为stale。

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale. 当前issue 被标记为stale已有14天，即将关闭。