GPT-SoVITS 变更日志精读：从 V1 到 V2Pro 的版本演进与源码级技术脉络

本文以 docs/en/Changelog_EN.md 为核心，系统梳理 GPT-SoVITS 从 2024 年初到 2026 年 4 月的完整变更脉络：版本主线（V2、V3、V4、V2Pro 系列）的发布时间与硬件门槛、推理加速与流式合成的落地路径、训练侧 DPO/LoRA/梯度检查点等能力演进，以及跨平台兼容与文本前端的持续打磨。读完本文，你可以把变更日志当作“可检索的技术索引”，将每一条记录快速对应当前仓库中的真实实现文件与配置，从而准确选择模型版本与推理/训练方案。

一、变更日志的组织规范：如何阅读每一条记录

Changelog 按“年月（YYYYMM）”分节，每节内部按日期倒序/正序罗列条目。每条记录遵循固定结构，这也是检索时的关键抓手：

• 日期 + 引用：标注对应的 Commit（如 Commit#ea62d6e0）或 PR（如 PR#108），部分重大特性标注 Commit 区间，表示一段连续提交。
• Content（内容）：一句话描述变更内容，加粗内容（如 “Added GPT-SoVITS V2 model.”）均为里程碑级特性。
• Type（类型）：Feature（新特性）、Fix（缺陷修复）、Optimization（优化）、Documentation（文档）、Performance Optimization（性能优化）、Refactor（重构）、Chore（杂务）、Style（代码风格）等。
• Contributor（贡献者）：主贡献者名单，可据此追溯具体 PR 的讨论背景。
• Related（关联）：部分条目附带 Related Issue 编号，用于定位问题的原始讨论。

这种“日期 + 类型 + 贡献者”的结构化写法，使得针对某一症状（例如“16 系显卡 half 精度报错”“GPT 训练不保存 ckpt”）做关键词检索时，能直接命中修复时间点，判断自己所用的代码版本是否已包含该修复。

二、版本主线：四次正式发布的里程碑

变更日志中最显著的骨架是四次“Officially released”正式版本发布，它们各自带有明确的硬件门槛，这些数字在日志中均有明确记载：

版本	发布时间	日志中的关键记载	当前仓库中的对应证据
V2	2024.08.21	“Added GPT-SoVITS V2 model”（2024.08.02 提交区间），V2 同期加入粤语 ASR、多音字处理优化、fast_inference 分支合并入主分支	config.py 中 pretrained_gpt_name["v2"] 指向 gsv-v2final-pretrained/s1bert25hz-5kh-longer-epoch=12-step=369668.ckpt
V3	2025.02.28	“requires 14GB VRAM for fine-tuning”；随后加入梯度检查点（降至 12GB）、LoRA 训练（降至 8GB）、24kHz→48kHz 音频超分模型	GPT_SoVITS/s2_train_v3_lora.py、GPT_SoVITS/configs/tts_infer.yaml 的 v3 段
V4	2025.04.22	“Added GPT-SoVITS V4 model”（2025.04.20 提交区间）；随后启用 V4 并行推理、修复版本参数传递、numpy/numba 版本不匹配	config.py 中 pretrained_sovits_name["v4"] 指向 gsv-v4-pretrained/s2Gv4.pth
V2Pro 系列	2025.06（V2Pro/V2ProPlus）	“Added GPT-SoVITS V2Pro Series model”；同期支持 V4 TorchScript 导出、修复 ge.sum 数值爆炸导致的静音推理	GPT_SoVITS/configs/s2v2Pro.json、GPT_SoVITS/configs/s2v2ProPlus.json

版本与权重的映射关系在代码中可以直接验证。config.py 中的两个字典维护了各版本预训练权重路径：

pretrained_sovits_name = {
    "v1": "GPT_SoVITS/pretrained_models/s2G488k.pth",
    "v2": "GPT_SoVITS/pretrained_models/gsv-v2final-pretrained/s2G2333k.pth",
    "v3": "GPT_SoVITS/pretrained_models/s2Gv3.pth",
    "v4": "GPT_SoVITS/pretrained_models/gsv-v4-pretrained/s2Gv4.pth",
    "v2Pro": "GPT_SoVITS/pretrained_models/v2Pro/s2Gv2Pro.pth",
    "v2ProPlus": "GPT_SoVITS/pretrained_models/v2Pro/s2Gv2ProPlus.pth",
}

