Kitten TTS:这款 25MB 的 AI 语音模型即将改变一切(即使在低配设备上也能运行!🥔)

Kitten TTS:一款25MB、仅需CPU、开源的语音模型。无需GPU或费用即可实现实时语音合成。几分钟内即可安装并快速部署。

好了,让我们来谈谈正事。多年来,人工智能领域一直痴迷于“大”。大型模型、海量数据、高性能GPU,甚至更高的云计算费用。目前大多数文本到语音(TTS)模型都是烧钱的大户。我们说的是一些拥有数十亿参数、吞噬GPU资源的庞然大物,它们需要的硅芯片数量可能比你的手机、笔记本电脑,甚至整个社区的总和还要多。它们确实能提供出色的声音……但前提是你愿意将你的第一个孩子交给AWS。

忘掉这些吧。膨胀的人工智能时代已经结束。

如果我告诉你,真正的革命并非来自一个巨大的、空调恒温的数据中心?它来自一个如此之小的模型,几乎成了笑话。一个可以轻松存放在优盘中的模型,甚至还有剩余空间。

欢迎认识 Kitten TTS。😻

这不仅仅是另一个被上传到 Hugging Face 的模型;这是一个宣言。它是面对大型科技公司 AI 的“大卫”。由 KittenML 的魔法师们开发,这个模型旨在证明“大小并非一切”。

元素周期表

而且,这并非孤立事件。整个行业正在觉醒,意识到更小、更智能、更高效的模型才是未来。我们正见证一场向轻量级、设备端AI的重大转变,这种AI真正尊重你的隐私和钱包。这是将权力交回给开发者、创作者、爱好者——那些没有风险投资人随时待命的人。从集中式、由大型科技公司控制的人工智能转向分布式、社区驱动的生态系统,是当前科技领域最令人兴奋的趋势。而Kitten TTS不仅跟随这一趋势,更是引领潮流。

令人惊叹的规格 🤯

好,让我们深入细节。是什么让这个小家伙如此强大?这些不仅仅是 GitHub README 中的要点;这些规格将根本性地重新定义你对本地人工智能可能性的认知。

1500 万参数 & <25MB 体积。不,这不是打字错误。

大多数所谓的“轻量级”模型仍然体积庞大,达到数百兆字节。Kitten TTS?它仅有1500万参数,大小不到25MB。想想看,这比你手机上拍的大多数照片都小。它的体积大约是前一代“小型”冠军Kokoro-82M的五分之一,而Kokoro-82M已经因其高效性而备受赞誉。如此微小的体积意味着它可以在几秒钟内下载,并可以部署在任何设备上。

无需 GPU 运行。你的钱包会感谢我们。

这是重磅消息。这是为所有那些一直旁观 AI 革命的“GPU 匮乏”人士准备的。你不需要昂贵的显卡。Kitten TTS经过了激进的CPU优化,可在日常笔记本电脑、廉价的树莓派、安卓手机……甚至如果你敢尝试的话,连智能烤面包机上都能运行。我不是开玩笑,有人在免费的Google Colab CPU实例上测试过,它能在几秒钟内生成音频。入门门槛已被彻底打破。

多种表达声音(全家齐聚!)

对于这样一个小型模型,你可能会以为它只有一种机械化的“1988年史蒂芬·霍金”式声音,对吧?错!Kitten TTS 默认提供八种不同风格的语音,其中包括四种女性语音和四种男性语音。对于这个规模的模型而言,这种表达力的水平实在令人震惊,对于希望构建具有个性化应用程序的开发者来说,这无疑是一个巨大优势。我们稍后会逐一介绍这些语音。

超快速推理,适用于实时应用

这款设备专为速度而生。它经过优化,可实现实时语音合成,这意味着你的应用程序中再也不会出现尴尬的延迟。这对于构建响应迅速的聊天机器人、无需等待的语音助手以及为辅助工具提供实时 narration 至关重要。社区演示的反馈显示,即使在消费级硬件上,它也能以比实时更快的速度生成音频。

开源,宝贝!(Apache 2.0 许可证)

而这正是点睛之笔。最棒的部分。它完全开源,采用宽松的 Apache 2.0 许可证。这意味着您可以免费使用它。用于个人项目。用于商业产品。用于任何您想做的事情。没有任何限制。去创建一些令人惊叹的东西并赚取一些收入吧!代码在 GitHub 上,模型在 Hugging Face 上……这个舞台是您的。

这里真正令人惊叹的是创新的连锁反应。这一切都始于核心架构的突破:仅凭极少的参数就能实现令人惊叹的质量。这一单一成就直接导致了模型大小低于25MB。而这一小巧的体积,反过来又使其能够在仅靠CPU的系统上高效运行。而这种CPU效率正是其在低功耗边缘设备(如树莓派)上发挥潜力的关键。这是一个美丽的连锁反应,一个明智的设计选择同时解决了尺寸、成本和速度这三个边缘AI的圣杯问题。

别再废话了!让我们现在就让它运行起来(5分钟指南)

理论固然重要,但代码才是王道。让我们在你的机器上运行它。别再找借口了,这是可以直接复制粘贴的。让我们开始吧!🚀

步骤1:神奇的一行安装

打开终端。做正确的事,创建一个虚拟环境(python -m venv.venv && source.venv/bin/activate)。现在,将这段代码粘贴进去。就这样,你完成了。

# It's this easy, seriously.
pip install https://github.com/KittenML/KittenTTS/releases/download/0.1/kittentts-0.1.0-py3-none-any.whl

步骤2:你的第一个“Hello World”(基本生成)

创建一个 Python 文件,命名为 test_kitten.py,并将以下代码粘贴进去。首次运行时,该代码会自动从 Hugging Face 加载模型并生成你的第一个音频文件。

# test_kitten.py
from kittentts import KittenTTS
import soundfile as sf

print("Loading KittenTTS model... Meow! 🐱")
# This downloads the model from Hugging Face the first time
m = KittenTTS("KittenML/kitten-tts-nano-0.1")

text = "This high quality TTS model works without a GPU, which is pretty awesome!"

print(f"Generating audio for: '{text}'")
# Generate the audio waveform
audio = m.generate(text)

# Save the audio to a file at 24kHz sample rate
output_file = 'hello_kitten.wav'
sf.write(output_file, audio, 24000)

print(f"✅ Audio saved to {output_file}! Go listen to it!")

运行 python test_kitten.py,然后查看 hello_kitten.wav 文件。欢迎来到未来。

步骤 3:认识整个团队 (循环遍历所有声音)

不错,但你刚才使用的是默认声音。专业提示:默认声音(expr-voice-5-m)……嗯,就说它很有“个性”吧。其他一些声音对于通用用途要好得多。让我们为每个声音生成一个样本,这样你就可以为下一个项目选择最喜欢的。

创建一个新文件,all_voices.py

# all_voices.py
from kittentts import KittenTTS
import soundfile as sf

m = KittenTTS("KittenML/kitten-tts-nano-0.1")

TEXT = "Kitten TTS is an open-source series of tiny and expressive Text-to-Speech models for on-device applications."

# Get the list of all available voices
available_voices = m.available_voices
print(f"Available voices: {available_voices}")

for voice in available_voices:
    output_file = f"output_{voice}.wav"
    print(f"▶️ Generating for voice '{voice}' -> {output_file}")
    
    # The magic is here: specify the voice!
    m.generate_to_file(TEXT, output_file, voice=voice)
    
print("✅ All voice samples generated!")

运行这个脚本,你将为每个声音获得一个 .wav 文件。为了更方便,这里是官方列表。

语音 ID 性别 风格描述(我们的描述)
expr-voice-2-f 女性 清晰、专业,适合叙述。
expr-voice-2-m 男性 稳重、标准男性声音。可靠的选择。
expr-voice-3-f 女性 略微生动,适合角色塑造。
expr-voice-3-m 男声 深沉、富有思考性。适合讲故事。
expr-voice-4-f 女声 积极友好。适合助手角色。
expr-voice-4-m 男声 充满活力且清晰。能准确传达信息。
expr-voice-5-m 男声 默认选项。略显独特。使用时请谨慎! 😉
expr-voice-5-f 女声 注意:资料来源存在矛盾。部分列表显示7种声音,部分显示8种。官方GitHub列表显示7种,以5-m结尾。我们将随项目进展更新信息!

技术解析:这背后的魔法是如何实现的?(技术深度解析)

那么,KittenML 是如何做到这一点的?如何从一个比猫咪视频还小的模型中提取出高质量的语音?尽管团队尚未发布完整的研究论文,但开源社区已展开调查,共识相当明确。

尤其是r/LocalLLaMA社区的专家们认为,Kitten TTS的架构与VITS(基于对抗学习的变分推断端到端文本到语音系统)或StyleTTS2非常相似。

别被这些缩写吓到。VITS是一个极具巧思的端到端系统,将多个强大的AI概念融合成一个优雅的整体:

  1. 变分自编码器(VAE):其核心在于能够学习数据的压缩且有意义的表示。在此场景中,它学习的是语音的本质特征。
  2. 规范化流:这是一个高深的数学技巧,帮助模型生成更多样化且自然的语音变体,避免单调的机械音调。
  3. 生成对抗网络(GAN):这是提升质量的关键。GAN由两个模型组成,它们处于一场生死对决中。
  • 生成器从文本中生成音频。
    • 判别器充当批评家,试图分辨听到的音频是来自真实人类还是生成器的伪造音频。
  • 它们共同接受训练。生成器的唯一目标是欺骗判别器,而判别器的唯一目标是不被欺骗。通过这种对抗过程,生成器在生成高度逼真的语音方面变得极为出色。

这种架构非常适合名为“Kitten”的模型,因为它以极高的效率著称。它是一个非自回归模型,这意味着它可以并行生成音频片段,而不是一次生成一个样本。与较旧的、逐步生成的模型(如 Tacotron 2)相比,这使得它快得惊人。这种结合了变分自编码器(VAE)、生成对抗网络(GAN)和并行变压器 backbone 的架构,使得像 VITS 和可能的 Kitten 这样的模型能够同时实现小巧、快速和高质量。

这里的成功并不一定在于凭空发明一个全新的算法。它在于精妙的工程设计。这是将多个强大且经过验证的概念融合,打造出高度优化且精炼的实现方案的艺术。这充分证明了在现代人工智能领域,执行力和巧妙的组合与纯粹的研究同样重要。

小猫TTS对决世界:本地TTS终极对决

