聊到语音合成模型排行这件事，我得先把话说在前头：排行榜不是判决书，它更像一张地图，告诉你在什么样的地形下往哪走比较靠谱。我自己踩过不少坑，同一个模型在别人榜单上排第一，搬到我的业务里却连及格线都够不着。问题往往不在模型，而在于榜单评的东西和我要的东西根本是两码事。所以这一章我想把排行的底层逻辑拆开揉碎地讲清楚，让各位看榜的时候心里有数。
1.1 排行目标与适用边界：通用榜、中文榜与场景榜的差异
我见过太多人拿着一个通用英文榜单去选中文语音合成模型，结果上线后发现多音字读得乱七八糟，声调也飘。通用榜的评测语料大多以英文为主，覆盖的语言现象有限，它的分数高只能说明模型在那套语料上表现不错。中文榜就不一样了，得专门处理声调、多音字、中英混读这些中文特有的麻烦事。我印象很深的一次是测某个开源模型，英文MOS能到4.3，换到中文新闻文本上直接掉到3.6，韵律断句全乱套。
场景榜是另一个维度。有声书场景和实时客服场景对模型的要求几乎是反着来的，前者要韵律自然、长文本稳定，后者要低延迟、流式输出。我做过一个对比实验，把同一批模型分别按有声书标准和实时交互标准排了两次，前十名里有四个模型的名次变化超过五名。这个结果让我彻底放弃“一个榜单走天下”的想法。看榜之前先问自己：我的业务场景最像哪一类，然后再去找对应的榜单。
1.2 客观指标设计：自然度、相似度、可懂度、韵律、实时率与资源占用
客观指标这块，我个人的体会是“能算出来的都不够全面，但算不出来的一定有问题”。自然度通常靠MOS预测模型来打分，速度快、成本低，缺点是预测模型本身有偏差，遇到训练数据分布外的音色容易失真。相似度在语音克隆任务里特别关键，常见做法是算说话人嵌入的余弦距离，我测过几个模型，余弦相似度都在0.9以上，但人耳一听就能分出高下，说明这个指标的分辨率有限。
可懂度一般用字错误率或者音素错误率来衡量，这个指标在噪声环境和长文本里特别能暴露问题。韵律就麻烦了，停顿位置、重音分布、语调起伏这些很难用单一数值概括。实时率我习惯用RTF来算，资源占用则要看显存和CPU的峰值。有个细节值得说：不少榜单把实时率和资源占用放在一起加权，我觉得这两件事应该分开看，流式场景看RTF，离线批量场景看吞吐量，混在一起容易误导选型。
1.3 主观评测方法：MOS、CMOS、ABX盲测与试听样本组织
主观评测是绕不开的一环，我做过几次小规模的MOS打分，深感这件事的门槛比想象中高。MOS要求听测者在一个五级量表上打分，样本要打散、顺序要随机，听测者还得经过筛选，否则有人天生对音质不敏感，打出来的分数参考价值很低。CMOS是两两比较，让听测者判断哪个更好，这个在模型差异不大的时候比MOS更灵敏。ABX盲测更严格，适合验证两个模型是否真的存在可感知差异。
试听样本的组织方式直接影响结论。我见过一些榜单每个模型只放两三句话的试听，样本短、内容单一，结果参考价值大打折扣。我自己整理样本时会覆盖新闻播报、口语对话、情感表达、多音字密集句这几种类型，每类至少十条。听测环境也得控制，用手机外放和用监听耳机听出来的结论可能完全不一样。这些细节榜单页面上往往不写，得自己多留个心眼。
1.4 数据来源、许可证与可复现性：榜单可信度的基础
数据来源这件事，我觉得是判断一个榜单靠不靠谱的第一道筛子。有些榜单的测试集和模型的训练集有重叠，分数虚高得离谱，这种情况在开源模型榜单里尤其常见。我现在看榜会先翻它的测试集说明，如果语料来源不明或者和训练数据同源，这个榜的分数我基本只信一半。许可证同样重要，模型权重是Apache还是CC-BY-NC，直接决定了能不能商用，有些榜单只比分数不提许可证，选型的时候容易踩雷。
可复现性是另一个硬指标。好的榜单会公开推理参数、随机种子、评测脚本，甚至提供Docker镜像。我试过复现某榜单的前三名，结果发现其中两个模型的分数在我本地环境里差了0.2以上，后来查出来是解码参数不一致导致的。从那以后，我对没有复现说明的榜单都保持距离。一个榜单如果连自己怎么算出来的都说不清楚，它的排名就很难让人信服。
1.5 排行榜权重设置：不同业务目标下的指标取舍
权重设置是排行榜里最容易被忽略、又最影响结论的部分。我见过一个榜单把自然度权重给到0.5，实时率只占0.1，这个配置对有声音书场景是合理的，对智能客服场景就完全跑偏了。业务目标不同，权重的分配逻辑就该跟着变。做实时交互的，RTF和首包延迟的权重得拉高；做离线批量生成的，吞吐量和长文本稳定性更值得关注；做品牌配音的，相似度和情感表现才是核心。
我自己选型时会做一张加权表，把业务指标拆成必须满足的硬门槛和可以权衡的软指标。硬门槛比如RTF必须小于0.3、许可证必须允许商用，不满足的直接淘汰。软指标再按重要性赋权排序。这么做的好处是不会被榜单的总分牵着鼻子走。排行榜给的是一个参考坐标系，权重怎么调，最终还得回到自己的业务场景里去找答案。
我一直觉得开源语音合成模型的排行榜是这个圈子里最“热闹”的地方。每隔几个月就有新模型冲榜，分数刷得飞起，社区的讨论也跟着沸腾。我自己在选型的时候踩过不少坑，也帮朋友看过好几次榜，慢慢发现一个问题：真正能读懂排行榜的人不多，大部分人只盯着那个总分看，完全忽略了榜单背后的收录逻辑、版本变化和指标权重。这一章我就从自己的实际经验出发，聊聊怎么把开源榜单读明白。
2.1 开源榜单收录标准、版本管理与更新频率
我最早接触开源TTS榜单的时候，以为只要是开源的模型就能上榜，后来才发现完全不是这么回事。不同的榜单收录标准差异很大，有的要求模型权重必须公开可下载，有的只要求代码开源就行，权重可以不开。这个区别直接决定了你能不能真正用上这个模型。我印象特别深的一次是看到一个模型在榜单上排名很靠前，兴冲冲去找权重，结果发现只放了训练代码，权重得自己训练，训练数据还不公开，这种“开源”对大多数开发者来说基本等于没有。
版本管理这件事我也吃过亏。有个模型三个月内更新了两个大版本，榜单上显示的分数是旧版本的，新版本因为架构调整分数反而降了一点，但榜单一直没更新。我照着榜单分数去选型，部署完才发现用的版本和榜单评测的版本对不上。现在我养成了一个习惯，看榜先看它的更新时间戳，超过两个月没更新的榜单我会特别谨慎，尤其是那些迭代速度快的模型，版本差一代性能可能就差一截。
更新频率这块也挺有意思。有些榜单是月度更新，有些是季度更新，还有一些是“随缘更新”，模型提交得多了就整理一次。我个人更信任固定周期更新的榜单，至少说明维护团队在做持续投入。那些长期不更新的榜单我基本只拿来当历史参考，不会作为选型的主要依据。
2.2 代表性开源模型横向对比：VITS、FastSpeech2、Bark、ChatTTS、CosyVoice、Fish Speech、GPT-SoVITS等
这批开源模型我几乎都部署过一遍，每一个都有让我印象深刻的地方，也都有让我头疼的时候。VITS算是老牌选手了，端到端架构在当时很先进，合成质量放到今天也不算差，但它的推理速度确实偏慢，而且对显存的要求不算低。我拿它做过一次长文本合成测试，生成十分钟的有声书内容，中间出现了两次韵律崩塌，句子断得莫名其妙。
FastSpeech2走的是另一条路线，非自回归架构让它的推理速度非常快，实时率表现很好，适合对延迟敏感的场景。但它的自然度上限摆在那里，和基于扩散或者大模型的方案比，听感上还是差了一口气。我一般把它用在批量生成需求量大、对音质要求没那么苛刻的场景里。
Bark刚出来的时候社区很兴奋，因为它能生成带情感和副语言特征的声音，笑声、叹气这些都能出来。我试了一段时间，发现它的稳定性是个大问题，同一个文本跑两次，韵律和情感表现可能完全不一样，长文本尤其容易出问题。ChatTTS在对话场景下的表现让我眼前一亮，韵律很自然，口语感很强，但它的音色控制能力相对有限，想复刻特定说话人的声音比较困难。
CosyVoice和Fish Speech是我最近用得比较多的两个。CosyVoice在零样本克隆上的表现让我挺惊讶的，给一段十几秒的参考音频，克隆出来的相似度相当高，而且跨语言的泛化能力也不错。Fish Speech的多语言支持做得比较扎实，中英混读的流畅度在我测过的开源模型里能排进前三。GPT-SoVITS则是另一个路线，它把GPT结构和SoVITS结合起来，小样本克隆的效果很好，社区活跃度也很高，各种微调教程和整合包满天飞，对新手比较友好。
横向对比下来，我的感受是没有一个模型能在所有维度上通吃。VITS和FastSpeech2是稳扎稳打的基础款，Bark和ChatTTS在表现力上有亮点但稳定性要打折扣，CosyVoice和Fish Speech在克隆和多语言上各有侧重，GPT-SoVITS在社区生态和小样本适配上优势明显。榜单上的排名只能告诉你它们在特定测试集上的相对位置，真正选型还得结合自己的场景去试。
2.3 零样本语音克隆与多说话人能力排行观察
零样本克隆这个方向这两年进步太快了，我记得两年前测某个模型的时候，给三十秒参考音频克隆出来的声音还带着明显的“电音感”，音色是像了，但自然度差很远。现在榜单上排在前面的几个模型，十几秒的参考音频就能克隆出相当自然的声音，相似度和稳定性都比以前好了一大截。
多说话人能力这块，榜单上的评测方式差异很大。有的榜单用固定说话人集合来测，每个模型在同样的说话人上跑一遍算平均分。有的榜单更看重跨说话人的泛化能力，用模型没见过的说话人来测。我觉得后者的参考价值更大，因为实际业务里你遇到的说话人大概率不在模型的训练集里。我做过一个小实验，把同一个模型在“见过”和“没见过”的说话人上分别测相似度，差距能到0.1以上，这个差距在听感上已经很明显了。
还有一个容易被忽略的点是克隆的稳定性。有些模型单次克隆效果很好，但换个参考音频、换个文本内容，表现就波动很大。榜单上通常只报告平均值，不会告诉你方差有多大。我自己整理了一个小表格，记录每个模型在不同参考音频长度、不同文本类型下的克隆表现，这个表格比榜单上的单一分数有用得多。
2.4 推理速度、部署成本与开源生态活跃度对比
推理速度这件事，榜单上的数字和实际部署的感受经常对不上。榜单通常跑在高端显卡上，RTF算出来很漂亮，但我自己在消费级显卡上部署的时候，有些模型的显存占用直接把我卡住了。VITS和FastSpeech2的显存需求相对友好，Bark和ChatTTS的显存占用就明显高出一截，尤其是生成长文本的时候，峰值显存能差出好几GB。
部署成本不光是显卡的事，还要看模型的依赖复杂度和工程化友好程度。有些模型依赖一大堆音频处理库，装环境就得折腾半天，Docker镜像也不一定好使。GPT-SoVITS在这块做得不错，社区贡献了很多一键整合包，Windows上双击就能跑，对非技术背景的用户很友好。CosyVoice和Fish Speech的部署相对标准，按照官方文档走一般不会出大问题。
生态活跃度是我现在越来越看重的一个指标。模型分数再高，如果社区没人讨论、issue没人回复、更新停滞，用起来会很孤独。我一般会看几个信号：GitHub上的最近提交时间、issue的响应速度、有没有活跃的讨论群组、有没有第三方工具和插件的支持。GPT-SoVITS和ChatTTS在这块的表现比较突出，社区里各种微调教程、音色分享、参数调优的帖子很多，遇到问题比较容易找到答案。Bark的社区曾经很活跃，但最近一段时间的更新频率明显降下来了。
2.5 开源语音合成模型排行榜常见误读与选型建议
我见过最常见的误读就是“排名高=适合我”。榜单的评测环境和你的业务环境之间的差距，可能比第一名和第十名之间的差距还大。我有个朋友做的是方言语音合成，看榜单买了个排名第一的模型，结果那模型压根不支持他的方言，分数再高也用不上。这种情况在开源榜单里特别常见，因为大部分榜单的测试集以普通话和英文为主，方言和小语种覆盖很少。
另一个误读是忽略许可证。有些模型在榜单上分数很高，但许可证是CC-BY-NC，不能商用。我见过有人拿这种模型做了个demo去谈客户，聊到最后才发现商用授权有问题，只能换模型重来。我现在看榜会先把许可证一栏翻出来，不能商用的模型直接跳过，不管它排第几。
选型建议这块，我的做法是“榜单初筛+本地实测”。榜单用来缩小范围，筛出前十或者前十五的模型，然后拿自己的业务数据跑一遍试听。试听的时候我会特别注意几个点：多音字读得对不对、长文本会不会断片、情感表达是不是自然、克隆相似度能不能接受。这几个点榜单上不一定有细分数据，但对你自己的业务来说可能比总分还重要。还有一点，别只看当前版本的分数，去翻一翻模型的更新日志，看看开发团队的迭代方向和你未来的需求是不是一致。一个方向对得上的第八名，可能比方向不对的第一名更有长期价值。
我这两年看过太多榜单，大部分都是英文基准跑出来的分数，拿到中文场景里一测，排名能翻个面。中文语音合成这件事，评测的水比英文深得多——声调、多音字、韵律断句、中英混读，每一项都能把模型拉开差距。我自己搭过一套中文评测流程，踩了不少坑，也积累了一些和通用榜单不太一样的观察。这一章就聊聊中文TTS评测里那些真正影响选型的东西。
3.1 中文评测数据集构建：新闻、口语、多音字、中英混读与长文本
我搭第一版中文测试集的时候特别天真，拿了一堆新闻稿就开跑了。跑完发现模型在新闻文体上表现都还不错，分数拉不开，换到口语对话场景立刻现原形。新闻文本规整、书面化，模型见过大量类似语料，自然能读得顺。口语文本里有语气词、有省略、有重复、有倒装，模型处理起来难度完全不一样。我现在的中文评测集会分成四个子集：新闻播报、日常口语、多音字专项、中英混读。每个子集单独算分，这样能看出模型在不同文体上的强弱项。
多音字这个子集是我花时间最多的。中文里多音字太多了，“行”“重”“长”“还”“得”这些字在不同语境下读音完全不同。我见过好几个模型把“银行行长”读成“yín háng háng zhǎng”，听起来特别出戏。评测集里我会刻意塞进大量多音字短语，比如“差不多”“出差”“参差”“差遣”放在一起，看模型能不能正确区分。有些模型在这一项上能拿到九成以上的准确率，有些只有六七成，这个差距在实际使用里非常致命。
中英混读是我觉得中文评测里最容易被忽视的一块。真实业务场景里，“打开App”“这个case需要review一下”这种混读太常见了。我测过的一些模型中文读得挺好，一碰到英文单词就开始用中文音标硬拼，“app”读成“阿普”，“review”读成“瑞view”，听感很割裂。混读评测不仅要看英文单词发音准不准，还要看中英切换处的韵律衔接自不自然。我在评测集里会放几类典型句子：纯英文单词夹在中文里、英文缩写、品牌名、技术术语，覆盖不同混读密度。
长文本评测是另一个维度。短句合成大部分模型都能做好，给一段三五百字的文本，问题就暴露了。有的模型读到后面音色漂移，有的韵律越来越平，有的直接断片或者重复。我一般会用一千字以上的文本做长文本测试，记录合成过程中的稳定性指标，比如音色一致性、韵律波动程度、断句错误次数。长文本能力对有书场景太重要了，榜单上的短句分数根本反映不出来。
3.2 中文声调、韵律与多音字处理能力对比
中文声调这件事，英文评测体系里基本没有对应项。普通话四个声调加上轻声，每个字的音高曲线都有讲究，声调读错了意思就变了。“妈麻马骂”这四个字声调不同意思完全不同，模型要是声调处理不准，合成出来的话听着像是外国人说的中文。我评测声调能力的时候会用一个最小对立对测试集，把声调不同但声母韵母相同的字放在相似句子里，看模型能不能稳定区分。
韵律这块比声调更微妙。中文的韵律不光涉及声调，还涉及停顿位置、重音分布、句末语调。我听过一些模型合成出来的句子，每个字发音都对，声调也准，但整句话听起来就是“机器人味儿”，问题出在韵律上。停顿位置不对会让句子断得莫名其妙，“今天天气不错我们去公园散步吧”断成“今天天气不错我们去/公园散步吧”和“今天天气不错/我们去公园散步吧”听感差很多。我评测韵律的时候会用带标点的长句，把模型输出的停顿位置和人工标注的参考停顿做对比。
多音字处理能力在模型之间的差距比我想象的大。我做过一轮横评，用同一百个多音字测试句跑七个模型，最好的模型准确率能到百分之九十三，最差的只有百分之六十八。有意思的是，排名靠前的模型在多音字上不一定强，有些模型总分很高但多音字一塌糊涂，因为它们的训练数据里多音字覆盖不够。这个指标我在选型的时候会单独拎出来看，毕竟多音字读错对用户体验的伤害比音质稍微差一点要大得多。
声调和韵律这两个能力在榜单上通常合并成一个“自然度”分数，我觉得这个合并损失了太多信息。一个模型可能声调很准但韵律很平，另一个模型韵律流畅但声调偶尔出错，合并成一个分数之后你根本分不清它们的问题在哪。我自己做评测的时候会把声调准确率和韵律自然度分开打分，虽然麻烦一点，但对选型的指导意义大得多。
3.3 情感表达、方言口音与角色化声音评测
情感表达这块在中文评测里一直是个难题。英文有比较成熟的情感标注体系，中文的情感表达更依赖语境和语气词，标注一致性很难保证。我试过用人工标注的情感语料做评测，找了三个人标注同一批句子的情感标签，一致性只有七成左右，有些句子到底算“开心”还是“平淡”几个人吵了半天。后来我换了个思路，不追求精确的情感标签，改成做A/B偏好测试，让试听者从两个版本里选更自然、更有感情的那个。
角色化声音是这两年需求涨得很快的方向。有声书、虚拟人、短视频配音都需要不同角色音色，御姐音、正太音、老年音、播音腔这些。我评测角色化能力的时候会让模型用同一段文本合成不同角色，然后找目标用户群体来听。有些模型在标准女声上表现很好，换成老年音就完全不像，音色变化很生硬。GPT-SoVITS和CosyVoice在这块相对灵活，社区里有大量角色音色模型可以直接用，评测的时候能明显感觉到它们在角色切换上的自然度更好。
方言口音是我觉得中文榜单上覆盖最不足的部分。普通话评测做得好，不代表方言场景能用。我测过粤语、四川话、东北话几个常见方言，大部分通用模型在没有方言数据微调的情况下表现都很差，声调系统完全对不上。有些模型号称支持方言，实际测试发现只是带了一点方言腔调，词汇和语法还是普通话的，听起来像是一个普通话主持人故意模仿方言。方言评测需要专门的方言测试集和方言母语者来做主观评测，成本很高，大部分榜单不愿意做。
口音评测还有一个维度是“带口音的普通话”。中国这么大，各地人说普通话都带点地方口音，模型能不能合成出带轻微口音的自然普通话，对有地方特色的内容场景挺重要的。我评测的时候会让试听者判断合成语音的“口音自然度”，有些模型合成出来的口音听起来像刻意模仿，不够自然，有些模型则能做出比较舒服的地域感。
3.4 中文零样本克隆相似度、稳定性与跨说话人泛化对比
中文零样本克隆的评测比英文难做，中文的音节结构和声调系统让克隆的难度更高。英文克隆主要看音色相似度，中文克隆还要看声调模式能不能复制过去。我测过一个模型，音色克隆得很像，但声调模式完全是它自己的，克隆出来的声音用原说话人的音色说着另一个人的腔调，感觉特别怪。中文克隆相似度评测我会从三个维度打分：音色相似度、声调相似度、发音习惯相似度。
稳定性这个问题在中文克隆里尤其突出。有些模型第一次克隆效果惊艳，换个参考音频就崩了。我做过一组测试，用同一个说话人的五段不同参考音频（时长不同、内容不同、录音质量不同）分别克隆，然后看相似度的波动范围。波动小的模型在实际业务里可靠得多，因为你没法保证用户上传的参考音频质量都很好。Fish Speech和CosyVoice在这块的稳定性我测下来属于第一梯队，参考音频质量下降时性能衰减比较平缓。
跨说话人泛化能力是我现在评测克隆模型时最看重的指标。实际业务里你遇到的说话人大概率不在模型训练集里，模型对“没见过”的说话人的克隆能力才是真实水平。我会把测试说话人分成两组，一组是模型训练数据里可能出现的说话人（比如公开数据集里的标准发音人），一组是完全冷门的说话人（比如我自己录的、网上找的小众播客主播）。两组之间的分数差距越小，说明泛化能力越好。这个差距在不同模型之间能到零点一五以上，选型的时候必须看。
克隆稳定性还有一个容易被忽略的点是跨文本稳定性。同一个参考音频，克隆模型读新闻和读口语的相似度可能不一样。我测过一个模型读新闻时相似度很高，读口语时音色明显漂移，听起来像换了一个人。这种问题在榜单上看不出来，因为大部分榜单只用一种文本类型做测试。我自己评测的时候会用至少三种文本类型分别测克隆相似度，取最低值作为参考。
3.5 中文榜单与英文榜单差异及跨语言迁移影响
我经常看到有人直接拿英文榜单的排名来选中文模型，这个做法风险很大。英文榜单的测试集、评测指标、主观评测组织方式都是围绕英文设计的，中文的语言特性在里面基本没有体现。一个模型在英文榜单上排前三，中文可能连前十都进不去。我对比过几个模型的英文和中文排名，位次变化最大的能差出十几名，声调处理和多音字能力是主要的拉开差距的因素。
评测指标的权重差异也很大。英文榜单里“可懂度”权重通常不高，因为英文的音素和单词边界比较清晰，大部分模型可懂度都不差。中文里可懂度的问题更突出，多音字读错、声调读错、断句断错都会直接影响可懂度。我建议中文评测里可懂度的权重应该比英文评测更高，但大部分直接翻译过来的榜单没有调整这个权重。
跨语言迁移是另一个值得关注的点。有些模型在英文上训练得很充分，迁移到中文时声调系统需要重新学习，迁移效果参差不齐。我测过几个以英文为主的模型，中文合成出来的声调走向明显不对，听起来像是一个外国人在说中文。反过来，一些中文优先训练的模型在英文上的表现反而还不错，因为英文的音素系统相对简单，中文模型的多语言能力往往被低估了。
跨语言迁移还有一个实际问题是中英混读场景下的语言切换自然度。单独评测中文和单独评测英文都还行，混在一起读的时候韵律衔接、语速匹配、音色一致性都会出问题。我在评测里会专门看混读句子的切换处，有些模型中文部分和英文部分的音色有细微差异，切换的时候能听出来像是两个人在说话。这种细节在单语榜单上完全测不出来，但对实际使用体验影响很大。
中文评测这件事没有捷径，必须用中文的数据、中文的评测维度、中文母语者的主观判断来做。通用榜单可以用来做初步筛选，真正决定选型的还得是自己搭一套中文评测流程，把业务场景里最常出现的文本类型和语言现象覆盖到。我现在选中文TTS模型，榜单只看个大概方向，最后拍板全靠自己那套测试集跑出来的结果。
榜单这东西我越用越觉得，脱离场景谈排名基本等于耍流氓。通用榜上排第一的模型，放到实时客服系统里可能延迟高到没法用，放到有声书场景里可能读个十分钟就开始音色漂移。我自己做过二十多次选型咨询，最常听到的需求就是“帮我看看哪个模型最好”，每次我都得先反问一句：你打算用在哪儿？这一章我把几个典型场景拆开聊，每个场景下的排行逻辑和选型要点差别真的挺大。
4.1 实时交互场景：流式合成、低延迟与并发能力排行
实时交互场景对TTS模型的要求跟其他场景完全不在一个维度上。语音助手、智能客服、游戏NPC对话这些场景，用户说完话之后系统要在几百毫秒内给出语音响应，超过一秒的延迟用户就能明显感觉到卡顿。我测过一批模型的首包延迟，差距大到离谱——有些流式模型能做到首包两百毫秒以内，有些标榜流式的模型实际测下来首包要八百多毫秒，这中间的差距在实时对话里是能决定产品生死的那种级别。
流式合成能力是第一个硬门槛。真正的流式合成要求模型支持文本分块输入、音频流式输出，推理过程中不需要等整段文本处理完才开始出声。我见过不少模型号称支持流式，实际测下来是“伪流式”——等用户说完一整句话才开始合成，只是合成分块返回而已，首包延迟根本没降下来。真流式和伪流式的区别在打断恢复场景里特别明显，用户说话打断之后，真流式模型能快速续上，伪流式模型得重新来过。CosyVoice、ChatTTS在流式这块的表现我测下来比较靠前，FastSpeech2系列经过优化也能做到低延迟，但声音自然度会打折扣。
并发能力是第二个容易被榜单忽略的维度。单路合成延迟低不代表并发场景下还能保持低延迟，有些模型单路测试时首包三百毫秒，开到五十路并发延迟直接飙到两秒以上。我评测并发能力的时候会看两个指标：不同并发量下的延迟曲线拐点，以及长稳跑过程中的内存增长情况。有模型跑着跑着内存持续上涨，几个小时之后服务就挂了，这种问题在榜单上永远看不到，但在生产环境里是灾难级的。做实时交互选型的时候，我一般会把“单路延迟”和“百路并发延迟”分开看，两个数字都好看的模型才值得进入下一轮测试。
4.2 有声书与长文本场景：韵律连贯性、稳定性与批量生成能力
有声书场景是我测过最折磨模型的场景之一。网络小说动辄几百章，一章几千字，模型要在这么长的文本上保持音色、韵律、情感的一致性，跟短句测试完全是两码事。我用五十章的小说文本做过一轮横评，大部分模型在第一章表现都不错，读到第十章左右开始出问题——有的音色慢慢漂移，听起来像是换了个配音员；有的韵律越来越平，刚开始还有点抑扬顿挫，后面直接变成念经；还有的读着读着把段落顺序搞乱了，或者重复读同一句话。
长文本韵律连贯性这块，模型之间的差距比短句测试大得多。短句测试的时候大家分数都集中在四点几分，拉开差距很难，长文本一测，好的模型和差的模型直接差出两个档次。我观察下来，影响长文本表现的核心因素是模型对上下文信息的利用方式。有些模型把长文本切成很短的片段独立合成，片段之间的韵律衔接很生硬，听感上能明显感觉到一句一句拼起来的痕迹。有些模型在切分的时候会带上下文窗口，衔接自然很多，但处理速度会慢一些。Fish Speech和CosyVoice在长文本上的节奏感我比较满意，GPT-SoVITS的表现取决于微调数据的质量，社区模型水平参差不齐。
批量生成能力是有声书场景里另一个实际约束。一本二十小时的有声书，如果用单路合成要跑好几天，批量页面的调度效率、失败重试机制、断点续跑能力都得考虑进去。我见过团队花大价钱买了效果很好的模型，结果批量生成一跑就崩，五百章文本只能成功合成三百章，剩余两百章得手动跑，运维成本比模型授权费还高。选型的时候我会专门测批量任务的稳定性，用两百个长短不一的文本做一轮批量测试，记录失败率、平均合成速度和输出文件的完整性。这个测试花不了太多时间，但能省掉后面很多麻烦。
4.3 短视频与虚拟人场景：情感表现、音色克隆与多样性
短视频和虚拟人场景对TTS的要求跟前面两个场景又不一样。这类场景文本短、更新频率高、对情感表现和音色多样性的要求排在延迟和稳定性前面。一条几十秒的短视频，配音要是一点感情没有像在念稿子，完播率直接掉一半。虚拟人直播更夸张，观众对声音的“人味儿”极其敏感，稍微机械一点弹幕就开始刷“AI”。我测这类场景的时候会把情感表现权重调到最高，自然度、音色多样性其次，延迟排在后面。
情感表现这块我测下来，模型之间的差距主要在对细粒度情感的控制能力上。基础的情感分类比如开心、悲伤、愤怒，大部分模型都能做，但仔细听就能分出高下——有些模型表达“开心”就是提高音调加上语速加快，听起来很假；有些模型能把开心处理出不同的层次，微笑式的开心、大笑式的开心、克制的喜悦，听感丰富很多。我评测的时候会用同一段文本让模型用不同情感读出来，然后找目标用户群体做偏好测试，不告诉他们哪个是哪个模型合成的，就让他们选“听起来最自然的”。结果经常是榜单排名靠后的模型在某些情感类型上反而更受欢迎，因为榜单的MOS评测很少细分情感维度。
音色克隆能力和多样性在短视频场景里是刚需。创作者希望用自己的声音批量产出内容，或者用不同的角色音色做剧情类视频。零样本克隆的相似度我在第3章已经聊过了，这里补充一点短视频场景特别看重的：克隆的“可编辑性”和“稳定性”。可编辑性是指克隆出来的音色能不能通过参数调整情感、语速、语调，有些模型的克隆音色只能用参考音频的状态读，想换个情绪就得重新录参考音频，用起来很麻烦。稳定性是指多条视频批量用同一个参考音频克隆，音色能不能保持一致。我见过团队用某个开源模型克隆了老板的声音做周会通知，结果每条通知听起来都像不同的人在模仿老板，最后还是换回了真人录音。CosyVoice和GPT-SoVITS在这块社区认可度比较高，可调性和稳定性平衡得比较好，Fish Speech的克隆质量也不错但微调门槛稍高一些。
4.4 离线与嵌入式场景：模型体积、算力需求与许可证约束
离线与嵌入式场景是榜单最容易忽略的一块，因为这块的评测维度跟在线服务完全不同。车机语音、智能家居、离线翻译机、工业设备语音提示，这些场景没有GPU服务器可用，模型要跑在ARM芯片或者低端CPU上，内存可能只有几百兆。我见过太多选型事故，团队看榜单选了个效果很好的模型，兴冲冲往车机上一部署，单核CPU上合成一句话要八秒钟，产品直接没法用。
模型体积和算力需求是嵌入式场景的第一道筛子。我一般会先看模型的参数量、推理时的内存峰值和单核CPU上的实时率，这三个指标不达标直接排除。有些模型效果好是好，参数量动辄几个G，量化压缩之后音质崩塌得厉害，压缩前是播音员水平，压缩后变成收音机杂音。VITS系列在这块优势比较明显，模型体积小、推理速度快，经过量化和剪枝之后在嵌入式设备上还能保持不错的音质。FastSpeech2的轻量版本也是嵌入式场景的常客，推理效率高但自然度上限比VITS低一些。Bark和ChatTTS这类模型在嵌入式场景基本不用考虑，模型体积和算力需求都远超设备承受范围。
许可证约束在离线场景里比在线场景更严格。在线服务用AGPL协议的开源模型，只要不修改代码、通过API调用，很多时候还能绕开一些限制。离线部署要把模型打包进硬件产品里发给客户，这时候许可证的传染性就会变成实打实的法律风险。我见过硬件团队把某个GPL协议的TTS模型直接烧进设备固件里售卖，后来被社区发现，整批产品召回重做固件，损失大得吓人。选型的时候我会建议对许可证做一轮硬性筛查，明确哪些协议能接受、哪些不能接受，筛查完再去看模型效果和性能。MIT和Apache协议的模型用起来最省心，CC协议要看具体条款，GPL和AGPL在闭源硬件产品里基本不要碰，除非法务明确点头。
4.5 企业级落地场景：安全合规、可维护性与服务化能力
企业级场景选型看的已经不只是模型效果了，效果只要达到及格线就行，真正决定能不能长期用的是安全合规、可维护性和服务化能力这些东西。我参与过不少企业采购决策，技术评分表上模型效果占的分值其实不高，合规和技术支持才是大头。一个模型效果好到天上去，数据要传到境外服务器上处理，对金融和医疗客户来说直接一票否决。
安全合规这块我一般会从三个角度查：数据不出境、声音克隆的授权机制、内容安全过滤能力。数据不出境要求模型能私有化部署，不接受把用户文本传到第三方云端。声音克隆的授权机制要求系统能记录谁克隆了谁的声音、授权范围是什么、能不能撤回，企业场景里老板的声音被员工偷偷克隆了做恶搞视频这种风险是真实存在的。内容安全过滤能力要求模型在合成的环节就有风控，不能等合成完了再去做审核，成本高而且有漏网之鱼。我测过几个企业级方案，有些把合规功能做得比较完善，克隆授权流程、水印嵌入、敏感词拦截都是内置的，有些开源模型要自己从头搭这些周边，工作量比模型集成本身还大。
可维护性和服务化能力是另一个关键分水岭。企业场景不是一锤子买卖，模型要跟着业务跑三五年，期间要升级、要扩缩容、要排障。我见过团队用某个学术圈口碑很好的模型，上线之后才发现社区基本不维护了，提issue三个月没人回，遇到问题只能自己啃代码。选型的时候我会评估项目的更新频率、文档完整度、社区响应速度和有没有商业支持渠道。CosyVoice、Fish Speech这几个项目的社区活跃度目前还可以，文档也在持续完善，但跟商业TTS服务比还是有不小差距。有些企业最后选的是商业API加开源自建混合方案，核心业务用商业服务保证稳定性，边缘场景用开源模型控制成本，这个思路我觉得挺务实。
服务化能力还包括可观测性和弹性扩展。生产级的TTS服务要能监控每路请求的延迟、失败率、音频质量指标，出问题要能快速定位是模型本身的问题还是资源调度的问题。开源模型直接部署的话这些能力基本为零，得自己搭监控、告警、限流、熔断全套。我评估的时候会看有没有现成的服务化封装，比如有没有gRPC接口、有没有健康检查端点、支不支持水平扩展。把这些周边成本算进去之后，有些看起来免费的方案总拥有成本并不低，选型的时候要把三五年内的运维人力成本也算进账里。
场景选型这件事说到底就是一句话：没有最好的模型，只有最合适的模型。实时交互看延迟和流式能力，有声书看长文本稳定性和批量效率，短视频看情感和克隆多样性，嵌入式看体积和许可证，企业级看合规和服务化。我建议每个团队在选型之前先把自己的场景拆成具体的技术指标，给每个指标设好及格线和期望线，拿着这张表去对榜单、跑测试，比对着一个综合排名拍脑袋靠谱得多。
排行榜我看了三年多，越看越觉得它像一张地图——能告诉你大致方向，但真要走这条路，坑在哪里、路况怎么样，地图上不一定标得清楚。很多团队拿着榜单排名直接拍板选型，上线之后才发现问题一堆。这一章我想聊聊怎么把榜单用对，怎么避开那些榜单不会告诉你的坑，以及这个领域接下来一两年大概会往哪走。
5.1 如何结合试听、A/B测试与业务指标使用排行榜
排行榜最大的价值是缩小候选集，不是替你做决定。我一般的做法是拿榜单当前二十名当海选名单，先按场景硬指标筛掉一批——实时场景看延迟、嵌入式看模型体积、企业级看许可证，筛完能剩五到八个模型。这五到八个再进试听环节，我自己会准备一套测试文本，覆盖业务里最典型的句子类型，新闻播报、口语对话、数字金额、中英混读各来几条，每个模型合成一遍，戴上耳机逐条听。试听这步听起来很土，但特别管用，有些模型榜单分数很高，一听就露馅——机械感重、断句奇怪、多音字乱读。
试听之后是A/B测试，这一步很多团队会跳过，我觉得挺可惜。试听是你自己在听，A/B测试是让真实用户在不被告知的情况下做选择。我做过一个短视频配音的A/B测试，两个模型在榜单上差了十几名，盲测结果目标用户对排名靠后那个的偏好率反而高出十五个百分点。原因很简单，榜单MOS评测用的是通用朗读文本，短视频配音需要的情感张力和口语感在评测集里体现不出来。A/B测试的设计要注意控制变量，同一段文本、同一个参考音色、同一个播放环境，只换模型，让用户选“哪个更愿意听完”。样本量不用太大，几十个目标用户就能看出趋势。
业务指标是最后一层校验。模型选出来之后要跑一轮小流量线上测试，看合成音频对业务核心指标的影响——有声书场景看完播率、客服场景看用户满意度、短视频场景看互动率。我见过一个团队榜单选型加试听加A/B测试都过了，上线之后发现用户投诉率反而涨了，查了半天才发现是某个模型在特定文本模式下会偶发吞字，测试集里刚好没覆盖到。小流量上线跑两周，把线上bad case收集回来分析，比任何离线评测都真实。这三层筛下来，榜单排名第几已经不重要了，能活到最后的模型就是适合你的模型。
5.2 榜单复现与基准污染：版本、数据与参数差异的影响
榜单复现这件事我踩过不少坑，说出来都是泪。有次看到一个模型在某个榜单上自然度排第一，我兴冲冲下载下来想复现，结果怎么调都差一大截。折腾了两天才发现问题——榜单评测用的是官方推理脚本加默认参数，我用的社区封装版默认参数不一样，语速快了百分之十，韵律模型没加载对，自然度直接掉了一个档。后来我养成了一个习惯，复现榜单结果之前先把评测脚本、模型版本、推理参数、音频后处理流程全部对齐，任何一个环节有差异，结果就没法比。
版本差异是基准污染里最隐蔽的一种。语音合成模型迭代速度快，同一个模型名字下可能藏着十几个版本，v1.0和v1.5的合成质量能差出两条街。更麻烦的是有些榜单更新不及时，模型发了新版本榜单上还挂着老版本的分数，你拿着榜单去选型，选到的是半年前的水平。我现在的做法是看榜单先看更新日期，超过三个月的榜单只当参考，具体版本号要去模型仓库里核对，最好能把榜单引用的commit hash找出来，确保你测的就是榜单测的那个东西。
数据集泄漏和评测集污染是另一个层面的问题。语音合成领域公开评测集就那么几个，模型训练的时候有没有偷偷把评测集数据喂进去，外部很难查证。我观察到一些模型在某个特定评测集上分数高得离谱，换个自建测试集分数就回归平庸，这种情况多少有点嫌疑。榜单制作者如果不够严谨，评测集和训练集有重叠，排名就会失真。我现在看榜单会关注它有没有用私有测试集或者动态更新的测试集，固定公开测试集跑出来的分数，参考价值要打个折扣。榜单复现不是让你怀疑一切，是让你知道数字背后的前提条件，别把榜单分数当成物理定律。
5.3 许可证、商用合规与声音克隆伦理风险
许可证这事我在第4章嵌入式场景里提过一嘴，这里展开说说，因为它值得单独拿出来讲。我见过太多团队在选型的时候完全不看license，模型效果好就用，等到产品要上线了法务一审查，发现用的是GPL协议，整个技术栈面临重写风险。语音合成模型常见的协议有MIT、Apache 2.0、CC-BY-NC、GPL、AGPL这几类，MIT和Apache最宽松，商用基本没限制；CC-BY-NC禁止商用，拿来做内部工具可以，做对外产品不行；GPL和AGPL有传染性，修改代码或者通过网络提供服务都可能触发开源义务。我建议选型第一轮就把许可证筛一遍，把不能接受的协议直接排除，别等模型集成完了再回头换，那成本高得离谱。
声音克隆的伦理风险比许可证更棘手，因为它不光是法律问题，还是声誉问题。我见过一个案例，某公司用开源模型克隆了知名主播的声音做产品宣传，主播本人发现后发了一条微博，公司当天股价跌了八个点。技术上看克隆相似度很高，法律上看有没有侵犯声音权要看具体司法管辖区的规定，但舆论场上没人跟你讲技术细节。企业场景里我建议声音克隆功能一定配套授权管理——谁克隆了谁、授权范围是什么、授权期限多长、能不能一键撤回，这些流程要产品化，不能靠人工台账。有些团队觉得这些是法务的事跟技术无关，等出事的时候技术第一个被拉出来背锅。
合成内容的标识义务也越来越明确。国内生成式AI相关管理规定要求AI生成内容要有显著标识，语音合成这块目前执行还不算严格，但趋势是往严的方向走。我建议做语音合成产品的团队提前把音频水印能力纳进来，合成音频里嵌入不可听但可检测的标识信息，既能满足合规要求，也能在出现滥用的时候追溯来源。开源模型里带水印能力的还不多，有些商业TTS服务已经开始提供这功能，选型的时候可以把水印支持作为加分项。技术团队多往前想一步，后面少踩很多雷。
5.4 技术趋势：大模型TTS、流式端到端、情感可控与多语言统一
语音合成技术这两年变化很快，榜单半年不更新排名可能就翻天了。我观察下来有几个趋势比较明确，值得在选型的时候提前布局。大模型TTS是最大的变量，基于大语言模型架构的语音合成方案在自然度和表现力上明显比传统方案高一个档次，零样本克隆能力也是传统模型比不了的。大模型TTS的代价是推理成本高、延迟大，目前更适合离线生成或者对延迟不敏感的場景，在线实时场景还用不了。但我判断这个差距会在一年到两年内缩小，模型蒸馏、量化、推理优化都在快速推进，选型的时候可以把大模型TTS作为技术储备关注着。
流式端到端是另一个明确方向。现在的流式方案大多是文本前端加声学模型加声码器串起来，每个模块都有延迟，加起来首包延迟很难压到极致。端到端流式合成把整个链路做成一个模型，文本进音频出，中间没有模块拼接的延迟损耗，首包延迟能压到一百毫秒以内。这个方向目前工程化程度还不高，有些学术论文里的方案听着很好，实际部署稳定性不够。我建议实时交互场景的团队保持关注，但生产环境暂时还是用成熟的流式方案，端到端流式等生态再成熟一两轮再上。
情感可控和多语言统一是两个产品层面的趋势。情感可控方面，粗粒度情感标签已经不够用了，客户要的是细粒度控制——同一句话用“克制的开心”还是“放肆的开心”要能参数化调节。多语言统一是指一个模型同时支持中英日韩多语言合成，跨语言音色保持一致，这对出海产品和多语言内容平台很有吸引力。这两个方向目前榜单覆盖得不够充分，情感维度太主观难以标准化排名，多语言评测集也还没统一。我的判断是未来一年会出现专门的情感榜和多语言榜，现在选型如果有这方面需求，试听和自建测试比看榜单更重要。
5.5 面向搜索与内容运营的榜单更新机制：关键词、专题与长期维护
这一节聊点偏运营的内容，可能跟纯技术选型关系不大，但如果你在做技术内容站或者评测媒体，榜单的长期维护机制会直接影响流量和用户信任。我做语音合成内容这几年观察到一个现象——榜单类内容的搜索流量有很明显的长尾效应，“语音合成模型排行”“TTS模型对比”这类关键词的搜索需求稳定存在，用户搜的时候带着明确的选型意图。这类内容一旦排名上去，生命周期比单篇技术文章长得多，但前提是得持续更新，三个月不维护的榜单页用户点进来看到半年前的数据，跳出率会很高，搜索引擎也会慢慢降权。
更新机制我建议分三个层次。第一层是关键词布局，榜单页要覆盖核心词加长尾词的组合，“语音合成模型排行”是核心词，“开源TTS模型对比2025”“中文语音合成模型哪个好”是长尾词，一个榜单页可以把这些词自然融进去，不用堆砌，每个小节标题带一个词就够。第二层是专题化组织，不要只做一个大而全的排行榜，按场景拆成实时交互榜、有声书榜、嵌入式榜几个子页面，每个子页面针对不同的搜索意图，互相内链，形成专题矩阵。用户搜“车机语音合成模型”直接落到嵌入式榜，转化率比落到通用榜高得多。第三层是长期维护节奏，我的做法是季度小更新、半年大更新，小更新补新模型、修过时数据，大更新重跑评测、调整权重、刷新版本号，每次更新在页面上标明更新时间，用户和搜索引擎都能感知到内容在维护。
最后说一个容易被忽略的点——榜单页的可信度建设。用户看榜单不只是看排名，还会看你怎么测的、数据哪来的、有没有利益相关。我在榜单页里固定放一个评测方法说明区块，讲清楚测试环境、测试集来源、评分标准、有没有厂商赞助，宁可写得啰嗦一点，用户信任度会高很多。有厂商找过我想把他们的模型排名往前调，我一般直接拒绝，榜单一旦掺了商业利益，长期积累的信任就没了。这个领域不大，做内容的人也不多，口碑坏了很难捡回来。技术内容运营说到底跟技术选型是一个道理——短期看流量，长期看信任，能活下来的都是认真维护的那些。
