[ISSUE] 模型推理有优化参数或者预期的优化方案吗

[wenyangchou]

阅读 README.md 和 dependencies.md

• 我已经阅读过 README.md 和 dependencies.md 文件

检索 issue 和 discussion

• 我已经确认之前没有 issue 或 discussion 涉及此 BUG

检查 Forge 版本

• 我已经确认问题发生在最新代码或稳定版本中

你的issues

目前来看，用一张4090显卡推理，QPS超过1响应时间就很长了。在推理这块有没有优化参数或者优化方案，请求参数中有batch_size，这个参数batch合成是否意味着可以加速推理？从文档我没有看的太懂。

从压测数据来看，GPU使用率只能达到50%(worker配置的是4，batch_size设置的默认值)。

目前有优化方案或者优化路线吗？从模型工程或者算法层面有预期的优化策略吗

[zhzLuke96]

关于计划

• compile：编译之后能加速很多，但是需要实现 chunk padding 目前正在尝试实现
• vllm：应该可以用 vllm 的 page attn 加速，目前不清楚效果如何，之后可能会加
• 上游修复：官方的推理代码应该还有优化空间，(我cpu都可以跑 20it/s 但是 gpu 只能 30it/s 就很怪) 这方面就等待上游代码库提升效果了

对于你本地的话，目前最简单有用的优化就是装上 flash attn。正确安装之后 llama model 会自己加载并使用，有一定的速度增益

关于 batch_size，目前并不是传统意义上的 batch，因为推理依赖上下文无法完全并行，只有当满足分割条件时才会触发 batch 推理（即长文本推理）， 这个 batch_size 可以理解为 max_batch_size

[zhzLuke96]

相关 2noise/ChatTTS#302

[wenyangchou]

有4090相关的性能数据吗。

我这个数据看起来好像正常，但是感觉延迟还是很高。我怀疑我这边环境有问题，从监控看，GPU使用率很低。我想看下4090的一个正常加速的数据

[wenyangchou]

有4090相关的性能数据吗。

我这个数据看起来好像正常，但是感觉延迟还是很高。我怀疑我这边环境有问题，从监控看，GPU使用率很低。我想看下4090的一个正常加速的数据

Concurrent Requests: 1
P99 Response Time: 1.129 seconds
Average Response Time: 0.846 seconds
-----------------------
Concurrent Requests: 2
P99 Response Time: 2.488 seconds
Average Response Time: 2.072 seconds
-----------------------
Concurrent Requests: 3
P99 Response Time: 5.034 seconds
Average Response Time: 3.964 seconds
-----------------------
Concurrent Requests: 4
P99 Response Time: 7.924 seconds
Average Response Time: 6.559 seconds
-----------------------
Concurrent Requests: 5
P99 Response Time: 10.663 seconds
Average Response Time: 9.597 seconds
-----------------------

现象来看，响应时间跟并发成正比，感觉是并发没做起来。导致我整体的GPU使用率都提不上去

[zhzLuke96]

有4090相关的性能数据吗。

我这个数据看起来好像正常，但是感觉延迟还是很高。我怀疑我这边环境有问题，从监控看，GPU使用率很低。我想看下4090的一个正常加速的数据

Concurrent Requests: 1
P99 Response Time: 1.129 seconds
Average Response Time: 0.846 seconds
-----------------------
Concurrent Requests: 2
P99 Response Time: 2.488 seconds
Average Response Time: 2.072 seconds
-----------------------
Concurrent Requests: 3
P99 Response Time: 5.034 seconds
Average Response Time: 3.964 seconds
-----------------------
Concurrent Requests: 4
P99 Response Time: 7.924 seconds
Average Response Time: 6.559 seconds
-----------------------
Concurrent Requests: 5
P99 Response Time: 10.663 seconds
Average Response Time: 9.597 seconds
-----------------------

现象来看，响应时间跟并发成正比，感觉是并发没做起来。导致我整体的GPU使用率都提不上去

