把 TTS 压进 99M: Supertonic 3 与它的端侧语音方案

📖 目录导航

• 01. 一个有意思的出身:娱乐公司开源了一个 TTS
• 02. 版本是怎么一步步走到 3 的
• 03. 为什么能做到 99M 还这么快
• 04. 它真正聪明的几个产品决策
• 05. 核心调用:就两个旋钮要心里有数
• 06. benchmark 该怎么读
• 07. 用之前要想清楚的边界
• 08. 把它放进 voice agent 的链路里
• 09. 几点启发

先抛一个反直觉的数字。Supertonic 3 这个模型,在一台 M4 Pro 的 CPU 上跑,实时因子(RTF)能做到 0.01 量级——也就是合成一秒钟的语音,只花十几毫秒的墙钟时间。而它对标的一些开源模型,参数量是它的 5 到 8 倍,还得挂在 GPU 上才能跑。

我第一反应是不信,觉得要么是测试条件灌水,要么是牺牲了音质。翻完它的仓库、模型卡和几篇配套论文之后,结论是:这事是真的,但前提和取舍都得讲清楚。 这篇就把这个项目掰开聊聊——它的来头、版本怎么走到今天、为什么能做这么小这么快、以及真要用它你会撞上哪些边界。

01. 一个有意思的出身:娱乐公司开源了一个 TTS

先说背景,因为这个出身确实不太寻常。

Supertonic 来自 Supertone Inc.,一家 2020 年成立于首尔的韩国 AI 音频公司,创始人是 Kyogu Lee(李教九)和 Hoon Heo。据多家媒体报道,这家公司 2022 到 2023 年间被 HYBE 收购——对,就是 BTS 背后那家娱乐巨头,据报道交易额约 3200 万美元,HYBE 先后拿到控股权(一度披露为 56.1%)。

Supertone 早年出圈靠的是"歌声合成"(SVS)和声音克隆:

• 据报道,它用 AI 复刻过已故韩国歌手 Kim Kwang-seok 的声音,上过韩国电视节目;
• 在 Disney+ 剧集里把 60 岁演员崔岷植的声音"还原"成 30 多岁;
• 旗下还有实时变声工具 Supertone Shift、虚拟偶像团体 SYNDI8。

所以这是一家做娱乐内容生产的声音技术公司,不是典型的开源 infra 团队。理解这个出身有用,因为它解释了 Supertonic 的两个特征:一是对音质和自然度的标准很高(娱乐级);二是它开源出来的这套,和它商业上卖的那套(实时变声、虚拟艺人、Supertone API 的 Sona 等)是有意做了切割的——开源版聚焦在"固定音色的端侧 TTS",这点后面会细说。

模型权重的版权页写的是 Copyright (c) 2026 Supertone Inc.,GitHub 上的配套代码已经攒到 2.7k star,提供了十来种语言绑定。

02. 版本是怎么一步步走到 3 的

Supertonic 不是一上来就这样,看它的演进比看单个版本更能理解它的取向。据其 GitHub 更新日志:

• v1:只支持英文,主打端侧极致速度;
• 2026.01.06 v2 发布:扩到 5 种语言(英、韩、西、葡、法);同期上线了 PyPI 包、Voice Builder(把你自己的声音做成可部署的端侧 TTS);
• 2026.04.29 v3 发布:语言从 5 种扩到 31 种,提升朗读准确率,减少重复/跳读的失败,并保持与 v2 兼容的公开 ONNX 资产;
• 2026.05.18:Python SDK v1.3.1 加了 supertonic serve,一个本地 HTTP 服务,提供原生 /v1/tts 和兼容 OpenAI 的 /v1/audio/speech 端点。

这条线很清楚:先把"小而快"这个底座做扎实(v1),再往多语言和易用性上加(v2、v3),最后补部署形态(serve、OpenAI 兼容端点)。 它没有去追"参数越堆越大"的路线,而是一直守着端侧这条线。v3 相比 v2 据其自述主要是稳定性和语言覆盖的提升——重复念、漏念这类 TTS 老毛病减少了,跨共享语言的说话人相似度也有改善。

