TTS / STT 方案调研

调研背景

这次调研的核心需求很明确：我们希望把“文本转语音”和“语音转文本”接进产品里，但用户输入的语言并不固定，甚至可能出现中英文混杂的情况。

这会直接影响选型思路，因为很多传统语音服务虽然能力很强，但前提是你必须提前知道输入语言，或者至少先把候选语言范围圈出来。

如果做不到这一点，就会出现两个问题：

• TTS 阶段需要先猜用户文本是什么语言，否则声音和发音容易不对。
• STT 阶段如果平台要求你事先给出候选语言，而真实语种又不在候选列表里，识别结果就会偏掉。

所以这次调研真正要解决的，不只是“能不能转”，而是“在语言未知的前提下，谁更适合直接接进产品里”。

选型标准

TTS 的关注点

• 最好能自动适应输入文本语言。
• 最好能处理多语言或混合语言文本。
• 要有足够多的声音角色，不只是单一男声女声。
• 接入尽量简单。
• 便宜。

STT 的关注点

• 最好不要要求我们事先明确输入语音的语言。
• 如果必须传候选语言，范围不能太死。
• 便宜。

TTS：文本转语音

1. OpenAI

文档：https://platform.openai.com/docs/guides/text-to-speech
价格：https://platform.openai.com/docs/pricing/

OpenAI 现在的文本转语音主线已经不是早期那套简单 TTS 模型了，而是基于 gpt-4o-mini-tts 的 speech 接口。

它的优点很直接：

• 接口很简单，接入成本低。
• 支持多语言语音输出。
• 当前文档里提供了 13 个内置声音。
• 如果你的产品本来就在用 OpenAI 其他能力，整条链路会比较顺。

但它也有比较明显的问题：

• 官方文档明确提到这些声音“目前主要针对英语优化”。
• 声音角色的丰富度还是偏少。
• 如果你特别在意角色区分、音色风格和情绪表现，它可能不是最优选择。

价格上，当前文档给出的 gpt-4o-mini-tts 估算成本约为 $0.015 / minute。

我的判断是：如果重点是“接得快、链路统一、能力够用”，OpenAI 很合适；如果重点是“角色多样性”，它不是最有优的那个。

2. Azure Speech

文档：https://learn.microsoft.com/en-us/azure/ai-services/speech-service/index-text-to-speech
语言与语音：https://learn.microsoft.com/en-us/azure/ai-services/speech-service/language-support

这意味着什么？

• 如果你选的是普通单语音色，语言限制依然很明显。
• 但如果你选的是 Azure 提供的 multilingual voices，原来“必须先知道语言”的问题已经没有那么绝对了。

Azure 的优势也很明显：

• 语音库非常大，语言和地区覆盖广。
• 企业级能力成熟，和微软云体系结合紧。

它的问题主要在这里：

• 选型复杂度比 OpenAI 高，得先分清语音类型、区域和功能差异。
• 真正的多语言混合文本效果，仍然建议用自己的样例做一轮验证，不能只看文档描述。
• 价格和可用特性会受到区域、语音类型和套餐影响，不像 OpenAI 那样清楚。
• 它必须先指定输入语言，混合语言要靠 SSML/XML，非常麻烦。

不符合要求。

3. ElevenLabs

文档：https://elevenlabs.io/docs/overview/capabilities/text-to-speech
模型与语种：https://elevenlabs.io/docs/overview/models
价格：https://elevenlabs.io/pricing/api/

如果从“角色多、声音自然”这个角度看，ElevenLabs 很不错。

它的优势主要是：

• 官方文档写得很明确，当前 TTS 模型支持 32 种语言。
• 声音选择非常多，不只是几个固定角色。
• 低延迟模型和高质量模型分得比较清楚，适合不同场景。

如果看这次的需求，也就是“语言未知、最好支持多语言、声音角色丰富”，ElevenLabs 是最贴近需求的一档。

TTS 小结

• 如果你最重视声音角色、表达力和多语言体验，ElevenLabs 是最符合需求的选择。
• 如果你想优先追求接入简单、链路统一，并且对声音角色数量要求没那么高，OpenAI 是比较省心的选择。

STT：语音转文本

1. Google Cloud Speech-to-Text

文档：https://cloud.google.com/speech-to-text/v2/docs/multiple-languages

Google 的基础识别能力本身没什么问题，问题主要出在“语言未知”这个前提上。

它支持自动识别语言，但不是开放式自动识别，而是你先给它一组候选语言，它再从里面挑一个最匹配的。

官方文档里写得很清楚：

• 最多只能列 3 个候选语言。
• 这个能力更适合短语音，比如语音命令或搜索。

所以它的问题不是“不能自动识别”，而是“自动识别的前提仍然是你对输入语言范围心里有数”。

如果我们的产品场景真的是用户语言完全未知，或者语言组合太散，那 Google 就不合适。

2. Azure Speech

文档：https://learn.microsoft.com/en-us/azure/ai-services/speech-service/language-identification

Azure 的 STT 语言识别逻辑和 Google 很像，但文档写得更直白。

它要求你先提供候选语言列表，然后再做语言识别。当前官方文档里的限制是：

• at-start 模式最多 4 个候选语言。
• continuous 模式最多 10 个候选语言。
• 如果真实语言不在候选列表中，它仍然会返回候选列表里的某一个最接近结果。

这就意味着，如果我们的真实需求是“用户说什么语言我们根本不知道，甚至一句话里可能掺杂别的语言”，Azure 也不行。

所以 Azure 它更适合已知候选语言集合的场景，不适合开放式未知语种输入

3. OpenAI

文档：https://platform.openai.com/docs/guides/speech-to-text
价格：https://platform.openai.com/docs/pricing/

当前文档里，transcriptions 接口支持：

• gpt-4o-mini-transcribe
• gpt-4o-transcribe
• gpt-4o-transcribe-diarize

它的文档描述是，转写接口可以把音频转成“音频本身所使用的语言”文本，不需要你先给候选语言列表。这一点和 Google / Azure 的思路不一样。

对我们这种“输入语种未知”的需求来说，这个就太爽了。

就选它了。

结论

**TTS 是在 ElevenLabs、Azure、OpenAI 之间按侧重点取舍；STT 无脑选 OpenAI **