给开源项目加语音朗读,三种TTS方案对比与选型

给内部文档平台加"听文章"功能,选型期把三类TTS方案都试了一遍:云端API、开源端到端模型、传统拼接方案。对比记录和最终选型。

第一批测云端API,代表是Azure和几家国内厂商。优点是效果天花板高,韵律自然,多音字和数字朗读基本不用管;缺点是成本,按字符计费,日均两千万字符的阅读量一年算下来六位数,且文档内容走第三方,合规评审过不了关。这批留作兜底候选。

第二批测开源端到端模型,主力是Edge-TTS的免费通道、Piper和ChatTTS。Edge-TTS效果接近商用,但非官方接口有稳定性风险,不适合生产依赖。Piper是CPU友好的轻量方案,中文效果中等,胜在快,单句合成不到100毫秒。ChatTTS的自然度惊艳,但推理慢,长文档不稳定。这一档的问题是中文多音字和数字的坑要自己填:"行了"的行、"1.5万"这类读法错误率在5%左右,靠前端文本归一化修掉大半。

第三批传统方案听感明显落后,直接淘汰。

最终架构是分层:文本先走归一化管线,数字、英文缩写、符号转成朗读友好形式,再送TTS。

import re

def normalize(text: str) -> str:
    text = re.sub(r"(\d)\.(\d)", r"\1点\2", text)   # 1.5 -> 1点5
    text = text.replace("etc.", "等等")
    text = re.sub(r"(\d+)万", r"\1万", text)
    # 多音字按词典强制注音
    for word, pinyin in POLY_DICT.items():
        text = text.replace(word, pinyin)
    return text

产线用Piper做默认音色,CPU集群批量预合成加缓存,热门文档命中缓存零延迟;会员级别的高品质音色按量调云端API。整体成本比全量API方案降了九成,首屏等待控制在300毫秒内。TTS选型的关键不是谁效果最好,而是你的文本有多脏,前端归一化的投入常常比换模型更值。

上线后的迭代和踩坑补充。语速控制的需求是上线后才提的,老年人用户要求0.8倍速,直接对音频做时间拉伸音质劣化明显,后来在合成层按语速参数重新生成,双份缓存占用的存储翻了倍,做了LRU淘汰才控住。多音字词库的维护也持续了三个月,从用户反馈里又捞了四十多个错读case,词库现在三百多条,成了这个功能最值钱的资产。延迟优化上有个技巧,按段落流式合成,首段音频两秒内可播,用户感知的等待比整体合成完再播好太多,配合前端的双缓冲,长文档的朗读体验和商业产品已无差距。这个项目最大的教训是别小看TTS的"最后一步",模型再好,文本归一化做得糙,听感就是及格线以下。