Inworld 发布 Realtime TTS-2 更新：引入推理功能并优化性能

今天我们发布了两项针对 Realtime TTS-2 的更新。推理（Reasoning）功能使其成为首个在开口说话前决定如何表达某句话的语音模型：TTS-2 会读取文本以及你发送的任何上下文，生成简短的演绎方向指示，然后进行演绎。一个更新的模型能够更快地生成语音，更紧密地匹配参考音色，并在长会话和长文本中保持稳定。

两项更新均使用相同的公共模型 ID inworld-tts-2 运行。随着按区域逐步推出，现有集成会自动获得此次更新；推理功能为可选，只需在请求中添加一个字段即可启用。

共 2 项更新中的第 1 项

推理

Realtime TTS‑2 读取一句话及其上下文，决定其应有的听感，然后进行演绎。

01工作原理

语音模型会读取给定的文本，但没有任何东西告诉它们这些文本应该如何发音。在消费级应用中，你的大语言模型会在运行时生成每一条回复，因此没有人可以手动添加这种方向性指导。像“我真不敢相信你做了那件事。”这样的句子可能表达喜悦、受伤或难以置信，而在缺乏上下文的情况下，模型会对每种情况给出同样中性的朗读效果。

推理在合成之前增加了一个步骤，在同一个 TTS-2 请求内部：

无需调用或托管额外服务。推理步骤是一个语言模型，其唯一职责是为 TTS-2 编写表达方向。该方向随 API 响应返回，你自己设置的任何指令或标签都具有更高优先级。

02为何它优于情感标签

情感标签是一个固定列表。每一行都需要选择一个标签，比如 [happy]，通常由遵循提示规则的你自己的大语言模型来完成，然后语音会播放该标签。而推理（Reasoning）则写出一段自由形式的指导语，例如 warm, delighted, speaking through a smile，这样单次朗读就能根据你提供的上下文同时设定情感、语气和节奏。

节省时间

提示词中无需标签词汇，无需维护规则，也无需手动编写脚本进行标注。启用它并传入你已有的上下文即可。

听起来更自然

每一行都会根据其上下文获得一个方向指示，因此演绎方式会像真人一样有所变化，而不是在少数几种预设情绪之间切换。

03今天就来试试

在请求中启用 Reasoning 功能，并将上下文传入其专属字段。上下文会影响演绎风格，但不会被朗读出来。响应中包含生成的方向指示，因此你可以将其与输入一起记录，并在朗读效果不佳时调整你的上下文。

请求

curl -X POST https://api.inworld.ai/tts/v1/voice \
  -H "Authorization: Basic $INWORLD_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<'JSON'
{
  "text": "I can't believe you did that.",
  "voiceId": "Reed",
  "modelId": "inworld-tts-2",
  "synthesisContext": {
    "reasoning": "REASONING_ON",
    "reasoningContext": "A friend has arranged an unexpected reunion."
  }
}
JSON

响应

{
  "audioContent": "UklGRiQAAABXQVZFZm10...",
  "usage": { "processedCharactersCount": 29, "modelId": "inworld-tts-2" },
  "reasoningInstruction": "Breathless and stunned, like a friend seeing a long-lost face."
}

推理在 TTS-2 的合成、流式传输和异步请求上运行。这适合为每条消息生成音频，或提前生成音频，例如来自伴侣的语音消息、生成的故事和课程、有声书，或预生成的角色台词。WebSocket 流式传输、双向通信（包括实时 API）以及批量合成即将推出。

有关参数和限制，请参阅推理文档。

更新 2/2

更新的模型

生成速度更快，语音匹配更准确，长时间会话更稳定，使用相同的模型 ID，价格不变。

04跨话语长度的更快生成

更新的模型解决了在实际负载中显现出的失败问题。语音应用可以从简短的确认过渡到详细的解释，然后大声读出日期或确认码。一个陪伴者可能会在整个会话中继续这种交流。在这些过程中，语音可能会逐渐变化，长段落中可能会跳过某个词，或者句末的辅音可能会丢失。

