TTS

流式 TTS 全景调研 · 技术栈 / 难点 / 厂商方案

← 返回调研中心

流式语音合成（Streaming TTS）全景调研与学习方案

覆盖四个问题：流式 TTS 在国内外都用在哪、技术栈长什么样、难点与困点在哪、各大厂商怎么解；最后给出一套可执行的四阶段学习调研方案与自建评测设计。

一句话结论：流式 TTS 的竞争已经不在「像不像人」，而在「首包延迟 × 稳定性 × 单卡并发成本」三角。技术路线上，2023 年后全行业收敛到「LLM 生成语义 token + Flow Matching/扩散声码器解码」的两段式架构，流式能力靠块因果（chunk-aware causal）注意力把非流式模型改造成边收文本边出音频；工程上真正的分水岭是双向流式协议（文本流入 + 音频流出）——它决定了能不能吃掉 LLM 首 token 的等待时间。国内外差异明显：国外（ElevenLabs / Cartesia / OpenAI）卖极致低延迟 + 生态，国内（火山豆包 / 阿里 CosyVoice / MiniMax / 讯飞）卖中文韵律 + 方言 + 声音复刻 + 单价，且国内多了一层《AI 生成合成内容标识办法》强制水印的合规约束。

编制日期 2026-07-29 ｜ 第 3 轮版本（28 章，迭代记录见第 28 章）｜ 信源：厂商官方文档 / arXiv 论文 / GitHub / HuggingFace / 行业媒体 / Reddit 与知乎社区实测，关键结论均 2+ 独立信源交叉验证

▤1. 流式 TTS 到底「流」的是什么

很多人把「流式」理解成「音频边下边播」，这只是其中一半。真正决定实时交互体验的是输入侧是否也能流。

形态文本输入音频输出典型协议首包延迟量级适用场景
非流式（一次性）
Batch / offline
 整段一次性 合成完整体返回 HTTP POST + 完整音频文件 数百 ms ~ 数秒（随文本长度线性增长） 有声书、配音、TTS 批量离线生产
单向流式（输出流）
Server streaming
 整段一次性 分块流式返回 HTTP Chunked / SSE / gRPC server-stream 150~500 ms 长文播报、已知全文的播放场景
双向流式
Bidirectional / duplex
 流式输入（随 LLM 吐字） 流式返回 WebSocket（主流）、gRPC 双向流 80~250 ms，且与 LLM 生成重叠 语音客服、Voice Agent、实时同传、数字人直播
端到端语音大模型
Speech-to-Speech
 没有独立 TTS 模块，音频 token 直接生成 WebRTC / WebSocket Realtime API 整链路 250~500 ms 强情感陪伴、打断敏感的对话

为什么双向流式是分水岭

在 ASR → LLM → TTS 级联链路里，如果 TTS 只支持单向流式，就必须等 LLM 把第一个完整句子吐完才能开始合成，链路延迟 = LLM 首 token + 整句生成时间 + TTS 首包。双向流式允许把 LLM 的 token 流实时喂进合成会话，TTS 在收到几个字后就能起音，LLM 生成与音频合成完全重叠，实测可省掉 300~800 ms 的感知延迟。这也是火山「双向流式语音合成 WebSocket」、阿里百炼「实时语音合成」、AWS「Polly bidirectional streaming」、ElevenLabs「multi-context WebSocket」在 2024–2025 年集中上线的原因。

⌚2. 30 年演进时间线（看清今天为什么是这个样子）

学习 TTS 最高效的方式是沿着技术演进线读——每一代都是为了解决上一代的缺陷，而每次解决都引入新难题。绿点为与流式直接相关的关键节点。

1990s
拼接合成与 HMM/HTS：录音库切片拼接、参数合成。延迟极低、可上嵌入式，但机器感强。今天的车载/离线场景仍有它的影子。
2016
WaveNet：神经声码器开启时代，音质跳升，但原版推理慢到不可用，引发后续十年的推理加速竞赛。
2017–2019
Tacotron2 / FastSpeech / FastSpeech2：端到端声学模型普及。FastSpeech 的非自回归设计把 RTF 压下去，也让分块合成变得可行。
2020–2021
HiFi-GAN / VITS：GAN 声码器把实时率做到工业可用，VITS 完成单阶段端到端。这一代至今仍是很多企业生产环境的主力（稳、快、便宜）。
2023-01
VALL-E（微软）：用神经 codec token + 语言模型做 TTS，开启「零样本 3s 克隆」时代（G3 起点）。同时引入了至今未彻底解决的幻觉/稳定性问题。
2024-07
CosyVoice 开源（阿里通义）：支持声音克隆、情绪/风格控制、中英粤日韩与方言，把 G3 能力拉到开源社区。
2024-06→2024
Seed-TTS（字节）与 VALL-E 2：前者靠指令微调 + 强化学习做到情绪可控、短录音复刻；后者官方称零样本在公开数据集上接近人类水平，稳定性与自然度大幅提升。
2024-12
CosyVoice 2：关键节点——统一离线/流式框架，FSQ 量化 + 块感知因果流匹配，官方称双向流式、延迟低至约 150ms。开源世界终于有了可用的流式 G3 模型。
2024-12→2025
商业双向流式集体上线：ElevenLabs Flash（75ms 档）、火山双向流式 WS、阿里百炼实时语音合成、AWS Polly 双向流式、Deepgram Aura-2。行业从「比音质」转向「比首包」。
2025
MiniMax Speech-02 / 2.5登顶第三方榜单（中文/粤语/日韩 WER 优于 ElevenLabs）；CosyVoice 3 参数从 0.5B 扩到 1.5B；Qwen3-TTS 开源并宣称首包 97ms。中国厂商在中文与多语种上形成优势。
2025-09
国内强制标识落地：《人工智能生成合成内容标识办法》施行，合成语音必须带显式+隐式标识，合规从选项变成必选项。
2025→2026
两条路线并行：一边是级联链路继续押注双向流式与工程优化（Deepgram 把 Aura-2 TTFB 从 <200ms 做到 90ms），一边是端到端 Realtime（GPT-4o Realtime / 豆包 Realtime / Gemini Live）把整链路压到 250～500ms。流式 TTS 不会消失，但会变成「可控性优先」场景的首选。

◷3. 指标体系：不把指标定清楚，所有横评都是玄学

流式 TTS 至少要盯 4 类 11 个指标；单说「延迟 100ms」没有意义——必须说清是 TTFB 还是端到端、是 P50 还是 P95、文本多长、并发多少。

TTFB
首包延迟 / TTFA
从最后一个必要输入到第一个音频字节。实时交互最核心指标，目标 <300ms（P95）
RTF
实时率
合成耗时 / 音频时长。<1 才能不断流，实时场景要求 ≤0.3 留出抖动余量
Jitter
包间抖动 / 断流率
相邻音频块间隔的方差。抖动大 → 卡顿爆音，比平均延迟更影响体感
WER/CER
合成可懂度
合成音频回灌 ASR 的字错率，用于量化吞字/复读/念错等稳定性问题
SIM
音色相似度
声纹 embedding 余弦相似度，衡量音色复刻/克隆保真度
CMOS
主观自然度
人工 AB 对比打分（-3~+3），韵律与情感只能靠主观评测兜底
并发/卡
单卡并发数
直接决定成本。同一模型 RTF 与并发是此消彼长的权衡
$/1M
百万字符成本
商业 API 报价 or 自建折算，需含长连接与并发资源费

横评时最容易踩的 5 个坑

  • 混淆首包定义：厂商宣传的「75ms / 97ms / 150ms」通常是模型侧推理延迟，不含网络 RTT、鉴权、TLS 握手、排队等待。落地实测常见 2~4 倍差距（ElevenLabs Flash 官方 75ms，社区实测端到端 300~800ms）。
  • 只测短文本：短句掩盖长文本的显存增长、注意力退化与复读问题，必须覆盖 5 字 / 30 字 / 200 字 / 1000 字四档。
  • 只测单并发：单并发 RTF 0.1 的模型在 32 并发下可能升到 0.9，必须画「并发-延迟-断流率」曲线。
  • 不看 P95/P99：语音交互体感由长尾决定，P50 好看没用。
  • 不做同文本同音色控制：不同音色的 TTFB 差异可达 30%，克隆音色通常比预置音色慢。

▥4. 毫秒级延迟预算拆解（本报告最实用的一页）

下面两张图是典型语音客服链路的延迟构成：先看「未优化」怎么赔掉 1.8 秒，再看「优化后」怎么抢回来。数字为行业典型区间估值（基于厂商公开指标与社区实测推算），用作预算分配模板，不是绝对值。

场景 A · 未优化级联链路（感知延迟 ≈ 1800ms，用户会明确觉得「卡」）

VAD/尾点等待600ms
ASR 终态定稿200ms
网络 RTT × 多跳150ms
LLM 首 token300ms
等整句生成完300ms
TTS 首包150ms
客户端缓冲100ms
※ 红色那条「等整句生成完」就是没用双向流式的代价；橙色两条是判停与缓冲策略造成的。TTS 本身（绿色）只占 8%。

场景 B · 优化后链路（感知延迟 ≈ 620ms，接近自然对话）

语义 EOU 判停200ms
ASR（中间结果已预跑）50ms
网络（就近+长连接）40ms
LLM 首 token180ms
TTS 首包（重叠）120ms
客户端缓冲120ms
※ 注意第 5 行的条与第 4 行在时间轴上重叠——这就是双向流式的价值：120ms 的 TTS 首包被藏在 LLM 生成里，不再串行累加。其它关键变化：① 判停改用语义 EOU（参见本站EOU 选型调研）省 400ms；② 网络就近与长连接省 110ms。

并发对首包的影响（自建必测的拐点曲线）

