做这个 AI 口播视频工具的时候，我给自己定了一个硬性标准：语音必须像真人。不是"勉强能听"、"在 TTS 里算不错了"那种水平，而是你闭着眼睛听，分不出这是机器念的还是人在说。这一点上我没有妥协的空间，因为口播视频的核心就是"说话"，画面是辅助，声音才是灵魂。声音要是垮了，整个产品就废了。
这篇文章我打算把自己在 TTS 选型上走过的弯路、踩过的坑、最后为什么锁定 IndexTTS2 的全过程，原原本本地写下来。希望对同样在做语音合成相关项目的朋友有点参考价值。
最开始，我其实用的是一个商业 API
项目刚立项的时候，我的想法很朴素：先跑通流程再说，TTS 用现成的 API，省事。于是最早期的原型里，我接的是某国产大厂的语音合成 API。说实话效果在"标准普通话"场景下还行，但问题很快就暴露了：
第一，声音太"播音腔"。字正腔圆，每个字都咬得很准，但就是不像人说话。真正的口播博主说话是有节奏感的，有快有慢，有吞音有连读，偶尔还会带一点口癖。API 读出来的东西，怎么说呢，就像新闻联播——准确，但没人味。
第二，不可控。你没法让它在某个地方快一点、某个地方慢一点，也没法控制情感。我试过在文本里插 SSML 标签，但那个 API 的支持程度非常有限，基本上是给你什么你就得接受什么。
第三，也是压死骆驼的最后一根稻草——成本。口播视频的文案动辄几百上千字，按字符计费的话，每生成一条视频光是语音就要花掉不少钱。作为一个独立开发者，我没那么多预算去烧。
所以很快我就放弃了商业 API 这条路，开始转向开源方案。
开源 TTS 的漫漫选型路
进入开源世界之后，我才发现 TTS 这个领域比我想象的要繁荣得多。但繁荣归繁荣，真正能打的并不多。我列一下自己认真评估过的几个方案，以及为什么最后没选它们。
VITS 系列：经典但不够"活"
VITS（Variational Inference with adversarial learning for end-to-end Text-to-Speech）是最近几年开源 TTS 的标杆之一，基于它的各种衍生版本也很多。我最早试的是 MoeGoe 打包的一个中文 VITS 模型。
效果怎么说呢，比 API 自然，但稳定性差。同一个句子生成三遍，出来的结果可能完全不一样。有时候好得惊人，有时候莫名其妙地吞字、重复或者语气完全不对。对于要做产品的场景来说，这种不确定性是不能接受的。你不能让用户"多试几次，总能碰到好的"。
而且 VITS 的微调门槛不低。你想用自己的声音训练一个模型？可以，但需要高质量的数据集、足够的算力、以及大量的调参经验。我是一个人一台笔记本在搞，这条路走不通。
GPT-SoVITS：差点就定它了
GPT-SoVITS 应该是 2024 年初中文 TTS 圈最火的项目了。它的核心思路是把 GPT 的文本理解能力和 VITS 的语音合成能力结合起来，少样本音色克隆的效果确实惊艳。你用 5 秒钟的音频就能克隆出一个很像的声音，10 秒以上效果就相当不错了。
我花了大概一周的时间认真调 GPT-SoVITS，做到的效果已经让我比较满意了。但最终放弃它，有几个原因：
GPT-SoVITS 的音色克隆虽然牛，但它的"克隆"是整体性的——你给它一段参考音频，它把那个人的音色、语速、情绪一起"学"过去了。这意味着如果你想让同一个声音在不同场景下表现出不同的情绪（比如激昂的带货 vs 温柔的晚安问候），很难精细控制。
另一个问题是推理速度。在 RTX 5060 8GB 上，GPT-SoVITS 生成一段 30 秒的音频大概需要 8-12 秒左右。单看这个数字其实还行，但我的场景里用户可能要一次生成好几段文案，累积起来等待时间就长了。而且 8GB 显存在跑 GPT-SoVITS 的时候几乎是顶着上限跑的，稍不注意就 OOM。
还有一个很实际的问题：部署复杂度。GPT-SoVITS 的依赖链很长，各种版本的 torch、transformers、还有它自己 fork 的一些库。每次环境出问题排查起来都让人头大。我要做的是一个桌面工具，不能指望用户自己去折腾这些依赖。
CosyVoice：阿里开源的优秀选手
CosyVoice 是阿里在 2024 年开源的一个 TTS 项目，在中文效果上非常出色。它的优势在于情感控制做得很好，可以通过文本标签来控制语气，比如高兴、悲伤、惊讶等等。而且它的少样本克隆能力也很强。
我试了 CosyVoice 的 Demo，效果确实不错。但有两个问题让我犹豫：第一，模型体积大，完整模型好几个 GB，对于桌面工具来说太重了；第二，它的推理管线比较复杂，包含了前端文本处理、韵律预测、声学模型、声码器等多个步骤，整合到我的微服务架构里需要做不少适配工作。
坦白说，如果项目规模再大一点、有一个小团队的话，我可能会选 CosyVoice。但一个人做，我需要一个更"轻"更"可控"的方案。
Fish-Speech 和 ChatTTS：后起之秀
这两个项目我都有认真关注。Fish-Speech 的思路很有意思，用 LLM 来做语音合成，效果在英文上很强，中文还在追赶。ChatTTS 是专门为对话场景优化的，生成的声音非常自然，有停顿、有语气词、有笑声音效，听起来就像两个人在聊天。
ChatTTS 我差点就用了——它的对话自然度在目前的开源方案里可能是最好的。但它的定位是"对话"，而我的场景是"口播"。口播和对话虽然都是说话，但节奏不一样：口播是一段完整的独白，需要流畅的、有节奏感的输出，而不是一问一答的对话感。ChatTTS 在处理长段落独白的时候偶尔会出现"断气"的感觉，停顿位置不太对。
另外 ChatTTS 的音色控制非常有限——它提供了一些预设的音色种子，但你想精确控制音色？做不到。而我的工具里，用户需要能够选择和定制自己的"口播声音"，这个需求 ChatTTS 目前满足不了。
为什么最终选了 IndexTTS2
IndexTTS2 是 Bilibili 的 Index Team 开源的 TTS 项目，基于 GPT 风格的自回归模型 + 流匹配（Flow Matching）声码器。说实话，在试它之前我并没有抱太高期望，因为前面已经踩了太多坑。但第一次生成结果出来的时候，我愣了一下——这声音，有点东西。
具体来说，IndexTTS2 打动我的有这几点：
第一，自然度真的高。IndexTTS2 生成的语音有一种"松弛感"，不像传统 TTS 那样每个字都绷得很紧。它有自然的连读、有合理的停顿、有轻重缓急。特别是在一些口语化的表达上，比如"我觉得吧"、"那个啥"这种，它念出来的感觉很对。
第二，音色克隆和合成拆分开，这对我很重要。IndexTTS2 支持零样本音色克隆——你给它一段 3-10 秒的参考音频，它就能用那个声音说话。但更关键的是，它的克隆是只克隆音色，不克隆情绪和节奏。换句话说，它提取的是"谁在说话"的信息，而"怎么说"是模型自己根据文本决定的。这种拆分给了我很大的灵活性：同一个音色可以激昂、可以温柔、可以快速、可以缓慢，完全看文本怎么引导。
这一点是我最终放弃 GPT-SoVITS 而选择 IndexTTS2 的核心原因。我需要的是"同一个声音在不同场景下的灵活表现"，而不是"把参考音频的所有特征完整复制"。
第三，推理速度快。在 RTX 5060 8GB 上，IndexTTS2 生成一段 30 秒的音频大约需要 4-6 秒，比 GPT-SoVITS 快了将近一倍。而且显存占用更友好，峰值大概在 5-6GB 左右，给 LatentSync 留出了足够的空间（这个后面会讲）。
第四，部署相对简单。虽然 IndexTTS2 的官方文档……嗯，怎么说呢，比较"极简"——很多配置需要自己去翻代码理解。但核心依赖链比较清晰，主要就是 PyTorch + Transformers + 一些音频处理库。封装成微服务之后，维护成本在可控范围内。
第五，支持中英文混合。口播视频里经常会夹杂一些英文词汇，比如品牌名、产品型号、网络流行语等等。IndexTTS2 在中英混合场景下的表现相当不错，不会出现英文部分"突然变成另一个人"的违和感。
IndexTTS2 也有坑，得老实说
没有完美的方案，IndexTTS2 也有一些让我头疼的地方：
文档是硬伤。前面提到了，官方文档真的很"精简"。很多参数的含义、模型的工作原理、不同版本之间的差异，你只能去看源码或者翻 GitHub Issues。对于一个想快速上手的人来说，门槛不低。
长文本的稳定性。当文本超过一定长度（大概 200 字以上），IndexTTS2 有时会出现语调漂移——前面还很正常，后面突然变调了，或者语速明显变快。我现在是通过分段生成 + 拼接的方式来解决的：把长文案按照句号切分成小段，逐段生成，再拼接成完整的音频。这样做虽然多了一些逻辑，但最终效果很稳定。
音色克隆的质量依赖参考音频。如果你给的参考音频质量很差——有背景噪音、回声、或者说话人离麦克风太远——克隆出来的声音也会受影响。解决办法是要求用户提供清晰的、干净的参考音频，并且在服务端做一些预处理（降噪、归一化）。
某些声学场景下的细节不够好。比如在表达疑问句、感叹句的时候，语调的变化幅度有时不够。相比之下 CosyVoice 在情感表达上做得更好。但对于口播场景来说，大部分内容是陈述性的，这个问题影响不大。
我的 TTS 微服务架构
选定了 IndexTTS2 之后，我把它封装成了一个独立的微服务，跑在端口 8101 上。整个 TTS 服务的职责非常明确：
- 接收文本加参考音频，返回生成的语音文件路径
- 分段处理长文本，自动按句号切分，逐段生成后拼接
- 音频预处理：对参考音频做降噪、响度归一化
- 音色缓存：把提取的音色特征缓存起来，同一个用户不用每次都重新提取
API 设计上我尽量保持简单。主路由 /tts/generate 接收 POST 请求，参数包括文本内容、参考音频文件、以及一些可选参数（语速、音高调整等）。内部处理完返回生成的音频路径和耗时信息。
和主 API 服务（:8000）的交互方式是：主服务收到用户的生成请求后，先调用 TTS 服务生成音频，拿到音频路径后再调用 LatentSync 服务做唇同步，最后 FFmpeg 合成输出。整个链路是串行的，每一步都依赖上一步的结果。
最后聊聊选型的感悟
做技术选型这件事，我觉得有一个很重要的原则：不要追最新，要追最合适。刚进入一个领域的时候，很容易被各种新项目、高 Star 数、炫酷的 Demo 吸引。但真正落地的时候你会发现，Star 数和你的业务匹配度完全是两回事。
IndexTTS2 在 GitHub 上的 Star 数远不如 GPT-SoVITS 和 CosyVoice（至少在我写这篇文章的时候是这样），但它在我的场景里就是最合适的。它不一定是最好的 TTS 项目，但它是最适合"AI 口播视频生成"这个场景的 TTS 项目。
另外我还发现一个有意思的现象：开源 TTS 的发展速度远超我的预期。就在我开发这个项目的几个月里，至少有三四个新的中文 TTS 项目冒出来，而且质量都很高。这意味着今天的最优解，明天可能就被超越了。所以我在架构设计上特意留了"TTS 可替换"的能力——微服务封装、标准化的 API 接口、松耦合的集成方式。如果将来出现更好的方案，换掉 IndexTTS2 的成本不会太高。
这也是做独立开发的一个优势：你不需要说服任何人，自己试过觉得好就可以上。没有技术评审，没有团队拉扯，你的判断直接决定产品方向。这种自由是宝贵的，但同时也意味着你要为自己的每一个选择负责。