三个 AI 主播，一个播出系统——KAVANA 为什么不做"万能引擎"

KAVANA 工程团队 — 2026 年 6 月

去年我们给一家省级台装 AI 路况播报。头一周电话就响了——不是投诉，是主持人自己打来的："你们这个声音挺好的，但能不能让它听起来不像在念稿？"

我们当时用的是一套通用的云端语音方案。

换了两家供应商，调了三轮参数，终于让合成效果通过了主持人的耳朵。但代价是：每次切换引擎，接口要重写、延迟要重新调优、稳定性要从头验证。

那之后我们想清楚了一件事：广播不需要"最好的引擎"，需要"最不坏的选择"。

为什么不是"一套方案打天下"？

今年上半年，腾讯新闻上线了全网首个 AI 互动电台。联合国教科文组织在 2026 年世界广播日倡议中也明确鼓励电台引入 AI，同时强调要守住"人性化"这条线。

这些信号指向同一个判断：AI 播报正在从"能不能用"走向"用得好不好"的阶段。

但"用得好"的标准因人而异。一个县级台和一家省级台的负载差了 20 倍，一套方案不可能同时覆盖两端。

KAVANA 的做法是：把 AI 主播拆成 Pro / Max / Ultra 三个档位，但不是按"高端 / 中端 / 低端"分——是按场景分。

每天重复最多的事：报时、台呼、天气、路况、歌曲预告。这些内容模式固定、字数可预期、对音色一致性要求高。

Pro 档对应的就是这类"有规律可循"的工作。

它跑在云端引擎上，KAVANA 累计服务超过 500 家广播电台，Pro 档并发请求场景下每条口播的交付时间都是稳定的。成本也是三档中最低的。对于需要大批量、高频次合成的场景，Pro 档是最务实的选择。

KAVANA 的 AI 播报系统每天处理的口播中，超过七成走的是 Pro 档。

但 Pro 档有一个短板：音色是标准化的。

当电台的晚间音乐栏目需要一位有辨识度的声音——听众一听就知道"这个时段开始了"——标准音色不够用。

Max 档跑在本地高级引擎上，专门处理音色克隆。我们把主持人几十分钟的历史录音导入，训练出来的合成音色能保留原声的语调习惯和节奏感。听起来不像"某个 AI 在说话"，更像是"他在说话"。

代价是合成时间比 Pro 档长，适合用在精品栏目里，不适合全天候跑量。

去年南方某省遭遇极端天气，光缆中断，当地三家电台的云端 AI 播报同时停摆。

那次之后，我们把 Ultra 档从"可选"改成了"默认部署"。

Ultra 档是本地 GPU 引擎，AI 合成在电台自己的服务器上完成，数据不出本地网络。即使公网完全断开，播出链路上的 AI 口播也不会中断——系统自动降级到本地引擎继续工作。KAVANA 的护航系统负责这个切换，值班编辑甚至不需要知道后端发生了什么。

在数据安全和应急备播这两个维度上，Ultra 档提供了前两档做不到的兜底。

一个常见的误解是把 Pro / Max / Ultra 理解成"基础版 / 高级版 / 旗舰版"。

不是的。

准确的比喻更像是：

KAVANA 的播出系统在后台自动为每一条合成请求匹配档位。值班编辑不需要知道这条内容走了哪个引擎——系统替他做了选择。

但如果电台有偏好，也可以在编排台手动指定。一套 API，三个引擎，一个入口。

三档并存的架构不是一开始就有的。最初只有 Pro 档。然后客户想要定制音色，我们加了 Max。遇到网络中断事故，我们加了 Ultra。每一档都是在实际运营中补上的——不是因为规划做得好，是因为摔过跤。

现在回头看，Pro / Max / Ultra 三个档位用下来，每档都有自己的适用场景，没有哪个是多余的。

这也是为什么 KAVANA 不做"一个万能引擎"——不是做不出来，是广播本身就要求多个方案并存。

关于 KAVANA

KAVANA 是 AI 原生的电台播出系统，自 2005 年起累计服务全国 500 多家调频电台。我们走在云边融合广播的前沿，具备一键人工接管和三级 AI 审核的安全保障。

AI-assisted draft, reviewed and edited by KAVANA engineering team.