TTS 架构的六代演进（六）：第 6 代 · 端侧轻量化

本篇是「TTS 架构的六代演进」系列第 6 篇。

第 5 代（VALL-E / XTTS-v2 / F5-TTS 等）拿到了零样本音色克隆能力，代价是模型 GB 级、GPU 依赖、100 ms+ 首包延迟 ------手机 / 耳机 / 车载 / IVR 这些 CPU-only + 低延迟场景全线不友好。第 6 代（2023-）的目标是压回 100 MB 以下、CPU 实时、几十 ms 首包 ------放弃零样本换回质量密度和部署可行性。Kokoro-82M (hexgrad 2024，https://huggingface.co/hexgrad/Kokoro-82M) 是代表：82M 参数 、~300 MB fp32 / ~80 MB int8、CPU RTF 0.15 ，架构基于 StyleTTS 2 + iSTFTNet 精简、teacher 未公开。

这一代为什么值得单独一篇------四点：

端侧 TTS 是刚需------手机 App / 耳机侧 / 车载 IVR / 智能音箱都是 CPU-only + 100-200 MB 内存预算 + 100-300 ms 首包延迟要求，Gen 5 大模型完全塞不进
三条正交压缩路径叠加 ------架构精简 （复用 Gen 4-5 骨架、砍层数/hidden dim）、合成数据 （拿闭源 TTS API 输出训 student）、量化（fp32→int8）三条 orthogonal 路径并联，把 Gen 5 大模型压回 100 MB 以下。核心技术套路跟 Gen 5 完全反过来------不是砸更多数据 + 更大参数，而是牺牲通用性、榨干每个参数的表达力
放弃 zero-shot 换回质量密度 ------固定音色（voice pack 预训练好的一组 speaker embedding）替代动态 reference audio，训练目标更聚焦、参数利用率更高。Kokoro-82M 靠 54 个预置音色 + 8 语种覆盖，截至 2025 年在 TTS Arena 榜单前列压过 10 倍参数的模型（榜单动态、当前排名可能变化）
ONNX / GGML / RKNN 部署栈成熟------PyTorch 之外，跨平台推理引擎让"训练在 GPU、推理在 ARM CPU"成为可行 pipeline，Kokoro-ONNX / Piper / MeloTTS 都是 ONNX-first

一、原理：端侧三约束 + 三条压缩路径

Gen 5 把 TTS 推到 zero-shot 任意音色克隆的高度，但也把成本推到 GB 级模型 + GPU 推理------完全不适合手机 App / 耳机 / 车载嵌入式。第 6 代的技术选择围绕三个硬约束展开，并对应三条压缩路径。

为什么端侧、代价是什么、怎么压------分四层解答：

① 端侧的三个硬约束------

内存：手机 App 音频模块预算 100-200 MB、耳机侧 20-50 MB、嵌入式 <20 MB。Gen 5 XTTS-v2 的 1.87 GB checkpoint 直接超标 10 倍
CPU-only：不能假设 GPU。ARM Cortex-A76 (手机)、Intel N100 (嵌入式)、Cortex-A55 或专用蓝牙 SoC (耳机) 是常见目标。Gen 5 CPU RTF 通常 >1（不能实时）
首包延迟：车载导航 <300 ms、客服 IVR <100 ms、直播 TTS <50 ms 才不觉得机器卡顿。Gen 5 首包动辄 500 ms 以上

② 三条压缩路径------业界主流做法叠加使用：

架构精简（模型侧） ：复用 Gen 4-5 大模型骨架（VITS / StyleTTS 2 / VITS2 等），但砍 Transformer 层数 （12 → 6）、减 hidden dim （512 → 256）、换更轻的 vocoder（HiFi-GAN → iSTFTNet）。Kokoro-82M 基于 StyleTTS 2 + iSTFTNet、Piper 是 VITS-style、MeloTTS 基于 VITS/VITS2/Bert-VITS2 系列------都是拿论文原骨架、按端侧预算裁维度
合成数据（训练侧） ：训 student 时混合 permissive 真实语料 + closed 大模型合成音频（"closed 大模型" 指商用闭源 TTS API，如 OpenAI TTS / ElevenLabs / Azure Neural TTS 等）。有时被简称为"蒸馏"，但严格意义上是 black-box synthetic distillation------student 只吃 teacher API 的 (text, audio) 输出对、不看 teacher 中间 logits。免了几十万美元配音成本，是 Kokoro 总训练成本压到 $1000 GPU 时的核心原因
量化（数值精度侧）：fp32 → fp16（通常无质量损失、大小减半）→ int8（质量微降、大小再减半）→ 激进的 int4（小尺寸端侧、明显质量损失）。Kokoro fp32 ~300 MB → int8 ~80 MB（官方 README 数据）

三条维度正交 ------同一模型可以只用一条（Piper 从头训、不用合成数据、只精简架构 + 量化），也可以三条叠加（Kokoro 三条全用）；合成数据是训练策略 、跟运行时无关，量化是部署优化 、跟训练无关，架构精简是模型结构本身、训练/部署都改。

③ 放弃 zero-shot 换回质量密度 ------第 5 代大模型要在 60K+ 小时数据上学 "任意 3 秒 reference audio → 任意音色"，参数被 speaker generalization 消耗大半。Gen 6 端侧模型放弃 zero-shot、只训固定的一组预置音色 （voice pack），同参数量下音色质量、韵律稳定性都更强。Kokoro voice pack v1.0 有 54 个音色 / 8 语种（英/日/中/西/法/意/葡/印），靠切换 embedding 而非 reference audio 选音色。

④ 部署栈：ONNX / GGML / RKNN ------PyTorch 直接部署到端侧太重，Gen 6 模型基本都提供 ONNX 导出。ONNX Runtime CPU 有 AVX/NEON 指令集优化、比 PyTorch CPU 快 2-5×；GGML 是 llama.cpp 生态的量化推理引擎、支持 int4/int8；RKNN 是 Rockchip NPU 的推理框架。训练在 GPU、推理在 ONNX / GGML / RKNN 是 Gen 6 的标准 pipeline。

二、前端：跟 Gen 4-5 一致的外挂 G2P

Gen 6 端侧模型的前端跟 Gen 4-5 没有本质差别------TN + G2P → 音素 ID 序列。差异只在实现更轻量：G2P 通常用规则或极小的模型（几百 KB），不再挂 phonemizer 那种依赖 espeak-ng 的重工具。Kokoro 内置了英/日/中/西/法/意/葡/印共 8 种语言的 G2P，全部实现在几百 KB 的规则表和微型模型里。

三、Kokoro-82M 端侧网络

架构基于 StyleTTS 2 + iSTFTNet ------Gen 4 后期 StyleTTS 2 在 LJSpeech 拿到 CMOS +0.28 显著超过真人的成绩（part4 §4.4），但 148M 参数、GPU 推理。Kokoro 团队把 StyleTTS 2 骨架精简到 82M 参数 ：vocoder 换成 iSTFTNet （逆 STFT-based，比 HiFi-GAN 更轻）、去掉 Style Diffusion 阶段 、保留 Text Encoder + Style Encoder + Decoder + Duration Predictor 主链路，配合 fixed voice pack 拿到端侧可跑的固定音色 TTS。注意 ------官方 model card 未公开具体 teacher 模型，训练数据是 permissive 真实音频 + closed 大模型合成音频的组合，严格来说不是"蒸馏 StyleTTS 2"、而是"架构继承 StyleTTS 2"。

每一块具体干什么------跟 part5 VALL-E 端到端网络的模块表对齐、一起看更容易理解代际差异：

模块	输入	输出	干的事	跟 Gen 5 的差别
G2P 前端	文本字符串 `"The quick brown fox..."`	音素 ID 序列	拼音标注（Kokoro 内置 8 语种轻量 G2P）	一样。轻量实现在几百 KB 规则表里
Text Encoder + PL-BERT	音素 ID 序列	text hidden `(L, d)`	Transformer + PL-BERT 出带语义信息的 text 特征	Gen 5 只是 phoneme embedding + Transformer；Gen 6 挂了 PL-BERT 预训练拿到更强的 prosodic 表征
Voice Pack Lookup	`voice="af_bella"` 字符串 key	style embedding `(d,)`	从预训练好的 voice pack 里查表拿固定音色向量	核心变化：Gen 5 是 encoder 从 reference audio 抽 embedding（动态、任意音色），Gen 6 是查表（静态、54 个预设）
Duration + Prosody Predictor	text hidden + style embedding	每音素 duration + pitch + energy 曲线	决定每个音说多长、什么音高、什么力度------韵律编排	Gen 5 flow matching 内隐式建模、Gen 6 显式预测 duration+pitch+energy（跟 FastSpeech 2 / StyleTTS 一样）
Length Regulator	text hidden + duration	帧级 aligned `(T, d)`	按 duration 把音素级 hidden 拉成帧级	Gen 4/5 都有类似模块（Gen 5 NAR 派也用）
Decoder + iSTFTNet Vocoder	aligned `(T, d)` + style embedding	wav `(N,)` @ 24 kHz	iSTFTNet 出幅度谱 + 相位谱 → 逆 STFT → 波形；AdaIN 把 style 注入 decoder	另一核心变化：Gen 5 用 HiFi-GAN（30+ 层 transposed conv）；Gen 6 用 iSTFTNet（预测频域后 iSTFT，vocoder 参数减半、CPU 更快）

为什么 iSTFTNet 比 HiFi-GAN 快 ------HiFi-GAN 要在时域堆几十层 transposed conv 一步步把 200 帧上采样到 48000 样本；iSTFTNet 只预测频域的幅度和相位（帧数不变、每帧 F 个 bin），最后一步 iSTFT 直接把频谱变波形。卷积层数从 30+ 降到 ~10 、CPU 推理 2-3× 加速，代价是理论天花板略低（时域直出的 HiFi-GAN 在极端场景重建更好），但端侧场景够用。

3.1 骨架：StyleTTS 2 + iSTFTNet 架构精简

模型仓库：https://huggingface.co/hexgrad/Kokoro-82M
ONNX 复现：https://github.com/thewh1teagle/kokoro-onnx
架构参考（StyleTTS 2）：https://arxiv.org/pdf/2306.07691
架构参考（iSTFTNet）：https://arxiv.org/pdf/2203.02395

继承 StyleTTS 2 的核心模块：

Text Encoder --- Transformer encoder + PL-BERT 预训练的 prosodic embedding
Style Encoder --- 从 voice pack 里读预训练好的 style embedding（不再是 diffusion 采样）
Duration + Prosody Predictor --- 从 text_embedding + style_embedding 预测每音素时长、pitch curve、energy
Decoder + iSTFTNet Vocoder --- 用 iSTFTNet 替代 StyleTTS 2 里的 HiFi-GAN：预测幅度谱 + 相位谱后做逆 STFT 出波形，比 HiFi-GAN 少一堆上采样卷积、更适合 CPU 推理；AdaIN 注入 style embedding

跟 StyleTTS 2 的差异：

去掉 Style Diffusion 阶段 ：原 StyleTTS 2 训练时用 diffusion 建模 style latent 分布、支持无 reference 生成；Kokoro 直接用 voice pack 里的预训练固定 style embedding，跳过 diffusion
去掉 SLM discriminator：原 StyleTTS 2 用 WavLM 作 discriminator 提升自然度；Kokoro 训练时用合成数据的 supervision，不再挂大 SLM 判别器
Vocoder 换成 iSTFTNet：原 StyleTTS 2 用 HiFi-GAN generator + AdaIN；Kokoro 用 iSTFTNet + AdaIN，vocoder 参数量减半、CPU 推理明显加速
模型大小：82M 参数 vs StyleTTS 2 的 148M

3.2 Voice Pack：预训练音色库替代 zero-shot reference

核心 trade-off ------Gen 5 XTTS-v2 靠 dynamic reference audio 支持任意音色（clone unseen speaker），Kokoro 靠 pre-trained voice pack 支持一组已知音色（不能 clone unseen speaker，但能选 54 个已训练音色）。

Voice pack 格式 ：voices-v1.0.bin 是一个二进制文件，里面存着 54 个 style embedding（每个音色对应一个 embedding）。推理时按 voice="af_bella" 之类的 key 查表。embedding 维度和文件大小官方 README 未公开，下载后加载查 tensor.shape 即可确认。

每个 voice 的训练过程：官方公开信息有限，社区讨论中 hexgrad 团队透露训练总量约 "a few hundred hours" 真实音频 + closed 大模型合成音频，v0.19 + v1.0 各 500 A100-hour（总成本约 $1000）。

3.3 训练数据："closed 大模型合成音频" 是什么

Kokoro model card 反复出现一句话------"trained on permissive audio + synthetic audio generated by closed TTS models from large providers "。这里的 "closed TTS models from large providers" 指的是商用闭源 TTS API------候选池是 OpenAI TTS-1-HD / ElevenLabs / Azure Neural TTS / Google Cloud TTS 这几家，hexgrad 团队公开承认这么用但没点名具体是哪几家、也没说各家占比。

做法------批量喂 text 到闭源 API 拿回合成 audio，组成 (text, waveform) 对喂给 82M student，让 student 拟合 teacher 的声学分布。跟"人肉录数据"相比：一是免了几十万美元配音成本；二是任意 text 立刻拿到对应 audio、想要什么发音风格就调 API 参数生成什么。这也是 Kokoro 训练总成本能压到 ~ $1000 GPU 时的核心原因（1000 A100-hour × \~$ 1/GPU-hour）------数据是"生成"出来的、不是"采集"出来的。

跟传统蒸馏的差别 ------传统蒸馏（Tacotron 2 → FastSpeech 2、BERT → DistilBERT）是 white-box 权重蒸馏 ：student 有 teacher 权重、看得到中间 logits / hidden states，损失函数里有 KL 散度让分布对齐。Kokoro 这种是 black-box synthetic distillation ------teacher 只暴露 HTTP API，只有 (text_in, audio_out) 这一对可见，student 从输出反推分布，损失里只有 waveform reconstruction 和 adversarial 那一套。术语区分 ------严格来说这是 "数据蒸馏"（data-side distillation） 而不是 "模型蒸馏"（weight-side distillation） ------前者合成一堆监督数据训 student、后者拿 teacher 的中间表征当额外监督。LLM 世界里叫 synthetic data training ------Alpaca 用 GPT-3.5 生成 52K 样本训 LLaMA 就是同一套路。Kokoro 是这套路子在 TTS 领域最早跑通到端侧规模的例子之一。

灰区 ------不同商用 TTS 厂商的 ToS 条款差异较大 ，并非全部一律禁止拿输出训练（OpenAI ToS §2©："You may not... Use output from the Services to develop models that compete with OpenAI"；ElevenLabs 服务条款也有类似禁止竞品训练的表述；但也有部分厂商允许非商用研究用途）。合规性在司法实践里还没统一定论。Kokoro 权重是 Apache 2.0 开源、任何人可拿走，但训练数据 provenance 有 ToS 争议------这也是它主要在开源社区和个人 App 里流行、大厂产品线基本不采纳的原因之一。想拿 Kokoro 商用的团队一般会自己重跑一遍 pipeline、换成 permissive 真录音训练。

3.4 部署：ONNX + 量化让 CPU 实时

ONNX 导出 ------Kokoro PyTorch → ONNX 一步转，然后用 onnxruntime CPU 后端跑。ONNX Runtime 在 x86 上启用 AVX2 / AVX-512，在 ARM 上启用 NEON，推理速度比 PyTorch CPU 快 2-5×。

量化梯度------以下 RTF 和大小为社区实测汇总（kokoro-onnx README + GitHub issues），非论文级严格评测：

精度	文件大小	CPU RTF (Intel i7 2.9 GHz)	质量
fp32 (原始)	310 MB	0.15	Baseline
fp16	155 MB	0.13	无感知损失
int8 (dynamic)	~80 MB	0.10	略有金属感
int4 (GGUF)	~40 MB	0.08	高频细节明显丢失

3.5 训练配置 + 推理与代码

训练配置（Kokoro 是社区模型、无正式 paper，以下数字来自官方 model card）：

项	设置
架构基础	StyleTTS 2 + iSTFTNet（Li et al., 2023 / Kaneko et al., 2022）、architected by Li et al
训练数据	permissive 真实音频（含 Koniwa `tnc` 日语 < 1h、SIWIS 法语 < 11h 等 CC-BY 数据）+ closed 大模型合成音频
训练数据量	"A few hundred hours"（官方 model card）
Teacher 模型	未公开（仅说"synthetic audio generated by closed TTS models from large providers"）
训练损失	feature matching + waveform L1 + adversarial（社区通用做法，官方未详细披露）
Voice pack	54 个预置音色（v1.0），8 语种覆盖
训练成本	~500 A100 80GB GPU-hours (v0.19) + ~500 h (v1.0)，总约 $1000
模型规模	82M 参数、~300 MB ONNX (fp32) / ~80 MB (quantized)

推理与代码 ------用 kokoro-onnx 直接跑：

python 复制代码

# pip install kokoro-onnx soundfile
from kokoro_onnx import Kokoro
import soundfile as sf

kokoro = Kokoro("models/kokoro/kokoro-v1.0.onnx",
                "models/kokoro/voices-v1.0.bin")
samples, sr = kokoro.create(
    "The quick brown fox jumps over the lazy dog.",
    voice="af_bella", speed=1.0, lang="en-us")
sf.write("wav/part6/gen6_kokoro_en.wav", samples, sr)
# 加载 0.44s, 推理 0.62s → 2.82s 音频, RTF 0.147 (Intel CPU)
# 对比 XTTS-v2 (Gen 5): 1.87 GB checkpoint、GPU RTF 0.11 (RTX 4090)

📢 $Gen 6 音频 \cdot Kokoro$ ------ gen6_kokoro_en.wav。跟 Gen 5 XTTS-v2 相比：音色是 fixed voice pack 里的一个（af_bella），不是任意克隆 ；质量在英文场景压过或接近 XTTS-v2 ；CPU 实时 vs XTTS-v2 CPU 不能实时。这就是 Gen 6 的核心 trade-off：换掉 zero-shot 拿回质量密度和部署可行性。

四、Gen 6 家族：端侧 TTS 的四条路线

Gen 6 目前活跃的端侧模型没有形成单一技术范式，而是沿着架构精简降本、codec-LM 场景优化、流式能力增强、极致体积压缩四个方向并行演进，对应四条主流路线。

4.1 架构精简派：基于 Gen 4-5 骨架 + 合成数据训练

4.1.1 Kokoro-82M（hexgrad 2024）

仓库 https://huggingface.co/hexgrad/Kokoro-82M ，架构见 §三。质量密度最高的端侧 TTS 之一 ------82M 参数压 XTTS-v2 40 倍、TTS Arena 榜单靠前、总训练成本约 $1000 GPU 时。中文表现：中文只是 Kokoro 8 语种覆盖里的一种，自然度和韵律弱于英文，不是首选中文引擎。

4.1.2 Piper（rhasspy → OHF-Voice 2023）

仓库 https://github.com/OHF-Voice/piper1-gpl 。基于 VITS 从头训（不是从 VITS 蒸馏，是 VITS-style 从头训练）+ 每 voice 独立 fine-tune ------每个 voice 是独立 ONNX 模型，社区实测常见大小 40-80 MB，Home Assistant 生态默认 TTS。Raspberry Pi 4 上都能实时（社区实测 RTF < 1）。语种覆盖广（60+ 种），但每个 voice 都是 fixed、不能切换韵律风格。

G2P 特例 ------§二说 Gen 6 端侧模型 G2P 不再挂 espeak-ng 那种重工具，Piper 是特例：它直接把 espeak-ng 编译进 phonemization 后端。做法是把 espeak-ng 深度集成为轻量依赖（而不是外挂完整 phonemizer 工具链），兼顾了 60+ 语种覆盖和端侧体积------这是"覆盖广"的代价。Kokoro / KittenTTS 那种纯规则 + 微型模型 G2P 更适合单语种极致优化，Piper 走的是另一条路子。

VITS 骨架 ------ 完整 end-to-end pipeline（Posterior Encoder + Prior + Flow + Decoder + Stochastic Duration Predictor + Monotonic Alignment Search 五大模块，具体推导见 part4 §三 VITS 章节，此处不重复）。Piper 完整继承这套结构、砍 hidden dim 和 encoder 层数适配端侧。

每 voice 独立 fine-tune 的策略 ------Piper 官方提供一个 base checkpoint（在 LibriTTS + VCTK 等多说话人数据上 pre-train），每个 target voice 拿几到十几小时该说话人录音 fine-tune，几十 GPU-hours 就能出一个 quality-good 的单说话人模型。代价是每音色一个 .onnx 文件 、切换音色要重加载；Home Assistant 的做法是本地按需下载对应 voice 的 ONNX。跟 Kokoro 的对比------Kokoro 一个 checkpoint 存 54 音色靠 style embedding 切换、Piper 每 voice 一个完整模型；trade-off 是 Piper 每音色质量更高（专门 fit），Kokoro 切换成本低（换 embedding 而非重载模型）。

4.1.3 MeloTTS（myshell 2024）

仓库 https://github.com/myshell-ai/MeloTTS 。多语种 + 声明 CPU 实时 ------支持中/英/日/西/法/韩 6 种语言（英文有 5 种口音变体、中文支持中英混合）。骨架基于 VITS / VITS2 / Bert-VITS2 （README 明说 "implementation is based on TTS/VITS/VITS2/Bert-VITS2"）。官方只声明 "Fast enough for CPU real-time inference"、未公开具体首包延迟数字。是端侧中文场景的主流选型------工业界流式 IVR / 电商直播场景大规模落地。

VITS2 相对 VITS 的三处升级 （见上图）------(a) Duration Discriminator 对抗训练时长 替代 VITS 的 stochastic flow-based duration predictor，训练稳定性和自然度都提升；(b) Flow 里加 Transformer Block + Convolution Block ，增强 long-range 依赖、韵律更连贯；© Text Encoder 的 Transformer Block 直接吃 Speaker embedding，multi-speaker 场景效果显著变好。这三点让 VITS2 在同参数量下 MOS 相对 VITS 有可观提升（具体对比数字见论文 arxiv 2307.16430 §5 表格）。

Bert-VITS2 加上 BERT 语义辅助------在 VITS2 之上，text 除了走 phoneme + Text Encoder 外，同时走一遍 BERT 出 semantic embedding、concat 进 Text Encoder。TTS 除了 phoneme 之外还能看到句子的语义------中文场景特别关键（同一音节不同调不同意，BERT 提供上下文帮 disambiguate）。MeloTTS 中文版本继承 Bert-VITS2 用中文 BERT 挂 semantic 辅助，英文和其他语种版本按 README 说法沿用 VITS2 骨架、语义 grounding 弱化。

4.2 codec-LM 派：AR 语言模型出 audio token

4.2.1 ChatTTS（2noise 2024）

仓库 https://github.com/2noise/ChatTTS 。主打对话感 + 语气词自然 ------不追求播音腔，专门优化"嗯"、"啊"、笑声、犹豫停顿这些口语现象。中英混合、支持情感控制（ $laugh$ 、 $uv_break$ 等 tag）。架构：AR TTS，用 Vocos 作 pretrained vocoder，参考 fish-speech 的 GVQ audio tokenizer 思路（README 明说）。参数量官方未公开；训练数据量 100K+ 小时中英，开源 HF 版本是 40K 小时预训练模型（未经 SFT）。

Vocos vocoder 的价值 （见上图）------HiFi-GAN 那种 time-domain GAN vocoder 要一层层 ResBlock + transposed conv 把低时间分辨率的 mel 逐级 upsample 到高时间分辨率 waveform；Vocos 反其道而行------全程保持低时间分辨率 、ConvNeXt Block 堆栈出 magnitude + phase 后一次 iSTFT 直接出 audio。ChatTTS 用它替代 HiFi-GAN 的好处：少一堆 upsample 卷积、CPU 推理明显更快；缺点：phase 建模比 time-domain 直出略弱、极端场景重建质量下降。跟 §三 Kokoro 用的 iSTFTNet 同源思路------都是"频域直预测 + 一次 iSTFT"路线，只不过 Vocos 用 ConvNeXt Block、iSTFTNet 用 HiFi-GAN-style 残差 + iSTFT 混合。

GVQ audio tokenizer + AR LM 结构 ------GVQ = Grouped Vector Quantization，把 24 kHz waveform 分组 codebook 量化成离散 audio token（跟 EnCodec 的 RVQ 逐层残差量化不同 ------RVQ 逐层残差、每层量化前一层的残差；GVQ 把 codebook 分若干组、每组并行独立量化，训练效率高、组间冗余更大）。ChatTTS 主体是一个 GPT-style Transformer，input 是 text token + audio token 混排、AR 逐 token 生成 audio token；最后 Vocos 把 audio token 还原成 waveform。这是典型的 Gen 5 codec-LM 架构在端侧的落地 ------比 VITS 系的 end-to-end 复杂，但支持 tag 控制（直接把 $laugh$ 、 $uv_break$ 作为 special token 训进去，推理时 prompt 里插 tag 就能触发对应语气）。跟 XTTS-v2 那种通用 codec-LM 相比，ChatTTS 参数量更小且优化对话/口语场景、不做 zero-shot cloning。中文场景是 ChatTTS 的核心优化语言，口语化和方言支持强于英文。

4.2.2 OuteTTS（OuteAI 2024）

仓库 https://github.com/edwko/OuteTTS 。LLaMA-based AR TTS ------底层直接吃 LLaMA 系列 checkpoint 出 audio token、neural codec（WavTokenizer 或 SNAC）还原成 waveform。主流版本是 OuteTTS-1.0-0.6B 和 Llama-OuteTTS-1.0-1B （参数量 0.6B / 1B），早期还有 0.2 / 0.3 版本。注意 ------OuteTTS 参数量在 0.6B-1B 级、量化后仍是百 MB 级 checkpoint，不属于 §4.4 那种 20-40M 极致轻量档，但相对 Gen 5 XTTS-v2 (1.87 GB) 或 CosyVoice 2 已经是"轻量 LLM-TTS"路线。

跟 ChatTTS 的对比 ------都是 codec-LM 家族（text token + audio token 混排、AR 生成），核心差别在底层 LLM：ChatTTS 自训 GPT-style Transformer + Vocos，OuteTTS 直接吃 LLaMA + llama.cpp 生态。OuteTTS 的优势 ：(1) LLM 生态成熟（HF transformers / llama.cpp / GGUF 量化一条龙）、(2) prompt engineering + speaker cloning 走 LLM 那一套熟路子；代价：参数量比 ChatTTS 大一档、对话感/口语 tag 支持不如 ChatTTS 专门优化。

4.3 流式派：从 Gen 5 大模型改流式

4.3.1 Streaming CosyVoice 2（阿里 2024）

论文 https://arxiv.org/pdf/2412.10117 、仓库 https://github.com/FunAudioLLM/CosyVoice 。Chunk-aware causal flow matching ------CosyVoice 论文里明确讨论了流式设计，把大模型的 flow matching 改成 chunk-by-chunk 处理，做到边收 text 边合成。首包延迟 ：普通流式场景 300-500 ms、极致优化的双流式 （text 输入流 + audio 输出流并行）方案最低可到 150 ms，适合直播和对话式 agent。中文是 CosyVoice 系列的核心优化语言 ------方言/口语场景表现强于同参数量的英文优先模型。这是"真流式"------模型训练时就加了 causal mask、chunk-wise 是原生支持，不是"整段切 phrase 拼接"那种伪流式。

论文架构三大模块（见上图）------

(a) Supervised Speech Tokenizer：在 SenseVoice-Large ASR encoder 的中间层插一个 FSQ（Finite Scalar Quantization）量化器，拿到 25 Hz、每帧 25-dim 的 semantic token。这个 tokenizer 是 supervised trained、监督信号来自 ASR loss，出的 token 天然带 phonetic + prosodic 信息，比无监督 codec（EnCodec / SoundStream）的 token 更贴近语义
(b) Unified Text-Speech LM：text token 和 speech token 混合排在同一序列，一个 Transformer 同时做 AR next-token prediction。同一 model 既支持 non-streaming（先收全 text 再出 speech）也支持 streaming（chunk-wise 交替），靠 attention mask 控制
© Chunk-aware Causal Flow Matching：speech token 到 mel 的解码用 flow matching，但改成 causal（Causal Transformer + Causal Conv-Transformer UNet）且 chunk-wise，能边收 speech token 边出 mel、边喂 vocoder 出波形。首包 300-500 ms 就靠这个 chunk 结构

跟 CosyVoice v1 的差别 ------v1 是标准 non-causal flow matching，必须全 speech token 攒齐才能出 mel；v2 加入 causal masking + chunk 结构，同一 checkpoint 兼容 streaming 和 non-streaming，streaming 首包降到 300-500 ms。这也是从 Gen 5 大模型骨架直接改流式的代表------不重训一个新模型，是原骨架加 causal + chunk trick。

4.3.2 Streaming F5-TTS / Kokoro-Stream（伪流式）

F5-TTS 仓库 https://github.com/SWivid/F5-TTS 、Kokoro 社区 streaming fork 分散在多个仓库。都是在 Gen 5-6 骨架上加流式改造 、不是全新架构------属于"伪流式"：模型本身是 non-causal、社区靠切分 + rolling window 硬造 streaming 效果。

F5-TTS 底层 ------DiT-style non-autoregressive flow matching TTS（Chen et al. 2024，arxiv 2410.06885），原始设计是 non-causal------需要看到完整 text 才能出 mel，不是天然 streaming 友好。社区 streaming 分支的做法：causal masking + rolling context window + chunk-wise flow step，但质量相对 non-streaming baseline 有明显损失（社区实测 MOS 有 0.1-0.3 分下降、官方未 benchmark）。

Kokoro-Stream ------Kokoro 本身是 non-streaming 结构（Length Regulator 需要看全 text 决定每音素 duration），社区 fork 走的路子是把整段 text 切成 phrase chunk，每 chunk 独立跑一次完整 Kokoro pipeline、把 chunk waveform 依次拼接。优点是不用改模型；缺点是 phrase 边界会有轻微 discontinuity、韵律连贯性受影响。真正 chunk-aware streaming 要重训一个 causal 版本 Length Regulator，社区还没开源实现。

4.4 极致端侧派 · KittenTTS

更小、更聚焦------参数量压到 15-80M、量化后 25-80 MB checkpoint，目标是耳机侧和嵌入式芯片。质量在英文短句场景可用，长句、多说话人、跨语种表现下降。

KittenTTS （2024-2025，仓库 https://github.com/KittenML/KittenTTS ）------基于 VITS 极致简化 ：砍 Text Encoder 层数、hidden dim 从 512 降到 128、去掉 Flow 层。三个版本 ------ kitten-tts-nano 15M / 56 MB (fp32)、int8 量化后 25 MB ；micro 40M / ~41 MB ；mini 80M / ~80 MB，目标是 iOS / Android 手机 App 本地 TTS。英文单说话人质量可用、跨域和长句崩得快，属于"够用就行"的取舍。

五、结构性短板

Gen 6 用蒸馏 + 量化把 TTS 塞进端侧，但仍有五个绕不开的短板：

没有 zero-shot 克隆------端侧模型基本都是 fixed voice pack。想克隆特定人的音色，仍要回 Gen 5（XTTS / GPT-SoVITS / CosyVoice）或做 voice fine-tune（Piper 每个 voice 训一次）
韵律 / 情感表达力受限------合成数据训 student 的机制让 student 学的是 teacher 的"高频常见模式"，对罕见情感、极端韵律的表达明显弱于原大模型
多语种覆盖不均------英文最好、中文次之、日/西/法可用、小语种基本没戏。语种扩展需要单独训练每个 voice
量化到 int4 有明显质量损失------fp16 无感知损失、int8 略有金属感、int4 高频细节明显丢失。耳机侧真塞进 int4 要接受质量下降
首包延迟仍是瓶颈------即使 CPU 实时（RTF < 0.5），首包也要 200-500 ms。真做到 <100 ms 要 streaming inference + KV-cache 优化，社区仍在推

下一代方向------现在（2025-2026）业界看到两条前沿路线：

多模态融合：视频驱动 TTS（嘴型 + 语音同步）、情感理解 + 合成一体化。Meta SeamlessM4T、Google AudioPaLM、Kyutai Moshi 是代表
实时对话式：跳过文本中间态、语音到语音直出。GPT-4o audio、Moshi、Sesame-CSM 是代表

六、数据流每一步的形态

Gen 6 (Kokoro 系) 单次推理数据流：

步骤	数据形态	说明
Text	`str`	目标文本
G2P (内置轻量)	`List[int]`, shape `(L,)`	音素 ID 序列
Voice pack lookup	`Tensor`, shape `(d,)`	fixed voice 的 style embedding（d 官方未公开）
Text Encoder + PL-BERT	`Tensor`, shape `(L, d)`	text hidden
Duration + Prosody Predictor	`Tensor int64` 时长 + `Tensor` pitch/energy curve	帧级 prosody
Alignment + Length Regulator	`Tensor`, shape `(T, d)`	T = sum(duration)
Decoder (iSTFTNet + AdaIN 注入 style)	`Tensor`, shape `(N,)`	N = T × hop
输出波形	`int16 PCM`, 24 kHz mono	固定音色说目标文本

承上启下 ------Gen 6 把 TTS 塞进了手机 / 耳机 / 嵌入式的端侧约束，六代演进走完 "波形拼接 → 参数合成 → 神经声码器 → 端到端 → 大模型 zero-shot → 端侧蒸馏" 的完整路径。下一篇 part 7 把六代模型放到同一套无参考 MOS 打分器下横评一遍，把每代的定位、trade-off、选型建议做定量对比。