GPT-SoVITS - OrbisLumenの部屋

做角色向视频时，画面之外还有一个很想折腾的东西：声音。如果能让熟悉的角色声音读出自己写的中文文稿，视频就又多了一种表达方式。

于是有了这个本地配音项目。从《樱之诗》的角色原音出发，整理数据、微调模型，再生成日语和中文语音。现在八个角色的首版训练已经跑通，也做了短句试听和中文长文合成实验。

项目代码整理在这里，原音、权重和生成音频保留在本机，仓库主要管理代码、配置、文稿和文档。

让角色声音读出新的文字#

核心使用的是 GPT-SoVITS，当前固定在 v2Pro。项目基于官方预训练权重做角色微调，训练、特征提取和合成都依托上游实现，外围再补上数据管理、Windows 适配和多角色操作界面。

整个过程可以概括为：从角色原音里选材，切成适合训练的短句，准备对应文本，提取特征并完成 SoVITS、GPT 两阶段微调。推理时加载同一个任务的两份模型，再提供参考音频、准确的参考台词和需要生成的文字。

这里很有意思的一点是，训练素材和参考音频都是日语，但目标文本可以是中文。项目利用底模已有的跨语言能力，把角色原音和中文口播接起来。训练标注仍然按真实的日语填写，不需要为了生成中文就把标签改成中文。

参考音频也不是可有可无的附件。它和模型、目标文本一起参与生成，换一段参考，听到的结果也可能不同。所以比较模型时，需要把参考和采样参数固定下来，才能知道变化大概来自哪里。

声音模型的输入看着很直观：音频，加上它说的那句话。但真的整理起来，才会发现“有声音”和“适合训练”之间还有不少工作。

项目保留原始录音，通过清单记录选中的素材，再统一格式、按静音切分，并检查时长、空音频、削波和重复文件。训练源与留出源在原始录音层面划分，避免同一段录音切出的相邻片段混在两边。

转写使用 faster-whisper 生成日语草稿，再进入标注确认环节。

这一环节不能简单理解成“跑完识别就有了正确答案”。人名、语气词和短句都可能识别错，声学指标正常的素材也不一定适合当前角色的配音目标。

目前心铃的数据有 64 条切片、约 203 秒，经过人工校对，朋友也参与了日语标注检查。其余七个角色采用的是已接受用于训练的自动转写，没有逐句完成人工听写校对。这个区别需要保留下来：流程里点了确认，不代表数据质量已经相同。

训练前还会核对音频、标注和特征是否对应。改了文字却继续使用旧特征，或者上游处理时漏掉了某个片段，都可能让后面的训练建立在不一致的数据上。比起等生成结果异常之后再猜原因，提前把这些关系检查清楚更有用。

运行环境是一台 Windows 笔记本，使用约 8GB 显存的 RTX 5060 Laptop。当前两阶段训练的 batch size 都是 2，并采用混合精度等设置，让这套流程能在本机完成。

实际折腾中，环境兼容也占了不少篇幅。日语前端的编译依赖、音频读取接口、单卡训练设置、网页依赖版本和日志编码，都可能成为中断点。这些问题和模型原理看起来离得很远，却决定了训练到底能不能继续。

所以项目后来越来越重视产物的组织：原音、切片、标注、特征、训练状态、推理权重和输出音频分别保留，关键文件记录哈希。素材或切分规则变化时另建任务，训练中断后也有状态可以恢复，不必每次都从头来过。

目前八个角色都完成了 SoVITS 20 轮、GPT 10 轮的首版微调，逐轮权重仍然保留。20/10 是当前默认组合，不能直接理解成轮数越多就一定越好。心铃做过固定条件下的轮次对照，但样本范围有限，还不足以证明某个组合在所有文本上都占优。

多角色界面也有一个很实际的细节：下拉框里选中了角色，并不代表对应模型已经加载。项目把选择状态和实际加载状态分开，合成前明确检查配套权重。八个角色是在同一块 GPU 上轮流加载，不是同时把八套模型塞进显存。

短句跑通之后，项目又尝试从 Markdown 口播稿提取章节，生成中文长文，并统一响度、整理输出。这一步让配音开始接近视频里的实际用途，也把停顿、重音和连续表达的问题带了出来。

文件存在、数值有效、输出不是静音，只能说明程序完成了一部分工作。声音像不像目标角色，中文读起来顺不顺，人名有没有念对，长句有没有漏字或重复，都还需要听。

把输出重新转写可以辅助发现问题，却不能代替试听；统一响度也只是让比较和后续使用更方便，不等于模型音质提高了。当前的长文合成仍属于实验，不能把已有样音写成所有文稿都已经完成了成片级配音。

这个项目让我开始把“训练完成”和“适合使用”分开看。前者有权重、日志和检查结果可以确认，后者还要回到具体文稿和视频里判断。有些问题需要换参考、修标注，有些则要拆成短句重新生成，再做拼接。

起点是想让熟悉的角色声音读出新的文字，做着做着，又多了一整套需要维护的数据和工具。不过，从原始音声一路走到自己的中文口播，这个过程本身就已经很值得记录了。