一、背景速览：TTS 评测该测什么

调研阶段已经把流式 TTS 的技术栈、厂商方案与延迟预算摸清（见 流式 TTS 全景调研 ↗，28 章 / 54 信源）。 但调研给的是别人的数字，本地没有一套能算自己数的工具——所以这次从零写了 tts-bench。

音质好不好只能靠人耳，但工程可用性有四个可量化的硬指标：

二、框架设计：为什么这么切模块

三、环境准备

零第三方依赖，Python 3.7+ 标准库即可（asyncio + wave + subprocess），不用建 venv。

tts-bench/
├── tts_bench/
│   ├── __main__.py          # CLI 入口：run / list
│   ├── metrics.py           # Timeline 打点 + 分位聚合
│   ├── runner.py            # 串行执行、落盘
│   ├── report.py            # 控制台表 + Markdown
│   └── adapters/
│       ├── base.py          # 适配器基类
│       ├── mock.py          # 纯模拟
│       ├── macos_say.py     # 真实本地引擎（两种模式）
│       └── cloud.py         # 火山/阿里/MiniMax 骨架
├── data/texts.jsonl         # 10 条中文客服话术测试集
├── vendors.example.json     # 配置模板（env: 占位）
└── README.md

测试集设计

10 条中文客服话术，刻意覆盖会打破 TTS 表现的六类文本特征：

四、跑通步骤

1. 看已登记的引擎

   $ cd tts-bench && python3 -m tts_bench list
   已登记 vendor：
     mock                 纯模拟流式合成，节奏由配置决定，只用于验证框架与指标计算。
     macos_say            （mode=whole）
     macos_say_stream     （mode=chunked）
     volcengine           火山引擎 豆包语音合成（双向流式 WebSocket）。
     aliyun               阿里云 智能语音交互 流式语音合成（CosyVoice / 通用模型）。
     minimax              MiniMax T2A 流式语音合成。

2. 三引擎对照跑，每条重复 2 轮
   执行评测

   $ python3 -m tts_bench run \
       --vendors mock,macos_say,macos_say_stream \
       --repeats 2

3. 观察逐条明细：注意分片数的差别

   # 整段合成：分片=1，首包 == 总耗时（非流式特征）
   [macos_say] long_09 ok 首包=1249.6ms 总耗时=1249.6ms 音频=30.27s RTF=0.0413 分片=1
   [macos_say] bye_10 ok 首包=1096.5ms 总耗时=1096.5ms 音频=3.923s RTF=0.2795 分片=1
   
   # 分句流式：分片>1，首包只等第一小句
   [macos_say_stream] long_09 ok 首包=997.2ms 总耗时=8038.7ms 音频=28.32s RTF=0.2839 分片=8
   [macos_say_stream] policy_05 ok 首包=1040.5ms 总耗时=5060.3ms 音频=12.835s RTF=0.3943 分片=5

4. 读汇总并试听音频

   音频落盘在 results/<时间戳>/audio/，16kHz 单声道 wav，可直接播放核对音质与断句。

   $ ls results/20260730-080959/
   audio/  raw_results.jsonl  summary.json  report.md
   
   $ afinfo results/20260730-080959/audio/macos_say_greet_01_r1.wav
   Data format:  1 ch, 16000 Hz, Int16

五、本机验证结果

单位 ms（音频时长除外）。三个引擎成功率均 100%，共 60 条无失败。

5.1 验证通过项

六、核心发现：为什么分句流式几乎没用

分句流式只降 7% 首包，这不符合直觉，所以单独做了一个佐证实验——测极短文本与超长文本的合成耗时差：

# 合成 1 个字「好」，跑 3 次
$ time (say -v Tingting -o t.aiff "好" && afconvert -f WAVE -d LEI16@16000 -c 1 t.aiff t.wav)
real 1.01
real 0.94
real 0.96

# 合成 88 个字的长段落，跑 2 次
$ time (say -v Tingting -o t2.aiff "非常感谢您的耐心等待。我这边已经为您查询到了完整的账单明细……" && afconvert ...)
real 1.10
real 1.11

6.1 这个结论怎么推广到真实选型

把它抽象成一条可复用的判据：

所以真实链路里降首包的正确姿势不是"在客户端切句"，而是：① 复用长连接消除建连与冷启动；② 服务端支持增量文本输入（LLM 出字即塞给 TTS）；③ 首句预热/缓存固定开场白。

6.2 顺带发现的两个副作用

七、接真实厂商

三家云厂商适配器骨架已就位，协议要点写在各自 docstring 里，补完网络调用即可：

$ cp vendors.example.json vendors.json
$ export VOLC_TTS_APPID=xxx VOLC_TTS_TOKEN=xxx
$ python3 -m tts_bench run --vendors volcengine,aliyun --config vendors.json --repeats 3

八、踩坑记录