端侧语音合成如何守住音频实时期限

端侧 TTS 能跑出声音，离稳定交付还差一道音频截止时间。Gradium 开源 Phonon 后，作者想提醒开发者：模型已经可以作为依赖集成，但持续播放、散热降频、分块接缝和设备音频路由，才是产品容易翻车的地方。

文章的结论很明确：别只看平均生成速度，要验证真实设备能否持续供上音频。这对准备接入本地语音合成的客户端团队，比一张漂亮的性能表更有用。

比实时更快，为什么还会卡顿

普通请求耗时 900 ms，通常只是让用户多等一会儿。音频回调只有 20 ms，却执行了 21 ms，就可能错过播放期限。数模转换器（DAC）按固定速度消耗采样，不会等模型算完；缓冲区耗尽，就会出现爆音、咔哒声或机械式停顿。

按原文的配置，24 kHz 采样率、20 ms 混音周期，每次回调需要 480 个采样点。不过，这不要求模型每隔 20 ms 必须完成一次推理。模型可以批量生成，缓冲区负责持续供给，关键是播放端不能断粮。

实时因子（RTF）是「合成耗时 ÷ 生成音频时长」。RTF 0.3 表示平均生成速度约为播放的 3 倍，但平均值会掩盖慢块，也看不出运行几分钟后的降频。

作者观察过一个引擎：前 60 秒维持 RTF 0.55，到第 4 分钟升至 1.1，原因是 SoC 从大核集群切到小核集群。若只测 5 秒，这个问题根本不会暴露。

因此，他们关注每块耗时的 p99、最慢块，以及预缓冲能留下多少余量。下面是原文测试脚本的报告函数，用来检查最慢块是否可能耗尽缓冲：

def report(run: Run, prebuffer_ms=400):
    rtf = sum(run.chunk_ms) / sum(run.audio_ms)
    p99 = statistics.quantiles(run.chunk_ms, n=100)[98]
    worst = max(run.chunk_ms)
    # Conservative bound for a stop-and-wait loop: a chunk longer than the
    # pre-roll plus one block drains the buffer before the next chunk lands.
    slack = prebuffer_ms + BLOCK_MS - worst
    print(f"RTF (mean)            {rtf:.3f}   # <1.0 is necessary, not sufficient")
    print(f"chunk p99             {p99:.0f} ms")
    print(f"worst chunk           {worst:.0f} ms")
    print(f"slack after prebuffer {slack:.0f} ms  {'OK' if slack > 0 else 'UNDERRUN'}")
    return rtf, p99, worst

要看的是 slack = prebuffer_ms + BLOCK_MS - worst。它使用 400 ms 预缓冲和 20 ms 周期估算余量，适用于原文描述的停等循环；流水线合成与播放时，这个边界会偏保守。片段依赖完整脚本中的 Run、statistics 和 BLOCK_MS，不能单独执行。

完整脚本用 time.perf_counter() 计时，默认先预热 3 条文本，接收单声道 float32 或 int16 PCM。作者建议在真机上连续跑至少 10 分钟，而不是拿笔记本上的短跑成绩验收。

缓冲能挡住抖动，也会拖慢开口

预缓冲就是先攒一段音频，再启动播放。原文给出的常规起点是 300–500 ms，用这段存量吸收偶尔迟到的合成块。

代价也直接：语音助手开口变晚，屏幕阅读器每次移动光标后都可能多等一下。因此，作者按用途分配预算：

• 对话场景使用 150–250 ms，要求模型更稳定，并接受偶尔降级。
• 旁白和媒体使用 400–800 ms，更偏向连续播放。
• 无障碍场景先完整生成短句，例如只有 3 个词的提示，再开始播放。

流式合成还会引入两种接缝。文本按句切分，可能让前后韵律不一致；声码器按帧生成，边界波形可能不连续。作者建议用 5–10 ms 的恒功率交叉淡化处理后者：短于 3 ms，爆破音附近可能有滴答声；长于 20 ms，又可能把辅音抹模糊。

但交叉淡化不能解决错误切词。作者见过分句器遇到 e.g. 或德语复合词时切坏文本，模型把半个词当完整输入朗读。另一种问题是对自然停顿也做重叠相加，削弱静音，让语音听起来很赶。原文建议按帧能量决定是否交叉淡化，或做帧级归一化。

缓冲、文本切分和波形拼接，需要一起调。

压缩模型之后，还要检查哪些设备问题

Int8 量化的影响，可能先落在自然度上，再落到可懂度上。作者指出，用自动语音识别（ASR）回转计算词错误率（WER），结果可能没变，声音却已经变平、带轻微嗡声。

他们改用固定的 50 句测试集，对比 float32 参考的基频（F0）曲线，统计有声帧上以音分计的平均绝对偏差；再看持续元音的频谱距离，并分别用设备扬声器和耳机做 A/B。手机小扬声器可能掩盖耳机能暴露的问题。

线程数也牵涉持续性能。4 线程可能更快生成单块，却增加功耗和发热。作者认为，10 分钟会话中，2 线程配较大预缓冲经常优于 4 线程配较小预缓冲，但没有提供对照数据。

平台设置同样影响延迟：

• Android 的 AudioTrack 支持 PERFORMANCE_MODE_LOW_LATENCY，但偏好设备原生采样率。24 kHz 输出交给框架转成 48 kHz，会增加重采样延迟，也引入未主动选择的滤波器。
• iOS 的 AVAudioSession 类别和模式影响音频路由，playback 配 modeDefault 与 voicePrompt 不能当作相同配置，需要真机验证。
• Embedded Linux 要显式设置 ALSA 的 period_size，并检查 snd_pcm_sw_params 中的启动阈值，板卡默认值未必合适。

还有冷启动缺页。数百 MB 权重即使通过内存映射加载，首次发声仍可能因大量页面调入而超时。原文提出启动时预热模型，或用 mlock 锁住热点区域。

我的判断

这篇最有价值的提醒，是把验收目标从「平均跑得快」改成「播放期间供得上」。 最慢块、持续 RTF 和缓冲余量，确实比单看 P50 更贴近可听见的故障。

但它是工程经验文章。原文没有给出 Phonon 的实测表，也没交代降频案例的设备、模型和系统版本。150–250 ms 等缓冲范围，以及线程数和交叉淡化建议，都适合作为试验起点，不能直接当成验收标准。

脚本也只记录合成耗时和产出音频长度，没有接入真实播放回调，更没测到最终出声时刻。它能筛出风险，却不能证明音频路由、重采样和系统调度都没问题。

量化评估的方向也合理，但 50 句测试集如何覆盖语言、情绪和文本长度，原文没说清。相较于只测 WER，增加韵律和听感评估更完整；是否值得量化，仍要结合设备上的内存、温度与听感结果判断。

能拿来做什么

• 接入端侧 TTS 时，先建立真机长跑记录，同时保留 RTF、每块耗时分布、最慢块和缓冲余量，并覆盖冷启动首次发声。
• 调整流式文本切分时，把 e.g.、复合词、长句和自然停顿放进回归样例，分别检查发音完整性、韵律和拼接噪声。
• 做 Int8 或线程优化时，把扬声器、耳机听测与持续性能放在一起比较，避免只凭短时速度决定配置。
• 上线前明确降级顺序：完整质量本地语音、降低采样率、缩短语句并增加每块预缓冲，最后才考虑服务端 TTS。原文称 48k → 24k 可将声码器成本减半；服务端回退需网络可用且用户不在按流量计费的连接上，换声音应等到句子边界。