需要提醒:开源的固定音色 TTS,和零样本声音克隆是两条路径。 据其仓库说明,这个开源仓库聚焦固定音色的本地 TTS,不含官方的声音克隆 pipeline;如果想把自己的声音搬进来,得走 Voice Builder 生成版本专属的 JSON。别下载了仓库就指望直接克隆任意音色。

专注大模型的电话智能体

了解更多

03. 为什么能做到 99M 还这么快

这是我最想搞清楚的部分。据 v3 的模型卡,公开 ONNX 资产合计约 99M 参数,而它对标的开源 TTS 普遍在 0.7B 到 2B 这个量级。一个差着一个数量级的小模型,凭什么在 CPU 上打过大模型的 GPU?

拆开看,我认为是三层东西叠出来的。

第一层,架构本身就是冲着"精简"设计的。 据其 GitHub 引用的三篇配套论文:

• SupertonicTTS(arXiv:2503.23108):提出整体架构,核心是一个语音自编码器加一个基于 flow-matching 的 text-to-latent 模块。把语音先压进一个紧凑的潜空间、再用流匹配在潜空间里生成,这是它能把模型做小的关键设计取向;
• LARoPE(arXiv:2509.11084):长度感知的旋转位置编码,专门改善 cross-attention 里文本和语音的对齐——对齐稳了,才能在小模型上少出重复/漏读;
• 自净化流匹配(arXiv:2509.19091):用 self-purification 的办法在有噪声标签的数据上稳健训练流匹配模型。

我的解读:它不是把一个大模型剪小,而是从训练目标和架构上就选了 flow-matching 这条"少步数也能出活"的路线,再用 LARoPE 把对齐这个最容易翻车的环节焊死。小,是设计出来的,不是压出来的。

第二层,推理步数是个显式旋钮。 flow-matching 这类模型,生成质量和采样步数直接挂钩。Supertonic 把它暴露成参数:据其性能表,默认用 2 步推理就能出可用结果,也提供 5 步的数据。2 步对 5 步,基本就是"更快 vs 更稳/更好"的权衡——这个旋钮交到了使用者手里,而不是替你定死。

第三层,工程上彻底押注 ONNX Runtime + CPU。 它不是"能跑在 CPU 上",而是为 CPU 优化,GPU 模式据其说明甚至没测过。配合 ONNX,它一套模型能落到一堆运行时上:Python、Node.js、浏览器(WebGPU/WASM)、Java、C++、C#、Go、Swift、iOS、Rust、Flutter。它甚至放了在树莓派、Onyx Boox 电纸书(飞行模式、RTF 约 0.3×)上跑的演示。

一句话:架构选了天生小且少步数的路线,推理步数做成旋钮,工程上死磕 CPU + ONNX 的可移植性。 99M 在 CPU 上打赢 GPU 上的大模型,是这三件事共同的结果,而不是某个单点魔法。

04. 它真正聪明的几个产品决策

抛开速度数字,有几个决策我觉得比"快"更值得说,因为它们是踩过坑才会做的选择。

• 文本正规化不依赖预处理。 TTS 工程里最烦的活之一,就是把 $5.2M、4:45 PM、Wed, Apr 3, 2024、(212) 555-0142 ext. 402、30kph 这种东西在喂模型前先正规化成念法。Supertonic 据其演示是直接吃原始文本、自己处理货币、日期、电话、缩写、技术单位的。这个对接入方是实打实的省事,少维护一大坨规则。
• 多语言不靠 per-language 微调。 据其官网,31 种语言是一个 99M 模型扛下来的,没有按语言分别 finetune。对部署方意味着:一套权重、一份内存占用,而不是每加一门语言就多一个模型。
• 给未知语言留了 na 兜底。 31 种 ISO 语言码之外,它提供一个特殊的 na 回退,用于语言未知或不支持的文本。这是个很务实的小设计——真实输入里总有识别不出语言的脏文本,有兜底总比直接崩了好。
• 直接给了 OpenAI 兼容端点。 supertonic serve 暴露兼容 /v1/audio/speech 的接口,意味着原本调 OpenAI TTS 的代码,改个 base URL 基本就能切到本地端侧,迁移成本极低。这是很懂"开发者怎么想"的一步。