与 TTS-2 的前一版本相比，短语句的生成速度提高了约 13%，中等长度语句的生成速度提高了约 9%。生成速度在不同输入长度之间也更加一致。这对于响应长度各异的应用程序很重要：语音代理可能先用几个字确认请求，然后再给出更长的解释；导师也可能在快速纠正和完整示例之间切换。

这些数字描述的是 TTS 生成性能。听众体验到的响应延迟还取决于轮次检测、语言模型生成、网络传输和播放缓冲。在评估应用程序的延迟时，应分别测量这些组件。

05更一致的声音和更可靠的语音

更新后的模型提升了 Stable 模式下的声音相似度，尤其是对于那些一直难以准确克隆的声音，并减少了长时间双工会话中的声音漂移。自定义声音更贴近参考说话人，而陪伴角色和语音智能体在对话推进过程中能保持更一致的身份特征。

它还修复了 TTS-2 在长语句中跳过单词或在某些词尾丢失爆破音的情况。保留这些辅音（如 /p/、/t/ 和 /k/）可使受影响的词尾发音更清晰。对于有声书和朗读文章，完整的朗读保留了源文本；对于语言学习者和来电者，清晰的发音使口语细节更容易理解。

创意模式现在能产生更自然的演绎，并带有轻微的内置引导。对于互动角色和同伴，这改善了台词的表演方式以及声音的听感。当语音一致性是首要考虑时，请使用稳定模式；而在表现力更强的演绎更符合体验的场景下，请测试创意模式。音频生成文档解释了可用的演绎模式。

在完整段落和扩展会话中评估这些改进，使用你的应用程序实际生成的行。将克隆语音与其参考进行对比，听取对话开头和结尾的样本以检测漂移，并检查生成的语音与源文本之间是否有遗漏的词语或结尾不清的情况。将这些评估与自然度和表现力分开进行。

06独立的速度和准确性基准测试

Cekura 的独立基准测试为 TTS-2 系列提供了背景信息。其结果更新于 2026 年 10 月 28 日，区分了 TTS-2 与 Realtime TTS-2 Flash：

• Realtime TTS-2 Flash：在完整文本预先提供的情况下，首个可听声音的中位数为 46 毫秒，p90 为 73 毫秒。Cekura 将其列为其测试的 27 个模型中非流式类别最快的模型。其逐词输入测试是另一项独立的衡量指标。
• Realtime TTS-2：在数字和简写、代码和地址、依赖上下文的词汇以及医学术语方面，正确朗读困难项目的比例为 93.4%。

Cekura 从发送完整句子的时刻计时到第一次可听声音的结果。准确率结果是根据语音转文本的转录内容估算的，而非人工聆听。每个模型都从美国东部云区域朗读相同的104条代理句子，每条重复三次；详见方法论。这些是Cekura测试过的模型在此更新之前且未启用推理功能时的结果。上述13%和9%的速度提升来自我们对更新后模型与先前模型的比较。

07保持集成并聆听差异

如果您已经在使用 inworld-tts-2，请继续使用您现有的集成。此次更新在该标识符背后推出，无需进行 API 迁移，价格也不变。推理功能为可选启用：在您于请求中启用之前，音频方面不会发生任何变化。

请在对您的产品至关重要的输入上试用更新后的模型：例如在稳定模式下使用具有挑战性的参考语音、扩展的双工对话，或此前容易丢失字词长段落。如果您已保存基线音频，请使用相同的文本、语音和设置以确保比较有效。然后，在几条内容中启用推理功能，并使用您的应用已有的上下文，对比朗读效果。

为了实现可重复的评估，Inworld TTS 开放评估工具包提供了逐样本的测量数据和报告，让你能够检查聚合分数背后的错误。将转录文本检查与针对你的生产语音和语言的听力测试相结合。