Junity

Please try pip install --upgrade pyworld. I encountered same issue and fixed

你需要搭建推理引擎，并发需要靠batchsize来并行，无论是写多worker还是异步用处为0。多个任务塞到gpu里，gpu并不会并行处理，他会并发处理，但是并发不是并行。*并发不会加速* 只会实现推1条1秒，推两条2秒后同时结束，而不是1秒结束一条。想要实现1秒推1条，然后1秒推两条，然后1秒推三条，即真正利用gpu并行，才能加速。 想要并行，需要把多个请求塞到一个batch里处理，或者使用更高级的技术，例如continuous batching，但是continuous batching在gsv下很难实现，理由是gsv是基于右padding，而右padding的结果是batchsize上去了如果参考音频有长有短，短的参考音频的padding 在参考和推理的音频token距离过大，会影响效果，具体表现是漏字等。 我们搭建了gsv的推理引擎但我们并没有将其开源，因为推理引擎是企业部署才需要的东西。具体使用可以在tts.yomio.ai尝试，我很欢迎技术上的交流。

> > 理由是gsv是基于右padding，而右padding的结果是batchsize上去了如果参考音频有长有短，短的参考音频的padding 在参考和推理的音频token距离过大，会影响效果，具体表现是漏字等。 > > 理论上控制好mask也不会出现这个问题。在之前的fast_inference_分支中，在进行next token的预测时（使用kv cache），sdpa中是没有mask的，这会导致sdpa中计算softmax时，将padding部分也纳入考虑，从而改变了概率分布， 这可能就是之前fast_inference_分支漏字的直接原因（相比于之前的main分支，毕竟这些在之前的main分支上也有，但没那么显著）。现在fast_inference_分支合并进了main分支，且修复了那个问题。但是当batch size>1和固定batch size=1，在经过linear之后同一张量上的结果仍然是会有差异的（虽然在误差范围内），但不清楚这种差异会带来什么影响。 分组能解决，即把参考音频是3-5秒的一组，5-8秒的一组，如果3秒和8秒一组进batch，绝对会漏一整个分句。

> > 理由是gsv是基于右padding，而右padding的结果是batchsize上去了如果参考音频有长有短，短的参考音频的padding 在参考和推理的音频token距离过大，会影响效果，具体表现是漏字等。 > > 理论上控制好mask也不会出现这个问题。在之前的fast_inference_分支中，在进行next token的预测时（使用kv cache），sdpa中是没有mask的，这会导致sdpa中计算softmax时，将padding部分也纳入考虑，从而改变了概率分布， 这可能就是之前fast_inference_分支漏字的直接原因（相比于之前的main分支，毕竟这些在之前的main分支上也有，但没那么显著）。现在fast_inference_分支合并进了main分支，且修复了那个问题。但是当batch size>1和固定batch size=1，在经过linear之后同一张量上的结果仍然是会有差异的（虽然在误差范围内），但不清楚这种差异会带来什么影响。 但如果是左padding能从根本上解决这个问题，我在我的gsv2项目中改成了左padding，这也是目前所有大语言模型都用的padding方式。

> 请教一下各位，你们的并发能做到多少？我用 main 分支的 api_v2 起服务，worker=10和5，配置是 显卡：80G 的 A100 上，CPU：AMD EPYC 7513 32 核。用 wrk -t5(或10) -c5(或10) -d10s -v --timeout 30s 去测 TTS，结果平均下来最好也只有 3 不到的 QPS。(非流式，一句话大概5-15s，平均每个请求花费 2~6s(其中TTS只占一半时间)) 虚心请教一下 @JunityZhan 大佬所说的推理引擎是怎么搭建呢，请问有其他的推理引擎的实现的推荐可以来作为参考吗，还是说这玩意就是只能自己敲出来呢，小白大概能明白上文说的问题，但是要怎么着手搞这个推理引擎完全是大脑空白......

> > 你需要搭建推理引擎，并发需要靠batchsize来并行，无论是写多worker还是异步用处为0。多个任务塞到gpu里，gpu并不会并行处理，他会并发处理，但是并发不是并行。_并发不会加速_ 只会实现推1条1秒，推两条2秒后同时结束，而不是1秒结束一条。想要实现1秒推1条，然后1秒推两条，然后1秒推三条，即真正利用gpu并行，才能加速。 想要并行，需要把多个请求塞到一个batch里处理，或者使用更高级的技术，例如continuous batching，但是continuous batching在gsv下很难实现，理由是gsv是基于右padding，而右padding的结果是batchsize上去了如果参考音频有长有短，短的参考音频的padding 在参考和推理的音频token距离过大，会影响效果，具体表现是漏字等。 我们搭建了gsv的推理引擎但我们并没有将其开源，因为推理引擎是企业部署才需要的东西。具体使用可以在tts.yomio.ai尝试，我很欢迎技术上的交流。 > > 大佬，有联系方式吗，想交流下推理引擎实现方式 微信JunityZ

同问，顺便请教一下楼主有没有对比过fm上升前和fm上升后的效果区别

I am a paying user, with $45 a month! Need it to be fixed ASAP