[Bug] GSV TTS (Local) 端点/参数类型不兼容导致 404/TypeError

[ludan0312]

What happened / 发生了什么

配置 GSV TTS (Local) 后，发送消息触发 TTS 时，日志报错 404 或 TypeError。

根本原因是 gsv_selfhosted_source.py 与 GPT-SoVITS api.py 的实际接口存在 4 处不兼容：

1. 端点错误：代码硬编码 GET /tts，但 GSV api.py 只提供 POST /
2. 参数类型错误：default_params 通过 str(value).lower() 把所有参数转成字符串，GSV 期望 top_p/temperature 等为数值
3. 字段名不匹配：ref_audio_path / prompt_lang / text_lang 应为 refer_wav_path / prompt_language / text_language
4. 布尔值错误：split_bucket=True 被转成字符串 "true"，GSV 期望 JSON 布尔值

修复后测试通过，中文 TTS 推理正常。

Reproduce / 如何复现？

1. 部署 GPT-SoVITS V2 Docker 容器（api.py 模式）
2. AstrBot 中配置 GSV TTS (Local)，API Base URL 指向 GSV 地址
3. 发送消息触发 TTS
4. 观察日志：先报 404 Not Found，手动改端点后报 TypeError: '<' not supported between instances of 'str' and 'float'

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

v4.26.5，Docker 部署（Unraid），GSV TTS (Local) 提供商，QQ 消息平台

OS

Linux

Logs / 报错日志

[GSV TTS] Request to http://192.168.31.46:9880/tts failed with status 404: {"detail":"Not Found"}

TypeError: '<' not supported between instances of 'str' and 'float'
File ".../utils.py", line 169, in logits_to_probs
if top_p is not None and top_p < 1.0:

[GSV TTS] 请求 http://192.168.31.46:9880/ 最终失败：Response payload is not completed

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[dosubot]

Hi @ludan0312! I'm Dosu and I'm helping the AstrBotTeam team.

确认了你报告的问题。查看 gsv_selfhosted_source.py 源码，当前实现确实存在你描述的这些不兼容：

• 端点 & 方法：代码使用 GET /tts 并通过 query params 传参 [1]，而 GPT-SoVITS api.py 期望 POST /。
• 参数类型：default_params 初始化时用 str(value).lower() 将所有值转为字符串 [2]，导致 top_p/temperature 等数值型参数变成 "0.9" 这样的字符串，GSV 端比较时抛出 TypeError。
• 字段名 & 布尔值：同样因为 config 中的 key 直接透传且值均为字符串，split_bucket=True 变成了 "true"。

值得注意的是，另一个 GSVI TTS API provider（gsvi_tts_source.py）在 2026 年 3 月已做过类似修复——从 GET 改为 POST，并调整了端点 [3]，但该修复未同步到 self-hosted 版本。

你的分析非常准确，期待你的 PR！

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[he-yufeng]

核对了一下 GPT-SoVITS 上游两个 api 文件（当前 main），这里其实是两套方言的问题：

• api_v2.py：GET/POST /tts，字段是 ref_audio_path / prompt_lang / text_lang，切权重是 GET /set_gpt_weights、GET /set_sovits_weights。
• api.py（v1）：只有 GET/POST /，字段是 refer_wav_path / prompt_language / text_language，切权重是 /set_model，根本没有 /tts 这条路由。

AstrBot 现在这份 provider（GET /tts + v2 字段名 + /set_gpt_weights）是严格对着 api_v2.py 写的，对着 v1 的 api.py 就会先 404，和你看到的完全一致。所以直接按报告里列的 4 点改，会把用 api_v2.py 的人改挂。另外两点补充：参数被 str(value).lower() 字符串化确实丑，但两边的 FastAPI 都会按声明类型解析 query 参数，实际不致病；真正的病根只有端点和字段名这两处方言差异。

两个结论：

1. 你本地最快的解封办法：改用 api_v2.py 起服务（v2 及之后的模型它都支持），当前 AstrBot 代码一行不用动。
2. 仓库层面的正确修法是加一个方言开关（比如 gsv_api_version，默认 v2 保持现状，v1 走 / + 字段改名映射 + /set_model），而不是把请求整体改成 v1 方言。

如果这个方向可以，我来提 PR。@Soulter 看下这个思路？