Amazon Polly 生成式引擎升级：语音链路升级前，先核五处兼容面

先把结论说清楚：这次 Amazon Polly 生成式引擎的更新，官方说法是 drop-in——语音名不变、SynthesizeSpeech 调用不变、价格不变，输出更自然。但「drop-in」描述的是 API 契约层面的兼容，不是对你系统里所有隐式依赖的兼容。升级前真正要核的，是你自己的语音目录从哪来、缓存键里有没有 engine 和 voice、locale 兜底怎么走、请求参数有没有被写死、以及成本结构会不会变。下面按这五处展开。

材料说了什么，没说什么#

据 AWS 在 2026 年 10 月 26 日发布的周报，Polly 的生成式引擎这次升级后包含 57 个生成式语音、11 种语言、25 个 locale；新增 14 个语音，覆盖 9 个 locale；印地语和芬兰语首次 generally available；其中两个新语音是巴西葡萄牙语，名为 Leo 和 Carolina。周报同时称这是一次 drop-in 升级：语音名称、同一个 SynthesizeSpeech 调用、以及价格都保持不变（AWS Weekly Roundup, 2026-10-26，本文对 Polly 的事实引用均来自该篇周报）。

这些数字回答的是「有哪些新语音」，不回答「你的链路会不会受影响」。周报没有给出以下信息，本文也不做推断：每个 VoiceId 具体对应哪些 locale、各语音支持哪些 Engine 取值、生成式引擎的 SSML 标签支持范围、并发与字符速率配额、各区域可用性、旧语音的保留策略。这几项需要以 Polly 的 API 参考、配额页和 DescribeVoices 的实际返回为准，待核实。

兼容面一：语音目录不要硬编码#

新增 14 个语音本身不会破坏任何现有调用，它只会让「你系统里那份语音清单」变成过期快照。常见形态是前端下拉框写死一组 VoiceId、配置中心里存一份 JSON、集成测试里比对一份语音快照——这三种都不会报错，只会让你看不见新语音，或者更糟：某天下游传进来一个上游能识别、你本地校验不通过的 VoiceId。

把目录做成运行时拉取，是让「新增 14 个语音」从运维事件变成配置事件的前提。下面这段代码是未执行的示例，只表达筛选逻辑，参数与字段名请以你所用 SDK 版本的 API 参考为准：

# 未执行示例：字段名与分页行为需与当前 API 参考核对
import boto3

polly = boto3.client("polly", region_name="YOUR_REGION")
resp = polly.describe_voices()

generative = []
for v in resp["Voices"]:
    if "generative" in v.get("SupportedEngines", []):
        generative.append((v["Id"], v["LanguageCode"], v.get("Gender")))

for row in sorted(generative, key=lambda r: (r[1], r[0])):
    print(row)

# 若响应含 NextToken，需要继续翻页；此处省略

注意这段代码不产生任何结论性输出。你需要的是把它跑在目标区域、把结果存档，然后和线上配置做一次 diff——差集才是这次升级对你真正的影响面。

兼容面二：缓存键里要有 engine 和 voice#

这是升级后「听起来没变」最常见的原因，而且和 Polly 本身无关。TTS 输出通常会被缓存：对象存储、CDN、进程内 LRU、甚至数据库里的音频字段。如果缓存键只由文本和 locale 组成，那么你切换到生成式引擎、或者把 voice 从旧语音换成 Leo，请求仍然会命中旧音频，而且不会有任何报错。

# 缓存键组合示意，不是可运行代码
key = sha256("|".join([
    "polly",
    engine,              # standard / neural / generative
    voice_id,
    language_code,
    output_format,       # mp3 / ogg_vorbis / pcm
    str(sample_rate),
    text_type,           # text / ssml
    normalizer_version,  # 你的文本规范化规则版本号
    text_hash,
]))

两个容易被忽略的字段：text_type 和 normalizer_version。前者区分纯文本与 SSML——同一段字符串在两种 TextType 下语义完全不同；后者是给「你的预处理规则」留的版本位，规则一改，同样的原文会产出不同音频，但 text_hash 不会变。显式加版本号，比事后排查「为什么这段音频对不上」便宜得多。

兼容面三：新增语音不等于你的 locale 被覆盖#

「14 个新语音覆盖 9 个 locale」是增量描述，「57 个语音覆盖 25 个 locale」是总量描述。两者都不保证你关心的那个 locale 在生成式引擎下有语音。语音可用性是多对多的：一个 locale 可能对应多个 voice，一个 voice 也可能只属于一个 locale。

所以兜底链要写显式，而不是靠「找不到就报错」：目标 voice → 同 locale 的其他 voice → 同语言其他 locale → 标准引擎。每一跳都应该是配置项，并且能单独开关。这样在灰度时你可以只把某个 locale 的某一跳指向生成式，其余保持原样。

兼容面四：请求侧被写死的参数#

生成式引擎的请求形式没变，但请求里被写死的值可能有不同的支持范围。上线前逐项确认：OutputFormat 与 SampleRate 的组合是否仍被接受；TextType 为 ssml 时哪些标签有效；如果用了 LexiconNames 或 SpeechMarkTypes，在生成式引擎下行为是否一致。这几项在本次材料中没有说明，属于待核实，不要按标准引擎或神经引擎的行为直接外推。

兼容面五：价格不变，账单结构可能变#

周报说「价格保持不变」，指的是这次升级没有调价。但你的账单不只由单价决定：它还取决于字符量、请求数、缓存命中率。如果新语音的听感更好导致播放完成率上升、或者你把某些原本用标准引擎的场景切到生成式、或者团队因为多了 14 个语音而扩大了试听与预览流量，账单结构都会变，即使单价没动。

配额同理。并发上限、每秒字符数这类限制在本次材料中未提供，需查官方限额页。待核实，不要按旧值做容量规划。

上线前检查表#

边界：别把周报当 API 契约#

周报是对外沟通材料，它承诺的是调用形式与价格这层兼容。它不承诺 SSML 支持范围、配额数值、区域可用性或旧语音的保留时长，也不会替你做缓存键设计。本次材料只包含这一篇周报正文，没有 Polly 的 API 参考、配额页或区域表，因此本文对这几项一律标注待核实，而不是替官方下结论。真要升级，第一步不是改代码，是把 DescribeVoices 的返回值存档，和自己的配置对一次 diff。