140ms
165ms
210ms
320ms
640ms
1 并发481632（拐点后）

形状典型特征：前段缓慢上升，过拐点后 P95 延迟爆炸式上升且开始断流。容量规划要取拐点并发 × 0.7 作上限，而不是拐点本身——因为真实流量有峰谷，卡在拐点上运行意味着任何小波动都变成事故。上图为典型形式示意（数值因模型/硬件而异，必须自测）。

⛭5. 技术栈全景与三代架构演进

理解流式难点的前提，是知道一段文字要经过多少道工序才变成声音，以及每道工序为什么天生反流式。

5.1 现代 TTS 的六段流水线

① 文本前端 TN
文本归一化、分词、多音字消歧、韵律预测、Markdown/LaTeX 过滤
→
② 语义/声学 token 化
音素或 BPE token；说话人 embedding、情感/风格标签注入
→
③ 自回归语言模型
Text token → Speech(semantic) token，通常是 Qwen/LLaMA 类 decoder
→
④ 声学解码器
Flow Matching / 扩散 / Transformer 把语义 token 变梅尔谱或声学 token
→
⑤ 声码器 Vocoder
HiFi-GAN / BigVGAN / Vocos 把谱转波形
→
⑥ 传输与播放
编码（PCM/Opus/MP3）、分块、抖动缓冲、播放器时间轴

流式的难点分布：① 需要看到足够上下文才能定读音与韵律（天生要等）；③ 自回归天生适合流式但容易漂；④⑤ 传统上需要完整谱做全局注意力/迭代去噪（天生反流式）；⑥ 抖动缓冲设置不当会把服务端省下的 100ms 又赔回去。

5.2 三代架构演进（决定了今天各家的技术底色）

代际代表结构流式友好度优点 / 致命短板
G1 拼接/参数
2000s–2015
 单元挑选、HMM/HTS 规则前端 + 拼接或参数声码器 天然流式 延迟极低、可上嵌入式；机械感强、拼接痕迹明显
G2 端到端声学模型
2017–2022
 Tacotron2、FastSpeech2、VITS 文本→梅尔谱→GAN 声码器 中等（FastSpeech2/VITS 非自回归、可分块） 音质大幅提升、RTF 低、可控时长；音色需专门训练、零样本克隆弱、情感表达上限低
G3 LLM + 生成式解码
2023–至今
 VALL-E、CosyVoice2、Fish-Speech、Seed-TTS(豆包)、MiniMax Speech、Qwen3-TTS、ElevenLabs v3、Cartesia Sonic LLM 出语义 token + Flow Matching/扩散解码 + 神经声码器 要专门改造（块因果注意力） 零样本 3s 克隆、跨语种、情感与指令可控、韵律接近真人；幻觉/复读/吞字、显存与算力高、并发成本高、长尾不稳定

关键认知：G3 的所有工程难点都源于「把一个本质上是 LLM 的东西塞进 200ms 的实时预算里」。所以业界的解法几乎都在两个方向：让模型更小更因果（Flash/Turbo/Mini 系列、蒸馏、量化），或让基础设施更狠（KV cache 复用、连续批处理、TensorRT/vLLM、预热常驻）。

5.3 关键技术名词速查（学习时按这个顺序补齐概念）

  • Speech Codec / 离散语音 token：EnCodec、SoundStream、FSQ（CosyVoice2 用有限标量量化）、S3Tokenizer。把连续波形变成 LLM 能建模的离散序列，是 G3 的地基。
  • Flow Matching（流匹配）：比扩散更少步数的连续生成方法，CosyVoice2 的「块感知因果流匹配」是流式化的核心创新点。
  • 块因果注意力 chunk-aware causal attention：把全局注意力限制在「当前块 + 有限右看窗」，用统一模型同时支持离线与流式，只切换 mask。
  • 单调对齐 / CTC 先验：NVIDIA NeMo T5-TTS 用单调比先验 + CTC 缓解 LLM-TTS 幻觉，是稳定性方向的代表工作。
  • Speaker embedding / prompt audio：零样本克隆的两条路——显式声纹向量 vs 上下文 prompt 续写。
  • Multi-context session：一条 WebSocket 上跑多个独立合成上下文，用于打断后快速切流、多角色对话。

⇉6. 把非流式模型改造成流式的四种手段

这一节是整份报告技术含量最高的部分：所有厂商的「低延迟」本质上都是这四招的组合。

手段 A · 文本切分驱动（最容易，天花板最低）

不改模型，在接入层把 LLM 的 token 流按标点/字数切成小片，逐片调用非流式 TTS，然后在客户端把音频首尾对齐拼接。LiveKit Agents 与 Pipecat 都内置 sentence tokenizer 做这件事。

代价：句间韵律断裂（每片都从「句首语调」重新开始）、拼接处易爆音、短片会放大模型固定开销。工程上要配「首片尽量短（抢首包）+ 后续片加长（保韵律）」的动态切分策略。

手段 B · 块因果建模（主流，改模型）

训练时就让注意力只能看到当前块与有限右上下文，使 LLM 与 Flow Matching 解码器都可以按块推理。CosyVoice2 的双向流式（官方称超低延迟约 150ms）、Qwen3-TTS 的 97ms 首包都属于这一类。本质是用「牺牲一点全局韵律」换「首包延迟」，右看窗（lookahead）大小就是这个权衡的旋钮。

手段 C · 模型瘦身与推理加速（成本主战场）

  • 分层模型家族：同一家给出 Flash/Turbo/HD/Pro 多档（ElevenLabs Flash v2.5 75ms vs Multilingual v2 高质量；豆包/百炼的实时版 vs 高清版），让用户自己选延迟-质量点。
  • 蒸馏 + 量化：AR 部分蒸馏成小模型、Flow 步数从 10 步压到 2~4 步、INT8/FP8 量化。
  • 推理引擎：LLM 部分接 vLLM / TensorRT-LLM（社区在 CosyVoice2 上的实践显示 TensorRT-LLM 对 input embedding 支持是主要障碍，vLLM 高并发下也有工程坑），声码器接 TensorRT / ONNX Runtime。
  • 连续批处理 + KV cache 复用：同音色 prompt 的 KV 可缓存复用，是把首包从 300ms 压到 150ms 的关键工程手段。

手段 D · 链路级藏延迟（最被低估）

  • 预连接 + 预热：会话开始前建好 WebSocket、跑一次 dummy 合成，避免冷启动与 TLS 握手计入首包。
  • 首句预生成 / 话术缓存：外呼开场白、常见 FAQ 首句直接放缓存音频，首包做到 ~0。
  • 就近部署：跨境场景（如新加坡节点打国内 API）光 RTT 就 60~200ms，必须区域化选点。
  • 抖动缓冲调优：客户端 buffer 从 500ms 降到 100~200ms，同时用「音频块到达速率」做自适应。
  • 投机起音：ASR 中间结果就启动 LLM/TTS，错了就丢弃（LiveKit 的做法），用算力换感知延迟。

⌗7. 双向流式协议解剖（学习时最缺的具体细节）

各家字段名不同，但会话模型高度一致。掌握这个抽象模型，读任何一家文档都能 10 分钟上手。

7.1 通用会话生命周期（以 WebSocket 为例）

// C = 客户端，S = 服务端 C → S 建连 + 鉴权（header/token） C → S StartSession：音色 voice_id、采样率、音频格式、语速/音量、情感、块大小 S → C SessionStarted（拿到 session_id，后续帧都带它） C → S TextChunk "您好，请问" // LLM 边吐边发 S → C AudioChunk [PCM/Opus 二进制] // 首包！开始播放 C → S TextChunk "是张先生吗？" S → C AudioChunk × N // 持续流出 S → C （可选）TimestampEvent // 字/词级时间戳，用于字幕与口型驱动 C → S FinishText // 告知文本发完（重要！否则服务端一直等） S → C AudioChunk（尾包）+ SessionFinished C → S 【打断分支】CancelSession / 新开 context C → S CloseSession（或保持连接复用下一轮）

三个新手必踩的坑：① 忘发 FinishText，服务端一直等后续文本，尾包出不来，表现为「最后几个字不读」；② 把会话当一次性请求用，每句新建连接，把双向流式退化成单向；③ 不处理 CancelSession，打断后 GPU 还在跑废弃请求，并发白白消耗。

7.2 各家命名映射（看文档时对照用）

抽象概念典型字段/叫法备注
会话启动StartSession / start_connection / 初始化帧 / session.update火山与讯飞都用自定义二进制帧头，阿里/OpenAI 类多用 JSON 事件
文本增量输入TaskRequest / continue-task / TextChunk / input_text_buffer.append注意是否有最小/最大字符限制，部分实现对过短分片会缓冲等待
文本结束FinishText / finish-task / 结束标志位最容易遗漏，且有的实现后续不允许再发文本
音频帧二进制帧 / audio.delta（base64）base64 会增加 33% 带宽与解码开销，高并发下优先选纯二进制
时间戳事件word/char timestamps、句级对齐信息数字人口型驱动、字幕同步必需；并非所有厂商提供，选型时要专问
取消/清空Cancel / flush / 新建 contextElevenLabs 的 multi-context 可在同一连接上开新上下文，打断切流最优雅
错误/限流error 事件、HTTP 429、并发报错码必须区分「可重试」与「不可重试」，否则雪崩

7.3 选接口时要确认的 8 个问题

  1. 支持真双向流式吗（文本能分多次发），还是只是输出流式？
  2. 一条连接能跑多少并发会话？鉴权是每会话还是每连接？
  3. 支持 cancel 吗？取消后能否立即复用连接？
  4. 最小可推送音频块多大（直接决定首包下限）？
  5. 支持 8k 采样吗？是模型原生还是服务端降采（后者音质更差）？
  6. 是否返回字级时间戳？
  7. Markdown/emoji 过滤是否内置？
  8. 限流粒度是 QPS、并发还是字符配额？超限是排队还是直接报错？

