11.84MB可调控TTS模型发布：WER不变，UTMOS仅降0.1

小型TTS模型正在向边缘设备快速下沉。WhissleAI 近日发布了 SteerTTS 的边缘版本——一个全部打包仅 11.84 MB 的可调控英文语音合成模型，在保持词错误率基本不变的前提下，把 UTMOS 主观音质评分损失控制在 0.1 左右。

从 v1 到 edge：一次极致的体积压缩

此前 WhissleAI 在 Hugging Face 上发布了 SteerTTS v1，特点是可以用数字参数直接调控语速、音高、停顿等语音特征。这次发布的 edge 变体（huggingface.co/WhissleAI/steer-tts-edge）继承了同样的调控能力，但把应用需要分发的所有内容——模型权重、音色、文本前端以及 Python 运行时——压缩到了 11.84 MB。

这个数字的含义值得拆开看：它不是单纯的权重文件大小，而是"一个 app 要 ship 的全部东西"。对于移动端或嵌入式场景，这种口径比参数量更有参考价值。

压缩是怎么做到的

三个模块各自做了不同的取舍：

• 声学模型（9.25M 参数，attention + 双向 Mamba-3 结构）采用量化感知训练（QAT）压到 int4；
• 声码器（6.2M 参数的 Vocos 风格模型）从 charactr/vocos-mel-24khz 蒸馏而来，同样做了 int4 QAT；
• 文本前端改用纯 numpy 实现，运行时不再依赖 NLTK、g2p_en、torchaudio 或 num2words。

文本前端的处理容易被忽略，但对边缘部署很关键：这些 NLP 依赖往往体积不小、安装链路长，砍掉之后整个分发包才能真正做到"小而自足"。

量化感知训练（QAT，Quantization-Aware Training） 是一种在训练阶段就模拟量化误差的技术。普通的事后量化（PTQ）是先把模型训练到收敛，再直接把权重从 fp32 截断到 int4，往往造成明显精度损失；QAT 则在训练的前向传播中插入"伪量化"节点，把权重按 int4 的粒度取整、再反量化回浮点参与计算，让模型在训练过程中就学会适应这种低精度表示。反向传播时梯度通常用直通估计器（STE）绕过不可导的取整操作。这样得到的模型在真正部署为 int4 时，精度下降远小于 PTQ，代价是需要重新训练或微调。对声学模型和声码器这类对数值敏感的网络，QAT 是能在激进压缩下保住音质的关键手段。

双向 Mamba 指的是一种基于状态空间模型（SSM）的序列建模结构。传统 Mamba 以线性复杂度沿序列单向递推，擅长处理长序列且推理时状态固定；双向 Mamba 则同时用前向和后向两个 SSM 扫描序列，使每个位置都能聚合左右两侧的上下文，效果上更接近双向 RNN 或 Transformer 的全局注意力，但计算和内存开销仍是线性增长。对 TTS 的声学模型而言，双向建模有助于把握韵律和音素协同发音的长程依赖，而线性复杂度又契合边缘设备对算力和内存的严苛约束，这也是该结构被选入 9.25M 参数小模型的原因之一。

质量账本：可懂度没丢，音质小幅让步

作者按照 Open TTS Leaderboard 的评测协议在本地跑了对比（非官方提交）。结果如下：

版本	Seed-TTS WER / UTMOS	CV3-Eval WER / UTMOS
v1 fp32（无 refiner）	0.96% / 4.20	—
edge	0.96% / 4.11	—

WER 完全一致，说明压缩没有伤到可懂度这一核心指标。UTMOS 从 4.20 降到 4.11，约 0.1 的损失，作者指出几乎全部来自那个小型 int4 声码器。这个归因有一定指导意义：如果后续要继续优化边缘版音质，声码器是优先级最高的改进点，而不是声学模型。

调控能力在量化后基本保留

可调控是这个模型区别于普通小 TTS 的核心卖点。作者称 12 个控制维度——语速、响度、音高、音高范围、句末上扬、停顿、tilt、气声等——每一个都保留了 fp32 版本至少 95% 的调控效果。

此外还支持 50 个风格标签和内联标记，例如：

Well, *that* was fast. [pause 400ms] <slow>Let me think.</slow> <whisper>Don't tell anyone.</whisper>

这种内联语法让开发者可以在文本里直接控制停顿、语速和耳语风格，不需要额外的控制接口。

UTMOS 是一个基于 MOS 预测的语音自然度客观评价模型，用大量人工主观打分数据训练，输入一段语音即可输出接近人类主观评分的预测值（通常 1–5 分）。它常被 TTS 研究用作无需人工听测的自动指标，与 WER（衡量可懂度）互补：WER 只看字词是否听对，UTMOS 则反映音色、韵律、噪声等整体听感。Seed-TTS WER 指 Seed-TTS 论文提出的一套评测基准，用统一的 ASR 模型对合成语音转写后计算词错误率，因评测流程标准化而被 Open TTS Leaderboard 等采用，便于跨模型横向比较。需注意这两项都是客观代理指标，UTMOS 与真实人耳偏好仍可能存在偏差，0.1 的降幅在主观听感上是否明显，最好辅以人工盲测确认。

速度与限制：定位清晰的边缘方案

在纯 CPU 环境（2018 款 Threadripper，带负载）下，4 线程时 RTF 为 0.053，约 19 倍实时；配合句子级流式，首包音频延迟约 120 ms。这个延迟水平已经能支撑交互式语音应用。

作者也坦率列出了限制：

• 仅支持英文，内置 200 个音色（完整版为 2,825 个）；
• 设备端不支持声音克隆、自由文本提示和 flow refiner，这些能力保留在完整模型中；
• 权重在加载时会被反量化为 fp32，因此这一版省的是体积，不是推理速度——除非针对边缘设备重写算子内核；
• 情感标签大多只是风格切换，fast/anger 两类效果偏弱。

最后一条限制值得注意：很多小模型宣传"量化加速"，但这里作者明确区分了体积收益和速度收益，这种表述对工程选型更有帮助。

RTF（Real-Time Factor，实时因子） 是衡量语音合成速度的核心指标，定义为合成一段音频所需计算时间与该音频时长之比。RTF = 0.053 意味着生成 1 秒音频只需约 0.053 秒计算，即约 19 倍实时（1/0.053 ≈ 18.9），数值越小越快，RTF < 1 即达到实时。与之配套的首包延迟指从输入文本到输出第一段可播放音频的时间，是交互式语音应用（如语音助手、实时对话）体验的关键；配合句子级流式合成，模型可以在整句尚未生成完时就先吐出开头音频，把感知延迟压到百毫秒级。这两项指标结合，才能完整描述一个 TTS 方案在端侧是否"可用"。

多源视角下的定位判断

以上信息来自 Reddit 上作者的发布帖及 Hugging Face 模型卡，属于单一来源的自述数据。由于 WER 与 UTMOS 均为本地按 Open TTS Leaderboard 协议跑出、非官方榜单提交，横向对比其他模型时需谨慎。不过作者公开了模型地址和示例页面（whissleai.github.io/steer-tts），社区可以复现验证。

作者明确在征求两类反馈：声码器音质差距的改进方向，以及希望支持的边缘目标（ONNX、移动端、WASM）。对于需要在端侧落地语音合成的团队，这个 11.84 MB 的方案提供了一个值得实测的基线。