语音模型发布 实时语音 ai

你要做实时语音功能，翻了一圈发布稿，参数都挺好看，但落到自己项目里还是不知道该接哪个。这篇不讲谁排第几，只给一套可执行的筛选顺序：先量自己的延迟基线，再分清链路里是识别、合成还是端到端对话，然后按并发和授权卡一遍，最后人工听一遍定稿。具体数字和规格到站内对应页面看当时的记录。

你要做实时语音功能，翻了一圈发布稿，参数看着都挺好看，但落到自己项目里还是不知道该接哪个。原因通常不在模型本身，而在于你没先把自家链路的约束量清楚——延迟预算、链路角色、并发上限、授权范围，这四条任何一条没对齐，选出来的东西到上线那天都会返工。

这篇不讲谁排第几，也不给规格清单，只给一套可执行的筛选顺序：先量自己的延迟基线，再分清链路里是识别、合成还是端到端对话，然后按并发和授权卡一遍，最后人工听一遍定稿。具体数字和规格口径，到站内对应页面看当时的记录，别拿发布稿上的宣传值当自己的验收线。

先量你自己的延迟预算，再谈模型

实时语音的体感延迟是分段叠加的：上行网络、识别、模型思考、合成、下行播放，任何一段超标，整体就「不像人」。所以第一步不是看模型，是量你自己的网络基线。先用 /tools/speed-test 量出你所在网络到接口的往返基线，再倒推各部分能分到多少预算，剩下的才是你能给模型的空间。

1. 测网络基线用 /tools/speed-test 在真实办公网和真实移动网络下各测一轮，记下往返时间和抖动范围，别只测机房到机房。
2. 拆延迟预算按上行、识别、思考、合成、下行五段列一张表，给每段填一个可接受上限，加起来不超过你的体感红线。
3. 带并发复测单请求跑得快不代表高峰可用，用接近真实峰值的同时在线人数再跑一遍，重点看排队和限流行为。
4. 核对披露口径各家的并发上限、超限策略、限流表现到 /voice 和 /official-api 看当时披露的记录，不要凭发布稿推测。

把场景分成三档：打断式对话最严、单向播报和字幕最宽松、录音后转写基本不用管实时性。档位定错，最常见的后果是你花大价钱买了一整套低延迟特性，结果你的业务只是每天批量转写几百条录音。反过来说，如果你的场景是用户随时插话的对话，那点延迟省不出来，体验就是崩的。

分清链路角色：识别、合成还是端到端

挑模型要按「你要解决的那一段」去挑，而不是按「哪个模型最强」。只做转写就看识别类，只做播报就看合成类，要能被打断的双向对话才需要考虑一体化方案。这三种需求对应的验收方法完全不同，混在一起比就没意义。

端到端方案的好处是省掉拼接和上下文传递，代价是可调项少、换单个环节困难，出问题时不好判断是哪一段坏了。它适合快速验证，不太适合长期深度定制。拼接方案每一项都能替换和单独压测，但你得自己管好断句、标点和上下文衔接，这块的工程成本经常被低估。

# 判断顺序，不是执行脚本；照着把问题问清楚再选型
1. 我的场景需要「听懂」「说出来」还是「能对话」？
2. 需要能被打断吗？需要 -> 端到端候选；不需要 -> 优先拼接
3. 需要单独替换其中某一段吗？需要 -> 拼接优先
4. 团队有精力管断句和上下文衔接吗？没有 -> 端到端
5. 先用拼装跑两周最小闭环，再决定要不要换一体化

拿不准方向时，别在选型会上耗着，先用拼装方案做一个能跑通的最小闭环，跑两周再判断有没有必要换一体化。两周里你会积累真实语料、真实延迟分布和真实出错类型，这些比任何发布稿都有用。

并发、音色与授权：三条容易漏的线

实时语音是长连接场景，并发比文本接口更容易把额度打满。先按你的峰值同时在线人数估算需要多少路通道，再去看各家的并发上限和超限行为。超限时是拒绝新连接、降级、还是排队等待，这三种行为对用户体验的影响完全不同，必须提前问清楚。

• 并发：按峰值同时在线人数估算通道数，别按日活估；到 /official-api 核对各家的并发口径和超限策略。
• 音色与语种：官方清单写了支持不等于你的场景效果好，务必自己录几条带口音、带方言的真实语料去试。
• 授权范围：看清可商用范围、是否需要标注、能不能自训练音色，把条款和法务确认一遍，面向消费者的产品尤其不能省。
• 自建成本：需要自建时先到 /compute/sizing 按模型算一遍卡数和带宽，别直接跳到采买环节。

音色和语种是最容易被清单误导的一项。官方支持列表通常覆盖主流语种和标准音色，但你的用户可能带明显口音、可能夹方言、可能面前有背景噪声。这些情况下，同一家产品在不同语料上的表现差距会比你想象的大，所以「支持」和「可用」之间要自己铺一条验证路。

上线前的人工听测清单

模型选完不算完，上线前必须有一轮人工听测。这一步不是走形式，而是把发布稿里的指标翻译成你业务里能说出口的感受。听测的关键是语料设计和记录方式，别用通用测试集，也别只记一个总评分。

1. 准备语料覆盖口音、背景噪声、打断、专有名词四类，长度对齐你线上典型时长，每类至少准备几条。
2. 盲听打分同时跑两三家，同一批语料匿名盲听，重点记出错类型而不是总好评率：识别看错字分布，合成听机械感和断句。
3. 记录耗时分布不只记平均值，把每次请求的实际耗时分布记下来，尾部长尾才是用户抱怨的来源。
4. 上线后盯波动用 /tools/quality-monitor 一类手段持续看质量波动，别只在上线那天测一遍就放心。

听测结论要落到「哪一类语料在哪种情况下出错」，而不是「A 比 B 好」。因为上线后你会根据出错类型去调参数、加前置处理或换链路，笼统的排名给不了这些动作。价格和规格的最新口径，到 /price-watch 和 /voice 核对当时的数字。

什么情况下这套流程不适用

这套筛选顺序是为「要做实时语音、且对延迟有要求」的场景准备的。下面几类情况不必照搬，硬套反而增加不必要的选型成本和时间。

• 纯离线播报、内容固定不变的场景，直接选一个够用的合成接口即可，不必走完整套筛选流程。
• 对延迟完全不敏感的批量转写任务，优先看单小时成本和批量接口能力，低延迟特性对你没有意义。
• 语音只是产品里很小的一块时，先接官方 API 快速验证需求，等确定要长期做再考虑自建或换方案。
• 已经有稳定链路、只是偶尔换一家对话模型时，重点放在兼容性和回退方案，不用重跑整套延迟测算。

还有一种容易忽略的情况：如果你的产品只需要单向合成且内容每天不变，那预生成音频再分发的成本往往低于实时合成，连模型选型都可以省掉。判断标准很简单——用户能不能接受等几秒才听到第一句。能接受，就不必上实时链路。