Breeze TTS 2 本地安装指南

在程序文件夹中打开终端，输入：

.\breeze-server.exe breeze-tts-2-q8_0.gguf --host 127.0.0.1 --port 8088 --webui

找不到 cl、cmake 或 ninja：确认安装了对应组件，并使用 x64 开发者终端。提示缺少 third_party/ggml：在仓库目录执行 git submodule update --init --recursive。其他编译或运行错误请保留完整日志，对照项目构建文档；本文尚未验证排错结果。

本轮从 GitHub 重新下载 73,939,562 字节程序包，从魔搭重新下载 3,568,844,480 字节 Q8_0，完整校验后放入新目录。没有复制旧程序包、旧模型、缓存权重或转换工具。启动时排除 Python、Conda 等路径，只用 Windows 自带工具和下载文件。

已验证完整网络下载、解压、首次启动、网页生成、WAV 下载，以及缺程序、缺模型、模型未下载完整、端口占用时的提示。系统原有显卡驱动；未在重装系统或虚拟机中测试，也未运行 Mac、CPU、Q4_K、F16 或长篇配音。

Q8_0 SHA-256：a02bcc4b69b0601032727f8040c4942149b1b73aa0f69022fe5aaa6a8f0ef879

这期从自己的录音中截取 6.55–15.50 秒，得到 8.95 秒的参考片段，转为 24 kHz 单声道，保存为 ref.wav。ref.txt 写完整、逐字一致的文本，包括重复和口头语。换成自己的录音时，也必须一起更换逐字稿。

参考音频和逐字稿先复制到纯英文工作目录，例如 D:\BreezeWork\。该项目曾在含中文路径时遇到进程静默退出、只留下空 WAV；这是当时的排错经验，不能据此认定所有中文路径都会失败。私人原始录音与个人目录不随本文提供。

字幕保留原稿；另外准备 lines_say.json 给 TTS 念。一句一条，示例如下：

[{"id":"L01","text":"你好，这是我的第一段声音克隆配音。"}]

当时使用已配置好的独立 Conda 环境，解释器位于 envs\qwen3-tts\python.exe，加载魔搭下载的 BreezeBlue/Breeze-TTS-2 原版权重。环境名称是本机历史命名，实际运行的是 Breeze。项目自定义入口为 tools/audio/tts_clone.py，模型只加载一次，循环生成每句 WAV。

python tts_clone.py --repo D:\Breeze\breeze-tts --model D:\Breeze\Breeze-TTS-2 --lines lines_say.json --ref ref.wav --ref-text ref.txt --out vo_raw --seeds 42 --cfg 1 --eager --work-dir D:\BreezeWork\temp

先激活对应环境，在解压后的脚本目录运行。--repo、--model 和 --work-dir 是去敏公开版新增参数；示例盘符需改成自己的位置。可先加 --validate-only 检查输入，再去掉它正式生成。补一句用 --only L02；覆盖已有结果需明确加 --overwrite，或换输出目录。此命令不能粘到 GGUF 程序目录运行。原版安装和官方单句入口见官方 PyTorch 仓库。

这一期实际使用 eager 省显存路径。脚本传入 --eager 后，fast_all=False，不启用那组 CUDA Graphs / 编译加速。当时 TTS 约占 8 GB 显存，其他任务已经占了约 22 GB，因此没有选择快速路径。

同一个自定义脚本去掉 --eager，会设置 fast_all=True，启用 CUDA Graphs 和 torch.compile 相关快速阶段。脚本记录这台机器首次编译约 75 秒，缓存后准备约 20 秒，预热峰值约 26 GiB，之后约 8 GiB。这些是当时环境的记录，不是最低显存要求，也没有在本文重测加速倍数。

操作顺序：先保存并结束自己不需要的 GPU 任务，给首次编译、预热留足显存；先用一句短文本验证快速路径，再批量生成。显存不足、编译失败或结果异常时，加回 --eager 退回已用过的路径。不要只按预热后的占用估算所需显存。

注意两个不同设置：模型加载时的 attn_implementation="eager" 是 attention 实现；脚本的 --eager 控制是否关闭快速阶段。这个项目即使启用快速阶段，attention 参数仍然是 eager。