05. 核心调用:就两个旋钮要心里有数

Python 这边接口很薄,真正要拿捏的就是音色和速度/质量这两个旋钮。下面只贴有信息量的部分(完整参数以官方文档为准)。

# 省略模型/音色资源的加载
# 关键调用:voice_style 决定音色,lang 指定语言
# lang 拿不准时用 'na' 兜底,别让未知语言文本直接炸掉
wav, sr = tts.synthesize(
    "The startup raised $5.2M, up from a $450K seed round.",  # 货币/缩写不用自己预处理
    voice_style=style,
    lang="na",   # 已知就填 ISO 码(en/ko/...),未知用 na
)

速度/质量的权衡落在推理步数上(参数名以官方为准,概念上 2 步偏快、5 步偏稳):

• 2 步:默认,延迟最低,voice agent / 实时朗读这类场景优先用;
• 5 步:吐字更稳、质量更好,适合离线生成、有声书这种不赶时间的活。

一个容易踩的坑:别拿 GPU 来想当然地提速。 它是 CPU 优化路线,GPU 模式官方没测过(据其技术说明)。你在服务器上一股脑挂 CUDA,未必比多线程 CPU 更快,反而可能踩到没验证过的路径。要快,先把 CPU 线程数给够——官网那个对标 800M GPU 模型的数据,用的是 16 线程 CPU。

06. benchmark 该怎么读

它的数字很漂亮,但漂亮的数字更要看口径。据其 GitHub 性能表(M4 Pro、2 步推理):

• 吞吐(字符/秒):CPU 上短文本约 912、长文本约 1263;WebGPU 更高;云端 API 类(ElevenLabs Flash、OpenAI TTS-1、Gemini 2.5 Flash TTS)普遍只有几十到一百多。
• RTF:CPU 上 0.012–0.015,云端 API 普遍在 0.05–1.0 之间。
• 它特意标注了对比条件:API 类是从首尔测的(含网络),开源类里 Kokoro、NeuTTS Air 都在同一台 M4 Pro CPU 上测。

读这个表我会留意几点:

• 拿本地端侧的 RTF 去比云端 API,对 API 不完全公平——API 那 0.1~1.0 里有很大一块是网络往返,不是模型本身慢。它自己把这点标出来了,算诚实,但你心里要清楚这不是纯模型对纯模型。
• 真正同台竞技的是那几个开源模型(同机 CPU),Supertonic 在吞吐和 RTF 上确实领先,这部分含金量更高。
• 质量维度它换了个比法:据 v3 模型卡,它是说在测得的 WER/CER 区间上,对标 VoxCPM2 这类大得多的模型"保持有竞争力",而不是声称全面超越。这个措辞很克制,说明它清楚 99M 在质量上限上不是来碾压的,而是"够用且极快极小"。
• 66M 还是 99M? 仓库概述里出现过"66M 参数、167× 实时"的说法,而 v3 模型卡写的是约 99M。我倾向于理解为前者对应更早的版本、后者是 v3 的口径,但仓库没把这点写得很清楚,引用时建议以你实际用的那个版本的模型卡为准,别混用。

07. 用之前要想清楚的边界

它很能打,但不是万能,这几条边界我会先确认:

