请教一下，如果只想使用TTS功能、克隆，想整合到自己的项目中，应该怎么合并呀？现在哪一种方式运行推理速度最快，并且效果不差

[hjj-lmx]

No description provided.

[XXXXRT666]

直接调API,对接API接口就够了

[teneous]

如果你的场景支持独立部署，那么你可以起一个docker，然后走http的api调用。
如果你的场景只想部署一个应用，那么你就需要把api_v2代码中引用到的所有包带进去，或者说可以踢掉train和webui相关的代码（包含去掉tool中的降噪，切割，asr标记等）

考虑到代码融合可能和你本地项目有大量的冲突，从可维护性角度来说，第一种独立部署会更好。

推理速度的话：api_v2就可以了，此外如果你想只用底模，只根据不同参考音进行切换，需要改动一下代码将prompt_cache改为一层<参考音,cache>的结构，在切换音色场景可以优化0.2s左右，推理的速度4090基本都是80～100it/s，半精度可以到130it/s。如果还要再快可以考虑onnx改造的。

[XXXXRT666]

onnx就别想更快了

[XXXXRT666]

推理4090的话看你别的硬件,快的可以580it/s

[XXXXRT666]

而且要是没记错的话prompt_cache存的东西和模型无关,切换模型不会影响prompt_cache

[teneous]

而且要是没记错的话prompt_cache存的东西和模型无关,切换模型不会影响prompt_cache

感谢补充，我看到是prompt_sematic设置的时候，引用到了vits模型。prompt模型存储的是参考语音的sematic缓存，代码中仅缓存了上一次参考音的，切换有0.8s的耗时，补充下：我的配置是4090。
想了解下这个580it/s是怎么跑出来的，民用4090或者A10这种应该跑不到这么高吧...
我压测过接口，生成15字大概在1400ms，如果本文数量多，增大batch_size确实可以并行减少耗时，但我场景是任意标点切分，这是基于上游LLM的流式输出切分的，如果能像fishspeech达到800ms，那么我觉得就很棒了。目前还没摸索到方法，如果有可以分享给我么？

[hjj-lmx]

推理4090的话看你别的硬件,快的可以580it/s

如果我要多卡的话，需要怎么修改api_2.py

[hjj-lmx]

我想要2000字三秒左右出结果，8张L4能达到吗？需要修改什么代码才能实现

[XXXXRT666]

如果我要多卡的话，需要怎么修改api_2.py

直接多开几个,然后自己做一下负载均衡

[XXXXRT666]

而且要是没记错的话prompt_cache存的东西和模型无关,切换模型不会影响prompt_cache

感谢补充，我看到是prompt_sematic设置的时候，引用到了vits模型。prompt模型存储的是参考语音的sematic缓存，代码中仅缓存了上一次参考音的，切换有0.8s的耗时，补充下：我的配置是4090。 想了解下这个580it/s是怎么跑出来的，民用4090或者A10这种应该跑不到这么高吧... 我压测过接口，生成15字大概在1400ms，如果本文数量多，增大batch_size确实可以并行减少耗时，但我场景是任意标点切分，这是基于上游LLM的流式输出切分的，如果能像fishspeech达到800ms，那么我觉得就很棒了。目前还没摸索到方法，如果有可以分享给我么？

Issue里有,别人测出来的

[XXXXRT666]

而且要是没记错的话prompt_cache存的东西和模型无关,切换模型不会影响prompt_cache

感谢补充，我看到是prompt_sematic设置的时候，引用到了vits模型。prompt模型存储的是参考语音的sematic缓存，代码中仅缓存了上一次参考音的，切换有0.8s的耗时，补充下：我的配置是4090。 想了解下这个580it/s是怎么跑出来的，民用4090或者A10这种应该跑不到这么高吧... 我压测过接口，生成15字大概在1400ms，如果本文数量多，增大batch_size确实可以并行减少耗时，但我场景是任意标点切分，这是基于上游LLM的流式输出切分的，如果能像fishspeech达到800ms，那么我觉得就很棒了。目前还没摸索到方法，如果有可以分享给我么？

自行尝试compile或者别的方式,然后用linux,CPU也挺重要