值得注意的技术细节是：从 V3 开始，GPT（Text2Semantic）权重统一复用 s1v3.ckpt——pretrained_gpt_name 中 v3、v4、v2Pro、v2ProPlus 均指向该文件，而版本差异主要体现在 SoVITS（VITS）声码侧权重与配置上。GPT_SoVITS/configs/tts_infer.yaml 中的 v3/v4 段同样体现了这一点：t2s_weights_path 相同，仅 vits_weights_path 与 version 字段不同。推理入口 GPT_SoVITS/TTS_infer_pack/TTS.py 中也存在版本断言 assert self.version in ["v1", "v2", "v3", "v4", "v2Pro", "v2ProPlus"]，与日志 2025.07.16 的修复条目“Fix TTS.py not recognizing actually supported versions v2Pro and v2ProPlus”前后呼应——说明版本枚举是随每次新模型发布逐步扩大的。

此外，config.py 中 SoVITS_weight_root 与 GPT_weight_root 按版本分目录存放微调产物（SoVITS_weights_v2、GPT_weights_v3 等），WebUI 依据这些目录扫描并下拉列出可用模型，这也解释了 2024.01.23 条目“优化模型文件排序逻辑”（custom_sort_key 至今仍在 config.py 中以正则拆分数字段做自然排序）。

三、推理加速主线：从 fast_inference 到流式合成

日志中性能优化类条目密度很高，可以梳理出一条清晰的加速路线图：

1. 2024.03.09：单次推理加速约 50%（日志注明测试环境为 RTX3090 + PyTorch 2.2.1 + CU11.8 + Win10 + Py39），并新增快速推理分支 fast_inference_；
2. 2024.07.06：加速推理代码验证后合并入主分支，日志强调“确保与基线推理效果一致”，并支持无参考文本模式下的加速推理；
3. 2025.03.31 / 2025.04.01：SoVITS v3 启用并行推理（parallel inference），并修复异步模型加载逻辑；
4. 2025.05.26：引入缓存策略，使 V3/V4 推理再提速约 10%；
5. 2025.11.28：流式推理（streaming inference）特性合入，同期还有文本前端对数学表达式的优化。

当前仓库源码与这条路线完全吻合：

• GPT_SoVITS/TTS_infer_pack/TTS.py 中保留了缓存类推理接口参数：return_fragment（分步返回音频片段，质量最佳、响应最慢的旧版流式模式）、streaming_mode（分块返回，中等质量）、fixed_length_chunk（固定长度分块，响应更快但质量更低）。三种档位与日志 2025.11 的流式推理特性一一对应；
• GPT_SoVITS/stream_v2pro.py 文件头注释自述“这是一个实验性质的实现，旨在探索 stream infer 的可能性”，其 StreamT2SModel 封装了 pre_infer 导出接口，基于 TorchScript 的 T2SModel 做 KV cache 化的增量解码——这正是流式推理的底层骨架；
• 并行推理与 V4 的关系可在 GPT_SoVITS/TTS_infer_pack/TTS.py 中看到 use_vocoder and parallel_infer 的组合判断，即并行推理在带 vocoder 的 V3/V4 路径上有独立的分桶逻辑。

四、训练能力演进：DPO、梯度检查点与 LoRA

训练侧的日志条目集中在三个阶段：

• DPO Loss（2024.02.12）：启用实验性 DPO Loss 训练选项，通过在训练时构造负样本来缓解 GPT 的重复与漏字问题，并让若干推理参数在推理 WebUI 中可配；两天后（2024.02.15）调整为可选项而非强制，且勾选后 batch size 自动减半。这一“构造负样本 + 自动降 batch”的设计，是理解 DPO 变体在此项目中落地方式的关键。2026.04.18 还有一条后续修复：DPO 训练不支持漏字模拟（missing word simulation）的 bug。
• V3 显存阶梯（2025.02）：V3 微调需 14GB 显存 → 梯度检查点支持（PR，2025.02.12）降至 12GB → LoRA 训练（2025.02.23 提交区间）进一步降至 8GB。日志给出的这条“14GB → 12GB → 8GB”路径，为显存受限用户提供了明确的选型依据。
• LoRA 实现（源码印证）：GPT_SoVITS/s2_train_v3_lora.py 使用 peft 库，训练启动时对 VITS 的 cfm 模块注入 LoraConfig；推理侧 GPT_SoVITS/TTS_infer_pack/TTS.py 在加载 LoRA 权重时针对 to_k/to_q/to_v/to_out.0 构建相同配置的 LoraConfig，加载后执行 merge_and_unload() 将 LoRA 权重合并回主干——训练与推理两端的模块列表保持一致，这是 LoRA 权重可被推理端正确合并的前提。
• VQ 分布式训练（2025.11.28）：支持 VQ 分布式训练，属于 V3/V4 路径（带 VQ 语义编码）的多卡扩展。
• GPT 训练稳定性（2024.01.28）：修复“GPT 训练不保存 checkpoint”的缺陷。当前 GPT_SoVITS/s1_train.py 中自定义的 my_model_ckpt(ModelCheckpoint) 在 on_train_epoch_end 中接管保存逻辑（含 if_save_latest、if_save_every_weights 等开关），即该修复长期保留下来的机制。

