你想给桌面应用加一个朗读功能，过去常要为不同语音模型分别准备 Python 服务、转换脚本和加载方式。模型换一个，整套接线可能也要重来。audio.cpp Release 0.4 想把这些零散环节收进同一套本地工具链：新增 Higgs Audio v3 与 Fish Audio S2 Pro 两个重点 TTS 家族，并让已发布的全部模型家族都能通过 GGUF 加载。
TTS 是 Text-to-Speech，也就是把文字变成语音；它与把语音转成文字的 ASR/STT 方向相反。需要先说明的是，本次发布信息和性能数字都来自项目作者的一篇 Reddit 帖子，尚无正式发布页、模型原机构或第三方测试提供独立印证。
两个新声音，接进同一套插座
audio.cpp 是一套 C++/GGML 本地语音栈——用 C++ 应用和轻量张量计算库，在用户自己的设备上运行语音模型。它面向希望离线合成或识别语音的开发者，减少对云端接口和独立 Python 服务的依赖。
据作者介绍，Release 0.4 新增 Higgs Audio v3 TTS 4B、Fish Audio S2 Pro，以及用于语音识别的 Voxtral Realtime ASR。项目现在共支持 35 个模型家族。标题强调的“两大家族”指前两个重点 TTS 新增，并非这次更新的全部内容。
本刊 7 月 10 日报道过 audio.cpp 扩充 ASR/STT 与流式识别，当时重点是“边听边出字”。这次项目把重心继续推向文字转语音，同时统一底层模型加载。
关键是 GGUF。它是 llama.cpp 生态常见的模型文件格式，用一份文件统一保存模型权重和运行所需的元数据。可以把它理解为统一规格的行李箱：不同模型仍装着不同东西，但工具不必再为每一种箱子单独设计开锁方式。作者称，audio.cpp 已发布的全部模型家族如今都支持 GGUF，并提供可直接使用的 GGUF 包。
跑得多快，要看测试边界
作者在 RTX 5090 上使用 CUDA Q8 GGUF 测试。Q8 量化大致是用 8 位数字保存模型权重，以减少内存和显存占用；它通常比更低位量化保留更多精度，压缩幅度也相对较小。
在预热后的连续请求中，Higgs Audio v3 TTS 4B 的生成速度约为实时的 8.8 至 10.1 倍；一次生成超过 6000 字符的长文本时约为 8.5 倍。因此，“10x real time”更接近特定条件下的区间上限，不能理解为所有场景都稳定达到 10 倍。
Fish Audio S2 Pro 在同一测试条件下，预热后约为实时的 3.1 至 3.4 倍，长文本约为 3.3 倍。作者同时称，目前实现只是对框架模板的朴素适配，后续性能仍可能变化。Voxtral Realtime ASR 的离线处理约为实时的 15.7 倍；流式场景的 TTFT 约为 171 毫秒。TTFT 指首次输出出现前的等待时间，可近似理解为系统听到声音后，多久开始吐出第一段结果。
统一格式为什么值得关注
单个模型跑得快固然醒目，但更重要的变化是部署路径趋于一致。开发者可以在同一套 C++/GGML 工具链中接入更多合成与识别模型，不必让每个模型各带一套读取和转换流程。这还不是“一键安装”，却让本地语音能力更接近可复用的应用组件。
量化也开始带来实际收益。按作者的测试，相较 16-bit GGUF，Q8 在部分路径中最高提速约 1.5 倍，并将峰值显存最高降低约 37%。但作者明确表示，效果取决于模型和执行路径，Q8 并非处处有效，音质影响也因模型而异。调整 chunk size——每次处理的数据块大小——并缩短 reference audio（供模型模仿的参考音频），可让 Qwen3-TTS 等部分模型最高再提速约 2 倍；这里同样只是最佳情况。
Release 0.4 还新设 community models 区域，纳入 OuteTTS TTS 与 VieNeu-TTS-v3。这个区域用于仍在成熟中的社区移植，审核门槛低于核心框架，因此不应与重点支持的核心新增等量齐观。
局限与未知
- 所有发布事实和性能数据均为同一作者自测，测试限定于 RTX 5090、CUDA Q8 GGUF 和当前实现，不能外推到其他硬件或设置。
- 材料没有提供音质基准、盲测或误差指标，因而无法验证“高质量 TTS”的主观评价，也无法判断 Q8 对各模型音质的具体影响。
- Fish Audio S2 Pro 的实现仍较初步，社区模型的审核门槛也更低；两类实现后续都可能继续变化。