小猫TTS本身已经很酷了。但它与本地TTS领域的其他传奇相比如何?让我们把它扔进竞技场,看看会发生什么。叮叮!🥊

Kitten TTS vs. Piper TTS

这是争夺 Raspberry Pi 灵魂的终极对决。长期以来,Piper TTS 一直是快速、离线、设备端语音合成的无可争议的王者。它以极快的速度、极低的硬件要求和出色的语音质量而闻名。

最终结论:Kitten是新晋挑战者,且在体积上拥有显著优势。它的体积甚至比Piper的大多数语音模型更小,且针对相同的CPU专用性能配置。在纯粹的裸机效率和尽可能小的占用空间方面,Kitten确实具备明显优势。然而,Piper拥有更成熟的生态系统、更多由社区训练的语音选项,以及当前更广泛的语言支持。这是一场势均力敌的较量。

您的选择:如果您需要为英语项目使用绝对最小的模型,建议优先尝试 Kitten。如果您需要更广泛的语言支持或希望访问更大的语音库,Piper 仍是绝佳选择。

Kitten TTS 与 Kokoro TTS 对比

Kokoro 是首个让社区真正相信小型高品质 TTS 模型可行性的模型。凭借 8200 万参数,它相较于十亿参数的巨型模型实现了重大突破,并在标准 CPU 上实现了令人印象深刻的“Siri 级”音质。

结论:这是一次代际飞跃。Kitten TTS的参数数量约为1500万。Kokoro为Kitten铺平了道路,让后者能够跑完马拉松。虽然Kokoro证明了这一概念,但Kitten将其优化到了极致,以更小的体积提供了相当甚至更高的表现力。

您的选择:对于任何效率至关重要的新项目,Kitten TTS在体积与质量的权衡中显然是最佳选择。

Kitten TTS 与 Coqui XTTS

这并非直接对比,而是选择适合任务的工具。Coqui 的 XTTS 堪称重量级冠军,但其优势在于惊人的零样本语音克隆能力。只需提供 6 秒的语音片段,它就能开始以该语音说话。这是一种魔法,但是一种不同的魔法。

结论:如果你的项目需要克隆特定声音,XTTS就是你想要的模型。毫无疑问。但这种能力是有代价的——它是一个更大的模型,并且真的需要GPU才能流畅运行。Kitten TTS的目的是提供一套高质量的预构建声音,以最轻量化和高效的包形式呈现。

你的选择:使用 Kitten 实现速度、效率和设备端部署。使用 XTTS 进行声音克隆和高级风格转换功能。

为了更清晰地说明,以下是一个方便的比较表格:

功能 Kitten TTS (Nano) Piper TTS Kokoro TTS Coqui XTTS-v2
模型大小 <25 MB(15M参数) ~50-100 MB/语音 ~165 MB(82M参数) ~1.5 GB+
资源需求 仅CPU,低内存 仅CPU,低内存(RPi) 仅CPU,中等内存 推荐GPU
核心功能 极致体积与效率 速度与语言支持 体积内的高质量 零样本语音克隆
应用场景 边缘AI、物联网、无障碍 离线助手、RPi 通用CPU基于TTS 定制语音应用
许可证 Apache 2.0(商业用途允许) Apache 2.0(商业用途允许) Apache 2.0(商业用途允许) Coqui公共许可证(非商业用途)

颠覆性的应用场景(这就是我们都在这里的原因)

规格和代码很有趣,但你实际上可以用这个构建什么?这里才是真正令人兴奋的地方。Kitten TTS 不仅仅是一个酷炫的技术演示;它是开启全新一代应用程序的利器,这些应用程序此前是无法实现的、不切实际的,或是成本高得离谱的。

应用程序 1:真正的边缘 AI 与私有物联网

由于 Kitten 完全在本地运行,它是最适合边缘 AI 的引擎。想想看:智能家居设备可以与你对话,而无需将对话内容发送到另一个国家的服务器。这意味着三件大事:

  1. 更低的延迟:响应是即时的,因为无需与云端进行往返通信。
  2. 更好的隐私:你的数据从未离开你的设备。这是件大事。
  3. 离线功能:即使互联网断开连接,它也能正常工作。

这将开启一系列应用,例如支持语音控制的工业传感器、不会监视孩子的会说话玩具,以及真正尊重用户隐私的智能家居助手。转向设备端处理是直接回应公众对数据隐私日益增长的担忧,而Kitten正处于推动这一波“安全设计”产品的理想位置。通过消除传输敏感语音数据的必要性,它不仅保护用户,还简化了遵守数据主权法律的流程。

应用2:革新辅助工具

这点非常重要,也是社区真正期待的。视力障碍者或患有阅读障碍等学习障碍的人群依赖屏幕阅读器访问数字世界。但坦白说,许多默认语音仍显得机械且令人疲倦。一位Reddit用户专门提到了这一痛点,希望为NVDA屏幕阅读器提供一款不会占用过多系统资源的更好语音。

Kitten TTS正是解决方案。它足够小巧快速,可直接集成到NVDA等辅助工具中,提供更自然、更具人性化的语音,同时不会拖慢用户的电脑运行速度。这不仅仅是一个酷炫的功能,而是能够真正改善人们日常生活、让数字世界更加包容的技术。

应用3:独立开发者与爱好者的梦想

想为你的定制机器人打造语音功能?需要为独立游戏中的角色添加对话?想为自己的工作室创建一个定制的贾维斯式助手?在 Kitten 出现之前,你需要应对昂贵的 API 或搭建专用服务器。现在,你可以在树莓派上完成这一切。Kitten TTS 使高质量语音合成民主化,将其直接交到每位创作者、学生和爱好者手中,无论他们的预算如何。

最终评价与 Kitten 的未来

那么,Kitten TTS 是否是完美无缺的模型,将取代所有其他模型?让我们现实一点:还不是。它目前仍处于开发者预览阶段。部分用户指出音频中存在些许“轻微失真”,或质量尚未达到大型昂贵云 API 的水平。毕竟,它被称为“预览版”是有原因的。

但这完全偏离了重点。Kitten TTS 的魔力不在于它比一个 1000 倍大小的模型更好。魔力在于它在自身规模下表现得如此出色。性能与参数的比率绝对令人惊叹。它代表了效率和可访问性的飞跃。

故事尚未结束。KittenML团队已宣布正在开发一个更大的、约8000万参数的模型,该模型将使用相同的八种表达力强的声音。这个“大哥”版本有望解决“纳米”模型的 minor 质量问题,同时仍保持足够小巧和高效,可在CPU上运行。未来无比光明。

Kitten TTS 是一场革命。它证明了开源创新的力量以及人工智能向更智能、更小型化、更易于访问方向发展的不可阻挡趋势。

不要只是阅读,去创造吧!

常见问题与澄清

等等,Kitten 不是《战锤 40K》里的角色吗?

哈哈,你猜对了。如果你搜索了“Kitten TTS”并期待看到阿德普斯·库斯托德斯的辉煌总司令,那你来错地方了……但欢迎光临!那个传奇的“Kitten”来自精彩的YouTube系列《如果皇帝有一台文本转语音设备》。而这个Kitten TTS是一个AI模型。两者都相当酷炫。

有研究论文吗?

目前还没有!团队提到他们计划在正式发布后不久公布更多关于训练技术和架构的细节。社区正迫切等待!

像RTF或MOS这样的基准测试呢?

创作者尚未发布任何官方正式的基准测试。不过我们可以从社区中获得一些线索。在网页演示中,一位使用 M1 Mac 的用户对一个 26 秒的音频片段的生成时间约为 19 秒。这给我们一个粗略的

实时因子(RTF)约为 0.73。RTF 只是生成音频所需的时间除以音频本身的持续时间,因此任何低于 1.0 的值都比实时更快。对于在浏览器中运行的纯CPU模型而言,这非常令人鼓舞!

它支持哪些语言?

目前,nano-0.1预览模型仅支持英语。不过,团队已明确表示多语言支持将在未来版本中实现。

Kitten TTS是什么,为何如此重要?

这是一个约1500万参数、小于25MB的文本转语音模型,可在普通CPU上运行良好,并采用Apache 2.0许可证,因此您可以在产品中使用它而无需GPU或API费用。

Kitten TTS需要GPU吗?

不需要。这就是它的优化点,专为CPU优化,甚至可以在社区演示中完全在浏览器中运行。

下载大小具体是多少?

nano 0.1预览版(约1500万参数)的下载大小不到25MB。下载速度快且开箱即用。

它有多少种声音?

多种表达预设(通常提及约8种:4男声/4女声)。使用 API 中的 available_voices 列出并选择。

它支持多语言吗?

nano-0.1 预览版仅支持英语。多语言支持已在路线图中。

它能在浏览器中运行吗?

是的,有一个社区网页演示使用 transformers.js,完全在客户端 CPU 上运行。非常适合快速测试。

Kitten TTS是否支持SSML?

预览文档中未正式支持。社区讨论中有人询问过,目前我通过标点符号和分段控制语调。

它支持零样本语音克隆吗?

不支持,这是Coqui XTTS-v2的优势,但XTTS更耗资源且更适合GPU而非轻量级CPU。使用 Kitten 进行预设语音和速度调整;使用 XTTS 进行克隆。

Kitten TTS 和 Piper 该如何选择?

若您需要在 CPU 上实现英语语音的最小占用空间,建议从 Kitten 开始。若需要更广泛的语言支持和成熟的生态系统,Piper 仍是非常优秀的选择。我根据目标需求同时使用两者。

Kitten TTS 和 Kokoro 在 CPU 上的表现如何?

Kokoro(约82MB)证明了小巧也能实现优质音质;Kitten在约15MB的体积下进一步优化了大小与延迟。对于超轻量级构建,Kitten更具优势;Kokoro则拥有更成熟的应用场景和语音库。

许可证是否适用于商业用途?

是的。Apache-2.0许可证宽松且商业友好。可以放心使用。

如何快速安装?

创建虚拟环境并使用 pip install 安装 GitHub 最新版本的轮子,然后在代码中加载 “KittenML/kitten-tts-nano-0.1”。简单、可重复且支持离线使用。

实时性能是否足够快?

早期社区反馈和浏览器演示在 CPU 上的表现令人鼓舞。为了实现流畅的用户体验,建议分段流式传输较短的语音片段并缓存高频短语。

还有哪些需要注意的细节?

目前处于开发者预览阶段,部分用户反馈某些语音存在轻微失真。我建议选择更干净的预设(如“2-f/2-m/4-f”)用于叙述场景。

