ChatTTS：为对话场景而生的开源中文语音合成模型

ChatTTS：让中文语音合成听起来像"在聊天"，而不是"在念稿"

绝大多数开源 TTS 解决的是"把字读对"，ChatTTS 想解决的是"把话说自然"。它针对日常对话场景做了专门的建模：口语化的停顿、语气词、笑声、断句节奏都能被显式控制。如果你做过中文语音助手、有声书对白、播客生成，应该知道朗读腔有多难修——这个项目的默认输出就在努力绕开这个问题。

项目背景

ChatTTS 由 2noise 团队开发并开源，官方定位很克制，只有一句话："A generative speech model for daily dialogue."——不是通用 TTS，而是为对话而生的生成式语音模型。

它要填的坑很明确：当时开源生态里，中文 TTS 要么是传统拼接/参数化方案，音质和自然度有限；要么是面向朗读场景训练的大模型，遇到口语对话就露馅——该喘气的地方不喘，该笑的地方念成"哈"，多轮对话里每个角色的音色还互相串。ChatTTS 把"韵律"和"副语言信息"当成一等公民来建模，这是它和同类最本质的分歧点。

近四万 Stars、四千多 Forks，且在 2026 年仍有提交，说明它已经从"demo 爆红"进入了持续维护阶段。

核心功能解析

1. 副语言与韵律的显式控制

这是 ChatTTS 最实用的设计。它把笑声、停顿、口语化程度做成了可以写进文本的控制标记，而不是指望模型自己猜。[laugh] 表示笑声，[uv_break] 是不带音的短停顿，[lbreak] 是较长的句间停顿。你可以直接把它们嵌进待合成的文本里：

texts = [
    "这个方案我觉得[uv_break]还行吧[laugh]，不过预算得再聊聊[uv_break]。"
]

更细粒度的控制走 RefineTextParams，用 prompt 形式调整整段的风格倾向，比如口语度和笑声幅度的档位：

params_refine_text = ChatTTS.Chat.RefineTextParams(
    prompt='[oral_2][laugh_0][break_6]',
)

2. 音色采样与可复现的说话人嵌入

ChatTTS 不需要参考音频做零样本克隆，而是从模型分布里采样音色向量。这意味着你可以在短时间内批量生成不同说话人，用在对白、多角色场景里非常省事。关键在于：采样出来的 spk_emb 是可以保存复用的，固定住它就是固定的音色，这对一致性要求高的生产环境很重要。

rand_spk = chat.sample_random_speaker()

params_infer_code = ChatTTS.Chat.InferCodeParams(
    spk_emb=rand_spk,      # 保存这个向量即可复现音色
    temperature=0.3,
    top_P=0.7,
    top_K=20,
)

3. 基于 LLM 范式的两阶段生成

整体链路是"文本 → 离散音频 token → 波形"：先用自回归 Transformer 在音频 token 空间里做序列生成，再由解码器还原成 24kHz 波形。也就是说，它本质上是把 TTS 当成语言建模问题来做，而不是声学特征回归。这样做的好处是韵律、停顿这些"长程依赖"能被注意力机制自然地捕捉到，代价是推理是逐 token 的，延迟不低。

快速上手

git clone https://github.com/2noise/ChatTTS
cd ChatTTS
pip install --upgrade -r requirements.txt

import ChatTTS
import torch
import torchaudio

chat = ChatTTS.Chat()
chat.load(compile=False)   # 首次运行会下载权重

wavs = chat.infer(["你好，我是 ChatTTS，今天想和你聊两句。"])
torchaudio.save("output.wav", torch.from_numpy(wavs[0]), 24000)

生产环境建议把 compile 打开（依赖 torch.compile，首次编译慢，之后有明显加速），并把采样率固定为 24000Hz。

技术亮点

第一，把副语言信息从隐变量变成可控 token。传统方案里，笑声、叹息这类非语音现象要么被丢弃，要么混在声学特征的隐空间里无法干预。ChatTTS 把它们离散化成显式符号，在文本侧就能干预生成轨迹。这是一个非常工程化的取舍：牺牲一点"端到端纯洁性"，换来了可控性——而对做产品的人来说，可控性就是一切。

第二，音色解耦。把说话人表征作为独立的 spk_emb 注入 InferCodeParams，内容、韵律、音色三者在推理侧被拆开。这带来的直接好处是：同一句话可以用同一个音色向量跑不同 temperature，或者固定韵律换音色，做 A/B 测试的成本极低。相比"喂一段参考音频做克隆"的路线，它的音色一致性更稳定，但代价是不能复刻指定真人音色。

第三，文本侧的两段式推理。RefineTextParams 和 InferCodeParams 把"文本规范化 + 韵律规划"和"声学生成"分成两个阶段，可以分别调参、分别缓存。这在批量推理场景下能省掉重复的文本处理开销。

需要注意的坑：自回归解码意味着实时流式场景要打问号；temperature 调高容易出现吞字或乱读，实测 0.3 附近比较稳。另外协议是 AGPL-3.0，传染性很强——如果你的服务通过网络对外提供，改动后的代码原则上需要开源。闭源商业产品接入前请先过法务。

同类对比

结论很直白：要自然的中文对话且能接受自部署，选 ChatTTS；要复刻特定人声，它不是答案；要低延迟高并发且预算充足，云 API 仍然更省心。

总结

如果你在做中文语音对话、播客/有声对白生成，并且需要把停顿和语气当成可调参数而不是听天由命，ChatTTS 是当前开源方案里最值得先跑一遍的那个——前提是你能接受自备 GPU，以及 AGPL-3.0 带来的授权约束。