⚠8. 17 项难点 / 困点 × 对应解法

按「延迟类 → 稳定性类 → 质量类 → 工程类 → 业务类」五组排列，每条给出现象、根因、业界解法与验证方式。这是本报告的核心资产。

A 组 · 延迟类（4 项）

01首包延迟被模型固定开销吃掉

现象合成 2 个字和合成 20 个字的首包延迟差不多，短句尤其不划算。
根因AR 预填充（prefill）+ Flow Matching 迭代步数 + 声码器一次至少出一个感受野的音频，构成与文本长度无关的常数项。
解法减少 Flow 步数并蒸馏；缩小首块（first chunk）粒度让第一块只出 40~80ms 音频；KV cache 复用音色 prompt；常驻进程 + 预热避免冷启。厂商对应：ElevenLabs Flash v2.5（75ms 档）、Cartesia Sonic（官方 TTFA 199ms）、Qwen3-TTS（97ms 首包）、CosyVoice2（约 150ms）。
验证固定文本长度矩阵（5/30/200/1000 字）× 固定音色，测 P50/P95 TTFB。

02LLM 与 TTS 串行等待

现象用户说完话到听到第一个字要 1.5s+，但 ASR/LLM/TTS 单项指标都不差。
根因TTS 只支持整段输入，必须等 LLM 出完第一句；各环节延迟串行累加。
解法换双向流式 TTS 接口，把 LLM token 流直接送入合成会话；或用「首句短切分 + 后续长切分」策略在接入层模拟。厂商对应：火山「双向流式语音合成 WebSocket」、阿里百炼实时语音合成、AWS Polly bidirectional streaming、ElevenLabs multi-context WebSocket。
验证在链路上打时间戳（可用本工作区 duplex-trace 时序追踪站点做可视化），核对 LLM 首 token 与 TTS 首包是否重叠。

03网络与跨境 RTT 主导延迟

现象本地 demo 200ms，上线到海外线路变 800ms。
根因TLS 握手 + 鉴权 + 跨区域 RTT + 运营商链路抖动；每次新建 HTTP 连接都重付一次。
解法长连接复用（WebSocket 常驻）、连接池预建、区域化就近部署（新加坡业务用新加坡节点）、鉴权 token 缓存、优先 UDP/WebRTC 传输音频。
验证分别测「纯模型推理耗时」与「客户端观测 TTFB」，差值即链路开销。

04抖动 / 断流 / 爆音

现象平均延迟达标但听起来一卡一卡，或拼接处「啪」的一声。
根因音频块产出速率不稳（GPU 排队、并发抢占）；分片拼接处相位/直流不连续；客户端缓冲太小。
解法自适应 jitter buffer；块边界做 5~20ms 交叠淡入淡出（cross-fade）；服务端做速率整形保证「产出速率 > 播放速率」；限制单卡并发上限而不是无脑塞满。
验证统计相邻块到达间隔的 P95 与最大值、underrun 次数；波形上检查块边界跳变。

B 组 · 稳定性类（4 项，G3 架构的原罪）

05幻觉：吞字 / 漏读 / 复读 / 念出无关内容

现象长句丢掉半句、某个词重复念两三遍、结尾拖出无意义音节。
根因自回归 LLM-TTS 没有硬性的文本-音频单调对齐约束，注意力可能回跳或跳跃，尤其在长文本、生僻词、重复字串上。
解法① 单调对齐先验 + CTC 辅助损失（NVIDIA NeMo T5-TTS 的做法）；② 推理期用内部注意力对齐做引导，检测回跳即纠偏（学术界「注意力引导消除重复与漏读」方向）；③ 采样温度与 repetition penalty 调低；④ 兜底重试 + 合成后 ASR 回灌校验，字错超阈值就重合成或降级到 G2 模型。
验证构建 badcase 语料集（长文/重复字/中英混/数字串），跑合成→ASR→CER，统计幻觉率而非平均分。

06长文本注意力退化与显存膨胀

现象超过一定长度后音调发飘、语速漂移、显存线性上涨甚至 OOM。
根因KV cache 随序列增长；训练长度分布与推理长度不匹配。社区实测 F5-TTS 在长文本上出现异常音调即属此类。
解法分段合成 + 段间携带上一段末尾作为韵律 prompt（保持连贯）；滑动窗口 KV；限制单请求最大字符数（多数商业 API 都硬限制，如单次 300~1000 字）。
验证长文本专项测试：1000 字连续合成，检查语速漂移与音色一致性（SIM 曲线）。

07流式模式下韵律断裂

现象同样文本，非流式听起来自然，流式听起来一句一句割裂、重音位置怪。
根因块因果注意力看不到后文，无法预测句尾降调、疑问语调与整句重音分布。
解法保留有限右看窗（lookahead 1~2 块）；接入层做「语义完整性切分」而不是纯标点切分（避免在「因为」后面切）；同一段落内复用上文韵律状态；对疑问句、感叹句延后切分点。
验证流式 vs 非流式同文本 CMOS 主观 AB 对比，重点听句间衔接。

08音色一致性漂移

现象同一通电话前后音色/情绪不一致，克隆音色越说越不像。
根因每次分片独立采样，说话人条件信息在长会话中被稀释；零样本克隆依赖 prompt audio，分片时 prompt 与文本比例失衡。
解法固定随机种子 / 复用同一 speaker embedding；在会话级维护 TTS session（而不是每句新建）；对高价值音色改用「音色复刻/微调训练」而不是零样本；SIM 阈值在线监控。
验证同一会话内每片音频计算声纹相似度，看是否单调下滑。

C 组 · 文本与质量类（4 项，中文尤其重）

09文本归一化（TN）在流式下无法做全局判断

现象「2024-07」读成「二零二四减零七」、「3-5 个」读成「三减五个」、金额小数点读错、电话号码连读。
根因TN 需要上下文才能判断实体类型，但流式时后文还没到；且规则库通常是句级设计。
解法接入层做「TN 安全边界」——遇到数字/符号串时缓冲到实体结束再送入（延迟几十 ms 换正确率）；业务侧预处理成显式读法（把「¥1,200.5」直接写成「一千二百元五角」）；用 SSML/标签强制指定读法；关键实体（金额、单号、日期）走词典强控。
验证构建 TN 专项集：日期/时间/金额/百分比/单位/序号/电话/网址/中英混/表情符号，各 50 条人工校听。

10多音字与专有名词读错

现象「重庆」读 chóng/zhòng 混、「行长」「差旅」「藏区」读错，人名地名品牌名念错。
根因多音字消歧依赖词典 + 模型，长尾覆盖不足；G3 模型把 TN 隐式化后更难干预。
解法厂商侧提供自定义读音词典 / 热词（PaddleSpeech 走扩增短语词典路线，商业 API 多提供 SSML phoneme 或替换词表）；业务侧维护品牌词-拼音映射表并在送入前替换；badcase 闭环收集。
验证行业术语表 + 客户名录抽样校听，统计每千字读错数。

11LLM 输出里的 Markdown / 公式 / emoji 污染

现象把「**重点**」念成「星星重点星星」、把「- 」念成「减」、把 emoji 念成描述文字。
根因LLM 面向文本渲染优化，输出天然带格式标记。
解法接入层统一过滤器（火山官方明确支持「Markdown 过滤和朗读 LaTeX 公式」，可直接用厂商能力）；prompt 层约束 LLM 语音场景输出纯文本；流式过滤要注意跨块的标记（** 可能被切成两块）。
验证用带格式的 LLM 真实回复做回归集。

12多语种 / 方言 / 中英混读

现象中文句子里的英文单词用中文口音念、东南亚小语种发音生硬、粤语数字读法错。
根因训练数据分布不均；code-switching 样本稀缺；小语种 TN 规则缺失。
解法选支持 code-switch 的模型（MiniMax Speech 系列宣称 32 语种，中文/粤语/日韩 WER 优于 ElevenLabs；Qwen3-TTS 主打多语言 + 方言）；分语种选不同引擎（路由层按语种分发）；小语种走本地化服务商。
验证分语种 WER + 母语者主观评分，别只信厂商榜单。

D 组 · 工程与成本类（3 项）

13打断（barge-in）后的资源与状态回收

现象用户插话后 AI 还在念上一句，或打断后重新起音要 1s+。
根因已缓冲的音频未清空；TTS 会话没有 cancel 语义，GPU 还在跑废弃请求；新会话要重新建连。
解法协议层支持 cancel/flush（选支持 multi-context 或 finish/cancel 指令的接口）；客户端立即 drop 播放缓冲；保持热连接池，打断后复用连接；对已发送但未播放的文本做记账，便于「续接」而非重头念。
验证打断响应时间（用户开口→AI 静音）目标 <200ms；打断后新首包 <400ms。

14并发成本与 GPU 利用率

现象自建 G3 TTS 单卡只能撑十几路并发，成本远高于商业 API。
根因AR 部分是 decode-bound（小 batch 时算力浪费），Flow/声码器是 compute-bound，两段流水线难同时打满；实时约束不允许长时间攒批。
解法AR 与解码器拆成两个独立服务分别扩容与批处理；连续批处理（continuous batching）+ 微批窗口 10~20ms；vLLM / TensorRT-LLM 承载 AR，ONNX/TensorRT 承载声码器；分档路由（简单话术走轻量模型，高价值话术走高清模型）；缓存高频音频。
验证画并发-P95延迟-断流率三曲线，找出「拐点并发数」再乘 0.7 作为容量上限。

15可观测性缺失：出问题不知道是哪一段慢

