（未完成）AI实时语音通信（全双工方案）

用户194

2025年7月16日修改

写在前面

已经是比较老的东西了，应该是2024年中写的，本来想作为自己私有资产的，后来想想算了，公开出来算了。​

代码实现了60%，实验没有完整做完，效果未实测，理论应该可行。​

看得懂的朋友可能不太多，看懂了觉得不错点个赞就好啦。

背景说明

本POC是为了验证一个思想方案：将AI静态语音通信，转变为实时语音通信。​

传统AI语音通信的链路是：

音频输入-》音频输入结束-》静态音频文件-》语音识别音转文-》大模型文生文回复-》语音合成文生音-》音频回复​

有几个要点：

•
整个链路的处理开始以及音频回复，必须等待音频输入结束；虽然工程上可以通过用户侧的静默，判定输入结束，但这不改变前面这个事实。​

•
音转文和文转音都可以流式并且速度较快，大模型生成速度大约是20token/s，20-30汉字。​

•
服务端和客户端之间的通信延迟主要取决于音频输入和输出的buffer大小，使用webrtc这类协议可以让延迟在1秒附近。​

•
人类说话速度大约是3-5字/秒，所以实际链路处理速度远大于输入速度。​

所以这里表现出的产品问题主要有：

•
端到端耗时较长。推测主要原因是大模型推理速度较慢（假设是20token/s，大约20-30汉字），较长的文本输出时，生成耗时较长（例如80字左右需要4s）。同时整体链路的启动需要等待音频完全的输入。​

•
不允许回复侧打断输入；当然工程上允许用户中途的输入打断输出（等于是输出完全终止）。​

预期实现效果

•
超低延迟：​
◦
大模型推理必须在音频输入过程中就开始进行，以此降低音频输出延迟；也就是所谓的流式输入模式（这个比较超前思维，希望大家结合下面看得懂）​
◦
输入和输出buffer需要比较小（但是又在一个合理的尺度）​

•
双向可打断：​
◦
用户中途输入打断输出（工程上可解决）​
◦
模型音频输出可打断用户，当用户输入卡壳，无意义，或者用户输入需要被澄清，反驳，或者模型角色设定性格比较着急。​

•
双向附和音​
◦
模型音频输出“嗯，嗯，是的，好的”等，属于中途附和，不是打断。​
◦
用户输入“嗯，嗯，是的，好的”等，属于中途附和，不是打断。​

•
主动发音：用户静默一段时间之后，主动发音维持对话​

•
主动挂断：长时间无响应，可以主动挂断。​

技术实现

选型

•

•

•

•

技术初步推测

•
音频输入环节，使用流式输入或者buffer（长度固定or不固定）的切割输入​
◦
同时给出静默符（例如0.5秒的静默），看工程上是否能实现​

•
音生文环节，流式输出​
◦
同时给出人声静默符（例如0.5秒没有音生文输出，则给出一个流式的静默文本符号）​

•
在大模型文生文环节，使用流式输入与实时生成（阶段式生成）方案，方式如下：​
◦
将Q拆为q1 q2 q3 ...​
◦
第一次模型推理 q1->，得到a1​
◦
第二次模型推理 q1 q2 a1->，得到a2​
◦
...​

（未完成）AI实时语音通信（全双工方案）​