• License 不是无条件随便用。 代码是 MIT,但模型权重是 OpenRAIL-M:据其许可,权重开放、可商用,但带有基于用途的限制(不得用于伤害、不得未经同意做冒充/impersonation),且要求署名。考虑到这家公司本身就是做声音克隆和虚拟艺人的,这些限制不是走过场,商用前务必让法务过一遍。
• 开源版没有官方声音克隆。 想要任意音色克隆,得走它商业侧的 Voice Builder / Supertone 产品线,开源仓库给的是固定音色。把"开源 TTS"直接等同于"开源声音克隆"会踩空。
• 质量上限受限于 99M。 极致自然度、复杂情感表达、歌唱级表现,这种小模型不一定扛得住。对音质要求顶格的场景,该上更大的模型或它的商业方案。
• GPU 路径未验证。 上面说过,别想当然用 GPU。
• 项目还很新、迭代很快。 v3 才发布一个多月(本文写于 2026 年 5 月底),API、SDK 都在动。上生产要锁版本、做回归。

08. 把它放进 voice agent 的链路里

这块我想单独说,因为它和"实时语音对话"这个场景咬得很紧——也算和端侧低延迟这个大主题接上。

一个 voice agent 的回合里,TTS 是最后一段:LLM 吐字 → TTS 合成 → 播报。这一段如果慢,整个对话的"尾巴"就拖了。传统做法是调云端 TTS API,问题和云端检索一样——网络往返加进了延迟,而且按量付费、数据出境。

Supertonic 这种端侧方案,在 voice agent 里的价值很直接:

• RTF 0.01 量级意味着 TTS 几乎不占预算,延迟预算可以全留给 LLM;
• 本地运行,数据不出端,合规敏感的场景(医疗、金融客服)友好;
• OpenAI 兼容端点让你能把原来调云端 TTS 的链路低成本切到本地;
• 配合流式 LLM,可以做到 LLM 边吐字、TTS 边合成边播,把尾部延迟也藏进流式里。

要注意的是它给的是固定音色,如果你的 agent 需要特定品牌音色,得提前用 Voice Builder 把音色固化下来,而不是运行时动态克隆。

09. 几点启发

照例,抛开这个具体项目,我觉得它的思路对做工程的人有这么几点可借鉴的:

• "小"可以是设计目标,而不是优化的副产品。 大部分人默认"先做大做好,再想办法压小"。Supertonic 反过来,从架构(flow-matching 潜空间 + LARoPE 对齐)到工程(ONNX + CPU)一开始就奔着小和快去。当你的场景是端侧、是实时,把"小"当成第一性约束,往往能逼出完全不同的技术选型。
• 把权衡做成旋钮,是成熟产品的标志。 推理步数 2 步还是 5 步、音质还是速度,它不替你拍板,而是暴露出来。我们自己做系统时,与其偷偷替用户做假设,不如把关键权衡显式化、可配置。
• 降低迁移成本本身就是核心竞争力。 一个兼容 OpenAI 的 /v1/audio/speech 端点,可能比多跑赢几个点的 benchmark 更能决定别人用不用你。技术再好,接入要重写一堆代码,就会被挡在门外。
• 看 benchmark 先看口径,这条值得反复念。 上一篇讲检索我说过,这篇又撞上同样的事:本地比云端、含不含网络、同不同机、比的是速度还是质量。Supertonic 这点做得算诚实(条件都标了),但更普遍的情况是对方不标,那就得你自己拆。
• 开源和商业的边界可以是产品设计的一部分。 它开源固定音色、把声音克隆留在商业侧,这个切割既给了社区真东西,又守住了自己最值钱的资产。做开源时想清楚"开什么、留什么",比无脑全开或假开源都更可持续。

如果你手上是端侧、浏览器、或延迟/隐私敏感的语音场景,知识库式的固定音色够用,Supertonic 3 值得拉下来真机测一轮——但记得用你的目标设备、你的真实文本去测 RTF 和音质,M4 Pro 上那组数只是上限参考。商用前先把 OpenRAIL-M 的署名和用途限制确认掉。