现象用户投诉「机器人反应慢」，但看不出是 ASR、LLM 还是 TTS。
根因缺少贯穿链路的 trace id 与统一时间基准；TTS 内部指标（排队/推理/首块）不透出。
解法每通会话一个 trace id 贯穿 ASR/LLM/TTS，埋点到「块级」；服务端与客户端时间对齐（NTP 或握手校时）；把首包、块间隔、断流、重试、幻觉重合成率做成看板（本工作区已有 duplex-trace 可复用）。
验证能对任意一通会话画出完整时序甘特图。

E 组 · 业务与合规类（2 项）

16声音克隆的授权与滥用风险

现象用公开音频克隆真人音色，涉及人格权/声音权与诈骗风险。
根因零样本 3s 克隆门槛极低；国内《民法典》对声音权益有明确保护，已有判例。
解法复刻流程强制录制授权语句 + 留存书面授权；平台侧做声纹黑名单与相似度拦截；输出加不可感知水印以便溯源；对外呼场景明示「AI 客服」身份。
验证合规 checklist 走查 + 抽样审计。

17AI 生成内容强制标识（国内硬约束）

现象合成语音未加标识，不符合监管要求。
根因《人工智能生成合成内容标识办法》自 2025-09-01 施行，要求生成合成内容添加显式标识与隐式标识；配套标准明确语音标识要素需包含「人工智能/AI」与「生成/合成」语义，隐式标识写入文件元数据（含生成合成属性、服务提供者信息等要素）。
解法选择原生支持水印/元数据标识的厂商能力；自建则在音频封装写入元数据 + 可选音频水印；交互场景以语音提示或界面提示满足显式标识要求；把标识环节纳入发布流水线而不是事后补。
验证抽检产出音频的元数据字段与显式提示是否齐备。

中9. 国内厂商：流式能力与差异化策略

国内五家主力（字节火山 / 阿里 / 腾讯 / 讯飞 / MiniMax）已全部提供双向流式 WebSocket接口，差异在于中文韵律、方言覆盖、声音复刻体验与单价。下表信息基于官方文档与官方发布信息，数据截至 2026-07。

厂商 / 产品流式形态技术底色差异化卖点适合场景
字节·火山引擎
豆包语音合成大模型 Seed-TTS
 双向流式 WS
+ HTTP Chunked/SSE 单向流式（V3）+ 非流式 V1
 大模型（Seed-TTS 系），上下文情绪/语调预测 情绪表现强；原生 Markdown 过滤 + LaTeX 朗读；与 RTC 深度集成（实时对话开箱即用）；声音复刻成熟；并发版/时长版计费可选 语音客服、外呼、实时交互、短视频配音
阿里·百炼 / 智能语音交互
CosyVoice 系 / Qwen-TTS 系
 双向流式 WS
官方「实时语音合成」支持流式输入+流式输出
 CosyVoice2 架构（FSQ 量化 + 块感知因果流匹配） 同源开源（CosyVoice2 可自建，可平滑迁移）；官方宣称超低延迟约 150ms；声音复刻 + 声音设计；细粒度音频控制 需「云 + 自建」双轨、对自主可控有要求的团队
腾讯云
流式文本语音合成 / 对话式 TTS（TRTC）
 WS 流式文本输入
官方「边合成边播放」，与「实时语音合成」区分
 传统神经 TTS + 大模型音色并行 基于 TRTC 的对话式 TTS主打超低延迟；粤语/四川话等方言；电话场景 8k 采样支持完善；与云呼叫中心打通 呼入客服、IVR、微信生态应用
科大讯飞
超拟人语音合成 / 星火极速超拟人
 双向流式
官方文档明确「同一会话分段多次发送文本并获得音频」
 端到端大模型 + 多维度语音属性解耦表征 副语言现象（呼吸、叹气、语速变化）模拟；情感可感知度官宣较高；方言能力强；离线/私有化方案成熟 教育、政企私有化、新闻播报、方言客服
MiniMax
Speech-02 / 2.5 / 2.x 系列
 流式（WS/SSE） AR Transformer + 自研音色编码器 官方宣称 32 语种；中文/粤语/日韩 WER 优于 ElevenLabs（第三方榜单与新华社报道交叉印证）；情绪/停顿标签可控；已上架阿里百炼渠道 情感陪伴、有声书、出海多语种内容
智谱 / 其它
GLM-Voice 等端到端方向
 以端到端语音交互为主 端到端语音大模型 不拆 TTS，直接语音到语音；情感与打断体验好，但可控性与可审计性弱 陪伴、演示、弱合规要求场景

国内选型的三个实战建议

  • 先看接口形态，再听音质：如果业务是 Voice Agent，没有双向流式的产品直接出局——音质再好也赔在延迟上。
  • 一定要测 8k 电话采样率：很多模型在 24k 下惊艳，降到 8k 窄带电话链路后优势大幅衰减，外呼场景必须用真实电话链路盲听。
  • 备一家同源开源方案：阿里云与 CosyVoice2 同源，商业 API 涨价/限流/合规变动时可切自建，是成本与供应链双保险。

外10. 国外厂商：以「延迟数字」为营销武器的市场

注意：下表延迟均为厂商官宣模型侧数字，不含网络与应用开销；社区实测普遍高于此值 2~4 倍，选型时必须自测。

厂商代表模型官宣延迟流式能力技术/产品特征
ElevenLabs
 Flash v2.5 / Turbo / Multilingual v2 / v3 75ms（Flash v2.5，不含网络） WS 流式 + multi-context 声音库与生态最强；分档模型清楚（快/好二选）；社区反馈其 Conversational AI 整体延迟在 500~800ms 量级，且 Reddit 上有外呼场景嫉慢的真实抄评
Cartesia
 Sonic / Sonic Turbo TTFA 199ms（官方对比页） 原生流式（SSM 架构） 基于状态空间模型（非纯 Transformer），天生适合流式；以「比 ElevenLabs 快四倍」作为对比营销口径（官方口径，需自验）
OpenAI
 gpt-4o-mini-tts / Realtime API 未单独公布 TTFB TTS 流式输出；Realtime 走端到端 优势在「指令控声」（用自然语言描述语气）与端到端 Realtime 生态；级联场景延迟不是强项，社区实测普遍比 ElevenLabs 慢
Deepgram
 Aura-2 TTFB 从 <200ms 优化到 90ms（官方工程博文） 流式 + 可自托管部署 企业 Voice Agent 定位，强调清晰度与一致性而非极致情感；提供 on-prem；官方公开了降延迟工程细节，是学习优化手法的好教材
Microsoft Azure
 Neural TTS / 标准与定制神经声音 依赖 SDK 优化（官方有专题降延迟指南） 流式（SDK 封装） 语种与地区覆盖最全、企业合规与 SLA 最成熟；稳定性口碑好（社区对比中常与 CosyVoice 并列稳定档）；SSML 能力最完备
Google Cloud
 Chirp 3 HD / Gemini Live 社区实测流式约 200ms vs 批量 800ms StreamingSynthesize gRPC 流式接口上线较晨（Pipecat 社区 Issue 里有实现与延迟对比数据）；与 Gemini Live 端到端路线并行
AWS
 Amazon Polly（含 bidirectional streaming） 未单独公布 双向流式（官方博文专门为会话式 AI 推出） 传统神经 TTS 音质稳、价格低、工程可预测性强；情感与克隆弱于 G3 新势力
新势力（垂直）
 Rime（口语化）/ Hume Octave（情绪）/ Inworld（Realtime TTS） Inworld 官宣 P90 <250ms streaming-native 细分定位：Rime 主打真实口语感与呼叫中心场景，Hume 主打情绪可控，Inworld 主打高并发低成本；适合作为主引擎的备选/AB

一个必须记住的行业事实

行业博文反复出现同一个结论：即使 STT 150ms + TTS 75ms，大多数真实 Voice Agent 仍然做到 800ms~2s，因为延迟会在整条技术栈上复利叠加（VAD 等待 + 网络 + LLM 首 token + 分句缓冲 + 抖动缓冲）。所以换更快的 TTS 通常只能解决 10~20% 的问题，先做链路时序分析再选模型，才是正确顺序。

¥11. 价格与自建盈亏平衡

价格是选型的硬约束，但也是最易变动的信息。下表为公开官方报价的量级参考（截至 2026-07），实际商务价格与阶段折扣、包年并发、新用户免费额度强相关，必须以当前官网为准并走商务报价。

↔ 表格可横向滑动 ｜ 注意计费单位差异：国内多按「字符」（一个汉字可能算 2 字符），海外按 1000 characters

方案公开报价量级计费单位陷阱适合量级
阿里云 CosyVoice 大模型
 官方计费页：2.00 元/万字符 1 个汉字 = 2 字符，英文字母/标点/句中空格 = 1 字符——中文实际单价要翻倍算 中小量；大量走商务或自建
火山引擎（豆包）
 开发者文章口径约 1.3 元/千字，量大折扣；另有并发版包年商品 要区分「字」与「字符」；并发版按路数计价，适合持续高负载外呼 高量外呼首选（并发版摊到每字成本极低）
MiniMax（百炼渠道）
 如 speech-2.8-hd 级别报价 3.5 元/万字符；音色复刻单次计费 高清档与快速档价差大；克隆音色有额外费用 多语种/情感优先的内容型业务
ElevenLabs
 API 页：Flash/Turbo $0.05 / 1000 字符，Multilingual v2/v3 $0.10 / 1000 字符 换算下来约为国内方案的数倍到十倍；高量预付套餐可降 小量高质量、英语为主的海外业务
Google Cloud TTS
 旧版标准声音低至 $4 / 百万字符；Neural2 等高级声音显著更贵 阶段计价，要分模型档看；新 Chirp3 HD 单独定价 成本敏感、质量要求不极端的海外场景
