ChatTTS语音合成实战：如何通过Prompt控制实现精准停顿(Break)插入
语音合成里，停顿不是“可有可无”的装饰，而是让听众大脑喘口气的节拍器。。一段没有停顿的语音，就像一口气读完的说明书——信息密度高到炸裂，却没人记得住。尤其在客服、导航、播报这类“高信息+短时长”场景，停顿控制直接决定用户是“秒懂”还是“秒挂”。ChatTTS 把停顿权交给了开发者，但很多人翻遍文档只看到“prompt”输入框，找不到传说中的 break，于是误以为“这模型天生不会停”。其实它支持 SSML，只是入口藏得有点深。
直接改文本 vs 上 SSML：两种思路的 PK
| 方案 | 实现方式 | 精度 | 可维护性 | 翻车点 | |---|--- --|--|--|--| | 方案A：文本里硬塞空格/标点 | “你好，逗号停顿一下” | 依赖模型“猜”长短，500ms 还是 50ms 全看运气 | 低，换个模型就失效 | 中英文混排时，标点被吞掉 | | 方案B：SSML 标签 |<break time="500ms"/>| 精确到毫秒级 | 高，标签语义明确 | 需要开 SSML 开关，否则当普通文本念出来 |
结论：一次性 demo 可以方案A，线上生产请直接方案B，否则产品经理会拿着日志问你“为什么用户听到的是‘逗号停顿一下’七个字”。
核心代码：用 SSML 在 ChatTTS 里“指哪停哪”
下面这段脚本把“入口检测 → 参数校验 → SSML 拼装 → 请求 → 本地缓存 → 异常重试”整条链路一次性跑通，注释直接写到行级，拿来改两行就能上线。
#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ ChatTTS SSML 停顿示例 依赖: requests, cachetools, tenacity """ import re import time import hashlib import requests from cachetools import TTLCache from tenacity import retry, stop_after_attempt, wait_exponential # 1. 基础配置 API_URL = "https://api.chattts.com/v1/synthesize" API_KEY = "sk-YourKey" MAX_CONCURRENT = 5 # 控制并发，别一上来就把限流打满 CACHE_TTL = 600 # 10 分钟缓存，重复文本直接复用 # 2. 线程安全缓存：key 是 ssml 的 md5，value 是音频 bytes audio_cache = TTLCache(maxsize=1000, ttl=CACHE_TTL) # 3. 参数校验：SSML 白名单 + 时长范围 BREAK_PATTERN = re.compile(r'<break\s+time\s*=\s*["\'](\d+)(ms|s)["\']\s*/?>', re.I) MAX_BREAK_MS = 5000 # 最长 5 秒，别让用户“停”到怀疑人生 def validate_ssml(ssml: str) -> str: """ 检查 SSML 合法性： 1. 标签必须成对/自闭合 2. break 时长不能超过 MAX_BREAK_MS 返回：校验后的 ssml（如有需要可自动修复） """ for m in BREAK_PATTERN.finditer(ssml): val, unit = int(m.group(1)), m.group(2).lower() if unit == 's': val *= 1000 if val > MAX_BREAK_MS: raise ValueError(f"break {val}ms 超过上限 {MAX_BREAK_MS}ms") # 极简闭合检查：只数 <speak> 标签 if ssml.strip().count("<speak>") != ssml.strip().count("</speak>"): ssml = f"<speak>{ssml.strip()}</speak>" return ssml def ssml_prompt(ssml: str, voice: str = "zh-CN-XiaoxiaoNeural") -> dict: """ 把 SSML 塞进 ChatTTS 接口需要的 payload 注意：一定要开 enable_ssml=True，否则标签会被念出来 """ return { "text": ssml, "voice": voice, "enable_ssml": True, # 核心开关 "rate": 0, # 语速 0 表示不调整 "pitch": 0, "volume": 0 } @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10)) def fetch_audio(ssml: str, voice: str = "zh-CN-XiaoxiaoNeural") -> bytes: """ 带重试的请求逻辑： 1. 先查缓存 2. 真正请求 3. 写缓存 """ key = hashlib.md5(f"{ssml}_{voice}".encode()).hexdigest() if key in audio_cache: return audio_cache[key] payload = ssml_prompt(ssml, voice) headers = {"Authorization": f"Bearer {API_KEY}"} resp = requests.post(API_URL, json=payload, headers=headers, timeout=10) resp.raise_for_status() audio = resp.content audio_cache[key] = audio return audio # 4. 业务层：演示多停顿时长 if __name__ == "__main__": demo_ssml = """ <speak> 欢迎使用智能客服<break time="300ms"/>， 请听完以下菜单<break time="500ms"/>： 查余额请按一<break time="200ms"/>， 办业务请按二<break time="1s"/>， 重播请按井号键。 </speak> """ demo_ssml = validate_ssml(demo_ssml) audio_bytes = fetch_audio(demo_ssml) with open("demo_break.wav", "wb") as f: f.write(audio_bytes) print("合成完毕：demo_break.wav")跑通后，用播放器打开就能听到“菜单”与“选项”之间恰到好处的空拍，300ms、500ms、1s 的阶梯节奏让提示不再是一锅粥。
性能注意：网络延迟与并发请求
- ChatTTS 云端接口单次耗时 200~800ms，break 标签再多也不会增加额外计算，但会把首包时间拉长——因为模型要等“停顿”那一帧也渲染完。
- 并发高时，限流按“连接数”算，不是按“文本长度”。建议池化请求，MAX_CONCURRENT 控制在 5~10，重试间隔用指数退避，别把错误当“无限重试”。
- SSML 文本越长，首包延迟越高；把大段文案拆成 ≤500 字的小段，即使用户无感，也能降低单次失败的重试成本。
生产环境 3 条最佳实践
- 缓存策略：SSML 一旦固定，音频基本不变。用 TTLCache + md5 指纹，10 分钟级缓存可把 QPS 降一个量级；对静态提示音可以永久落盘，更新时手动刷新。
- 失败重试：网络抖动占大头，用 tenacity 的指数退避，最大 3 次、最大间隔 10s；超过阈值直接降级到本地预置 TTS 文件，保证“必有声”。
- 监控告警：把 break 时长、voice 名、合成耗时打到日志，再配一条“耗时 >1.5s”的告警。发现某 voice 突然变慢，可以第一时间切流。
把停顿玩明白后，ChatTTS 就不再是“念字机器”，而是能打节拍的“语音乐手”。下次产品经理再提“自然一点”，直接把 break 标签甩给他，节奏长短，毫秒不差。