背景痛点：多人实时语音对话到底难在哪？
去年给一款线上狼人杀做语音旁白，12 人房同时发言，高峰期 3000 个房间并发跑在 4 张 3060 上。只要有人喊“过”，系统就得在 300 ms 内把这句话播出来，还要保持同一个“法官”音色。上线第一晚就翻车了：
- 连接暴涨到 1.2 w，uwsgi 模式下一个 worker 只能串行处理，CPU 空转却排队
- 音频流乱序，玩家听到“张三”的句子被“李四”的音色读出来
- GPU 显存碎片，第 5 分钟开始爆音，日志里全是 OOM
总结下来，核心矛盾就三条：
- 并发连接管理：WebSocket 短帧+长时合成任务，IO 与计算模型不匹配
- 音频流同步：多路合成任务返回节奏不同，需要全局时钟对齐
- 资源竞争：ChatTTS 的 speaker embedding 与 GPU Context 绑定，粗暴多进程会互相踩内存
技术选型：为什么把 WSGI 换成 ChatTTS + ASGI
先放一张 100 并发下的压测对比：
| 方案 | 平均延迟 | 95 P99 | 备注 |
|---|---|---|---|
| gunicorn + flask + edge-tts | 1.8 s | 3.1 s | 串行，无流式 |
| uvicorn + fastapi + ChatTTS | 220 ms | 290 ms | 流式，RTF≈0.3 |
WSGI 的同步模型决定了“一个请求一个线程”，遇到 400 ms 的 RTF 直接卡死线程池；ChatTTS 本身支持 chunk 级流式输出，再搭配 ASGI 的单线程事件循环，可以把 GPU 等待时间全部换成网络 IO，CPU 利用率从 18% 提到 71%。
ChatTTS 另外两个优势：
- speaker embedding 可提前缓存，切换音色只需换一次 128 维向量，时间复杂度 O(1)
- 自带 Jitter Buffer 友好接口，返回 chunk 带时间戳，方便做对齐
实现方案：三步搭好高并发骨架
1. 全局架构
整体分三层：
- 接入层：Nginx + uvicorn 多端口，4 进程 * 2 线程，单进程承载 2 k 连接
- 状态层：Redis 5.0 Stream，保存“房间-发言者-文本-序列号”
- 合成层：ChatTTS 进程池（GPUContextPool），每个 Context 绑定一张卡，最大 4 并发，内部用 asyncio.Queue 做背压
2. 异步服务端 FastAPI 骨架
# main.py import asyncio, json, time, redis, torch from fastapi import FastAPI, WebSocket, WebSocketDisconnect from contextlib import asynccontextmanager from chatts_pool import GPUContextPool # 后面给出 @asynccontextmanager async def lifespan(app: FastAPI): # 初始化连接池 app.state.pool = GPUContextPool(device_ids=[0,1,2,3]) app.state.redis = redis.asyncio.Redis(host='127.0.0.1', port=6379 circuittest) yield await app.state.pool.shutdown() app = FastAPI(lifespan=lifespan)3. WebSocket 入口与流式下发
@app.websocket("/room/{room_id}/ws") async def room_ws(room_id: str, ws: WebSocket): await ws.accept() try: while True: data = await ws.receive_json() # 快速校验 text, seq, spk = data["text"], data["seq"], data["spk"] # 写进 Redis Stream，返回消息 ID msg_id = await app.state.redis.xadd( f"room:{room_id}", {"spk": spk, "text": text, "seq": seq} ) # 异步消费合成结果并流式推回 async for chunk in synthesize_stream(room_id, msg_id): await ws.send_bytes(chunk) except WebSocketDisconnect: pass4. 合成任务队列与流式生成
# chatts_pool.py import asyncio, torch, time from chatts import ChatTTS # 官方库 class GPUContextPool: def __init__(self, device_ids): self.queue_map = {dev: asyncio.Queue(maxsize=8) for dev in device_ids} self.workers = [] for d in device_ids: t = asyncio.create_task(self._worker(d)) self.workers.append(t) async def _worker(self, device): tts = ChatTTS(device=f"cuda:{device}") # 预加载 speaker embedding，O(1) 切换 spk_emb = torch.load("default_spk.pt", map_location=f"cuda:{device}") while True: item = await self.queue_map[device].get() st = time.time() wav_iter = tts.synthesize_stream( item["text"], spk_emb, speed=1.0, chunk_size=4800 ) for pcm in wav_iter: # 加上 RTP 风格时间戳，方便客户端对齐 ts = int((time.time() - st) * 1000) yield pcm, ts item["future"].set_result(None) async def submit(self, item): # 轮询选最短队列，O(n) n=GPU 数，可忽略 dev = min(self.queue_map, key=lambda k: self.queue_map[k].qsize()) fut = asyncio.Future() item["future"] = fut await self.queue_map[dev].put(item) return futsynthesize_stream内部 RTF 实测 0.28，4800 sample 的 chunk 40 ms 就能吐出，背压队列长度 8 是为了防止 GPU 被洪水冲爆。
5. 音频流分片与 WebSocket 传输优化
- 分片大小：4800 sample（≈ 300 ms 16kHz），既能让客户端尽快播放，又避免太多小帧头部开销
- 二进制协议：直接发 PCM + 时间戳 8 byte，省去 base64 30% 膨胀
- 客户端 Jitter Buffer：用 ts 排序，深度 3 片，延迟 90 ms 可抗 50 ms 抖动
性能优化：把 3060 跑到 70% 还不掉帧
压测脚本：Locust 模拟 4 k WebSocket 长连接，每 350 ms 发一条 20 字文本
- 峰值 QPS：11 k
- P99 延迟：290 ms
- GPU 利用率：71%，显存 9.4 GB / 12 GB
GPU 利用率技巧
- 把 ChatTTS 的
torch.cuda.graph()打开，一次编译多次执行，RTF 再降 12% - 合成前做 batch=2 拼接，注意 mask pad，平均 latency 增加 15 ms，但吞吐 +34%
- 显存碎片整理：每完成 500 条调用后，后台
torch.cuda.empty_cache()，一次 30 ms，对 P99 无影响
- 把 ChatTTS 的
关键指标 RTF（Real Time Factor）计算
RTF = 合成耗时 / 音频时长目标 <0.5，否则无法做流式。ChatTTS 官方 fp16 模型 RTF=0.28，满足要求。
避坑指南：音色爆音与网络抖动
音色切换爆音
- 根因：speaker embedding 切换时，模型隐状态未软过渡
- 解决：在 embedding 之间插值 5 帧，fade 长度 80 ms，听感平滑
def interp_emb(old, new, steps=5): alphas = torch.linspace(0, 1, steps).view(-1, 1) return old*(1-alphas) + new*alphas网络抖动导致音频断裂
- 客户端维护一个 3 片 Jitter Buffer，收到空帧自动补 20 ms 静音
- 服务端发送节奏用 4800 sample 固定，不随网络快慢改变，杜绝累积误差
Redis Stream 消息堆积
- 设置 maxlen=5k，超过直接丢弃旧消息，防止内存爆炸
- 消费者组 ack 机制，崩溃重启从最后 ack 点开始，不重复合成
延伸思考：声纹识别 + 动态音色适配
目前所有房间共用同一个“法官”音色，如果能把发言者的真实声纹实时提取出来，再映射到相近的 speaker embedding，就能做到“谁说话像谁”。思路：
- 客户端上行 3 秒语音 → 声纹模型（EcapaTdnn）→ 128 维向量
- 向量在 Redis 里做 L2 搜索，选最邻近的 10 个候选音色
- 动态插值到默认 embedding，实现“近似克隆”，但延迟增加 <80 ms
这样，旁白不再千篇一律，玩家沉浸感更强，适合剧本杀、虚拟主播等场景。
实际跑下来，ChatTTS 的流式接口 + ASGI 事件循环是真正能扛高并发的组合，把 GPU 等待时间全部转成网络 IO 后，单机 4 卡就能撑起近万并发。唯一要注意的是显存碎片和音色切换的软过渡，做好这两点，线上基本听不到“咔哒”爆音。下一步想把声纹克隆也接进来，让每个人听到的都是自己“熟人”的声音，应该会更好玩。