自建（CosyVoice2 类）
 成本 = GPU 租金/折旧 + 运维人力 + 峰谷闲置损耗 真实成本取决于平均利用率；利用率 20% 的自建通常贵于 API 数据不出境 / 定制音色 / 极大量稳定负载

盈亏平衡测算方法（直接拿去用）

设：商业 API 单价 P 元/千字，平均每分钟语音对应 W 字（中文普通语速约 220～260 字/分钟），自建月固定成本 C 元（GPU + 运维），自建单卡可持续并发 N 路。

  • 商业 API 月成本 = 月总分钟数 × W / 1000 × P
  • 自建月产能（分钟）= N × 60 × 24 × 30 × 平均利用率
  • 盈亏平衡点：月总分钟数* = C × 1000 / (W × P)；低于此值用 API，高于此值且负载稳定才考虑自建
  • 必须计入的隐形成本：自建需额外养 1 人日常运维 + 模型迭代跟进，以及幻觉重试带来的额外 GPU 消耗（典型 3～8%）

经验结论：对大多数团队，先用国内商业 API 并发版跑业务，并行把自建作为降级/议价筹码，是比一上手就自建更理智的路径。

◈12. 开源方案横评（自建路线）

自建的真实动机通常不是省钱，而是数据不出境 / 音色自有 / 定制方言 / 不被限流。选型时先问一句：这个模型原生支持流式吗？

↔ 表格可横向滑动 ｜ 信息来源：各项目 GitHub / 论文 / 社区实测对比文章，截至 2026-07

项目架构原生流式零样本克隆稳定性口碑适用定位
CosyVoice 2
阿里通义 · Apache-2.0 系
 LLM(Qwen 类) + FSQ token + 块感知因果流匹配 ✓ 双向流式
官方称低至约 150ms
 强 社区对比中常与 Azure 并列稳定档 首选：需要流式 + 中文优先 + 可商用的自建基底
Qwen3-TTS
阿里 · 2025 开源
 多语言可控 LLM-TTS ✓ 超低延迟流式
技术报告称首包低至 97ms
 3s 声纹克隆 较新，长期稳定性待观察 多语种/方言 + 自然语言描述“设计音色”的新选项
Fish-Speech
· 1.5+
 双 AR + 神经声码器 ✓
社区对比中与 CosyVoice 并列为少数支持流式的项目
 强 社区反馈可能带底噪 多语种、轻量、快速落地
GPT-SoVITS
 GPT 类 AR + SoVITS 声纹转换 需改造/分句模拟 少样本微调极强 音色像度极高，但参数敏感 定制音色、二次创作、非实时产能
F5-TTS
 非自回归 DiT + 流匹配 ✗ 原生不支持 强 社区实测长文本可能异常音调，需调参 离线高质量合成、研究基线
MaskGCT
 掩码生成式（非 AR） ✗ 强 质量高、推理重 离线配音、学术对比
Kokoro / Piper
轻量级
 小参数量神经 TTS（G2 路线） ✓ CPU 即可实时 不支持/很弱 极稳，几乎不幻觉 兵家必争位：降级兜底、边缘/嵌入式、成本敏感场景
IndexTTS / Spark-TTS 等
 LLM-TTS 变体 部分支持 强 迭代快，需自验 中文内容创作、备选对比

自建架构建议（可直接用作落地蓝图）

三层引擎组合：① 默认层走 CosyVoice2（流式 + 克隆）；② 降级层备 Kokoro/Piper 类轻量模型，当 GPU 排队超阈或幻觉重试失败时自动切（宁可机械不可断流）；③ 高价值层走商业 API（重要客户/重要话术）。服务拆分为 AR 服务（vLLM/TensorRT-LLM）+ 声码服务（TensorRT/ONNX）+ 接入层（TN/切分/过滤/缓存/降级/水印），接入层是自建的真正护城河。

◉13. 应用场景：国内 vs 国外的重心差异

场景延迟要求国内典型形态国外典型形态关键矛盾点
语音客服 / 外呼
极高 <300ms 首包智能客服市场成熟（IDC 将其定义为融合 ASR/TTS/NLP/知识图谱的对话式 AI）；重外呼、催收、回访、电销Voice Agent 初创密集（预约、客服、预审），多跑 LiveKit/Pipecat/Vapi 技术栈8k 窄带传输、打断、方言、合规明示
智能座舱
高，且需离线兼容语音交互已是乘用车座舱标配（行业报告渗透率高达 86%），轻量 TTS 上车需求大同样广泛，但更依赖云端断网降级、端侧算力、唤醒联动
数字人 / 直播
高，且要与口型对齐电商直播、虚拟主播、景区展馆解说虚拟主播、游戏 NPC（Inworld 类定位）音频-口型同步、长时稳定性
有声书 / 配音
低（可非流式）出版业规模化 TTS 制作，广播剧、教育、泛娱乐有声书平台与自流量创作者质量优先，流式不重要，但长文稳定性致命
无障碍 / 屏幕朗读
极高，要本地系统级 TTS、轻量模型下载需求上升同样以本地轻量模型为主（Piper 类）纯本地、低功耗、可控语速
同传 / 会议助手
极高，边听边说会议系统、翻译机硬件实时翻译 API（OpenAI 将推理能力引入语音模型后同传成本大幅下降）流式输入不完整句，TN 与韵律双重挑战
情感陪伴
中高，情感优先陪伴 App、声优类产品Character.AI 类、Hume 情绪路线情感自然度 > 延迟，往往选端到端

国内外差异总结（四条）

  • 技术取向：国外卸载到「延迟数字 + 开发者体验 + 生态集成」；国内卸载到「中文韵律 + 方言 + 声音复刻 + 云上一体化（RTC/呼叫中心）」。
  • 商业模式：国外按字符/时长计费为主；国内普遍提供并发版包年，高量外呼场景单位成本可能数倍低于海外。
  • 合规：国内多一层强制标识与深度合成备案；海外主要靠平台自律（声纹验证 + 水印）与当地隐私法。
  • 链路形态：海外开源编排框架（LiveKit Agents / Pipecat）事实上成为链路标准，国内多为厂商一体化方案或自研中控（如 FreeSWITCH + Java 中控）。

⇄14. 级联（ASR+LLM+TTS）vs 端到端语音大模型

维度级联链路端到端 S2S
延迟双向流式优化后可做到 500~800ms（实测典型值）可至 250~500ms，且打断响应更自然
可控性高：话术、知识库、工具调用、敏感词、日志都可控低：输出难审核，话术合规难保证
情感与自然度中（受 TTS 上限限制）高（保留语气、笑声、语气词）
成本可分档优化，总体可控目前普遍更贵，并发成本高
可观测/可迭代每段可量化，便于定位黑盒，只能整体 AB
适合业务型客服/外呼（主流，且仍将长期主流）陪伴、娱乐、高沉浸交互

行业共识

多份行业总结与开发者调查指向同一结论：级联方案因灵活性与低成本仍占主流，端到端在长上下文与情感包容性上逐步崛起。理智的做法是链路层抽象接口，让 TTS 可替换、也能整体切到 S2S，而不是现在就二选一。

♫15. 可控性：SSML 与新一代「指令控声」

业务上真正让 TTS 可用的不是「声音好听」，而是「能改」——读错能纠、停顿能控、情绪能调。可控手段正在从 SSML 标记 向 自然语言指令 + 富语言标签 迁移。

控制手段形态能控什么代表实现流式下的坑
SSML（XML 标记）
 <prosody>/<break>/<phoneme>/<say-as> 语速、音高、音量、停顿、强制音素、数字读法、多说话人切换 Azure（能力最完备，含风格/角色）、阿里云 ISI、腾讯云、华为云 标签可能被切块截断，必须在接入层保证完整标签不跳块；部分大模型 TTS 对 SSML 支持反而不如传统模型
富语言 / 情感标签
 文本内嵌标签，如笑声、叹气、停顿、情绪词 情绪表达、拟声插入、语气词 阿里百炼（官方明确支持情感与富语言标签）、MiniMax（预设标签库与停顿）、讯飞（副语言现象：呼吸/叹气） 标签写错会被当普通文本念出来，必须做白名单校验
自然语言指令
 另起一个 instruction 字段描述语气 “用温柔安慰的语气”“像客服一样专业”等整体风格 OpenAI gpt-4o-mini-tts、阿里百炼（指令控制表现力）、豆包 Seed-TTS（指令微调+RL） 效果不稳定、难回归；同一指令不同文本表现可能差很多
参数式控制
 speed / volume / pitch / emotion 枚举 全局语速音量、预定义情绪 几乎所有厂商 改参数可能需重建会话（注意能不能会话中途改）
词典 / 热词
 自定义读音表 品牌名、人名、多音字、行业术语 PaddleSpeech（扩增短语词典）、部分商业 API 提供替换词表 落地必备：没有词典能力的引擎，读错了你没手段修

选型时的可控性硬指标

对客服/外呼类业务，自定义读音词典 > 停顿控制 > 情绪控制 > 自然语言指令。一个能改读音、能控停顿的“70 分音质”引擎，比一个什么都改不了的“90 分音质”引擎在生产上有用得多。

⏱16. 时间戳与口型/字幕对齐（数字人场景的隐形需求）

很多团队选完 TTS 才发现「数字人嘴型对不上」、「字幕对不齐」，而这个能力选型阶段不问就没有。

三种对齐方案（从好到差）

  1. TTS 原生字级时间戳（首选）：合成时同步返回每个汉字/单词在音频中的起止位置（阿里云称之为「字级别音素边界接口」，官方定位就是用于驱动动画）。优点：零额外延迟、流式可用。
  2. 视素（viseme）事件：比字级更进一步，直接给出与音素对应的面部关键姿态（Azure 提供 viseme 事件，可直接控制 2D/3D 头像）。优点：口型最自然。缺点：厂商支持面窄。
  3. 事后强制对齐（兜底）：拿到音频后用对齐模型反推时间轴。缺点：引入额外延迟与算力，实时场景基本不可用，只适合录播。

