原贴链接

大家好！我是长期潜水者，第一次在这里发帖。我最近一直在试验本地大型语言模型（LLM），尝试了所有可用的交互接口。对我来说一直可用的一个是Open WebUI。在Open WebUI中，可以在设置中启用OpenAI的文本到语音（TTS）端点，也可以选择用自己的解决方案替代。我喜欢Openedai - Speech项目，但我想利用微软Edge的TTS功能并节省系统资源。所以我创建了一个本地替代方案，可以返回免费的Edge TTS音频来代替OpenAI端点。我想在这里和大家分享这个项目。

image
。“your_api_key_here”实际上就是你的API密钥 - 不需要修改它。默认情况下，它在5050端口运行，以免干扰可能正在运行的其他服务。除了在Open WebUI中以及运行curl POST请求来验证功能外，我还没有使用过它，但在任何可以使用OpenAI的TTS API并且可以定义自己端点（url）的地方，这个都应该可行。可以通过环境变量自定义端口或一些默认设置等。如果没有docker或者不想安装它，可以在终端运行python脚本（所有这些都在自述文件中！）。如果有人需要帮助设置，请随时发表评论。如果喜欢这个项目，请在GitHub上给它点赞⭐️🙏🏻

讨论总结

原帖作者分享了一个可以在本地替代OpenAI的TTS API的微软Edge TTS API端点项目，包括项目使用方法等。评论者们从不同角度进行了回应，有人认可项目并提出希望能离线运行的期望，有人觉得这种API使用方式有趣，有人询问Edge - tts服务的可靠性和限制情况，还有人探讨能否对Google Chrome的TTS进行类似操作。总体氛围比较平和，大家都在围绕项目本身进行理性探讨。

主要观点

  1. 👍 对原帖作者的工作表示感谢并认可项目目前成果，同时希望能离线运行。
    • 支持理由：原帖分享的项目有价值，但离线运行功能会使其更加完善。
    • 反对声音：无。
  2. 🔥 认为用户bot欺骗企业API是有趣的API使用方式。
    • 正方观点：这种使用方式独特有趣。
    • 反方观点：无。
  3. 💡 对Edge - tts服务的可靠性不清楚衡量标准，但自己使用未遇到问题。
    • 解释：无法确切定义可靠性，不过个人使用体验尚可。
  4. 💡 猜测微软对Edge - tts服务有限制防止滥用，不建议非个人用途使用。
    • 解释：虽然不确定但基于微软的商业逻辑做出猜测，并给出使用建议。
  5. 💡 对是否能类似劫持Google Chrome的TTS表示疑问。
    • 解释：看到原帖对Edge的操作，联想到Chrome并提出疑问。

金句与有趣评论

  1. “😂 Thank you for your work! It would be great if it could run offline.”
    • 亮点：简洁地表达了对项目的认可和建设性期望。
  2. “🤔 Ylsid: Lol epic, userbots deceiving corporate APIs is my favourite kind of API use”
    • 亮点：提出一种独特有趣的关于API使用方式的看法。
  3. “👀 可靠? 我不确定如何衡量那个——但我还没有遇到问题。”
    • 亮点：诚实地表达对Edge - tts服务可靠性的不确定和自身使用情况。

情感分析

总体情感倾向是比较积极正面的。主要分歧点较少，大家基本都在理性探讨项目相关内容。可能的原因是项目本身是一种技术分享，大家更多关注技术方面的问题、改进方向和联想拓展，没有涉及到比较容易引发争议的话题。

趋势与预测

  • 新兴话题：能否对Google Chrome的TTS进行类似劫持操作可能会引发后续讨论。
  • 潜在影响：如果项目能不断完善，可能会影响到相关语音API的使用方式和人们在本地替代API方面的选择，也可能促使更多人探索不同浏览器语音功能的可操作性。

详细内容：

《关于 Microsoft Edge TTS API 本地替代方案的热门讨论》

在 Reddit 上，一位长期潜水的用户首次发帖，分享了自己创建的 Microsoft Edge TTS API 本地替代方案。该帖子获得了众多关注，引发了热烈讨论。

原帖介绍了作者在本地 LLM 实验中的发现，并详细阐述了如何利用 Microsoft Edge 的 TTS 功能创建替代 OpenAI TTS API 的本地方案，还提供了相关项目的 GitHub 链接https://github.com/travisvn/openai-edge-tts。

讨论的焦点主要集中在以下几个方面：

  • 离线运行问题：有人表示希望该方案能够离线运行。比如[Such_Football_758]称“感谢您的工作！要是能离线运行就太好了。”而[lapinjapan]回应称，由于 edge-tts Python 包的工作方式，它是向微软/Azure 发送模拟请求，所以目前无法离线运行，但 Open WebUI 文档中的 Openedai-speech 提供了部分可离线运行的 TTS 模型。
  • VRAM 资源使用：[Pedalnomica]提到“如果使用 piper 选项，VRAM 使用率为零，而且速度仍然很快。”[lapinjapan]回应“很高兴知道！”
  • 可用的声音选项：[Pedalnomica]表示喜欢 libritts_r 等，还提供了相关链接https://github.com/matatonic/openedai-speech/blob/main/voice_to_speaker.default.yaml。
  • 服务的可靠性和限流问题：[BakGikHung]询问“这个 edge-tts 服务的可靠性如何？如果生成大量音频，会有限流吗？”[lapinjapan]表示不确定如何衡量可靠性，自己尚未遇到问题，并猜测微软可能有速率限制以防止滥用。

讨论中的共识在于大家对新的技术方案表现出了浓厚兴趣，同时也对其功能完善和优化提出了期待。

特别有见地的观点如[JustinPooDough]提出“可以通过切换到 Microsoft Sam 声音来离线使用 api，延迟更低，效果确实不错。”这为解决离线问题提供了新思路。

总的来说，这次关于 Microsoft Edge TTS API 本地替代方案的讨论，展示了大家对新技术的探索和对优化改进的渴望。