五、硬件兼容性与精度治理：一条反复出现的主题

日志中关于 GPU 精度（fp16/fp32）的修复条目数量惊人，覆盖 UVR5、SoVITS 训练、CPU 推理等多个场景，核心痛点是 16 系（SM 7.5）显卡的 half 精度问题：

• 2024.01.26：自动对不支持 half 精度的 GPU 强制单精度，CPU 推理强制单精度；
• 2024.01.29：针对 16 系显卡将训练配置改为单精度；
• 2024.02.07：修复 UVR5 is_half 参数未转布尔导致“常半精度”、进而在 16 系显卡上产生 inf 的 bug；
• 2025.06.05：优化自动精度检测逻辑。

这些条目在 config.py 的 get_device_dtype_sm 中有最终沉淀：通过 torch.cuda.get_device_capability 读取 SM 版本，并用正则 16\d{2} 匹配显卡名识别 16 系（且 SM 恰好为 7.5）；对 SM 6.1 与 16 系一律返回 torch.float32，SM > 6.1 才启用 torch.float16；显存不足 4GB 或 SM < 5.3 则回退 CPU。2025.06.05 的“优化自动精度检测逻辑”条目对应的正是这段逻辑的演进。跨平台方面还有几条值得注意的记录：

• macOS：2024.01.25 支持 Mac 训练推理 → 2024.02.21 将 Mac CPU 推理从 MPS 切回 CPU（性能更快）→ 2024.02.28 修改 is_half 检查确保 Mac 上 CPU 推理正确 → 2024.03.13 支持 CPU 训练；
• WSL ROCm：2025.08.02 修复条目；
• 环境搭建：2026.02.08 修复“未接受 Conda 条款导致构建失败”（对应 Docker/miniforge_install.sh 一类脚本）、2026.02.09 优化自动环境配置（对应 install.sh）。

六、文本前端与多语言：日志中最高频的“长期工程”

文本前端（text frontend）相关条目贯穿全部周期，按主题归并如下：

• 中文规范化：2024.01.23 将 jieba 替换为 jieba_fast 提速；2024.02.03 引入 PaddleSpeech 的 Normalizer，修复“xx.xx%”百分比、“元/吨”被读成“元吨”、下划线报错等问题；2024.07.27 持续改进中文前端；
• 中英/中日混读：2024.01.26 支持中英、日英混合输出文本；2024.02.03 支持中日英混合文本的自动分句与语言识别；
• 语言切分工具升级（2025.02.14）：更换为新的语言切分工具，改进多语混读切分策略与数字/英文处理——当前仓库 GPT_SoVITS/text/LangSegmenter/langsegmenter.py 即该组件的落点；
• 多音字：2024.08.06 V2 多音字处理优化 → 2025.06.06 修复“X一X”模式多音字检测 → 2026.04.18 优化 G2PW 推理输入构造与多音字处理，减少长句冗余计算。多音字资源可见 GPT_SoVITS/text/g2pw/polyphonic.md5 与 GPT_SoVITS/text/g2pw/polyphonic.md5 对应的 polyphonic.rep；
• 标点与句子边界：2024.01.30 增加按标点切句、修复中英标点切分；2024.07.06 修复按标点切句时误切小数点；2024.06.10 改进纯标点/多标点输入逻辑；2025.11.28 优化数学表达式文本的前端处理。

另一条相关主线是 ASR（用于零标注数据准备）：2024.01.21 cmd-asr.py 增加 FunASR 模型缺位时自动从 ModelScope 下载的逻辑（对应 tools/asr/funasr_asr.py）；2024.01.29 FunASR 升级 1.0 并修复接口不匹配；2024.02.07 集成 Faster Whisper 支持日英 ASR（tools/asr/fasterwhisper_asr.py）并切换镜像下载规避 HF 连接问题；2025.07.17 Whisper ASR 支持更经济的蒸馏模型；2025.11.28 再次优化 ASR 模型下载逻辑。V2 发布同期（2024.08.03）还加入了基于 FunASR 的粤语 ASR。