流式下的三个细节

  • 时间戳基准必须是会话内累计音频时长，而不是分片内部偏移；分片拼接时必须累加修正，否则越到后面偏移越大。
  • 打断时要同时丢弃待播音频与对应时间戳事件，否则数字人会「嘴已经在动、声音已停」。
  • 中文多音字与字级时间戳会相互影响：用词典强控改变读音后，时间戳粒度可能变化，需回归验证。

▢17. 端侧与离线流式 TTS（车载 / 嵌入式 / 无障碍）

云端方案再快也怕两件事：断网与隐私。车载、工业设备、屏幕朗读这三类场景必须有本地兜底。

方案形态资源量级流式能力适用与局限
sherpa-onnx
下一代 Kaldi 部署框架
 ONNX Runtime 跑 VITS / Piper / Kokoro 等模型，跨平台（Android/iOS/Linux/RTOS 类），已有 NPU 适配实践 小（百 MB 内存量级），纯 CPU 可实时 可分句流式 端侧事实上的首选底层；局限：音色克隆与情感表现远弱于云端 G3。注意社区有「播放不完整、丢最后几句」类 Issue，尾包处理要自己验
Piper
 轻量 VITS 系，多语种预训音色 极小（可上树莓派类设备） ✓ 无障碍、屏幕朗读、离线提示音；不支持克隆
Kokoro（80M 类）
 小参数神经 TTS，多语言 小，已有在国产 NPU 上的部署方案 ✓ 质量/体积平衡好，适合作为云端降级兜底与端侧主力
商业离线 SDK
讯飞/百度等
 厂商提供离线合成库 + 音库授权 中（取决于音库等级） ✓ 车载/政企私有化成熟；注意按装机量授权计费的商业模式（按发音人×装机数叠加）
云端 G3 模型下放
 CosyVoice2 等量化后上边缘服务器 大（需 GPU 或强 NPU） 可行但成本高 适合厂区/门店级边缘节点，不适合真正的端侧

云边协同的推荐做法

不要二选一。固定话术（唤醒应答、错误提示、开场白）预先在本地合成好或用端侧轻量模型即时出，动态内容走云端 G3；断网/超时时全量回退到端侧。这样用户感知到的是「很快但偶尔机械」，而不是「没反应」。

✓18. 工程落地清单（可直接当验收表用）

接入层（最容易被忽略但收益最高）

  • ☐ 文本流接收器：支持增量 token 输入，内部缓冲到「可安全切分点」
  • ☐ 动态切分策略：首片 8~15 字抢首包，后续片 30~60 字保韵律
  • ☐ 清洗器：Markdown / LaTeX / emoji / 控制字符（注意跨块标记）
  • ☐ TN 层：日期/金额/单号/百分比/单位显式转写 + 安全边界缓冲
  • ☐ 词典层：品牌词/人名/术语读音表，支持热更新
  • ☐ 缓存层：开场白/高频话术音频缓存（key = 文本+音色+参数 哈希）
  • ☐ 降级层：超时/错误/幻觉触发 → 切备用引擎，切换在 200ms 内完成
  • ☐ 标识层：水印/元数据写入（国内强制）

传输与客户端

  • ☐ WebSocket 长连接池 + 心跳保活 + 自动重连（重连不能丢当前会话）
  • ☐ 会话开始前预热（dummy 合成），避免首句冷启
  • ☐ 自适应 jitter buffer（初始 150ms，根据到达速率动态调整）
  • ☐ 块边界 cross-fade，避免爆音
  • ☐ 打断时立即 flush 本地缓冲 + 发 cancel 给服务端
  • ☐ 电话场景确认重采样链路（24k→8k 要用高质量重采样，不能简单抽点）

服务端与容量

  • ☐ AR 与声码器拆服务，分别 HPA
  • ☐ 连续批处理 + 微批窗口 10~20ms
  • ☐ 单卡并发硬上限，超限快速拒绝而不是排长队（保尾延迟）
  • ☐ 优先级队列：实时交互 > 离线批量
  • ☐ 模型版本灵活切流 + 可回滚
  • ☐ 存储合成样本抽样（用于回归与审计，注意隐私周期）

可观测与报警

  • ☐ 首包延迟 P50/P95/P99（服务端 + 客户端双口径）
  • ☐ 块间隔分布与 underrun 率
  • ☐ 幻觉重试率、降级触发率、缓存命中率
  • ☐ 单位时长成本（元/千分钟）与 GPU 利用率
  • ☐ 报警阈值：P95 首包 > 500ms、underrun > 1%、降级率 > 5%

✗19. 12 条反模式（别人踩过的坑，你不用再踩）

这一节是反面教材。每条都是在真实项目或社区讨论（Reddit / GitHub Issue）里反复出现的错误做法。

选型阶段

  • ✗ 拿厂商官宣延迟直接做选型依据 → 官宣不含网络与并发，实测差 2~4 倍。必须自测。
  • ✗ 只在 24k 高保真下试听，上线才发现 8k 电话里很难听 → 选型就要用真实链路盲听。
  • ✗ 不问自定义读音词典能力 → 上线后品牌名读错你没任何手段修，只能换引擎。
  • ✗ 忽略时间戳/viseme 需求 → 后期上数字人时发现嘴型对不上，重构成本极高。

开发阶段

  • ✗ 每句新建一次 WebSocket 连接 → 把双向流式退化成单向，白白多付握手与鉴权延迟。
  • ✗ 忘发文本结束帧（FinishText） → 尾包出不来，“最后几个字不读”。同类问题在端侧框架上也有（sherpa-onnx 社区有「丢最后几句」的 Issue）。
  • ✗ 纯标点切分 LLM 输出 → 在「因为」后面切断，韵律碎成一段一段。
  • ✗ 用单块正则过滤 Markdown → ** 跨块被切开时漏网，念出星号。必须用跳块缓冲状态机。
  • ✗ 客户端缓冲开 500ms 固定值 → 把服务端花大力气省下的首包又赔回去。用自适应。

上线阶段

  • ✗ 把单卡并发塞到拐点 → 平时看着很省钱，一注流量尖尖就集体断流。取拐点×0.7。
  • ✗ 只监控平均延迟，不监控 P95 与 underrun → 用户已经在投诉卡顿，看板还是绿的。
  • ✗ 没有降级链路 → 厂商限流或模型抽风时，整个业务直接哑火。
  • ✗ 合规标识等上线后再补 → 历史音频要重处理，成本远高于一开始就接入发布流水线。

⑂20. 3 分钟选型决策树

不想读完全文的人，只看这一节。按顺序回答问题，直接得到推荐。

第一层：你的场景需要双向流式吗？

  • 需要实时对话（客服/外呼/数字人/同传）→ 必须双向流式，继续往下看。
  • 只是把已知全文读出来（播报/有声书/配音）→ 不需要双向，直接比音质与单价，推荐先试 MiniMax / 讯飞超拟人 / ElevenLabs Multilingual。

第二层：数据能出境/出公司吗？

  • 不能出境或必须私有化 → 走自建路线：CosyVoice2（主）+ Kokoro/Piper（降级）；或讯飞类离线 SDK。直接跳到第四层。
  • 可以上云 → 继续。

第三层：主要语种与地区？

  • 以中文（含方言）为主、国内业务 → 首选火山豆包（情绪 + RTC 集成 + 并发版成本），备选阿里百炼（可平滑迁到自建 CosyVoice2）；呼入/IVR 重度依赖腾讯生态则看腾讯对话式 TTS。
  • 东南亚/多语种出海 → 先测 MiniMax（宣称 32 语种）与 Qwen3-TTS，小语种缺口用 Azure 补（语种覆盖最全）。
  • 英语为主的海外 Voice Agent → Deepgram Aura-2（企业级 + 可自托管）或 Cartesia Sonic（流式原生架构），声音库需求强则 ElevenLabs Flash。

第四层：量级与成本

  • 月用量低于盈亏平衡点（见第 11 章公式）→ 就用商业 API，不要自建。
  • 高于平衡点且负载稳定 → 商业并发版 + 自建双轨，自建先跑非关键流量。
  • 流量峰谷差异大（如白天外呼、夜间空闲）→ 商业 API 撑峰值 + 自建撑底谷，避免为峰值买 GPU。

第五层：无论选哪家，这 5 件事都要做

  1. 接入层自建（TN + 切分 + 过滤 + 词典 + 缓存 + 降级），不要把这些逻辑散在业务代码里。
  2. 全链路 trace 埋点，能对任意一通会话画时序图。
  3. 备一个轻量降级引擎（宁可机械不可断流）。
  4. 建 badcase 回归集，模型/厂商一换就跑一遍。
  5. 合规标识接入发布流水线（国内）。

§21. 合规与安全要点

国内（硬约束，上线前必过）

  • 生成合成内容标识：《人工智能生成合成内容标识办法》2025-09-01 施行，需同时满足显式与隐式标识；配套标准对语音标识要素与元数据字段有具体规定。
  • 声音权益：克隆真人音色必须取得明确授权，建议录制授权语句并长期留存。
  • 外呼场景：需明示 AI 身份、遵守骚扰管理与呼叫时段限制，免打扰名单必须生效。
  • 数据：合成文本往往包含客户姓名/金额/单号，属于个人信息，日志要脱敏、传输要加密。

海外

  • 平台侧普遍要求克隆时做声纹验证（录制指定语句），并对名人音色做黑名单。
  • 欧盟 AI Act 对深度合成内容有透明度义务；跨境业务需同时看 GDPR 与当地录音法（部分州/国家双方同意才能录音）。
  • 呼叫类业务额外受 TCPA 等营销呼叫法规约束（美国）。