目前有哪些好的应用场景?

设备端助手、离线辅助工具、独立游戏/NPC,以及无法依赖云端TTS的隐私敏感型应用。(这正是我首先会部署它的场景。)

共有 362 条讨论

      1. 谢谢。我真的不想经常听这些声音。

      2. 酷,谢谢……顺便说一句:最后一个男性声音听起来很高亢/醉醺醺的。

    1. Reddit上的视频很棒。我不明白为什么有人称它为“还行”的模型。不到25MB且仅使用CPU就能达到这种质量,真是令人惊叹。

      1. 称它为“还行”的人可能自己试用过。视频中演示的模型与他们发布的25MB模型并不相同。

          1. 没想到还能再看到LimeWire这个名字,真没想到

        1. 它确实提到这是个预览版本,所以我会在正式发布前保留判断。

        1. 我们仍在训练模型。我们预计下一版本的质量会有所提升。这只是一个预览版本 🙂

    2. 听起来非常清晰。对于像我这样的非英语母语者来说,很容易理解。

      1. 语速始终是一个可调参数,而非模型固有属性。

        与espeak的对比在于,对于长句的表达力和正确语调。考虑到模型规模,实际效果已相当惊人。最接近的可能是KokoroTTS(82M参数,约300MB)。

        1. 我认为他指的是英语配音中常见的过度表演。

          1. 声音听起来不自然且有些刺耳。男性声音尤其缺乏深度:只有最终版本的声音有任何深度,而其他声音听起来像尚未完成青春期的青少年。这些声音都不太像人的声音,而且非常令人讨厌,部分原因是它们听起来像是在表演。

          2. 我听到了一点《守望先锋》中的 DVa。

      2. 唯一真正的问题是,他们是从哪款中国抽卡游戏中提取的数据,以及他们是否使用了 Claude Code 或 Gemini CLI 进行 Python 编码。我敢打赌,从这种过度拟合的数据输出中可以得到共鸣峰匹配。这不会维持太久。

    3. 它是用《飞出个未来》的声音进行交叉训练的吗?

      1. 听起来像《家庭男人》中的Mort。

    4. 技术成就令人印象深刻,但就我是否会使用它而言:天啊,那个男性声音就像那些假装兴奋的新闻播报员。他们总是处于喘息的边缘。女声好些,但听起来还是像在念产品广告,被要求必须表现得特别兴奋。我猜这可能是训练数据的普遍情况,而非演示的刻意设置。不确定自己能否习惯这种风格

      我平时在手机上经常使用TTS,最近还尝试了F-Droid上一个名为SherpaTTS的新项目,该项目从Huggingface获取模型。这些模型非常占用资源(手机在运行时会将其他应用程序暂停到磁盘上),但声音效果不错。然而,在第一篇新闻文章中,已经出现了一两个发音错误,因为它在猜测如何发音不常见或新词汇,而不再基于逻辑规则将文本转换为语音。

      Google和Samsung在我的设备上预装了各自的TTS引擎,这些引擎的发音和工作效果都很好。虽然略显单调,但它们总是以相同的方式发音,因此你可以始终弄清楚文本的内容。

      Espeak(或-ng)是绝对最差的,但仔细听30秒后,你就会习惯它,并且可以理解一切。我不确定它是否是最佳开源选项(可能还有其他值得尝试的选项),但至少它是可靠性最高的,你能始终准确获取信息,且可无缝安装在任何设备上而无需担心授权问题

      1. 还有其他人想尝试 sherpaOnnx 吗?你可以试试这个.. https://github.com/willwade/tts-wrapper 我们最近在 kokoro 模型中添加了一些内容,应该会听起来好很多。可供选择的模型非常多。我感觉 Droid 应用在冷启动方面处理得不太好。

      2. 非常感谢详细的反馈。我们正在开发一些不使用音素化器的模型

  1. 我希望这就是未来。离线、小型机器学习模型,在普遍且廉价的硬件上运行推理。这些模型易于集成到其他系统、设备和应用中,甚至可能由其他模型驱动。

    1. 专用的单一功能硬件搭配模型将更加节能。理论上可以设计仅使用电阻(而非晶体管)运行神经网络等算法的芯片。

      此类硬件并非通用型,且无法升级模型,但存在大量合理应用场景。

      1. 但电阻器,即使在理论上,也是散热装置。与晶体管不同,晶体管在理论上可以完美地处于开或关状态(两种状态均不散热)。

      2. 从理论上讲是可能的,但物理“神经元”是个糟糕的主意。全连接神经网络中两层之间的连接数是每层权重数的乘积,因此布线问题会让其他所有问题都显得微不足道。

      3. 问题是新模型每天都在推出。因此,为单一模型制造芯片在经济上是不切实际的

    2. 这就是苹果公司通过其SLM所设想的,例如专门用于管理日历事件的模型。它不需要包含人类全部知识——只需具备管理日历所需的功能。

      1. 问题是他们设想所有人都只使用苹果产品。

        1. 就像谷歌希望所有人都使用他们的产品一样。这就是公司的运作方式。

          技术仍然是公开的,研究也已公开

      2. 苹果的硬件素以价格过高著称,所以我认为他们根本没有这种设想。

        1. 是吗?售价$600的Mac和$150的Apple TV无疑是其市场中最具性价比的产品之一

          1. 我仍然相信未来的 AppleTV 型号会是一款功能齐全的本地大语言模型 (LLM) 机器。

            这样,他们就可以将尽可能多的“LLM”工作卸载到家中的设备上,所有家庭成员的手机和设备都可以使用它进行本地推理。

            反正它已经太强大了,为什么不把它用在有用的事情上呢?

    3. 嗯。一种只需支付一次(或根本不支付)的模式,可以在任何设备上运行?还是订阅模式,会让你陷入其中,并且需要只有最富有的跨国公司才能负担得起的硬件?我好奇哪一种会胜出。

    4. 没错,完全同意。这些小型模型的质量只会越来越好。

  2. 我做了一些快速基准测试。

    Ubuntu 24,Razer Blade 16,Intel Core i9-14900HX

      性能结果:
    
      初始延迟:~315ms(短文本)
    
      音频生成速度(每秒处理时间生成的音频秒数):
      - 短文本(12个字符):3.35倍实时
      - 中等文本(100个字符):5.34倍实时
      - 长文本(225个字符):5.46倍实时
      - 非常长文本(306个字符):5.50倍实时
    
      发现:
      - 模型加载时间约为710毫秒
      - 以约5倍实时速度生成音频(不包括初始延迟)  
      - 性能在不同语音之间保持一致(4.63倍至5.28倍实时速度)
    
    1. 感谢您运行基准测试。目前模型尚未优化。当我们发布面向生产的SDK时,我们将优化加载等功能 🙂

    2. 在我的Intel(R) Celeron(R) N4020 CPU @ 1.10GHz上,导入/加载需要6秒,文本生成速度在大多数文本长度下约为实时速度的1倍。

      1. 感谢您在与我相同的硬件上进行测试。

    1. 有人觉得科幻电影必须大幅扭曲“机器人声音”以使其听起来“足够机械化”这件事有趣吗?在许多情况下,一种机械化、_明确_非自然的声音是完全可以接受的,甚至更可取。我并不期待智能烤面包机像BBC主持人那样说话;只要语音容易辨认就足够了。

          1. 但它没有延迟,与KittenTTS不同,因此它也有其应用场景。

        1. 哦,现在我知道Airdorf在《Faith: Unholy Trinity》中用了什么了。

        1. 声音听起来很棒!我认为它相当美观,但远非无性别。

        2. 有趣的概念,但为什么那个网站充斥着Top X博客垃圾信息?

          1. YouTube视频[1]发布于2019年。博客垃圾信息帖子时间跨度从2022年11月至2023年7月。

            除了视频外,唯一相关的内容在关于页面[2]。该页面称该声音是5个不同实体的合作成果,包括倡导团体、营销公司和音乐制作人。

            视频是该声音的唯一使用示例。没有API、权重、SDK等。

            我怀疑这是哥本哈根骄傲节在疫情前赞助的一次一次性营销噱头。最初的反响足够强烈,以至于几年后仍能持续获得少量但稳定的流量。参与其中的某家营销公司决定将该资产商业化,并用博客垃圾信息对其进行了篡改。

            [1] https://www.youtube.com/watch?v=lvv6zYOQqm0

            [2] https://genderlessvoice.com/about/

        3. 嗯。听起来完全清晰且明显是人工合成的。对我来说,它听起来有点女性化,但这只是因为我从品牌定位中被引导去思考性别。

          这是机器人声音的好选择。它比共振合成器或故意失真的真人声音更容易理解。无性别特征的设定足够陌生,避免了恐怖谷效应。你直觉上知道自己面对的是些许不同的存在。

      1. 在《文化》系列小说中,伊恩·班克斯设想我们可能会对传输声音/全息图的诡异真实感感到不适,因此故意加入一定程度的失真以表明你正在与一个图像对话

      2. 这取决于电影。在《异形》系列中,阿什和毕晓普的声音听起来很人性化,直到有戏剧性的理由让它们听起来更“机械化”。

        我同意你的观点。我经常使用Google TTS与Moon+Reader(我尝试过由真人朗读的有声书,但更喜欢TTS的一致性)

        1. 这里稍有不同,因为在两种情况下,瑞普利(以及我们)都无法分辨他们是机器人,直到真相被揭露。关键在于它们并未被呈现为人工制品。与《银翼杀手》中的“比人类更像人类”一样。若缺乏这种模糊性,影片便失去核心意义。

          1. 你说得对。我本应以《银河系漫游指南》中的马文为例。他的语音处理非常轻微。

      3. 我记得《第五元素》的小说版描述过,警察在使用扬声器时会被训练得尽可能像机器人一样说话。我一直觉得这个想法很奇怪,有人会_想要_那样

      4. 如果你使用的是 Mac,可以在终端中输入“say [要说的话]”。

      5. 我个人更喜欢在文本来自软件或语言模型时使用较旧的合成语音进行文本转语音(TTS)。

    2. 除了 WebGPU 相关的问题(目前处于测试阶段),如果能在设置中提高语音速度而不影响语音音调,那将非常不错。

    3. 当我尝试使用 6 句话的演示时出现了错误,但当我将文本减少到 3 句话时,它运行得很好。长度限制是由于模型本身还是只是演示的限制?

      1. 目前我们尚未启用分块功能。我们很快会添加该功能,这将消除长度限制。

      2. 或许是长度限制?我尝试了以下内容:

        “这部第一卷首先简要概述了整个主题,即人类的叛逆及其因此失去的乐园;随后探讨了人类堕落的主要原因——蛇,或者说蛇中的撒旦。撒旦背叛上帝,并拉拢了众多天使军团,最终被上帝命令驱逐出天堂,连同其所有随从一同被抛入深渊。”

        在我的i7核心上需要一段时间才能开始生成声音,但大致可行。

        这段也有效:

        “blah. bleh. blih. bloh. blyh. bluh.”

        所以我认为这不是标点符号的限制。不过语音质量相当差,与我预期的八十年代老派C64 SAM(https://discordier.github.io/sam/)相比,差距并不大。

    4. 我尝试复制他们的演示文本,但不知为何听起来效果不佳。

      如果其他人想尝试:

      > Kitten TTS 是一系列开源的轻量级且富有表现力的文本转语音模型,专为设备端应用设计。我们的最小模型不到 25 兆字节。

        1. 或许,但 25MB 模型是他们目前唯一发布的版本

    5. > 生成语音时发生错误:无法调用 OrtRun()。错误代码:2,错误消息:在运行 Expand 节点时返回非零状态代码。名称:‘/bert/Expand’ 状态消息:无效的展开形状

      似乎不支持泰语。

    6. 谢谢,我正在寻找这个。虽然 Reddit 演示听起来不错,尽管在我们几年前就达到的水平上,我尝试的所有 TTS 样本几乎都难以理解。

      1. 这只是一个早期检查点。我们希望未来质量会有所提升。

    7. 在PC上,这是一个Python依赖地狱,但有人设法将它打包成一个自包含的JS代码,一旦加载了模型,就可以离线使用?这是如何实现的?

      1. ONNXRuntime使这变得相当简单,你只需要提供ONNX文件的路径,以正确格式提供输入,然后使用输出。ONNXRuntime 库会处理其余部分。你可以在 main.js 文件中看到这一点:https://github.com/clowerweb/kitten-tts-web-demo/blob/main/m

        此外,Python 软件通常会陷入依赖地狱,而网页天生就必须自成一体(感谢上帝,我们不再需要 Silverlight 和 Java 小程序了…)

    8. 感觉它处理标点符号不太好。我听不到句子边界和逗号。听起来像是一连串的单词。

    9. 是的,这只是早期检查点的一个预览模型。完整模型将于下周发布,包括一个15M模型和一个80M模型,两者的质量都将远高于这个预览版本。

    10. 使用男性声音2,采样率48kHz,速度0.5倍,听起来很像《Celeste》中Madeline的台词。我觉得挺有趣的。

    11. 这在Safari上似乎无法正常工作。但在Chrome上运行良好。

        1. 这个人只是在项目评论中大量发布垃圾信息。

        2. 在线连接是硬性要求,但如果您确实需要,可以使用GHIDRA来解决这个问题。我曾尝试将他们的模型转换为ONNX格式(使他们的专有管道失效),但未能成功。

          希望开源技术未来能让它们变得无关紧要。

      1. 有没有适用于Android的APK来替换其语音转文本引擎?我尝试过sherpa-onnx,但它似乎太慢,无法用于实时使用,尤其是在加快速度时播放有声读物。

  3. 核心功能不仅仅是25MB的体积。关键在于KittenTTS采用Apache-2.0许可证。这一组合意味着你可以将完全离线的语音功能嵌入到树莓派Zero级硬件或甚至电池供电的玩具中,无需担心GPU、云调用或限制性许可证。一举将语音功能从硬件/许可证问题转化为封装问题。质量优化可以稍后进行;解锁这一部署层级才是真正的游戏规则改变者。

    1. 是的,我们非常兴奋地开发这些小型且高质量的 AI 模型。本地语音界面是不可避免的,我们希望未来能为其提供动力。顺便说一句,这个模型只是一个预览,下周发布的完整版本质量会高得多,还有另一个约 80M 的模型 😉

      1. 问题更严重的是:phonemizer 使用的是 espeak-ng,它并不擅长将字形转换为音素。在其他依赖音素的 TTS 系统(如 Zonos)中,这被证实是导致生成质量低下的关键问题之一。

        而且这无法修复,因为模型是在基于不良音素的数据上训练的(所有人都使用 Whisper + 然后对文本转录进行音素化)。

        1. _> 我不是律师,但据我所见,这留下了两个选项:更换许可证或移除该依赖项。

          还有第三种选择:向项目申请例外。

          不过这种情况不太可能获批¹,最终你还是只能选择前两种方案。

          当然还有第四种选择:直接忽略许可证。这是像Onyx这样的公司采取的方案,而我本可能对他们的产品感兴趣……

          —-

          [1] 选择GPL3或AGPL的人通常是为了保持明确性,而例外会模糊界限,此外,如果项目有多个维护者,重新授权可能需要所有提供代码的人同意,这可能根本不可能实现。此外,如果项目是从其依赖项继承的许可证,例外就更不切实际了。

          1. > 还有第三种选择:向项目申请例外条款。

            据我所知,该项目无法授予此类例外条款,因为其GPL许可证继承自espeak-ng。

            1. 啊,是的,好眼力,我根本没有深入查看依赖关系树。我将更新我的脚注,将此作为例外可能无法实现(或至少极不切实际)的原因之一。

          2. 第四种方案是采用双许可证模式:项目本身以GPL-3.0许可证发布,但本仓库中的源代码(不包含任何依赖项)也可在Apache 2.0许可证下使用。

            任何用户仍将受GPL-3.0许可证约束,但若有人能移除GPL依赖项,即可在Apache许可证下使用该项目。

            1. 这是图书馆发布者的选项,而非使用者。如果尚未完成,那么要求完成它与要求例外情况(选项三)是相同的。

              1. 使用该库的代码仅有四行。其中三行用于初始化库(phonemizer.backend.EspeakBackend(language=“en-us”, preserve_punctuation=True, with_stress=True)),另一行用于调用该库(phonemes_list = self.phonemizer.phonemize([text]))。此外,我猜还需要导入语句。即使不考虑谷歌与甲骨文的纠纷,我认为这些代码行本身并不满足任何原创性门槛。

                显然,你不能在不遵守GPL的情况下运行它们(使用原始库)。但我看不出来为什么我不能独立于此,也以Apache 2.0许可证向你提供这个文本文件,让你随心所欲地使用(需要说明的是,这仍然不允许你在不遵守GPL的情况下使用原始库运行它们,但那是音素库迫使你这样做,而不是这个项目)

                你必须对双许可证条款做出非常明确的说明,以避免在Apache许可证条件下可做之事的混淆。你不能仅仅说“它是双许可证的”

            2. 您甚至可以将不调用GPL库的部分提取到一个采用Apache 2.0许可证的上游项目中,然后在下游项目中同时引入该项目和GPL库,依靠Apache 2.0与GPL 3.0的兼容性而非显式双许可证,使组合作品能够在GPLv3下分发。

        2. 一旦许可问题解决,希望能够通过发行版的常规包管理器进行安装。

      2. 这仅适用于他们将 GPL 许可的代码与自有代码一同分发的情况。

        如果我的 MIT 许可的一行 Python 库包含以下代码行…

          run([“bash”, “-c”, “echo hello”])
        

        ……我不会突然受到bash许可证的约束。不过,任何想要运行我的代码的人,都需要确保自己已经安装了bash。

        (但为了反驳我自己的观点,如果操作系统供应商将我的库与bash的副本一起分发,他们是否需要将我的库重新授权为GPL?)

        1. FSF认为这属于衍生作品,必须使用LGPL许可才能允许链接。

          然而,这一观点从未在法庭上得到证实,且有许多合理论据认为链接行为不构成衍生作品。

          某律师撰写的老帖子(版本3不会影响此问题)[1]

          对我个人而言,我不太明白,如果动态链接具有传染性,那么使用Linux运行代码为何不具有传染性。显然,Linux在运行你的代码时,会在某个层面上调用GPL许可的代码。

          不过这其实并不重要,因为FSF的立场足以让公司不敢使用它,而个人被起诉的可能性极低。

          [1] https://www.linuxjournal.com/article/6366

          1. > 对我个人而言,我不太明白,如果动态链接具有病毒性,那么使用Linux运行代码为何不具有病毒性。显然,Linux在运行你的代码时,会调用GPL许可的代码。

            Linux内核对用户空间软件有一个明确的例外条款:

            > 注意!本版权不涵盖通过正常系统调用使用内核服务的用户程序

            1. GPL还对“系统”软件(如内核、平台库等)有一个明确的例外条款:

              > 可执行作品的“系统库”包括除作品整体之外的任何内容,且满足以下条件:(a) 该内容包含在主要组件的正常打包形式中,但并非该主要组件的一部分,以及 (b) 该内容仅用于使作品与该主要组件配合使用,或实现一个标准接口,且该接口的实现以源代码形式向公众开放。在此背景下,“主要组件”指的是特定操作系统(如有)上可执行作品运行的主要核心组件(如内核、窗口系统等),或用于生成该作品的编译器,或用于运行该作品的对象代码解释器。

              > 对于以对象代码形式存在的作品,“对应源代码”指生成、安装(对于可执行作品)运行对象代码以及修改作品所需的所有源代码,包括控制这些活动的脚本。然而,它不包括作品的系统库,或在执行这些活动时未修改地使用的通用工具或普遍可用的免费程序,这些程序并非作品的一部分。

        2. > 这仅适用于他们与自己的代码一起分发GPL许可的代码的情况。

          据我对FSF对其许可的解释的理解,情况并非如此。即使你只是动态链接到GPL许可的代码,你创建的组合作品也必须整体上根据GPL许可。

          我认为这并不包括通过其命令行界面(CLI)调用外部程序,但这似乎并非相关代码所做的事情。

          (这并非推荐, merely 是我对 GPL 工作原理的理解。)

        3. 这是一个错误的类比。这非常简单明了。

          通过 exec()/fork()/spawn() 等调用 bash 并不等同于(静态或动态)与它的代码库进行链接。如果你的 MIT 许可的一行代码链接到 GPL 许可的代码,那么它就会受到 GPL 许可的影响。

          1. 我见过有人使用IPC来绕过GPL,但我也见过FSF的解释声称这仍然是衍生作品。

            我不知道这是否曾在法庭上被测试过。

          2. 你说得对。这里说的链接是指LD(链接器)进行的链接,而非概念上的链接。

        4. GPL现在主要是针对老一辈开发者。软盘?分发?你可以使用工具但不能修改它?调用DLL意味着你需要重新分发你的代码,但分支则不需要?

          荒谬

          1. GPL 出现于网络软件分发之后(我们通过 FTP 获得了第一个 gcc)。

            1. 是的,但如果你使用开源库来构建你的闭源 SaaS,那没问题。人们通过网络将软件交付到虚拟机中(你的浏览器)。

        1. 兼容意味着它们可以被链接在一起,但结果是GPL-3。

          1. > 结果是 GPL-3

            结果只能在 GPL-3 条款下分发。这实际上是一个关键区别:没有什么能阻止 Kitten TTS 采用 Apache 许可证,在该许可证下寻求技术贡献,以及其部分代码在其他软件中以该许可证重新使用。是的,目前这限制了你对 Kitten TTS 的使用方式(例如将其嵌入到你的产品中),但许可证本身仍是 Apache 许可证,这仍具有价值。

      3. 好吧,有什么能阻止你将代码输入到大语言模型(LLM)中,然后重写它,使其成为你的呢?你甚至可以添加额外的步骤,比如让它逐块分析代码,然后在重写时进行监督。砰。人工智能时代知识产权自由。

        道德可能阻止你,但除此之外?依我之见,只要有人愿意花费一些AI代币,所有开源代码都可视为公共领域代码。

        1. 那将构成衍生作品,仍需遵守许可条款和条件,至多如此。

          对此有标准做法称为清洁室工程。

          https://en.m.wikipedia.org/wiki/Clean-room_design

          一人阅读代码并制定详细的技术规范。另一人审核以确保其中不包含任何可能被视为受版权保护的材料,然后第三人(从未见过原始代码)实现该规范。

          您可以在两个阶段都使用大语言模型(LLM),但您必须能够证明执行实现的大语言模型(LLM)事先对相关代码一无所知……考虑到大语言模型(LLMs)的训练方式,在我看来,在法律问题得到解决之前,这似乎是一个非常可疑的领域。

        2. AI在代码隔离方面确实有用,但实际操作远比你描述的复杂。为了避免法律风险,你可能需要将代码重构为另一种语言,再转换回目标语言。最终,这将演变为被迫深入理解代码库并监督其重写的过程。我曾使用大语言模型(LLMs)将库翻译成另一种语言,我认为这个过程相当于自己编写代码的一半工作量。所以最终,走两条路,你可能还是自己重写代码比较好……但使用大语言模型(LLMs)会让你熟悉主题,这样你就可以重写代码了,所以你可以把它看作是一种充满错误的教程过程吧?

          1. 我甚至不确定这是否足够。为了安全起见,你真的需要进行一次干净室重实现——与编写代码的人进行干净室重实现的原因完全相同。

            1. 是的,算法和程序流程必须在实质上有所不同才能真正安全。也许在大部分情况下,切换编程范式就能实现这一点?JavaScript→Haskell→JavaScript?听起来像噩梦一样,哈哈。

        3. 请告诉我,您没有在大型、非平凡的代码库上使用过大语言模型(LLMs),而没有告诉我… 🙂

          1. 请告诉我,您不知道如何正确使用大语言模型(LLMs),而没有告诉我。

            您不会将整个代码库交给大语言模型(LLMs),并期望它一次输出结果。相反,您会将其分解,并逐块编写代码。这样,代码库的大小就无关紧要了。你把大语言模型(LLM)当作工具来使用,它不会取代你。你不会像《杰森一家》中的乔治那样,只是按一个按钮,什么都不碰,而是当大语言模型(LLM)进行编码时,你掌握着整个过程。你每一步都测试代码,看看实现是否符合预期。这样做足够多,你就能得到真正的、完整的“定制”软件。

    2. 节日的英语模型 festvox-kallpc16k 大约 6 MB,这是一个大型模型;festvox-kallpc8k 大约 3.5 MB。

      eSpeak NG 的数据文件大约 12 MB(多语言)。

      我猜这个模型可能生成更自然的语音,但较旧或低端计算机之前也能够实现不错的语音合成。

      1. 可以添加自定义语音,但对一些用户来说速度更重要。

        $ ls -lh /usr/bin/flite

        上次检查时显示为 27K。

        我记得一些盲人用户能够以大多数人难以理解的速度解码 Gordon 8 位对话。=3

        1. 我不是盲人,但口语英语比书面英语难理解得多(我是非母语者),而 Flite 在 n270 笔记本上以惊人的速度运行,且语音质量足够好。

    3. > KittenTTS采用Apache-2.0许可证

      关于训练数据,大家是否100%确信模型并非训练输入的衍生作品,即使它们能完美复现输入内容?

    4. 我目前在玩NVIDIA Jetson Orin Nano Super,搭配Gemma3:4b其实相当实用且速度很快——即使是图像处理也能在10-20秒内完成,但这是在GPU支持的情况下。当系统出现故障且Ollama未启用GPU时,这些操作会耗时极长,因为CPU性能实在太差。

      我很好奇仅使用CPU时的速度如何。

    5. 这取决于espeak-ng,它采用GPLv3许可证

    6. 这为医疗设备、离线语言学习工具以及视力障碍者的辅助设备打开了语音接口的大门——这些领域此前因对云服务的依赖和专有许可证而受阻。

    7. 但Pi Zero有GPU,为什么不利用它呢?

      1. 因为那样你就只能局限于那台设备了。

    8. GitHub上只有几KB的Python代码,看起来像安装脚本。这在C++中是如何使用的?

  4.   系统要求
      几乎在任何地方都能运行
    

    哈哈,在我的一台机器上,Python版本太旧,包/依赖项无法安装。

    在另一台机器上,Python版本太新,包/依赖项无法安装。

    1. 我提交了几个PR来解决这个问题:

      https://github.com/KittenML/KittenTTS/pull/21 https://github.com/KittenML/KittenTTS/pull/24 https://github.com/KittenML/KittenTTS/pull/25

      如果你安装了`uv`,你可以尝试我合并的分支,其中包含所有这些PR(以及#22,一个修复短生成被不必要截断的补丁)与

          uvx --from git+https://github.com/akx/KittenTTS.git@pr-21-22-24-25 kittentts --output output.wav --text “This high quality TTS model works without a GPU”
      
      1. 感谢您对 UV 的快速介绍,看起来像是 Python 的 Docker 层

        我发现 TTS 速度有点慢,所以我将输出管道传输到 ffplay,并以 1.2 倍速播放,使声音听起来更好

           uvx --from git+https://github.com/akx/KittenTTS.git@pr-21-22-24-25 kittentts --text “我在餐厅为超过1000000名顾客提供12种不同啤酒” --voice expr-voice-3-m --output - | ffplay -af “atempo=1.2” -f wav -
        
        1. 啊,对,好眼力——我也在CLI中添加了模型原生速度倍增器(例如--speed=1.2)。

    2. 是的,有些人遇到问题后会想“我用Python解决”。结果他们现在面临五十个问题。

    3. 我用的是太新的版本。

      这个包就是依赖地狱的典型代表。

      说真的,还是用piper-tts吧。

      安装简单,50MB就能获得优秀效果,100MB则能用数百种声音获得良好效果。

    4. 在Fedora上无法运行,因为g++版本不匹配。

      1. 不确定现在是否已修复,但我本地在Fedora上已能正常运行。

          > g++ --version
          g++ (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2)
          Copyright (C) 2025 Free Software Foundation, Inc.
        
    5. 我们正在努力修复这个问题。感谢您

      1. “修复 Python 打包”比 AGI 更难一些。

        1. 我和我的兄弟一起感叹,要设置一个运行一个大语言模型(LLM)或扩散模型的环境是多么困难,更不用说多个或组合了。其中 5% 是 CUDA/ROCm 的困难,95% 是 Python 的困难。我们有一个理论:任何从事生成式人工智能工作的人都必须忍受输出仅有90%准确性的情况,并且完全可以接受使用仅有90%功能的语言和环境。

          为什么Python在这方面表现如此糟糕?它比Bash脚本更少笨拙,但即使是Bash脚本也更容易让其正常工作。

          1. 这是一个普遍问题。

            JS/TS/npm同样糟糕,可能还有更多构建工具/框架。

            Rust一团糟。

            Go,嗯。

            就连Perl也相当复杂。

            1. 是的,但这很容易解决,可以通过指令、头文件或Makefile指定遵循的语言标准。更好的是,你可以使用不同语言标准的不同语法,这样就清楚该遵循哪个标准。如果编译器能自动判断我是在编译 C 还是 C++,为什么 Python 解释器不能判断我是在运行同一语言的版本二还是版本三?

            2. > JS/TS/npm 同样糟糕,可能还有更多构建工具/框架。

              这完全错误。NPM 包默认是本地目录的。而且我多年未见过有包依赖特定的 Node 版本。Node 的向后兼容性也很好,大约 5 或 6 年前有一个非常流行的原生包被废弃,但这就是全部了。

              我可以使用当前的 LTS Node 版本,运行过去 4 或 5 年内从 NPM 仓库中编写的几乎任何包,它都会正常工作。与此同时,许多 Python 包却需要特定的版本。这简直是胡闹。

              Node 版本管理器确实存在,并且可以设置为按目录工作,这非常酷,但我已经多年不需要 NVM 了。

        2. 这就是我们知道ASI已经到来的方式。

      2. 你是否考虑过提供一个uvx命令,让人们快速开始使用?

        1. 不过我认为你仍然需要安装Python构建依赖项才能让它正常工作。

          1. 如果你将依赖项限制为仅那些有 wheels 可用的,那么 uv 应该就能为你处理它们。

          2. 我认为它也可以安装 Python 本身。不过我遇到过一些问题,尤其是 SSL 证书位置的问题,这是 Linux 的另一个混乱之处。

        1. 一个仅在一年或两年前发布的工具?它几乎不会出现在大多数操作系统/发行版中。只有现代或滚动更新的系统可能会有(可能)。当推荐的 Python 依赖管理器与脚本本身一样难以安装和使用时,这真是讽刺。非常 Python 风格。

        2. 该项目已完成约 80%,只需一个与 uv 和 poetry 兼容的 pyproject 文件即可。但目前未指定包版本,Python 版本要求极为宽松,且未提供锁定文件。

          1. 在此情境下,uv与poetry配合使用完全没问题。如果你从poetry发布一个wheel包,uv可以直接使用它。你无需在项目中进行任何更改即可实现。

        1.   PYTHON(1)                   普通命令手册                  PYTHON(1)
            
            名称
                 python - 一种面向对象的编程语言
          
            摘要
                 python [ -c 命令 | 脚本 | - ] [ 参数 ]
            
            描述
                 Python 是标准编程语言。
          

          计算机科学家喜欢 Python,不仅因为空格在 ASCII 字符表中排在首位,还因为它是标准。其他人喜欢 Python 因为它是 PYTHON!

          1. Python 被使用并非因为它很好,而是因为它足够好,就像 Windows 和塑料一样。

    6. 你收到很多类似“为什么不直接____”的评论,这充分说明整个Python社区已经完全被“斯德哥尔摩综合症”控制了。

      在其他任何编程语言中,你都不需要维护多个完全不同的语言版本,而每个版本都需要相对较大的安装包。你能想象如果我们为了编译五个不同的现代C项目,每个人都必须拥有五个不同的LLVM或GCC吗?

      我可能会被大量点赞,但这并不能改变2025年的Python过于脆弱的现实。

      1. 这就是我所面临的情况。我参与的C++代码库需要针对特定版本的LLVM进行编译,且启用了大量警告(作为错误),使用不同版本进行编译需要付出一定努力。Ubuntu可以轻松安装多个版本的LLVM并行使用,或者在Docker容器中使用正确的编译器进行编译。同样,我参与的TypeScript代码库在CI中针对特定版本的node.js进行测试,且package.json中的engine字段会被明确指定。不同版本通过nvm进行管理。Python则通过uv和pyproject.yaml实现类似功能。

        1. 我并不怀疑这一点,但我认为这种情况在 C/C++ 开发中并不被视为默认情况。大多数情况下,我期望开源软件能够使用我自己的 Clang 进行编译。

      2. 我同意你的观点,但

        > 如果我们每个人都有五个不同的LLVM或GCC

        哦,这些例子不太恰当。除了Clang之外,大多数使用LLVM的编译器都会附带自己的LLVM补丁,而使用GCC进行交叉编译确实需要为每个目标安装工具链。

        1. 交叉编译是完全不同的主题……我试图进行一个公平的比较。如果你为宿主架构编译大量开源 C 项目,通常不需要多个 LLVM 或 GCC。通常,Makefile 会检测平台和编译器的各种信息,然后以一个难以理解的错误失败。但那是另一个问题!哈哈

      3. > 想象一下,如果我们为了编译五个不同的现代C项目,每个人都必须拥有五个不同的LLVM或GCC?

        是的,因为我只需要看看现实世界。

    7. 还有人使用全局Python安装而不是环境吗?Python依赖地狱早在几年前就已糟糕,但如今这种方式完全不切实际。即使在树莓派上也是如此。

      1. 没错。Python十年前就不再是Python了。现在只是有无数个Python版本。Perl……另一方面,你仍然可以在任何系统上的Perl解释器运行任何时期的Perl脚本,而且它能正常工作!当然,Perl 不受欢迎,也没有持续获得新功能,尤其是关于硬核数学/计算库方面。

        无论如何,我认为我会继续使用 Festival 1.96 进行文本转语音(TTS)。它在我的 Core 2 Duo 上运行得非常快,而且我完全没有机会让这个 Python 3 风格的脚本在任何运行时间超过几年的操作系统上运行。

        1. 看到 Perl 失宠让我心碎。Perl “6” 丝毫没有帮助。

      2. Debian 基本上通过让 pip 拒绝在非虚拟环境中安装包来“解决”了这个问题。

        1. 据我所知,这实际上是上游 pip 的更改。

        2. 嗯,我的 Python 3.13.5 甚至无法运行!

          相当令人印象深刻,但这似乎是大多数 AI/ML 项目的标配。

          “在我的机器上运行正常”或“直接使用 Docker”,尽管在这里后者似乎根本不是选项。

        3. OpenSUSE也是如此,至少在Tumbleweed上是这样。

      3. 使用venv并不能避免安装了错误版本的Python解释器。

    8. 对于需要 25MB 内存的东西来说,这是多么无知的话。

      1. 不确定大小与此事有何关联。

        我给你发送一个 500KB 的 Windows .exe 文件,并声称它可以在任何地方运行。

        因为它的大小而对它提出任何反对意见是否无知?

        1. 我们都知道,在此语境下“在任何地方运行”指的是计算能力。因开发环境问题责怪作者是愚蠢的。

          1. 直到你提到这一点,我才意识到它的含义。

      2. 这让我想起了《过山车大亨》用汇编语言编写所带来的成本与收益。由于它对资源需求极低,可以在任何个人电脑上运行,或者至少在任何x86架构的设备上运行,而当时几乎所有设备都属于x86架构。

        如今,RISC 架构已变得非常普遍,因此与当时罕见的 68K Apple/Amiga 等计算机相比,现在更常见的是希望在 ARM 或偶尔的 RISC-V 处理器上运行软件,因此使用 x86 汇编语言编写代码需要进行模拟,这会导致性能比编译语言更差。

    9. 系统 Python 用于已知可协同工作的系统应用程序。如果你需要为其他用途安装 Python,可以使用 venv 或 conda,然后通过 pip 安装相关软件。

    10. 你应该使用 venv 处理除操作系统自带 Python 脚本以外的所有情况

  5. 我试过了。考虑到模型大小和速度,效果不错。不过一旦安装所有所需的庞大库和组件,实际大小远超 25MB。尽管如此,这仍是个很酷的项目。

    1. 关于依赖关系的问题提得很好。

      为了简化设置并添加一些用户在此处请求的功能(如GPU支持和长文本处理),我为该模型搭建了一个自托管服务器:https://github.com/devnen/Kitten-TTS-Server

      目标是通过标准的 Python 虚拟环境实现“开箱即用”,以避免依赖冲突。

      安装流程仅需标准的 git 克隆、在 venv 中使用 pip 安装,然后运行 python server.py。

      1. 哇,真是令人印象深刻。制作这个花了你多久时间?

        1. 没花太久时间。我已经为Dia和Chatterbox TTS模型开发了两个类似项目,只需转换几个文件即可。

    2. 提到ONNX,想必ONNX模型已提供或即将提供。

      ONNX运行时是一个单一库,C#包压缩后约115MB。

      虽然不算小,但实际运行时通常只需几行代码,且仅有一个依赖项。

      1. 该仓库已运行ONNX模型。但ONNX模型不接受英文文本作为输入,而是接受分词后的音素。预处理环节是大部分依赖项的来源。

        这在我看来完全合理,但显然伴随一定的权衡。

        1. 对于空间敏感的应用程序(如嵌入式系统),能否将预处理移至编译时?

          你需要限制词汇表才能看到任何好处,但这可能是合理的。例如,你可以使用数字、单位和度量名称的枚举来处理动态时间、温度和其他仪表盘项目。

          对于更复杂的场景如离线导航,你本就需要存储地图数据。可将街道名称以令牌形式而非文本存储。添加几个转向指令后,即可实现无需设备端预处理的离线语音导航。

    3. 通常引入大量库有助于更快地开发和迭代。等整体框架成型后再移除这些库。

      1. 这种情况可能不同,但……通常那个“以后”永远不会到来。

  6. 我对MB大小并不太在意,关键是它纯粹依赖CPU且质量有保障,但我确实关心延迟问题。希望它能足够快。

    附带问题:有没有完全离线、无需训练的语音转文本模型?

    当我们能与AI以自然对话速度交流,而非“提问、停顿、回应”时,我将非常钦佩。

    1. 语音转文字的完全离线功能可以通过Whisper实现。部分应用程序提供此功能用于语音输入或转录。

    2. “棕色的狐狸跳过懒惰的狗..”

      每次生成平均耗时:1.28秒

      每秒处理字符数:30.35

      “嗯”

      每次生成平均耗时:0.22秒

      每秒处理字符数:9.23

      “棕色的狐狸跳过懒惰的狗……棕色的狐狸跳过懒惰的狗……”

      每次生成平均耗时:2.25秒

      每秒处理字符数:35.04

      处理器:0

      供应商ID:AuthenticAMD

      CPU家族:25

      型号:80

      型号名称:AMD Ryzen 7 5800H 带 Radeon 显卡

      步进:0

      微代码:0xa50000c

      CPU 频率:1397.397 MHz

      缓存大小:512 KB

      1. 嗯,这实际上似乎非常慢,Piper 可以在 Pi 4 上几乎瞬间输出一个句子,而 Pi 4 与 Ryzen 相比就像一只树懒,而且乍一看,语音质量似乎大致相同。

        如果你想将其纳入已经占用了大部分 GPU 资源的大语言模型(LLM)中,并且可以在剩余的有限 VRAM 中运行,那么这似乎是合理的。

      2. 假设大多数回答都超过一句,考虑到中间的令牌生成时间,2.25秒已经足够长了……更不用说需要推理的情况了!我们还没到那一步。

    3. 有没有人知道TTS模型中影响延迟的因素有哪些?

      1. 主要是模型大小和输入大小。一些使用注意机制的模型是O(N^2)

  7. 不错。

    虽然我认为这确实令人印象深刻且有特定应用场景(例如嵌入式领域),但我并不完全确定其质量足以取代更大规模的模型。

    目前已有fish-speech[1]和f5-tts[2]等开源模型在离线文本转语音领域推动质量极限。我用旧款NVIDIA 1660(6GB显存)测试了F5-TTS,效果还算不错,因此在稍新硬件上运行不会花费太多成本,且能实现多语言支持和零样本训练,质量提升显著。

    对于Android平台,有SherpaTTS[3],与大多数语音合成应用兼容性良好。

    1: https://github.com/fishaudio/fish-speech

    2: https://github.com/SWivid/F5-TTS

    3: https://github.com/woheller69/ttsengine

    1. 我们目前仅发布了该模型的预览版本。我们希望在未来版本中进一步优化该模型。

    2. Fish Speech 表示其权重仅限于非商业用途。

      此外,这两个模型的 VRAM 要求是什么?该模型拥有 1500 万个参数,可能在配备最新软件的低功耗、低于 $100 的计算机上运行。您的硬件是一块过时的 6GB GPU。

  8. 嗯,质量并不令人印象深刻。我正在寻找一个听起来非常自然的模型。对 piper/kokoro 不太满意,XTTS 的设置有点复杂。

    对于 STT,whisper 真的很棒。但我缺少一个好的 TTS。我不在乎投入 GPU 算力。但无论如何,这也不是我要的,听起来比 kokoro 还差。

    1. > 嗯,质量不太令人印象深刻。[…] 我不介意投入GPU算力。

      这不适合你。你应该根据不需要GPU这一事实来评估质量。

      在Tacotron2时代之前,我曾在Digital Ocean的droplets上运行过轻量级TTS和声码器模型,如GlowTTS和MelGAN。几乎不需要GPU。运行成本几乎为零。

      此后,趋势是向大规模扩展。我们需要更多模型来实现小型化。

      未来我们将看到小型模型在设备上运行。嵌入在不需要或不希望连接网络的玩具和工具中。部署在Raspberry Pi上。

      边缘AI将对机器人、玩具、消费品和游戏(即世界模型)产生巨大影响。

      1. > 这不适合你。你应该根据不需要GPU这一事实来评估质量。

        我明白,但这只是一个普遍的评论。在开源领域,目前还没有真正优秀的文本转语音(TTS)解决方案。我查看了这里的一些其他建议,但它们都有太多缺点。Dia听起来不错,但消息必须满足特定长度等要求,而且每次都会随机选择声音。我希望有一个自托管的解决方案,效果能与OpenAI媲美。

      1. 谢谢,我会试试!我喜欢它的声音,质量真的很好。但限制真的很严重(短于5秒不行,超过30秒也不行,每次都会播放随机声音,这些限制让它基本上无法作为助手使用)。

        但可能值得设置并看看它是否会随着时间改进。

        1. 你可以通过提供样本来获得一致的语音——是的,时间同步是需要解决的问题——基本上需要将输入分成块。

      1. 谢谢,我之前没听说过。我会去看看!样本听起来确实很棒。

  9. 微软和谷歌的一些TTS模型会犯最简单的错误。例如,它们有时会将“i.e.”读作“例如”。这对视力较差且使用TTS进行校对邮件等任务的人来说是个问题。

    为什么会这样?我真的很想知道。

    1. 嗯,语音合成器以读错各种东西而闻名。但我对基于大语言模型(LLM)的TTS感到非常担忧的是,其中一些模型无法读出大于100的数字。它们会尝试,但经常失败。至少tts-1-hd对几乎所有3位或4位数字都出现这种情况。当读出年份时,这种情况尤为明显。

      1. 从网页演示来看,这个模型在处理数字方面表现出色。它会快速读出数字,虽然会稍微混淆一些,但所有数字都是正确的,甚至包括7位数(未进一步测试)。

        看起来他们通过使用传统语音合成器的预处理阶段生成音素,并仅使用大语言模型(LLM)将这些音素转化为听起来比较自然的语音来规避此类问题。这限制了模型的自然程度,但它应该能够正确发音预处理能够发音的任何内容。

      2. 虽然并不完全相关,但人类也有同样的问题。

        在配音脚本编写时,我们总是明确写出所有内容。例如,我们不会写1 000 000,而是写一百万或百万。这是一个简单的例子,但如果数字是1 548 736,你几乎不可能直接读出来。然而,一百万,五十四万八千七百三十六可以直接读出,无需解析。

        同样适用于URL,例如W W W dot Google dot com。

        1. 关于人类,答案是既是又不是。如果一个人像tts-1-hd一样,在处理3位数和4位数时总是遇到问题,我会怀疑他们是否在某种程度上存在神经多样性。

          是的,我已经在提示中添加了你描述的类似指示。遗憾的是,我们不得不这样做。毕竟,大语言模型(LLM) TTS 已经解决了许多实际问题,比如文本中的语言切换或外语单词。它的发音比我们以前听过的任何东西都好。但它无法读取短数字。我觉得这个问题可能通过一些微调就能解决。但我实际上并不了解这项技术,所以……

    2. 它们通常是从视频字幕中训练而来的,而人类撰写字幕时也会犯这种错误。

    3. 你可能想用“例如”而不是“即”?

      这可能是故意为之,且属于训练数据的一部分,因为“例如”听起来比“即”好得多。对于大多数用途而言,语言的自然性比准确性更重要。

      1. 有时我会连续在句子中使用“例如”和“e.g.”以避免重复,甚至可能在同一个句子中使用(例如在括号中)。在这种情况下,将两者都读作“例如”会降低语言的自然性。

        无论如何,我希望TTS不要采取这种艺术自由。

      2. 我确实指的是“即”。这就是问题所在:-

  10. 哇,太棒了,希望未来能看到更多在CPU上运行的出色模型!

    1. 谢谢,未来我们将发布更多仅在CPU上运行的模型。

  11. 太棒了!迫不及待想将其集成到https://desktop.with.audio中。我已经使用KokorosTTS而无需GPU。它在Apple Silicon上运行得相当不错。

    这样的基础工具为一次性付费甚至免费工具的可能性打开了大门。

    1. 很期待看到结果。下周发布的完整模型将比当前版本更具表现力和更高质量,我们很期待看到您尝试。

  12. 这对英语很棒,但其他语言是否有类似方案?能否通过某种方式训练以支持其他语言?

  13. 模型训练数据来自哪里?是否有公开可用的数据集供人们使用?

  14. 好的,有很多详细信息和示例代码,很棒。但快速浏览后,我没有看到任何音频样本来说明质量?

      1. 谢谢!是的。它的质量绝对不是最好的,但它远胜于macOS的默认TTS选项(因为第三方开发者无法访问Siri的声音)。而且它的大小还不到许多现代网页的一半……

  15. 这些评论最初发布在另一个线程中(https://news.ycombinator.com/item?id=44806543)。我将它们移至此处,因为在HN上我们始终更倾向于为项目创作者的工作给予应有的认可。

    (这确实解释了为什么这些评论比它们现在所属的帖子更早)

  16. 其他地方展示的示例似乎来自一个更大的模型?

    在本地测试后,它听起来仍然相当机械,并且在处理包含数字的简单短语(如“简单如1-2-3”)时会彻底失败。如果80M模型能在保持Reddit帖子中展现的表达力同时改善这一点,那看起来很有前景。

  17. 你好。训练和微调代码也会发布吗?

    如果训练数据也能发布就太好了!

  18. 我很好奇为什么较小的TTS模型会产生金属质感的嗓音。

    发音听起来大致正确——我以为这是难点。而模型确实做得不错。但嗓音音色应该更容易调整?比如,一个简单的FIR滤波器就能改善吗?

    1. 我们根据个人风格、情绪、上下文和其他因素调整语调。一个准确的生成器可能需要在模型中编码所有这些信息。它会比不做这些处理的模型更大。

    2. “金属感”可能由于细节不足,无法轻易修复。

  19. 向各位专家提问:有哪些SOTA TTS模型能在普通笔记本电脑(32GB内存,4GB显存)上运行?我只想将TTS与SLM输出结合,并获得尽可能高的语音质量和人类相似度。

  20. 有人能将这个模型移植到ONNX格式吗?这样我们就不用做这么多繁琐的工具了。

  21. 虽然这不是最好的TTS模型,但它简直令人惊叹——如此小的模型就能实现,而且对于许多应用场景来说已经足够好了。

    1. 感谢,但请注意这个模型只是一个预览检查点,仅训练了10%。下周发布的完整版本质量将高得多,并将包含一个15M模型和一个80M模型。

  22. 反向的语音转文本技术中,有什么好的推荐吗?

  23. 我视力障碍,使用NVDA搭配语音合成器。这有什么新消息吗?我不明白!我的语音合成器叫Eloquence,大小是4089KB

    1. 你的Eloquence安装是否包含多种语言?我拥有的版本仅为1876KB,仅支持美国英语。而经典的DECtalk版本更小,我这里有一个仅638KB的版本(同样仅支持美国英语)。

  24. 我喜欢我们正在努力的方向。构建能够在CPU上运行的模型,AI将变得更加主流。

  25. 这感觉不同了。这感觉像是一个真正具有里程碑意义的发布。天啊。

    做得非常出色。质量卓越,技术参数简直令人难以置信。这让我想要尝试将它嵌入到电路板上,看看是否可行。

  26. 这是一个适合电路弯曲的有趣模型,因为语音风格向量相当小。

    例如,尝试在 `ref_s = self.voices[voice] 之后添加 np.random.shuffle(ref_s[0])`…

    编辑:如果你这样做,请注意你的系统音量设置。

  27. 我对这个模型是如何制作的感到非常困惑。它似乎不在代码中,或者这部分比我想象的要简单得多。它似乎使用了一个来自日本的先进库,不确定它到底有多复杂。

  28. 如何构建类似的模型,但适用于不同的语言?我以为既然是开源的,应该会有一些关于如何自行构建所有内容的说明。

  29. 您是否考虑过添加一些“渲染”示例,展示模型听起来的效果?

    我很好奇,但目前不想安装包并运行代码。

  30. 以这个规模来说还不错(以我对该领域非常有限的了解)!

    在几次测试中,“Male 2”的声音听起来还算合理,但我发现它在处理某些词组时存在问题,尤其是在上下文较少的情况下。我认为是短句的问题。

    例如,如果你只说“Hey gang!”,它会听起来像“Chay yang”。但如果你在后面加上一句,它会听起来有点不同(但仍然奇怪)。

        1. 运行本地版本需要 API 密钥和互联网连接?哈哈。典型的 .NET 项目。

          1. 是的,他们目前正在用他们的商业产品刷屏。

    1. 实际上,我发现读我文件中完全没有提及语言这一点令人烦躁。我认为从读我文件本身的语言来推断是不好的做法。我不想只凭德语读我文件就得到德语的 TTS 模型……

    2. 我试着用日语测试了一下,结果读出来是……“中文字符 中文字符 日文字符 中文字符……” 😀

      不过,如果和其他情况一样,未来我们可能会看到基于相同技术但针对不同语言的“模型”

    3. TTS 通常不是多语言的。人们可能会认为,对声音进行良好的语音描述就足够了,但语言和 TTS 的运作方式并非如此。

      (但不知为何,大语言模型(LLMs) 却能完美地处理多语言输入!仔细想想,这有点奇怪)

    4. 是的。常见问题解答中说,多语言功能正在开发中。

  31. 我对 TTS 模型还不太了解,但这是我可以像大语言模型(LLMs)一样插入到我自己的引擎中的东西吗?还是需要它随附的 Python 堆栈?

  32. 我很希望看到类似的东西被训练成多语言用途。它似乎与 piper 属于同一级别,但速度稍快一些。

  33. 太棒了!在TTS领域,人类相似性往往被过度强调,以牺牲用户访问性为代价。坦率地说,只要声音清晰,听一段时间后,大脑会过滤掉大多数初次听到的怪异之处。因此,许多视障人士仍然可以完美地使用espeak-ng。其他属性,如生成速度和大小,使其值得使用。

    我已经使用了一个自定义的AI有声读物生成程序[0]与Piper一起使用了一段时间,并且非常期待整合Kitten。历史上,Piper一直是唯一一个好的免费CPU仅本地模型选项,因此我非常高兴看到该领域有更多竞争。易于安装是一个大问题,因为piper历史上一直存在这个问题。(这就是为什么我不得不添加自动安装支持[0])

    [0] https://github.com/C-Loftus/QuickPiperAudiobook

  34. Atom n270运行Flite,搭配优质语音-slt-与这相比……它是否足够快来运行一个MUD?Flite几乎是实时速度……

  35. 我仍在寻找本地克隆语音的方法。我拥有不错的硬件。例如,我可以使用Mistral Small 3.1或其本地名称。预制语音也可能有趣,但我寻求的是自定义语音。或许可以通过向模型提供音频及其对应的文本,进行训练,然后输入新文本让其朗读。

  36. 不错。但若缺乏清晰度,我不会想长时间聆听。对于非英语用户在各类工具中的应用可能非常有效。

  37. 超越这个!Commodore C64 也有类似功能,名为 SAM(扬声器合成器),支持英语和波兰语。仅需 48 KB 内存

    超越这个!

    1. 这不是同一功能,但至少与“随处运行”的差距不是几个数量级

  38. 简而言之:如果你对 TTS 感兴趣,应该探索其他替代方案

    我尝试使用它…

    它的 Python 虚拟环境已膨胀至 6 GB 大小。演示句子

    > “这款高质量 TTS 模型无需 GPU 即可运行”

    工作时,渲染音频需要3秒。音频听起来像罐头里的声音。

    我尝试让一篇新闻文章被朗读出来,但失败了

    > [E:onnxruntime:, sequential_executor.cc:572 ExecuteKernel] 在运行Expand节点时返回非零状态码。名称:‘/bert/Expand’ > 状态消息:无效的Expand形状

    如果你对 TTS 感兴趣,应该探索其他替代方案

  39. say 在 MacOS 上仅为 193K

      ls -lah /usr/bin/say
      -rwxr-xr-x  1 root  wheel   193K 15 Nov  2024 /usr/bin/say
    

    用法:

      M1-Mac-mini ~ % say “hello world this is the kitten TTS model speaking”
    
    1. 这并不是一个恰当的比较。say 只是调用了自 Mac OS 8 以来就存在的语音合成 API。

      不过,‘经典’(AI 之前)的语音合成器比 kitten 小得多,所以你并非完全错误,只是理由不对。

      1. 这里顶级目录中的链接仓库也有几千兆字节的依赖项。

    2. 它链接了哪些动态库?还引入了哪些其他数据?

    3. 与现代基于神经网络的文本转语音引擎相比,`say`听起来糟糕透顶。

        1. 对我来说听起来更糟,尤其是在构建某些更复杂的句子或单词时。

    4. 在26 beta版本中尝试过,默认语音听起来比之前顺滑多了。

      运行`man say`显示“此工具使用语音合成管理器”,所以我猜Apple Intelligence相关功能已经启用。

      1. 与Apple Intelligence无关。语音合成管理器(在Classic Mac OS中,管理器一词用于指代系统组件)自90年代中期左右就已存在。你听到的变化很可能是新的或修改过的默认语音。

        1. > 与Apple Intelligence无关抱歉,我需要澄清一下——我的意思是,在macOS beta 26中,`say`命令的输出与系统设置 -> Apple Intelligence & Siri -> 语音 > 选择… 菜单中设置的选项一致。

          > 语音合成器管理器(在经典Mac OS中,“管理器”一词用于指代操作系统组件)

          在当年的彩虹iMac上玩这个功能特别有趣。

    5. 如果你创建一个调用 say 的 shell 脚本,该脚本会更小!

    1. 是的,XTTS2 对我来说性能不错,克隆效果也接受。

  40. 任何GitHub项目都缺少的一件事。一个几秒钟的演示。

  41. 我想知道要扩展它以支持自定义语音需要什么?

  42. 如果有一个本地化的版本,我终于可以构建我的小型亚马逊回声替代品。我希望所有语音合成都在本地设备上完成。

    1. 我现在正在使用 Home Assistant 语音做这件事。所有相关的 TTS、STT 和大语言模型(LLMs)都在我的网络上本地运行。它比其他所有语音助手产品都优越得多。(如果它只是一个纯粹的多模态模型就更好了)

  43. 优质的文本转语音功能本应作为原生功能内置于每台消费级设备中。这样用户可以自行选择是阅读还是聆听当前文本。

    我惊讶于手机制造商并未在其浏览器API中集成优质的文本转语音模型,例如,以便网站能够构建优质的音频界面。

    我个人非常希望打造一款用户可完全通过语音操作的文本编辑器。文本输入可能已经可以通过“语音输入”功能实现,Android和iOS都提供了这一功能。

    但似乎没有好的方法可以在不通过服务器来回传输数据的情况下输出语音文本。

    我希望的界面能够提供“语音输入”功能,然后可以使用命令如“好的编辑器,读出最后一段”或“好的编辑器,删除最后一句”。

    这样在行走时进行写作会很酷。只需将耳机连接到放在口袋里的手机即可。

    1. 在Mac OS上,几乎所有应用程序都可以通过内置语音(如Siri语音或一些较旧的语音)“说出”文本。所有操作均离线进行,甚至可以在终端中使用“say”命令。

      1. 几个月前我尝试用它在Apple Books中朗读一本EPUB电子书,结果以一种奇怪的方式彻底崩溃了。一开始还算正常,但翻了几页后,语音开始含糊不清、漏读单词、句子尾音拖长且未完整读完,最终完全静音。

        (我刚刚再次尝试,前几页并未出现该问题)

        > Siri语音或某些旧版语音

        您可以选择“增强版”和“高级版”的语音,这些语音文件较大,听起来既悦耳又现代。我之前使用的“Serena Premium”语音文件超过200MB,比这个Show HN要好得多。它听起来非常自然,但对任何稍显非标准的发音都处理得相当糟糕,这令人遗憾地涵盖了我阅读的几乎所有内容,例如人名/地名、技术/科学术语或科幻/奇幻作品中的新词汇。

        例如,在一本登山书籍中,藏族名字的发音简直令人费解,以至于您不得不核对文本。如果被念错的单词频繁出现,比如主角的名字,那使用起来就太痛苦了。

    2. 难道大多数人阅读速度不比听速快吗?这难道不是电话菜单如此糟糕的原因吗?

      > 但似乎没有好的方法能在不通过服务器往返生成音频的情况下输出语音文本

      正如人们指出的,自80年代以来,我们一直使用着质量平平的文本转语音技术。如果它真的有好处,人们即使使用不完善版本也会使用。

    1. 喜欢这个想法,但生成的文本对我来说过于华丽

      “一款新工具正在编程社区中引发热议和争议”

      直接给我事实,不要美国式的修饰。你不是在推销什么吧 =)

      1. 抱歉,刚看到这个。

        我完全同意,但它对华丽的语言非常执着。我尝试在提示中添加“不要使用空洞的短语,如‘不断演变的技术景观’!!!!”之类的内容,但它就是无法抗拒。

        我想对整个系统进行彻底改造,也许更新的模型会更好。或者,也许需要第二次大语言模型(LLM)处理来去除花哨的语言(笑)。

  44. 我们可以直接将它集成到浏览器中!

    — browserOS.com

  45. Elixir 朋友们。如何在Elixir中使用这个?我刚接触Elixir,大概15天后就能用上。

    1. 看起来是Python,所以可能可以通过https://github.com/livebook-dev/pythonx使用?但并行使用 huggingface/bumblebee 的想法也很不错,之前没见过也没想过,这确实适用于很多其他模型,好奇你是否能让它正常工作!我可能在几个月后自己尝试一下,所以随时在这里反馈或私信我!

      1. 我刚决定快速尝试一下,但在Mac上遇到了些问题,供参考。可能在Linux上运行更好,但我遇到了`curated-tokenizers`的编译问题,可能是curated-tokenizers中的setup.py或pyproject.toml文件有拼写错误,被AI发现: -Wno-sign-compare-Wno-strict-prototypes 应改为 -Wno-sign-compare -Wno-strict-prototypes,或许可以通过向 curated-tokenizers 提交 PR 或分叉项目来修复…

        可能还存在其他问题,且不确定是否需要依赖 kitten 直接不依赖的其他库,如 torch 或 torchaudio?但… 虽然不是5分钟就能解决的简单问题,但看起来这些问题或许可以逐步解决…

        供参考,我尝试的基本内容如下:

          Mix.install([:pythonx])
        
          Pythonx.uv_init(“”"
          [project]
          name = “project”
          version = “0.0.0”
          requires-python = “>=3.8”
          dependencies = [
            “kittentts @ https://github.com/KittenML/KittenTTS/releases/download/0.1/kittentts-0.1.0-py3-none-any.whl”
          ]
          “”")
        

        导致出现上述错误。

  46. 不错,这个模型看起来和StyleTTS 2很像?能确认一下吗?

  47. 看起来很棒。我一定会试一试并告诉你结果

  48. 有没有可以加载到移动应用上的语音转文本(反向方向)功能?

  49. 这个名字是不是在开玩笑,说“如果皇帝有一个 TTS 设备”?挺有趣的

  50. 有没有描述该模型架构的论文?

  51. 这是一个非常好的模型,感谢开源

    1. 非常感谢,这个模型只是一个预览检查点。下周发布的完整版本质量会高得多。

  52. 主页上没有几个示例真是令人恼火又愚蠢。难道你没想到这是人们最想听到的第一件事吗?

  53. 这个模型能在英特尔NPU单元上运行吗?

  54. 如果未来能支持 TypeScript 就太好了

  55. 现在,如果我们能将大语言模型(LLMs)做到这种规模就好了!我对 TTS 的内部运作了解不多,为什么它会如此简单呢?

  56. 我认为其中一个女性声音属于伊丽莎白·沃伦。

  57. 这太不可思议了。在没有GPU的情况下运行高质量的表达式文本转语音技术,这将改变游戏规则——尤其是对独立开发者和边缘设备应用而言。迫不及待想在树莓派上尝试。对开源这一举措表示巨大敬意。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的: