Audio8_TTS

项目定位

Audio8_TTS 是 Edge0-AI（Audio8）发布的紧凑型多语言 TTS 模型仓库，主打「小体量 + 零样本音色克隆」：主模型 0.6B 参数（不含 codec），另有 0.1B 预览版，官方口号是 SOTA-Class TTS at Compact Scale。仓库提供 Preview 权重说明、Hugging Face 远端代码、推理脚本，以及一条独立的 SFT 微调流水线。

对个人开发者最有价值的两点：

1. 显存/内存友好——0.6B 主模型意味着单卡 12–16G 消费级显卡就能跑起来，比动辄 3B+ 的开源 TTS 更亲民；
2. CPU 也能部署——onnx_runtime/ 提供权重 INT4 + 激活/KV/Codec FP16 的纯 CPU 部署，Apple M2 实测在线会话约 1 GiB 内存，不需要 PyTorch 与 Transformers。

架构要点

采用受 Fish Audio S2 Pro 启发的 DualAR 双自回归架构：

Slow AR 逐帧预测语义 token，Fast AR 在 Slow 隐状态与前序 codebook 条件下补全该帧的 codec 码本；两侧均使用静态 KV cache。权重自带神经 codec，参考音频编码与波形解码不需要额外模型，这一点对部署链路简化很大。

上手体验

安装门槛不高：Python 3.10+，推荐 CUDA 显卡。

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

从 Hugging Face 下载 checkpoint 放到 model/audio8_tts_0_6B_preview/，或直接用 --model 传 HF model id。推理命令很直观：

# 零样本克隆（参考文本需与参考音频内容一致）
python audio8_tts_infer.py \
  --text "Welcome to audio8_tts." \
  --reference-audio examples/reference.wav \
  --reference-text "Transcript of the reference recording." \
  --output outputs/clone.wav

# 不带参考音色的普通合成
python audio8_tts_infer.py --text "This utterance does not use a reference voice." \
  --output outputs/no_reference.wav

批处理走 JSONL manifest，每条是一个独立 JSON，相对音频路径以 manifest 所在目录解析；输出 manifest.jsonl 与 failures.jsonl，已存在的 WAV 默认跳过（除非 --overwrite）。这个设计适合先把大批文案跑一遍试听，再挑问题样本重跑。

实测要注意的坑：

• 官方明确建议单次输入控制在 150 字符以内，超长文本质量下降明显，需要自己切句；做长文朗读（有声书、播客）时务必加一层分句 + 拼接逻辑，否则会出现尾音截断或语调漂移。
• Preview 版语言覆盖刻意收窄，最佳效果限定在 11 种语言：粤语、中文、荷兰语、英语、法语、德语、意大利语、日语、韩语、波兰语、西班牙语。中文方言与更多语种要等后续版本，急着上多语种产品的话这块要留风险预算。
• 零样本克隆的效果高度依赖参考音频质量：参考文本必须与音频逐字一致，背景噪声或口音重的参考会直接拉低相似度与稳定性。
• CPU ONNX 路径在注册音色时会先释放在线会话再加载 codec encoder，用来压低峰值内存——这个取舍说明它在内存上是真的紧张，边缘设备部署要照着它的加载顺序来。

适用场景

• 小语种/多语种的有声内容生成（11 语种覆盖内）
• 需要克隆特定音色的配音、播客片头、客服语音
• 想在有 GPU 的服务器上自建 TTS 服务，替代按量计费的云厂商 API
• 端侧或纯 CPU 盒子上的离线语音合成（走 ONNX INT4 + INT8 0.1B 路线）
• 作为 TTS 微调实验底座：仓库自带独立 SFT pipeline，可用自有数据做音色/风格适配

不太适合：需要 60+ 语种、要求极低延迟流式对话（虽然 ONNX 版有 streaming PCM，但 Preview 质量优先于速度）、或者没有 CUDA 环境又想要 0.6B 全精度效果的情况。

二开建议

1. 长文本切分：围绕 150 字符上限写一个按标点 + 语义的分句器，配音色一致性与停顿参数，再拼接输出；这是落地长音频最必要的一层。
2. 服务化：仓库已给 SGLang Omni Serving 与 ONNX 本地 web/HTTP 服务两条路。高并发走 SGLang + 静态 KV cache 复用；成本敏感或私有化走 ONNX CPU 版。
3. 音色库管理：把 reference_audio + reference_text + 注册后的 speaker 表示做索引，避免每次请求重新编码参考音频（注册流程本身较贵）。
4. 质量门禁：在批处理层接 ASR 回译 + 说话人相似度打分，自动筛掉 failures.jsonl 之外的「能跑但不像」样本，比人工试听省力得多。
5. 量化再压：已经有 INT4/INT8 官方产物，若面向移动端可在此基础上尝试 codec 侧进一步量化，注意 44.1 kHz 采样率对解码端算力的要求。
6. 合规：声音克隆属敏感能力，Apache-2.0 只解决代码授权，音色本身需获得说话人授权，商用前建议在服务层加显式同意与留痕机制。

一句话总结

把 0.6B 做到能克隆、能多语种、还能纯 CPU 跑，Audio8_TTS 在「体积/效果/部署难度」三角上是目前少见的平衡点；Preview 的语种与 150 字符限制是主要门槛，适合有能力自建分句与质检管线的团队，而不是开箱即用的成品服务。