⚑22. 四阶段学习调研方案（可执行、带验收标准）

设计原则：每阶段都有可交付物，且验收标准可量化。建议节奏：每阶段一周，共四周；如只想建认知可只做阶段一与二。

阶段一 · 概念与指标建立（建认知）

第 1 周 丨 目标：能用自己的话说清流式 TTS 的架构与延迟构成
  • 读清 3 份文档：火山「双向流式语音合成 WebSocket」、阿里百炼「实时语音合成」、Azure「How to lower speech synthesis latency」。重点看协议字段与会话生命周期。
  • 读 2 篇论文/技术报告：CosyVoice2（块感知因果流匹配、FSQ）、Qwen3-TTS 技术报告（流式低延迟）。
  • 读 1 篇工程博文：Deepgram「How We Took Aura-2's TTFB from <200ms to 90ms」——看真实优化手法。
  • 输出一张自画的延迟拆解图：从用户停止说话到听到第一个字，标注每一段的预算毫秒。
验收标准：能准确区分单向/双向流式；能列出 8 个以上指标并说出各自的测量方法；能解释为何「模型 75ms 但链路 800ms」。

阶段二 · 动手跑通流式链路（建手感）

第 2 周 丨 目标：亲手把首包从秒级压到毫秒级
  • 任务 A：用任意一家商业 API 写三个脚本——非流式 / 单向流式 / 双向流式，分别测量同一文本的 TTFB，体会差异。
  • 任务 B：本地跑通 CosyVoice2 流式推理（本工作区已有 Python 环境经验可复用），对比官方宣传的 150ms 与自己机器的实测值。
  • 任务 C：把一个 LLM 流式输出接到 TTS，实现动态切分策略，对比「整句等待」与「首句短切」的感知延迟。
  • 任务 D：手写一个最小抖动缓冲播放器，制造一次 underrun 并修好它。
验收标准：手上有一份自测数据表（至少 2 家引擎 × 4 种文本长度 × P50/P95）；能把双向流式下的感知首包做到 <500ms。

阶段三 · 难点复现与治理（建深度）

第 3 周 丨 目标：把本报告的 17 项难点至少复现 6 项并修好
  • 构建 badcase 语料集（至少 300 条）：长文、重复字串、中英混、数字/日期/金额、多音字、Markdown 污染、表情符号。
  • 建立 合成→ASR 回灌→CER 自动流水线（可直接复用本工作区 asr-bench 的引擎适配层与指标代码）。
  • 实验：改 lookahead 大小 → 观察首包与韵律的权衡曲线；调采样温度 → 观察幻觉率变化。
  • 实现一个降级开关：幻觉检测命中就自动切轻量模型，验证切换耗时。
  • 完成打断链路改造：cancel + 本地 flush，测打断响应时间。
验收标准：流水线能一键输出延迟/CER/幻觉率三类报表；打断响应 <200ms；能用数据说明自己修好了哪 6 项难点。

阶段四 · 选型决策与成本模型（建判断）

第 4 周 丨 目标：输出一份能让老板签字的选型报告
  • 定义业务约束：语种、并发峰值、首包预算、单分钟成本上限、合规要求、是否需要私有化。
  • 对 3~4 家候选（建议：火山 + 阿里 + 一家海外 + 自建 CosyVoice2）跑完整评测矩阵。
  • 建立成本模型：商业 API 按量价 vs 自建（GPU 租金 + 运维 + 峰谷利用率），算出盈亏平衡分钟数。
  • 定义降级与多供应商策略，写入架构文档。
验收标准：报告含指标矩阵、成本盈亏点、风险与降级方案、合规 checklist；每个结论都能指向一份自测数据或 2 个独立信源。

☷23. 学习资料清单（按优先级排序，不要从第一篇论文开始读）

学习流式 TTS 最大的坑是一头扎进论文。正确顺序是：官方文档（建直觉）→ 工程博文（建手感）→ 开源代码（建细节）→ 论文（建原理）。

P0 · 先读这 5 份（一天内可完成，性价比最高）

  1. 火山「双向流式语音合成 WebSocket」文档——看完整帧协议与会话时序，是本报告第 7 章的原型。
  2. 阿里百炼「实时语音合成」文档——对比看两家协议差异，建立「抽象模型」认知。
  3. Deepgram「Engineering real-time low-latency voice AI at scale」——官方公开把 TTFB 从 <200ms 做到 90ms 的具体手法，比任何论文都实用。
  4. Azure「How to lower speech synthesis latency」——客户端侧降延迟的最佳实践清单。
  5. 声网「从 ASR 到 TTS，全链路对话模型打通意味着什么」——建立全链路延迟视角，避免只盯 TTS。

P1 · 代码与仓库（上手必跑）

  • FunAudioLLM/CosyVoice：重点读流式推理入口与 flow 模块的 chunk 处理；再看 Issues 里关于 vLLM/TensorRT-LLM 加速的真实讨论（如 #873），那里才是工程真相。
  • pipecat-ai/pipecat 与 livekit/agents：读它们的 sentence tokenizer 与 TTS service 封装——工业级分句与打断处理的参考实现。
  • PaddleSpeech Wiki · TTS Text Frontend：中文 TN、多音字消歧、词典扰动的工程做法，国内业务必读。
  • 轻量模型（Kokoro / Piper）：跑一次，体会「什么叫真的低延迟」，建立降级方案的实际手感。

P2 · 论文（按这个顺序读，不要跳）

  1. VALL-E（2023）——理解「LLM + codec token」范式为何能做到 3s 克隆，以及幻觉从哪里来。
  2. CosyVoice / CosyVoice 2 / CosyVoice 3——三代连着读，重点看 FSQ 量化与块感知因果流匹配（流式化的核心），以及参数从 0.5B 到 1.5B 带来的变化。
  3. Seed-TTS（字节）——看指令微调 + 强化学习如何做情绪可控。
  4. Qwen3-TTS 技术报告——看多语言 + 超低延迟流式是怎么同时做到的（宣称首包 97ms）。
  5. NVIDIA NeMo T5-TTS——幻觉治理的代表工作（单调比先验 + CTC）。
  6. StreamFlow（Streaming Flow Matching with Block-wise Guided Attention）——流式流匹配的前沿方向。
  7. VALL-E 2与「流式实时语音生成综述」——收尾补全图景。

P3 · 社区与反面教材（最容易被跳过，但价值极高）

  • Reddit r/ElevenLabs「Voice Agent Too Slow for Cold Calls」与 r/LLMDevs 上线踩坑帖——看真实产品怎么死的，比厂商官网有信息量。
  • Pipecat Issue #1812（Google Chirp3 HD 流式实现）——看开发者如何实测出「流式 ~200ms vs 批量 ~800ms」。
  • 知乎/CSDN 开源 TTS 横评系列——参考价值在于“稳定性坑”的描述（底噪、长文异常音调），但数据需自验。
  • 本工作区已有报告：EOU 选型调研（判停环节，直接影响 400ms 预算）、ASR 评测看板（评测框架可直接复用）、全双工时序追踪（链路延迟可视化）。

☵24. 中英术语对照表（查论文与看英文文档用）

中文资料里的译名不统一，搜论文时必须用英文关键词。这张表把本报告全部概念对齐到官方英文说法。

中文英文 / 缩写一句话解释
首包延迟TTFB / TTFA（Time To First Byte / Audio）从最后一个必要输入到第一个音频字节
实时率RTF（Real-Time Factor）合成耗时 / 音频时长，<1 才不断流
双向流式bidirectional streaming / duplex文本流入 + 音频流出同时进行
块因果注意力chunk-aware causal attention只看当前块 + 有限右看窗，流式化核心
右看窗 / 前瞻lookahead允许模型提前看到的未来内容量
流匹配Flow Matching / CFM（Conditional Flow Matching）比扩散更少步数的连续生成方法
有限标量量化FSQ（Finite Scalar Quantization）CosyVoice2 用的语音 token 量化方式
神经音频编解码器neural audio codec（EnCodec / SoundStream）把波形变成离散 token，G3 的地基
声码器vocoder（HiFi-GAN / BigVGAN / Vocos）把梅尔谱或声学特征转成波形
零样本克隆zero-shot voice cloning不微调，靠短 3～5s 参考音频复刻音色
说话人向量speaker embedding / d-vector表征音色身份的向量
幻觉（吞字/复读）hallucination / repetition & omissionAR TTS 的稳定性问题
单调对齐monotonic alignment文本与音频顺序不回跳的约束
文本归一化TN（Text Normalization）把书面形式转为可读口语形式
多音字消歧polyphone disambiguation判定汉字在上下文中的正确读音
韵律预测prosody prediction预测停顿、重音、语调起伏
标记语言SSML（Speech Synthesis Markup Language）用 XML 标签控制合成细节
视素viseme与音素对应的可见口型关键帧
打断barge-in用户插话时中止 AI 发言
抖动缓冲jitter buffer吸收网络/产出速率波动的播放缓冲
缓冲耗空underrun音频没跟上播放，表现为卡顿
连续批处理continuous batching不等攒齐就动态组批的推理调度
端到端语音模型S2S（Speech-to-Speech）/ Realtime API不拆 ASR/TTS，直接音频 token 生成
话轮结束检测EOU（End-of-Utterance）/ turn detection判定用户是否说完，直接影响延迟预算
中英混读code-switching一句话内混用多语种

▤25. 自建 tts-bench 评测框架设计

本工作区已有 asr-bench（商业 ASR 批量评测）与 duplex-trace（全双工时序追踪），tts-bench 完全可以复用它们的适配器与看板结构，不需要从零开始。

