FunAudioLLM
Cosyvoice2.0 流式推理慢的原因看这里，不知道是作者故意埋的坑还是暂时先这样做。
从这段代码里可以看出来，在cosyvoice2model的tts推理函数里，在stream为true的情况下，每次推理都会把之前攒起来的长度一起推，如果chunk_size是A，那么每次推一个chunk的长度依次为：A, 2A, 3A, 4A....依次类推，到最后一个chunk，会推一整句话，所以会特别慢，暂时不清楚这是作者糊涂了这么写，还是先放一个placeholder推理
理论上如果跟训练保持一致的话 是不可能做到低延时的 因为你必须每个chunk能看到过去的所有chunk 在最后一个chunk你需要提供过去的所有chunk 所以其实一般在流式训练中的做法是设置 num_left_chunks 就是能看到过去多少的chunk 如果完全不设置的话 那确实得这么推 但肯定不可能低延时
所以实在不建议直接用这个推理 因为你不清楚作者到底是怎么训练的 有没有设置 left chunks 你只会得到一个特别慢的结果 如果作者只关注首帧延迟的话 那么确实可以 但这应该不可能因为这样根本不可能实用 或者 作者在自己内部的推理里 cache了所有causal推理需要的过去状态 比如 cnn cache attn cache 但考虑到 encoder upsample 和 unet部分都需要很多cache 所以也不现实
最有可能的就是作者的训练代码是有 num_left_chunks的设置的 但因为cosyvoice2不准备开源训练 所以他就给一个傻瓜推理给你们用
感觉这样推理才能和训练时causal mask保持一致
理论上如果跟训练保持一致的话 是不可能做到低延时的 因为你必须每个chunk能看到过去的所有chunk 在最后一个chunk你需要提供过去的所有chunk 所以其实一般在流式训练中的做法是设置 num_left_chunks 就是能看到过去多少的chunk 如果完全不设置的话 那确实得这么推 但肯定不可能低延时
感觉这样推理才能和训练时causal mask保持一致
理论上如果跟训练保持一致的话 是不可能做到低延时的 因为你必须每个chunk能看到过去的所有chunk 在最后一个chunk你需要提供过去的所有chunk 所以其实一般在流式训练中的做法是设置 num_left_chunks 就是能看到过去多少的chunk 如果完全不设置的话 那确实得这么推 但肯定不可能低延时
目前推理num_left_chunks似乎是-1，看左边所有的chunks
感觉这样推理才能和训练时causal mask保持一致
理论上如果跟训练保持一致的话 是不可能做到低延时的 因为你必须每个chunk能看到过去的所有chunk 在最后一个chunk你需要提供过去的所有chunk 所以其实一般在流式训练中的做法是设置 num_left_chunks 就是能看到过去多少的chunk 如果完全不设置的话 那确实得这么推 但肯定不可能低延时
目前推理num_left_chunks似乎是-1，看左边所有的chunks
这是开源出来的代码 不一定是训练/推理用的代码 不过如果确实设置的是-1的话 就必须cache了 不然想不出可以快速推理的办法
感觉这样推理才能和训练时causal mask保持一致
理论上如果跟训练保持一致的话 是不可能做到低延时的 因为你必须每个chunk能看到过去的所有chunk 在最后一个chunk你需要提供过去的所有chunk 所以其实一般在流式训练中的做法是设置 num_left_chunks 就是能看到过去多少的chunk 如果完全不设置的话 那确实得这么推 但肯定不可能低延时
目前推理num_left_chunks似乎是-1，看左边所有的chunks
这是开源出来的代码 不一定是训练/推理用的代码 不过如果确实设置的是-1的话 就必须cache了 不然想不出可以快速推理的办法
是的，得看一下训练到底怎么设置的
150ms请使用阿里云，而且是预训练音色不需要提取token和embedding情况下。开源版本是python且zero shot推理，跟150ms肯定是有差距的，但是模型方案是一模一样的，有能力的可以先进行工程话，开源后续可能会更新一个llm用vllm推理
用3秒克隆代码保存的pth文件做推理测试，相同的一句话“你好，请稍等，我正在思考您的问题…”，从fastapi里的server启动服务，推理这句话。300M推理速度是2秒，0.5B是8秒。
用3秒克隆代码保存的pth文件做推理测试，相同的一句话“你好，请稍等，我正在思考您的问题…”，从fastapi里的server启动服务，推理这句话。300M推理速度是2秒，0.5B是8秒。
是否是在相同的prompt下进行对比，cosyvoice和coysvoice2初始化时，都指定load_jit等为false
是否是在相同的prompt下进行对比，cosyvoice和coysvoice2初始化时，都指定load_jit等为false
把coysvoice2初始化的load都设置成false之后速度确实变快了，推理“你好，请稍等，我正在思考您的问题…”的时间是3秒。
是否是在相同的prompt下进行对比，cosyvoice和coysvoice2初始化时，都指定load_jit等为false
把coysvoice2初始化的load都设置成false之后速度确实变快了，推理“你好，请稍等，我正在思考您的问题…”的时间是3秒。
所以使用TorchScript模型反而没有加速吗？
torch.compile（）可以加速一下吗，有没有方案
我们现在提供的是与我们阿里云一致的引擎导出方案(jit和trt)，其他的没有做过尝试
我开 autodl 的各种 gpu 环境测了1天，最终将 zeroshot 每秒 rtt 稳定在 0.46 秒（实际端侧首包延迟在1秒以内），后续每 0.33 秒输出1秒chunk，累死我了，技术原理我不太懂，期待 cosyvoice2 能有类似 funasr runtime 一样开箱即用的编译方案。
2025-03-04 13:06:01,838 INFO synthesis text 在他讲述那个荒诞故事的过程中，他突然[laughter]停下来，因为他自己也被逗笑了[laughter]。
2025-03-04 13:06:02,661 INFO yield speech len 1.84, rtf 0.4568521346216616
2025-03-04 13:06:03,289 INFO yield speech len 2.0, rtf 0.3134329319000244
2025-03-04 13:06:04,024 INFO yield speech len 2.0, rtf 0.3671818971633911
2025-03-04 13:06:04,299 INFO yield speech len 0.8, rtf 0.3430652618408203
100%|█████████████████████████████████████████████████████| 1/1 [00:02<00:00, 2.59s/it]
先上最佳配置：
- CPU：16 vCPU AMD EPYC 9654 96-Core Processor
- GPU：vGPU-32GB
- GPU驱动：550.54.14
- CUDA版本：cuda12.4
- conda环境：ai 相关加速库使用目前最新的依赖，其他与官方相同
- 推理参数：load_jit=False, load_trt=True, fp16=True
推理参数实测： 1、JIT编译对速度影响不大（开了之后前面几次推理会卡慢几秒，十次之后稳定？） 2、tensorrt对推理加速明显（首次推理还是会慢0.3秒左右），首次加载时需要等个3分钟左右编译engine 3、fp16会影响后续推理速度，开启后会快个0.3秒左右
非常重要：实测同样的 conda 环境（克隆系统盘和数据盘）下服务器使用 intel 的 12 vCPU Intel(R) Xeon(R) Platinum 8352V CPU @ 2.10GHz 推理速度会慢将近一倍，因为 GPU 都是租的临时的，不能随时开，经常需要克隆数据到新机器。这个我测了半天才找到原因，日志输出虽然都一样，但是对推理速度影响非常大！之前一直怀疑是 cuda 版本问题 🤣
其他GPU推理速度实测：
3090 首包推理 rtt 0.8秒左右，后续每 0.6 秒输出1秒chunk
4090d 首包推理 rtt 0.45秒左右，后续每 0.3 秒输出1秒chunk（和 vgpu 速度差不多）
现在终于处于能应用的状态了 😂 ，好奇 150ms 的实际延迟是咋实现的，哪位大佬懂的也可以给指个优化方向🫡
我开 autodl 的各种 gpu 环境测了1天，最终将 zeroshot 首包延迟 rtt 稳定在 0.46 秒，后续每 0.33 秒输出2秒chunk，端侧首包延迟在1秒以内，累死我了，技术原理我不太懂，期待 cosyvoice2 能有类似 funasr runtime 一样开箱即用的编译方案。
2025-03-04 13:06:01,838 INFO synthesis text 在他讲述那个荒诞故事的过程中，他突然[laughter]停下来，因为他自己也被逗笑了[laughter]。 2025-03-04 13:06:02,661 INFO yield speech len 1.84, rtf 0.4568521346216616 2025-03-04 13:06:03,289 INFO yield speech len 2.0, rtf 0.3134329319000244 2025-03-04 13:06:04,024 INFO yield speech len 2.0, rtf 0.3671818971633911 2025-03-04 13:06:04,299 INFO yield speech len 0.8, rtf 0.3430652618408203 100%|█████████████████████████████████████████████████████| 1/1 [00:02<00:00, 2.59s/it]先上最佳配置：
- CPU：16 vCPU AMD EPYC 9654 96-Core Processor
- GPU：vGPU-32GB
- GPU驱动：550.54.14
- CUDA版本：cuda12.4
- conda环境：ai 相关加速库使用目前最新的依赖，其他与官方相同
- 推理参数：load_jit=False, load_trt=True, fp16=True
推理参数实测： 1、JIT编译对速度影响不大（开了之后前面几次推理会卡慢几秒，十次之后稳定？） 2、tensorrt对推理加速明显（首次推理还是会慢0.3秒左右），首次加载时需要等个3分钟左右编译engine 3、fp16会影响后续推理速度，开启后会快个0.3秒左右
非常重要：实测同样的 conda 环境（克隆系统盘和数据盘）下服务器使用 intel 的 12 vCPU Intel(R) Xeon(R) Platinum 8352V CPU @ 2.10GHz 推理速度会慢将近一倍，因为 GPU 都是租的临时的，不能随时开，经常需要克隆数据到新机器。这个我测了半天才找到原因，日志输出虽然都一样，但是对推理速度影响非常大！之前一直怀疑是 cuda 版本问题 🤣
其他GPU推理速度实测：
3090 首包推理 0.8秒左右，后续每 0.6 秒输出2秒chunk
4090d 首包推理 0.45秒左右，后续每 0.3 秒输出2秒chunk（和 vgpu 速度差不多）
中间的链路应该还可以优化，有空再分析下吧，现在终于处于能应用的状态了 😂 ，好奇 150ms 是咋实现的，哪位大佬懂的也可以给指个优化方向🫡
这个0.46不是首包延时吧， 这个首包延时是0.46*1.84s=0.84s
yield speech len
还真是，没仔细源码里的 rtt 是除以 speech_len 之后的，我说怎么实际延迟翻了一倍，还以为是前后处理的时间 😂 谢谢提醒，原评论已修改 🌹
flow 里decoder 还有transformer里的encoder 用的num_decoding_left_chunks 应该都是-1，这块加cache应该怎么改啊，所有的encoder和decoder部分都得重新写吗？
需要增加attn、conv cache，还需要对一些细节进行微调。总体思路可以模拟流式、非流式进行对拍，屏蔽掉一切随机数，看看哪里不一致就修改哪里。这个还是比较费时间的。另外要注意不同时间步的cache不一样。
我开 autodl 的各种 gpu 环境测了1天，最终将 zeroshot 每秒 rtt 稳定在 0.46 秒（实际端侧首包延迟在1秒以内），后续每 0.33 秒输出1秒chunk，累死我了，技术原理我不太懂，期待 cosyvoice2 能有类似 funasr runtime 一样开箱即用的编译方案。
2025-03-04 13:06:01,838 INFO synthesis text 在他讲述那个荒诞故事的过程中，他突然[laughter]停下来，因为他自己也被逗笑了[laughter]。 2025-03-04 13:06:02,661 INFO yield speech len 1.84, rtf 0.4568521346216616 2025-03-04 13:06:03,289 INFO yield speech len 2.0, rtf 0.3134329319000244 2025-03-04 13:06:04,024 INFO yield speech len 2.0, rtf 0.3671818971633911 2025-03-04 13:06:04,299 INFO yield speech len 0.8, rtf 0.3430652618408203 100%|█████████████████████████████████████████████████████| 1/1 [00:02<00:00, 2.59s/it] 先上最佳配置：
- CPU：16 vCPU AMD EPYC 9654 96-Core Processor
- GPU：vGPU-32GB
- GPU驱动：550.54.14
- CUDA版本：cuda12.4
- conda环境：ai 相关加速库使用目前最新的依赖，其他与官方相同
- 推理参数：load_jit=False, load_trt=True, fp16=True
推理参数实测： 1、JIT编译对速度影响不大（开了之后前面几次推理会卡慢几秒，十次之后稳定？） 2、tensorrt对推理加速明显（首次推理还是会慢0.3秒左右），首次加载时需要等个3分钟左右编译engine 3、fp16会影响后续推理速度，开启后会快个0.3秒左右
非常重要：实测同样的 conda 环境（克隆系统盘和数据盘）下服务器使用 intel 的 12 vCPU Intel(R) Xeon(R) Platinum 8352V CPU @ 2.10GHz 推理速度会慢将近一倍，因为 GPU 都是租的临时的，不能随时开，经常需要克隆数据到新机器。这个我测了半天才找到原因，日志输出虽然都一样，但是对推理速度影响非常大！之前一直怀疑是 cuda 版本问题 🤣
其他GPU推理速度实测：
3090 首包推理 rtt 0.8秒左右，后续每 0.6 秒输出1秒chunk
4090d 首包推理 rtt 0.45秒左右，后续每 0.3 秒输出1秒chunk（和 vgpu 速度差不多）
现在终于处于能应用的状态了 😂 ，好奇 150ms 的实际延迟是咋实现的，哪位大佬懂的也可以给指个优化方向🫡
我复现了vGPU-32GB，但是使用4090测试首包要0.7s~0.8s左右，跟 vGPU-32一样
