KaniTTS：在勉强算得上 GPU 的显卡上实时生成语音
大多数现代语音 LLM 式 TTS 模型都默认你有一块真正可供使用的 GPU——这个要 8GB，那个要 16GB。NineNineSix.ai 推出的 KaniTTS 则建立在一个小得多的前提上：3GB 显存，也就是消费级 RTX 3060 或 4050 能够腾出的余量，足以实时生成自然的语音。这种效率并不是以阉割功能为代价，而是来自专门打造的紧凑架构，从一开始就避免携带模型不需要的负担。
什么是 KaniTTS？
KaniTTS 是一个建立在两阶段流水线上的开源文本转语音系统：骨干大语言模型根据文本生成压缩的 token 表示，再由高效的神经音频编解码器迅速将这些 token 扩展成实际波形。其骨干是 LiquidAI 的 LFM2，一个拥有 3.5 亿参数、专门因其效率优于能力相当的标准 Transformer 而被选中的模型；音频端则与 NVIDIA 的 NanoCodec 配对。这种“语音即语言”的理念——像聊天模型预测词语一样，把音频生成当作 token 预测任务——直接受到 Orpheus TTS 和 Sesame CSM 的启发，但 KaniTTS 将同样的核心思想压缩到了比两者都小得多的资源占用中。
KaniTTS 的功能优势
- 真正低的显存要求：Kani-TTS-2 版本最低只需 3GB 显存即可运行，可兼容入门级消费类 GPU，无需专用工作站显卡。
- 生成速度快：实时因子约为 0.2，也就是说大约 10 秒的音频可在约 2 秒内生成；在流式模式下，文档还记录了低于 300ms 的首个音频块延迟。
- 通过说话人嵌入实现零样本声音克隆：Kani-TTS-2 版本只需一小段参考音频，就足以提取声音特征并立即应用，无需进行微调。
- 多个语言检查点和多说话人支持：专用模型变体分别覆盖英语、阿拉伯语、韩语及其他语言，而不是让一个模型勉强兼顾所有语言。
- Apache 2.0 许可：无需另行签订协议即可用于商业用途。
- 通过 vLLM 提供生产级服务：开箱即用的 OpenAI 兼容 API 服务器，适合希望像部署其他基于 LLM 的服务一样部署该模型的团队。
两阶段流水线如何实现这种效率
效率方面最核心的决定是选择 LFM2 作为骨干，因为 Liquid Foundation Models 的设计目标就是比能力相近的传统 Transformer 在计算上更加精简——当整体目标是尽量减少资源占用，而不是最大化原始容量时，这一点具有实质意义。先通过这一轻量骨干生成压缩的 token 表示，再交给 NanoCodec 快速扩展成波形，可以避开由大规模语言模型直接生成音频波形所带来的更高计算开销。它采用的是其他语音 LLM 系统也在使用的广义两阶段逻辑，但每一阶段的组件都是特意根据低占用来选择，而不是单纯为最大输出质量而优化。
训练数据也体现了对适用效率的同样重视：许多 TTS 模型使用有声书式、正式朗读的语料库训练，而 KaniTTS 的数据来自 Emilia（LAION 推出的大型多语言情绪标注数据集）和 Expresso-Conversational（自然对话录音）等来源。这也是其输出往往更像轻松交谈，而不是旁白者逐段朗读的部分原因——尤其适合助手式和对话式使用场景。
KaniTTS 入门
- 安装软件包并锁定所需的 transformers 版本。 先运行
pip install kani-tts，再运行pip install -U "transformers==4.57.1"——为了兼容 LFM2，必须锁定这个特定版本；文档指出，跳过这一步会导致加载失败。 - 从 Hugging Face 加载特定语言的检查点。 英语使用
nineninesix/kani-tts-400m-en，其他受支持语言则使用相应的检查点（阿拉伯语、韩语等都以独立专用模型提供）——应根据目标语言来选择，而不要假设一个检查点可以覆盖所有语言。 - 用几行代码生成音频。 先执行
from kani_tts import KaniTTS，然后运行model = KaniTTS('nineninesix/kani-tts-400m-en')和audio, text = model("Hello, world!")即可直接得到波形；model.save_audio(audio, "output.wav")会将其写入磁盘。 - 使用
kanitts-vllm仓库提供生产规模的服务。 这个独立项目（GitHub 上的nineninesix-ai/kanitts-vllm）将模型封装在带有 OpenAI 兼容端点的 FastAPI 服务器中，底层由 vLLM 异步引擎和 KV 缓存优化提供支持——这是文档针对本地测试以外场景给出的路径。 - 核对具体部署路径的硬件要求。 核心模型可在 3GB 显存上轻松运行，但基于 vLLM 的生产服务器文档建议使用 CUDA 12.8+ 环境，并配备 12GB 或更多显存，以便为规模化运行留出充足余量——在假定最低数字适用于所有场景前，先确认哪种配置符合实际用例。
- 尝试 GGUF 量化版本或 ComfyUI 节点，以使用其他工作流。 社区同时维护了基于 llama.cpp 的部署方案和基于节点的创作流水线；如果其中一种比基础 Python 软件包更适合现有工具链，就可以选用。
获得更好结果的技巧
- 让检查点匹配目标语言，不要默认使用英语。 KaniTTS 为不同语言提供专用模型，而不是一个通用的多语言检查点；为内容使用正确模型的效果，会优于把非英语文本强行输入英语调优模型。
- 多使用自然的对话式措辞，而不是正式旁白。 由于训练数据侧重对话，KaniTTS 在助手式或对话内容上的表现通常最自然，并不适合被要求演绎戏剧化、正式朗读式的文稿。
- 如果需要声音克隆，请明确使用 Kani-TTS-2。 通过说话人嵌入实现的零样本克隆是这一特定版本的功能——如果项目需要复现某个具体参考声音，请确认使用了正确的检查点。
- 结束本地实验后，转向 vLLM 服务器路径。 基础 Python 软件包非常适合测试，但对于需要承载真实用户流量的场景，专用的
kanitts-vllm服务器才是文档所列、更稳健的路径。 - 遵守项目明确的道德使用限制。 KaniTTS 的许可条款明确禁止生成未经同意冒充他人的欺骗性内容，以及其他有害或非法用途——应把这些限制当作部署中的实际约束，而不是一扫而过的样板条款。
KaniTTS 与其他语音 LLM 式模型的比较
| KaniTTS | Orpheus TTS | Chatterbox | |
|---|---|---|---|
| 骨干 | LiquidAI LFM2（350M） | Llama-3B | 基于扩散 |
| 最低显存 | ~3GB（Kani-TTS-2） | ~8GB（GGUF 量化） | 更低，但这不是主要重点 |
| 实时因子 | ~0.2 | 不是主要公开指标 | 不是主要公开指标 |
| 声音克隆 | 支持，通过说话人嵌入实现零样本克隆（Kani-TTS-2） | 支持，零样本 | 支持，零样本 |
| 设计重点 | 最低资源占用 | 表现力可与闭源商业系统竞争 | 情绪夸张度控制 |
| 许可证 | Apache 2.0 | Apache 2.0 | MIT |
KaniTTS 的具体取舍是：牺牲 Orpheus TTS 这类更大、更重模型所具备的一部分情绪细腻度和戏剧表现范围，换取在真正适中的硬件上可靠实时运行——当延迟和可部署性比最大表现力范围更重要时，这正是合适的选择。
常见问题
KaniTTS 实际最低需要多少显存？
Kani-TTS-2 版本最低可在 3GB 显存上运行，因此兼容 RTX 3060 或 4050 这样的入门级消费 GPU；不过，基于 vLLM 的服务器文档建议生产规模的服务留出更多余量（12GB+），以便在规模化运行时获得舒适的吞吐量。
KaniTTS 支持声音克隆吗？
支持。Kani-TTS-2 版本会从一小段参考音频中提取说话人嵌入，无需微调即可复现目标声音的特征。
KaniTTS 有多快？
其报告的实时因子约为 0.2，也就是大约 10 秒的音频可在约 2 秒内生成；在流式模式下，首个音频块延迟低于 300ms。
KaniTTS 可以免费用于商业用途吗？
可以。它采用 Apache 2.0 许可证发布，无需另行签订许可协议即可用于商业用途，但使用时仍须遵守项目针对冒充他人和有害内容所规定的明确道德限制。
KaniTTS 支持哪些语言？
它以各语言独立专用检查点的形式提供——英语是主要且最稳健的选项，此外还有分别用于阿拉伯语、韩语和其他语言的模型，而不是一个通用的多语言模型。
在浏览器中把文字转换为语音
如果你希望完成相近的“文字 → 单人语音”流程，可以使用 Echora 的文字转语音。输入最多 5,000 个字符，选择内置音色或已保存的自定义音色，按需添加支持的表达标签并调整语音稳定度，然后试听结果并下载生成的 MP3。