目录与模块设计

  • adapters/：每家一个适配器（volcengine / aliyun / tencent / xfyun / minimax / elevenlabs / azure / local_cosyvoice），统一接口 synthesize_stream(text_iter, voice, params) -> audio_chunk_iter。
  • datasets/：分集管理——latency 集（四档长度）、TN 集（十类实体）、badcase 集（幻觉诱发）、多语种集。
  • metrics.py：TTFB、块间隔分布、RTF、underrun、CER（回灌 ASR）、SIM（声纹）。
  • runner.py：并发扫描（1/4/8/16/32），自动画容量曲线。
  • report/：输出静态看板（与 asr-bench report-site 同构）。

必须固定的实验条件（否则数据不可比）

  • 采样率与编码统一（推荐同时跑 16k 与 8k 两套）；块大小参数尽量对齐
  • 同一地域的客户端；记录 RTT 基线（另开一个 ping 探针）
  • 每组至少 30 次重复，取 P50/P95；预热 5 次不计入
  • 音色固定为「预置女声 + 克隆音色」两组分别统计
  • 同时记录服务端返回的内部耗时（如有）以分离网络开销

?26. 30 道自测题（检验学习成果，点展开看答案）

能连续答对 24 题以上，说明你已经可以独立做流式 TTS 选型与落地。答错的题直接回到对应章节重读。

1. 单向流式与双向流式的本质区别是什么？
单向只有输出流式，输入必须一次性给全；双向允许文本分多次增量输入，从而让 TTS 合成与 LLM 生成重叠。
2. 为什么厂商官宣 75ms，你实测却是 400ms？
官宣通常只含模型侧推理时间，不含 TLS 握手、鉴权、跨区 RTT、排队等待、客户端缓冲。
3. TTFB、RTF、块间抖动分别对应什么体验问题？
TTFB → 「开口前的沉默」；RTF > 1 → 「跟不上播放，断流」；抖动大 → 「一卡一卡、爆音」。
4. 为什么横评必须看 P95 而不是平均值？
语音交互的体感由长尾决定，偶尔的 1.5s 停顿比平均多 50ms 更致命。
5. G3（LLM-TTS）带来的最大好处与最大代价各是什么？
好处：零样本克隆、情感与韵律接近真人、可指令控制。代价：幻觉/不稳定 + 高算力成本，且天生反流式。
6. 什么是块因果注意力，它的权衡旋钮是什么？
把注意力限制在「当前块 + 有限右看窗」，使模型可按块推理。旋钮是 lookahead 大小：越小首包越低，韵律越差。
7. Flow Matching 步数减少会带来什么变化？
首包与 RTF 下降，但音质/稳定性下降；通常需配合蒸馏才能保住质量。
8. 为何合成 2 个字和 20 个字首包差不多？
AR prefill + Flow 迭代 + 声码器最小感受野构成与长度无关的常数开销。
9. 分句切分为何不能只靠标点？
会在「因为」「但是」后面切断，造成韵律与语义断裂；需要语义完整性判断。
10. 首片与后续片为什么要用不同长度？
首片短→抢首包；后续片长→保韵律与降低固定开销占比。
11. 忘发 FinishText 会出什么现象？
服务端一直等待后续文本，尾包不返回，表现为「最后几个字不读」、会话不结束。
12. 为什么高并发下尽量避免 base64 传音频？
base64 增加约 33% 带宽与额外编解码 CPU，在千路并发下不可忽略。
13. 打断时除了停止播放，还必须做什么？
① 丢弃客户端缓冲；② 向服务端发 cancel 释放 GPU；③ 记账未播放文本以便续接。
14. 幻觉（吞字/复读）的根本原因是什么？
自回归 LLM-TTS 缺乏硬性文本-音频单调对齐约束，注意力可回跳或跳跃。
15. 工业上如何兜住幻觉？
合成后 ASR 回灌校验，CER 超阈则重合成或降级到稳定的 G2/轻量模型。
16. 长文本下语速漂移怎么解？
分段合成，段间携带上段末尾作为韵律 prompt；限制单请求最大字符数。
17. 为什么克隆音色会「越说越不像」？
分片独立采样 + 说话人条件被稀释；应会话级复用 session 与 speaker embedding。
18. 「2024-07」被读成「二零二四减零七」属于哪类问题？
文本归一化（TN）问题，且因流式看不到后文而加剧；需 TN 安全边界缓冲或业务侧显式转写。
19. 多音字读错在工程上靠什么兜底？
自定义读音词典/热词 + 业务侧品牌词拼音映射表；badcase 闭环。
20. 流式过滤 Markdown 有什么特殊难点？
标记可能跨块被切断（如 ** 分属两块），需要跳块缓冲的状态机而非单块正则。
21. 为什么外呼场景必须用 8k 真实链路盲听？
很多模型在 24k 下惊艳，降到窄带 8k 后优势大幅衰减，且重采样质量影响很大。
22. 为何建议把 AR 与声码器拆成两个服务？
两者瓶颈类型不同（decode-bound vs compute-bound），拆开才能分别批处理与扩容，提高 GPU 利用率。
23. 容量上限为何取拐点并发×0.7？
真实流量有峰谷，卡在拐点上跑，任何小波动都会让 P95 爆炸并开始断流。
24. 为什么说「换更快的 TTS 只能解决 10~20% 问题」？
因为延迟在全链路复利叠加（判停、网络、LLM 首 token、并发、分句缓冲、抖动缓冲），TTS 在典型预算里只占小部分。
25. 自建与商业 API 的盈亏平衡怎么算？
月总分钟数* = C×1000/(W×P)；C=自建月固定成本，W=每分钟字数，P=商业单价（元/千字）。还要计入运维人力与利用率。
26. 阿里云「2 元/万字符」对中文实际单价意味着什么？
官方计费规则里1 个汉字算 2 字符，所以纯中文内容的实际单价要按翻倍估算。
27. 客服场景选型时，可控性优先级如何排？
自定义读音词典 > 停顿控制 > 情绪控制 > 自然语言指令。能改比好听重要。
28. 国内上线合成语音必须做的合规动作是什么？
根据《人工智能生成合成内容标识办法》（2025-09-01 施行）同时做显式标识与隐式标识（元数据）。
29. 什么时候应该选端到端 S2S 而不是级联？
情感/际伴/娱乐优先、对可审核与话术控制要求低、对打断自然度要求高时。业务型客服仍应优先级联。
30. 如果只能做一件优化，应该做哪件？
先做全链路时序埋点与可观测。不知道钱花在哪一段，所有优化都是瞎猜。

◎27. 信源清单

官方文档为主，论文与厂商工程博文补充机理，社区（Reddit / 知乎 / GitHub Issue）提供真实落地反馈，相互交叉验证。

关于数据可信度的声明

  • 所有延迟数字均为厂商官宣或第三方测试口径，测试条件（文本长度、区域、并发）往往不公开，不可直接用于选型决策，必须自测。
  • 厂商对比页（如 Cartesia 对比 ElevenLabs）存在利益相关，仅作方向参考。
  • 开源项目能力迭代极快（月级），本表结论适用于 2026-07，建议季度重验。

↻28. 三轮迭代记录（本报告自身的验收轨迹）

本报告按「产出 → 验收 → 找缺口 → 重立方案」循环迭代三轮。这一节公开每轮发现了什么缺口、补了什么，方便后续继续追加。

第 1 轮 · 建骨架（15 章）

产出：流式形态定义、指标体系、三代架构、流式化四种手段、17 项难点、国内外厂商与开源横评、场景差异、级联 vs 端到端、工程清单、合规、四阶段学习方案、评测设计。

验收发现的 8 个缺口：① 全是文字表格、零可视化；② 没有毫秒级延迟预算；③ 没有协议帧级交互细节；④ 没有价格与成本量化；⑤ 没有按优先级的阅读清单；⑥ 没有技术演进时间线；⑦ 没有自测手段；⑧ 长页缺回顶部。

第 2 轮 · 补硬菜（15 → 22 章）

新增：30 年演进时间线、毫秒级延迟预算（含纯 CSS 瀑布图与并发拐点图）、双向流式协议解剖（帧序列 + 各家命名映射 + 8 个选型问题）、价格与自建盈亏平衡公式、SSML 与指令控声、分优先级学习资料清单、30 道自测题、回顶部按钮。

验收发现的问题：延迟瀑布图里「120ms 重叠」标签在 375px 下排版溢出；场景 B 条形占比与数值不一致（累计超 100%）；回顶按钮遮挡正文 —— 已全部修复。

第 3 轮 · 补落地层（22 → 28 章）

新增：时间戳与口型/字幕对齐（数字人隐形需求）、端侧与离线流式 TTS（车载/嵌入式/无障碍）、12 条反模式、3 分钟选型决策树、中英术语对照表、本迭代记录。

本轮定位：前两轮解决「看懂」，第 3 轮解决「会选」与「少踩坑」。现在一个从未接触过 TTS 的人，可以只读第 4 章（延迟预算）+ 第 20 章（决策树）+ 第 19 章（反模式）就能做出不离谱的技术选择。

下一轮（如需继续）建议补的方向

  • 真实实测数据：本报告所有延迟数字仍为厂商口径与行业推算，尚未包含本地实测。下一步应落地 tts-bench（第 25 章设计），拿自己的数据替掉估值。
  • 东南亚小语种 TTS 专题：参照本站 EOU 多语种报告的做法，做语种×引擎覆盖矩阵。
  • 声音克隆的反滥用与防伪造：与本站声纹/反合成调研交叉成专题。
  • 端到端 Realtime 方案的实测对比：现在只做了定性对比，缺同条业务下的 AB 数据。
流式 TTS 全景调研 · 第 3 轮版本（28 章）丨 编制 2026-07-29 丨 返回调研中心
↑