七、音频数据处理链路：UVR5 到人声分离与超分

日志中“UVR5”字样出现了十余次，构成数据清洗工具链的演进线：格式读取错误（2024.02.03）、librosa 高版本适配（2024.02.06）、FFmpeg 命令字符串格式与含空格路径兼容（2024.04.03、2024.06.10、2025.05.29）、混响去除模型设置反向（2024.02.28）、异常导致整批音频退出（2024.06.28，对应 tools/subfix_webui.py 所在的数据处理 WebUI）。模型侧则不断扩列：

• 2024.07.27 加入 BS-RoFormer 人声/伴奏分离（tools/uvr5/bs_roformer/bs_roformer.py），2024.08.01 启用 FP16 推理；
• 2025.02.27 加入 Mel Band Roformer 人声/乐器分离（tools/uvr5/bs_roformer/mel_band_roformer.py）；
• 2025.02.23 加入 24kHz→48kHz 音频超分模型，用于缓解 V3 模型生成 24K 音频的“闷”问题（对应 tools/AP_BWE_main/24kto48k）；
• 2025.03（202503 节末）集成 ONNX runtime GPU 推理支持：G2PW 内 ONNX 模型从 CPU 切到 GPU 以消除 CPU 瓶颈，foxjoy 去混响模型支持 GPU 推理。

数据准备阶段还有两个直接影响训练质量的修复：2025.05.02 修复“SoVITS 训练未冻结 VQ 可能导致音质下降”的问题——GPT_SoVITS/configs/s2v2Pro.json 中 "freeze_quantizer": true 即该约定的配置层体现；2024.06.06 修复 WebUI GPT 微调未读取中文输入文本 BERT 特征的问题，日志特别提醒“若此前用大量数据微调过，建议重训模型”。

八、交互与部署细节：容易被忽略但实用性强的条目

• 速度控制：2024.07.23 加入语速调节（可冻结随机性仅控速），2025.02.28 再次加入 speech rate 参数。当前推理接口中该参数落地为 speed_factor（float，默认 1.0），GPT_SoVITS/TTS_infer_pack/TTS.py 中通过调整 upsample_rate 与 ffmpeg atempo（见 speed_change 函数）实现变速；
• 公开网络映射：2024.01.21 config.py 增加 is_share 参数，当前实现为读取环境变量 is_share（config.py），置 True 可将 WebUI 映射到公网；
• WebUI 工程化：2024.08.01 WebUI 自动填充路径；2025.05.26 标注界面增加“每页完成需点击提交文本，否则不保存”的提醒；2025.06.05 WebUI 前端模块加入折叠功能；
• API 演进：2024.03.30 改进 API 格式、2024.08.20 修复并优化 API（对应 api_v2.py），语速特性同步更新至 api.py；
• i18n：2024.01.21 WebUI 加入英文翻译（PR 由 D3lik 贡献）；2024.07.13 重构 i18n 扫描流程，当前 tools/i18n/locale 下维护着 en_US、ja_JP、ko_KR 等 13 种语言包。

九、把变更日志当作排障索引的实用建议

综合全文，使用这份 Changelog 的三条实践路径：

1. 按症状检索：日志条目大量描述具体症状（“inf everywhere”“吞字”“静音推理”“ZeroDivisionError”），直接搜索症状关键词即可定位修复版本，再对照自己 checkout 的提交日期判断是否包含修复。例如“合成音频包含参考音频结尾”（2024.01.21 优化）与“句首吞字”（2024.01.28 修复）都指向 2024 年 1 月下旬的提交窗口。
2. 按 Type 过滤：升级大版本前先扫一遍 Performance Optimization 与 Fix 条目，了解该版本窗口内的稳定性投入（如 202503 节集中修复了 PyOpenJTalk、ONNX、Pydantic、PyTorch-Lightning 的依赖版本问题，说明该窗口是依赖收敛的关键点，当前 requirements.txt 即其结果形态）。
3. 按 Contributor 追溯：同一贡献者的条目往往成簇出现（如 KamioRinn 的文本前端系列、ChasonJiang 的并行/流式推理系列），沿贡献者线索可以重建某条技术线的完整决策过程。

最后需要说明两个边界：其一，日志中个别条目存在笔误（如 V4 正式发布行写作 “2024.04.22”，结合上下文应为 2025.04.22）；其二，日志记载的性能数字（“加速 50%”“提速 10%”“14GB/12GB/8GB 显存”）均为维护者在特定环境下测得，实际结果依赖显卡、CUDA/PyTorch 版本与文本长度，使用时应以自身环境实测为准。