Thirteen
Thirteen
maybe you can use postman or apifox to try connect the url
好的大哥，很遗憾我也无能为力。 have a nice day
理论上你把model_dir 这里 设置为你下载的whisper路径就可以了
> > 理论上你把model_dir 这里 设置为你下载的whisper路径就可以了 > > 那估计没有这么简单，CPU版和GPU版教程我都试过很多次whisper-large-v3了，不管是自己预先下载的还是自动下载的，都无法启动服务，cpu版我试sensevoice-small和paraformer-large都可以，GPU版示例的paraformer-large可以，但是多次尝试sensevoice-small和whisper-large-v3都不行，也都是从modelscope中下载的，应该是项目中提供的处理脚本并没有支持whisper 换了之后发现似乎是模型缺少某个参数是吗。我似乎遇到这样的问题。
报错信息在这里  而tokenizers在这里导入  看起来是你的模型有点问题
是的，但是需要有一定的数据量，否则会出现类似下面的问题 https://github.com/yangjianxin1/GPT2-chitchat/issues/126
能看一下具体的乱码以及使用的数据集吗？ 如果只是出现词不达意，那也不算乱码。
如果爆显存，不如把MP3的内容切开？然后再拼接再一起，分开进行语音识别。
有没有大佬把livekit agent接入进来。使用livekit agent的打断逻辑加模型回复，只使用livetalking的human 播放部分。 目前我能够实现两个应用的交互，还需要将livetalking的视频推送到livekit agent上。这一块还没完成[捂脸]
> [@WThirteen](https://github.com/WThirteen) 你无论怎么样你只要需要对口型，就都要把livekit的音频流推进来驱动口型，这不本质还是用tts驱动对口型么， 只要进入livetalking ，模型需要实时推理，以现在的架构就很难实现，我是设计了一个task_id的模式，从llm->tts每次请求都生成一个task_id,如果执行打断，就抛弃之前的，即便这样，打断也只能比原来快一点（大概2-3秒，但不会因为llm持续返回句子，一条一条的读），程序原本甚至能够到达5-6秒（基本是读完整个上下游游tts的音频流驱动后的列队，打断时间长短取决于llm断句生成的tts断句）， > > 有时候我真怀疑，为了对口型值得么，哈哈 是的，就是为了对口型。现在接入livekit之后，整体的打断逻辑变成了 llm生成完文本->调用livetalking 语音播报接口，当生成完文本之后才把上一个没讲完的打断。如果是用的私有化部署的模型再加上知识库，这部分就更慢了 ：（