这是开了 --workers 之后测的吗？启动参数是怎么样的？

[wenyangchou]

这个一周之前测试时，开启--worker一直OOM，子进程一直挂。今天又测了下，看起来好了一点。整体并发基本没啥问题了，偶尔还是会崩一两次，但是看不到日志。python的这个web框架是什么机制？子进程或者主进程崩了后怎么把日志调出来？

另外还是这个问题，GPU使用率还是用不上来。感觉模型并发有问题，我还在看代码实现；准备tensorboard看下模型耗时情况

[wenyangchou]

这边记录几个问题：

1. flash_attn只支持fp16和bp16。当前最新的代码虽然支持flash_attn，但其实没有驱动起来；原因是LlamaConfig配置fp16并没有生效。开启flash_attn会提示当前的类型fp32。这个问题我已经修复，晚会我会pr代码过来

2. 开启flash_attn性能下降，flash_attn有issue说这个可能是attention_mask导致，官方说是不能传padding、noPadding，都需要手动操作。但是实际我把attention_mask去掉，性能也还是没提升

3. 目前发现一个奇怪的问题：设置模型fp16会直接比fp32性能低20%；这个很奇怪，反常识；不确定是不是这个原因导致flash_attn不生效

4. compile开启后性能能提升一倍。但是经常触发recompile，recompile触发机制到现在还没有完全搞懂～

[zhzLuke96]

yysy 我都有点想放弃chatts了，现在正在准备给项目对接上其他模型，chattts还是不太成熟不适合做服务

[wenyangchou]

• fp16慢 这个我也排查过，就是纯粹的llama推理变慢。我对每个阶段都进行了打点，fp16相对于fp32，平均速度下降10%～20%，跟vocos没有太大关系

这个测试的结果，听起来感觉像是 f16 在某个地方又被自动转成 f32 导致的？

我重新看了下 gpt.py 里面好像有几个 dtype 有点问题 ee07d82

估计还是没完全解决问题

我也猜测是这样，但可能不是gpt问题，可能llama本身的问题。我看到其他社区看到llama转onnx之类这种问题会更明显。所以目前短期方案是考虑把vllm的llama部分抄过来。中长期是直接重构到vllm中。

哥 努力啊，别放弃啊，一起优化啊。我们都准备近期就上生产了

[wenyangchou]

gpt.py里面的所有的dtype我都修正过。否则flash_attn无法开启；但似乎fp16慢跟这个没啥关系。gpt这个包下很多函数例如forward都没有用到，底层直接 gpt.gpt.forward，直接调的llama的

[wenyangchou]

yysy 我都有点想放弃chatts了，现在正在准备给项目对接上其他模型，chattts还是不太成熟不适合做服务

你难道还有其他可替换的模型？？

[zhzLuke96]

yysy 我都有点想放弃chatts了，现在正在准备给项目对接上其他模型，chattts还是不太成熟不适合做服务

你难道还有其他可替换的模型？？

fish-speech和CosyVoice

具体进展可以关注这几个 story
#90
#91
#92

[tuxiaoseng]

2noise/ChatTTS#612 (commits)
@zhzLuke96 大佬vllm是不是可以更新一下，辛苦

[zhzLuke96]

官方实现的 vllm 不完善，等完善后会跟进

2noise/ChatTTS#640

[wenyangchou]

@zhzLuke96 音频的声道、位深 这些参数对应的是哪个文件的哪些key值？

[zhzLuke96]

@wenyangchou 没有声道配置，因为目前所有tts模型都是合成单声道音频。也没有位深配置。

你想你需要的可能是编码配置？具体可以看 AudioHandler.py 和 datacls/audio_model.py 可以配置编码器的 bitrate 和 acodec
如果有复杂的编码控制需求，建议设置 format 为 raw 接收完全未编码的原始 bytes 然后自行处理编码问题