Skye2099

> Thanks for the good work. However, since the test data are removed due to completion3d, can you report CD on the ShapeNet validation set? Moreover, it seems to be...

> > videotag_test.py现在的实现方式，是把所有数据特征提取完之后，再输入到lstm做分类，而不是一条处理完再处理另外一条，所以占用的内存会比较大。建议把3-5分钟的视频截取一下，后面我们也会优化这种实现 > > 跑tsn提特征也会OOM呀？比较多的小视频批量提取 我也是，只tsn提特征也会爆，请问你解决了吗

Me too

> [video](https://mp4.ziyuan.wang/view.php/907ef5d4fad9b9281a6c9db943af3f12.mp4) 我的也是抖动得厉害 你有用hubert优化吗？

你这个应该是训练不充分，两阶段分别训练了多少？

> @Skye2099 no it's not due to insufficient training, it's due to not following all the steps properly > > @3165523246 you can refer to this > > [#203 (comment)](https://github.com/ZiqiaoPeng/SyncTalk/issues/203#issuecomment-2284966521)...

>  > > 1. 为什么要先在sft_512.jsonl训练，然后再sft_2048.jsonl训练？ > 2. 按道理讲，将sft_512.jsonl和sft_2048.jsonl合在一起训练，效果会不会更好？ > [@jingyaogong](https://github.com/jingyaogong) 

> > api.py 没问题，“我叫王欣。”这四个字一个句号，在api.py下正常推理，在api_v2.py里就直接变成参考音频的内容了。 > > 是的，api.py的文字处理逻辑对短发音推理容易翻车做了预防。 请问对于短字会变参考音频的情况怎么处理呢？我是增加数据量重新训练还是通过api就可以解决？我理解api_v2应该是api的改进版吧，如果api能解决，这个功能应该可以集成到api_2?

> 你需要搭建推理引擎，并发需要靠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尝试，我很欢迎技术上的交流。 多worker会起多个进程，在单个进程吃不满GPU的情况下，多个worker（多个进程）加载了多份模型同时推理，不就是并行推理吗？并发只是单个进程里起多个线程，而多worker是多个进程

针对这三个问题，我说下我自己的理解，欢迎讨论： Q:单个 worker，能继续提升 GPU 利用率，或者提高并发量吗 A:单个worker下，提升GPU利用率要靠batch_size，原理是增加GPU矩阵计算的并行程度，分配更多的SM计算单元，提高并发要靠多线程，单个worker下默认单个进程可以通过async的to_thread来把pipline.run增加到后台线程池来提高并发（这里不考虑推理代码中使用multiprocess，跟多worker我理解是一样的），注意提高并发并不会减少总的推理时间，由于多线程的开销，首包实时率可能还会有下降 Q：多个 worker 下，没有请求的时候，显存利用率能否降低点呢 A：我在linux环境下，多worker在没有请求的时候，显存利用率是0 Q：除了增加 worker 数量，还有什么其他方法能提高 GPU 利用率吗 A：和上面问题略有重复了，1.提高batch_size 2.增加进程（等同增加worker）