TTS 音频格式和码率怎么选

2026-08-24

调 TTS 接口时，format 往往是最后才被注意到的参数。很多人照着示例填了 MP3，功能跑通就不再回头——直到要做流式播放、要接电话网关，才发现格式选错会把后面所有优化都拖住。

音频格式不是”随便选一个能播的”，它同时决定三件事：能不能边收边播、要不要额外的编码等待、以及在传输和存储上各花多少代价。

一句话结论

实时对话、流式返回：选 PCM 裸流。无压缩、无封装、不依赖文件头，延迟最低。
文件下载、归档保存：WAV 或 MP3 都行。这类场景不在乎首包，在乎的是通用性和体积。
实时通信、WebRTC 链路：选 Opus。它就是为这个场景设计的，低码率下语音质量表现好。
接传统电话网关：先确认对方要什么，通常是 8 kHz 的窄带，直接按目标信道合成，别绕远路。

四种格式各自在解决什么问题

格式	特点	能否边收边播	典型场景
PCM（裸流，如 s16le）	无压缩、无封装，拿到就能播，延迟最低	能	流式返回、实时对话
WAV	PCM 加一个文件头，头里要写总长度	不友好	文件下载
MP3	通用性极好，几乎所有播放器都认，但有编码延迟	有条件	分发、播客
Opus	低码率下语音质量好，专为实时通信设计	能	WebRTC、实时通话

这张表里最容易被忽略的是 WAV 那一行。WAV 本质上就是 PCM 加个头，而这个头里必须写明音频的总长度。 问题就出在这儿：流式合成的时候，你还没生成完，压根不知道总长度是多少，头就没法写完整。

绕法当然有——先填一个占位长度，播放器多半也能凑合播下去。但这已经是在跟格式的设计意图对着干：你选 WAV 本来是图它标准通用，结果为了流式又写了个不标准的头。既然要流式，就直接用裸 PCM，把封装交给应用层。

流式场景真正该看的判断依据

首包延迟为什么重要、由哪几段构成，流式 TTS 的首包延迟那篇已经讲透了。这里只补格式相关的那一段。

判断一个格式适不适合流式，只用问一句话：收到前面一部分数据，能不能立刻开始播，而不必等待后面的内容？

依赖文件头、而头部信息又取决于整体内容的，不行。
编码器需要攒够一定长度才吐出第一帧的，会拖慢首包。
拿到字节就能直接送进播放缓冲区的，最理想。

格式选择和流式能力是绑死的，不是两件独立的事。 一个常见的翻车顺序是：先按”通用性最好”选了格式，做完发现首包压不下去，再回头怀疑模型慢、怀疑网络差——其实是格式本身在门口就卡了一道。

采样率不是越高越好

这一条最反直觉，也最容易白花算力。很多人默认”采样率高 = 音质好”，不管什么场景都往高了选。但采样率的合理取值由目标信道决定，而不是由你的期望决定。

最典型的是电话场景。传统电话网就是 8 kHz 的窄带信道，你合成一份 48 kHz 的高保真音频，送进网关照样被降采样成 8 kHz——高出来的信息在传输第一步就被扔掉了。

扔掉的不只是采样点，还有生成这些采样点花掉的算力。 而这份算力本来可以用在别处：让首包更快、让并发路数更多、让单位成本更低。同样一台机器，做无用的高保真和做有用的低延迟，结果差得很远。

所以顺序应该反过来：先确认音频最终要走哪条信道，再倒推该合成什么采样率。 常见的档位就那么几个——8 kHz 对应电话，16 kHz 是宽带语音的常用值，22.05 / 24 kHz 是不少合成系统的原生输出，44.1 / 48 kHz 属于音乐和视频的规格。位深方面 16 bit 是最常见的选择，语音场景基本够用。

ASR 那一侧其实有完全对称的一套逻辑，可以对照着看：ASR 对音频格式有什么要求。合成端和识别端在这件事上的原则是一致的——匹配目标，而不是追求上限。

编码延迟本身就是首包的一部分

有损编码不是免费的。编码器要做变换、要分析，有些还需要看到一定长度的样本才能输出第一帧。这段时间实实在在地加在首包延迟里。

很多人算首包预算时只数了模型推理和网络往返，把编码当成”顺手就做完了”。离线生成里确实可以忽略，但实时对话链路上每一段都压在很紧的预算里，编码这段就不再是零。

所以选有损格式时，除了看”体积小多少”，还要问”要多等多久”。这两者往往反向：压得越狠，编码器要做的分析越多。

存储与传输是两本账

同一份音频，在不同环节的优化目标并不一样。

	优化目标	倾向
实时传输	首包快、抗抖动、带宽可控	低延迟格式，压缩要克制
长音频归档	单位时长的存储成本、检索方便	可以接受更高的编码代价

这两件事完全可以分开处理：实时链路走低延迟格式保证体验，播完之后需要留存的，再在后台转成更省空间的格式归档。硬要用一份文件同时满足两个目标，多半两边都将就。

另外，长文本的分片策略也会影响格式选择——分片之后每一片都要独立编码，编码延迟被乘上了片数。这块见长文本合成怎么切。

多端兼容要看最弱的那一端

浏览器、移动端、桌面客户端、电话网关，支持的格式集合并不相同，差异比想象中大。

选型不能看”大多数端都支持”，要看链路上最受限的那一端支持什么。 只要有一个端解不了，你要么给它单开转码链路，要么整体降级，两种都是成本。省事的做法是在项目早期把所有目标端的格式支持列成一张表取交集。端侧和云端的约束也不同，可参考端侧 TTS 和云端 TTS 怎么选。

别过度压缩语音

最后一条容易被忽略：语音的可懂度对某些压缩失真特别敏感。

音乐听起来闷一点只是体验打折，语音出现同类失真却可能直接影响听清——辅音区的细节被压掉后，发音相近的字就不好分辨。麻烦的是这种劣化在安静环境的短句测试里往往察觉不到，叠加上真实场景的背景噪声和口音才集中冒出来。

所以压缩要按听感实测来定，而不是按”能省多少带宽”来定，测试素材必须覆盖噪声、口音、长句和专业名词。

选格式该问的四个问题

选之前先回答这四问，答案会自动收敛到很小的范围：

要不要边收边播？ 要，就排除依赖完整文件头的格式。
音频最终走哪条信道？ 按目标信道倒推采样率，别做无用的高保真。
链路上最弱的那一端支持什么？ 取所有端的交集，而不是取最优端。
这份音频要不要长期留存？ 要，就把实时链路和归档链路分开设计，各优化各的。

常见问题

问：码率到底该设多少？

没有可以照抄的数字。码率的合理值取决于采样率、声道数、编码器和内容类型，各家实现的默认值和档位也不一样。可操作的办法是：从默认值起步，用真实素材做听感对比，逐档往下压到能接受的边界前一档停住。只用干净短句测出的结论不可靠。

问：能不能直接对合成好的音频做转码？

技术上可以，但要注意两点。一是转码有额外耗时，实时链路上这一段同样要算进延迟预算。二是有损转有损会二次劣化，把 MP3 再转成另一种有损格式，损失是叠加的。如果确定需要多种格式，更稳妥的是从无损的 PCM 分别编出去。

问：流式返回的 PCM 该怎么在浏览器里播？

关键是先跟服务端对齐三个参数——采样率、位深、字节序。裸流没有文件头，这些信息不在数据里，只能靠约定。这三项对不上，播出来就是噪声，而且症状很像”模型坏了”，排查时容易找错方向。拿到字节流之后按固定块长送进播放缓冲区即可，缓冲多少是延迟和抗抖动之间的取舍。