Piper：无需 GPU 也能存在的 TTS 模型
几乎所有声音克隆模型都假定你有 GPU、充足的显存，可能还得有网络连接，以便在必要时调用托管 API。Piper 完全不作这些假设。它从一开始就被设计为仅凭 CPU 在树莓派这类配置有限的硬件上实时运行——无需云端往返、无需 CUDA，也无需等待。如果你的项目真正的限制是“它必须在一块没有网络连接的小型开发板上运行”，那么 Piper 是少数专门为这种现实打造，而不是事后勉强适配的开源 TTS 方案之一。
Piper 是什么？
Piper 是由开发者 Michael Hansen 在 Rhasspy 语音助手项目下创建的开源神经文本转语音系统，首次提交可追溯至 2022 年 11 月。每个 Piper 声音都是一个导出到 ONNX 运行时的 VITS 模型，并配有一个小型 JSON 配置文件；在神经网络生成实际音频之前，espeak-ng 负责将输入文本转换为音素。正是紧凑、针对 ONNX 优化的模型与轻量音素转换器的结合，让 Piper 在完全没有专用图形处理能力的硬件上，既能生成自然的语音，又能真正快速运行。
它为何如此轻量
典型的 Piper 声音模型约有 1500 万参数——只是其他地方介绍的大多数克隆型模型的一小部分——而中等质量声音可以封装成一个仅数十兆字节的 ONNX 文件。声音分为四个质量档位：x_low 和 low（16kHz 输出）追求最小体积与最快生成速度；当音质比纯粹速度更重要时，则可选择 medium 和 high（22.05kHz）。这种分级设计让你可以依据具体硬件限制，有意识地在质量与体积之间取舍，而不是无论部署到什么设备，都只能受制于一个固定的模型大小。
速度数据也直接印证了“超轻量”的定位：Piper 仅使用 CPU 就能在 Raspberry Pi 4 或 5 上实时合成语音，在现代桌面 CPU 上的运行速度则约为实时速度的十倍——快到 GPU 加速不只是可选项，而是从根本上就不属于它的设计。
语言与声音覆盖范围
Piper 提供 100 多个预训练声音，覆盖 35 种以上的语言，包括英语、德语、法语、西班牙语、意大利语、葡萄牙语、荷兰语、波兰语、俄语、中文、阿拉伯语、土耳其语和乌克兰语等，全部公开托管在 Hugging Face 上。声音文件采用统一的命名规则（<language>_<region>-<name>-<quality>），无需每次翻查文档，就能直接识别并切换特定语言、地区口音和质量档位。
Piper 的实际应用场景：Home Assistant 及其他领域
Piper 的实际应用恰好集中在其轻量设计所面向的场景：家庭自动化、离线语音助手、无障碍工具，以及那些比起录音室级声音精致度，更重视延迟、隐私与零持续托管成本的嵌入式信息亭。它是 Home Assistant 原生且官方支持的文本转语音选项，通过 Wyoming 协议通信，安装后即可被自动发现，默认声音为 en_US-lessac-medium——这充分说明，该项目已在本地运行、注重隐私的智能家居配置中获得了深度采用，而非主要用于内容制作。
一个值得了解的维护细节
Piper 的原始仓库已于 2025 年 10 月归档，活跃开发此后转移到由 Open Home Foundation Voice 团队维护的 fork。这在实践中有两个重要影响：第一，如果你正在参考较早的教程或文档，请确认其指向的是已经归档的原始仓库，还是仍在积极维护的 fork。第二，许可证也随之发生了变化——原项目采用 MIT 许可证，而当前开发 fork 则以 GPL-3.0 发布；如果你的计划包含商业用途，两者的条款存在实质差异。在围绕 Piper 构建产品之前，请先确认你所部署的具体版本究竟适用哪个仓库和许可证。
开始使用 Piper
- 在虚拟环境中通过 pip 安装。
python3 -m venv .venv && source .venv/bin/activate && pip install piper-tts可以避免与系统管理的 Python 安装发生冲突；这种冲突尤其是 Raspberry Pi OS 上常见的安装难题来源。 - 下载声音模型及其匹配的配置。 每个声音都需要 Hugging Face 声音仓库中的
.onnx模型文件和对应的.json配置文件——两者都要下载，并确保正确配对。 - 确认说明所引用的仓库。 考虑到 2025 年发生了 fork，请核实指南针对的是原始
rhasspy/piper项目，还是当前的OHF-Voice/piper1-gplfork，因为两者的设置细节可能略有不同。 - 先进行一次快速合成测试。 Piper 的 CLI 可以用一条命令从文本字符串生成 WAV 文件；在把它接入更大项目之前，这是确认模型与配置文件是否正确配对的最快方法。
- 如果目标平台是 Home Assistant，就使用官方 add-on。 与其手动将 Piper 集成进智能家居配置，不如使用官方 add-on，让它通过 Wyoming 协议自动处理发现与配置。
- 让质量档位匹配硬件，而不只是匹配理想。 在资源确实受限的设备上，x_low 或 low 质量声音可以保持较快的生成速度和较低的资源占用；medium 或 high 档位则留给性能余量稍多的硬件。
获得更好结果的技巧
- 除非有明确理由需要从源码构建，否则先从 pip 安装路径开始。 根据社区在这些平台上的广泛测试，这是在 Raspberry Pi OS、Ubuntu 和 Windows WSL 上更快捷、更可靠的方式。
- 不要自动默认使用最高质量档位。 x_low/low 档位之所以存在，正是因为许多嵌入式场景不需要 22.05kHz 输出——如果你部署到资源真正受限的硬件上，请先测试较低档位。
- 把 Piper 看作解决部署限制的工具，而不是解决内容限制的工具。 如果你优先需要富有表现力和情感的旁白，更大的克隆型模型会更适合；Piper 的全部价值主张，就是在完全无法运行这些更大模型的硬件上提供可靠性与较小体积。
- 商业部署前检查目标仓库的许可证。 鉴于原始 MIT 许可项目与当前 GPL-3.0 fork 之间的分化，这一点确实非常重要，尤其对商业产品而言，不应凭想当然判断。
- 专门针对智能家居项目采用 Wyoming 协议集成路径。 如果你构建的是 Home Assistant 或类似语音助手生态相关的项目，使用既有的 Wyoming 集成会比自定义实现更易维护。
Piper 与其他轻量、CPU 友好型模型的比较
| Piper | Kokoro-82M | 典型 GPU 克隆模型 | |
|---|---|---|---|
| 参数量 | ~15M | 82M | 350M–1.7B+ |
| 仅靠 CPU 运行 | 是，设计目标如此 | 是，原生支持 | 最多只能算可选，强烈建议使用 GPU |
| 在 Raspberry Pi 上实时运行 | 是 | 并非主要设计目标 | 否 |
| 声音克隆 | 否，使用固定声音库 | 否，使用固定声音库 | 是，通常是核心功能 |
| 语言 | 35+ | 8 | 各不相同，在如此广泛的覆盖下通常更少 |
| 最适合 | 嵌入式设备、智能家居、离线信息亭 | 成本敏感的服务器端旁白 | 富有表现力的克隆、对话、制作级内容 |
Piper 的特定定位处在部署光谱中设备最小、资源最受限的一端——如果说 Kokoro 是为“在 CPU 服务器上低成本运行”而打造，那么 Piper 就是为“在可能连风扇都没有的设备上运行”而生。
常见问题
Piper 真的完全不需要 GPU 吗？
没错。Piper 在设计上就是纯 CPU 模型，不使用任何显存——它专门用于在 Raspberry Pi 等嵌入式硬件上离线实时运行，这正是它所面向的使用场景。
Piper 能克隆特定人物的声音吗？
不能。Piper 使用覆盖 35 种以上语言的 100 多个固定预训练声音，而不是从参考音频进行零样本声音克隆——如果克隆是你的核心需求，其他模型会更合适。
Piper 仍在积极维护吗？
是的，不过开发工作已从原始 rhasspy/piper 仓库（于 2025 年 10 月归档）转移到 Open Home Foundation Voice 团队维护的 fork，后者使用不同的许可证发布（GPL-3.0，而非原项目的 MIT）。
Piper 实际需要什么硬件？
它仅使用 CPU 就能在 Raspberry Pi 4 或 5 上实时运行，在典型的现代桌面 CPU 上，速度约为实时速度的十倍——任何环节都无需 GPU 或 CUDA 设置。
Piper 可以免费用于商业用途吗？
这取决于你使用的仓库与版本——原项目采用 MIT 许可证，但积极维护的 fork 使用 GPL-3.0，后者带有不同的义务。商用前请检查所部署具体版本的许可证。
在浏览器中把文字转换为语音
如果你希望完成相近的“文字 → 单人语音”流程，可以使用 Echora 的文字转语音。输入最多 5,000 个字符，选择内置音色或已保存的自定义音色，按需添加支持的表达标签并调整语音稳定度，然后试听结果并下载生成的 MP3。