当时 Windows 快速路径的兼容配置是 triton-windows<3.5，并在导入 torch 前设置下面的环境变量，避开当时 static launcher 的 32 位整数溢出问题。该组合依赖当时的 PyTorch、Triton 与源码版本，不建议在新环境中盲目降级套用。

$env:TORCHINDUCTOR_USE_STATIC_CUDA_LAUNCHER = "0"

官方原版 infer.py 用 --fast-all 开启快速路径；本项目封装则默认开启、用 --eager 关闭。不要把两个入口的参数混用。官方当前说明可用于核对模式和环境要求，本文 26 GiB 是本机历史预热记录。

两组采样参数由 update_generation_config_for_breeze() 写入模型，项目脚本没有覆盖它们。克隆模式这期用 CFG 1.0；按描述设计音色的 Voice Design，或参考音频加语气指令的 Voice Direction，是另外的模式，不能把它们的 CFG 配置混为一谈。

准确的生成次数：所有句子先用 Seed 42 各生成一遍，不批量抽种子挑选。检查发现第 2 句漏读“五”，修改朗读文本后，仅这句用相同参数再生成一次。因此不是每句最终都只生成过一次。

字幕用原稿 lines.json，朗读用 lines_say.json。只把易误读的形式改成读音：GLM-5 →“GLM 五”，Harness² →“Harness 平方”，Gemini 3.5 →“Gemini 三点五”，64.2 →“六十四点二”；72.4、75.7 同理。

第 2 句第一次漏读“五”。后来加逗号分隔型号与数字：“原本，GLM 五，只有六十四点二分，Gemini 三点五 Flash，有七十二点四分。”保留 Seed 42 和其他参数，只补这句，再核对。

当时逐句用 faster-whisper large-v3，设置 language=zh、beam_size=5，提示词加入 Google、GLM、Gemini、Harness、Codex，辅助检查漏字。另用 Whisper medium 的 word_timestamps 对齐画面关键词。转写和时间戳都可能出错，最终仍需对照原文试听与校正。

这里加快的是成品语速，不能算作模型推理提速。这期对每句原始 WAV 使用 FFmpeg 的 atempo=1.25，变速后再裁首尾静音。只做变速的命令示例：

ffmpeg -i L01_s42.wav -af "atempo=1.25" -ar 24000 -ac 1 -c:a pcm_s16le L01_fast.wav

项目裁静音的方法：在归一化到 −1～1 的浮点波形中，找到绝对振幅大于 0.012 的首、尾采样点，开头多留 20 ms、结尾多留 80 ms。这是这期的阈值，轻声或气声可能被误裁；处理后需检查起音和尾字，不能作为所有声音通用值。

公开版在脚本目录运行下列命令，会生成 prepared/vo/ 和 prepared/plan.json；再次运行请换新的输出目录。可加 --bpm 80 把句子起点放到后续节拍，也可加 --bgm D:\MyAudio\licensed-bgm.wav 使用自己的音乐。

python timeline.py --lines lines_say.json --input vo_raw --out prepared --seed 42 --speed 1.25 --gap 0.25

处理后的每句按 BGM 的小节、节拍安排起点，画面跟随实际配音时长。逐字时间戳要对应最终音频；若沿用变速前的时间戳，需要按变速比例及裁切偏移换算。

• 逐句统一音量：mix.py 对绝对振幅大于 0.01 的样本计算 RMS，再缩放到 0.12；并非对整句所有静音一起计算。
• BGM 自动压低：有人声时降低 7 dB，压低的时间常数 80 ms，恢复的时间常数 400 ms。数值取自这期时间轴与混音脚本。
• 最后统一响度：loudnorm=I=-14:TP=-1.5:LRA=11。这是目标值，当时成片记录为约 −14.7 LUFS、峰值 −1.4 dBFS；后者是数字峰值读数，不能直接当作真峰值 dBTP。

python mix.py --plan prepared\plan.json --out final_mix.wav

公开版相对音频路径以 plan.json 所在目录为准，没有 BGM 也能运行，输出是 48 kHz 双声道 PCM WAV。短音乐会循环，需自行检查循环点；原项目的音效、音乐剪段和画面事件未打包。

混完之后再测量、试听，避免削波、背景音乐盖住人声。RMS 对齐、BGM 压低和整体响度标准化分别解决不同问题，不是把同一个“音量”重复调三遍。