Gedanke

> @dgedanke @cypher256 are you still facing this issue? Added stale tag as we didn't receive any comment on this issue for more than 40 days. I'm sorry for taking...

> 你用的是哪个api？然后api的话 @ChasonJiang 一起看看？ main 分支的 api_v2

> 使用api_v2的话，可以增加batch_size，并使用cut5 text_split_method 一直是 cut5，看之前 issue 里面说这个效果最好 batch_size 设置过 2 的 n 次方，1，2，4，8，。。。 最后选择的是 4，并发情况下表现会好点 我想的是在能让 GPU 一直维持在高利用率状态，这样并发数量高，同时返回的流式语音不会中断  这是之前一次测试的结果，5 个 workers，GPU 前期利用率高，后面一直在处理任务，但利用率上不来 语音的长度是 1min 20s，流式语音首包返回大概就几秒，有些流式语音播放的时候就会有中断

> > 理由是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之后同一张量上的结果仍然是会有差异的（虽然在误差范围内），但不清楚这种差异会带来什么影响。 好的，谢谢大佬！

> > > 理由是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，绝对会漏一整个分句。 好的，感谢大佬的解答！