以下文章来源于共识粉碎机 ，作者 AI 芋圆子
前面的话：
GPT-4o 发布当周，我们的社区伙伴「共识粉碎机」就主办了一场主题为「GPT-4o 对实时互动与 RTC 的影响」讨论会。涉及的话题包括：
- GPT-4o 如何降低延迟（VAD 模块可能也应用了 LLM？）
- GPT-4o 怎么影响实时互动场景（分析了医疗、法律、教育、陪伴和客服等场景）
- GPT-4o 应用到实时，也有不完善的地方
- GPT-4o 为什么要用到 RTC（Input 场景 RTC 可以被视作解决方案。Output 场景 RTC 不一定是必须。）
- 怎么选择 RTC 供应商
- 实时场景对端侧的影响
另外，此次讨论会嘉宾史业民在我们的播客《编码人声》里深度解析了 GPT-4o 的能力边界，并基于实时多模态开发的一手经验，给开发者提出了不少建议，也欢迎收听。
这次讨论会的信息量极大，Enjoy！
本期讨论会参与者：
杜金房老师： 烟台小樱桃网络科技有限公司创始人，FreeSWITCH 中文社区创始人，RTS 社区和 RTSCon 创始人，《FreeSWITCH 权威指南》、《Kamailio 实战》、《深入理解 FFmpeg》作者，FreeSWITCH 开源项目核心 Committer。杜老师同时是 RTE 实时互动开发者社区联合主理人。
刘连响老师： 资深 RTC 技术专家，推特@leeoxiang。
史业民老师： 实时互动 AI 创业者，前智源研究院研究员。
徐净文老师： 负责百川的战略、投融资、开源生态、海外等业务。
1、GPT4o 如何降低延迟
GPT4o 前调用 OpenAI API 延迟极限情况下可以压缩到 2 秒
中美跨海光缆差不多 100-200ms，如果考虑丢包，那平均在 300-400ms。
语音场景需要经过 ASR（语音转文本），在大模型无法流式输入的情况下，一般需要说完一句话再喂给大模型，平均需要 400-500ms 延迟。
如果不考虑 Planning 和 RAG 等环节，只计算 First Token 的话过去平均需要 700-1000ms 延迟。
大模型可以流式输出，但一般第一句话节后给 TTS（文本转语音），TTS 环节也需要 400-500ms 延迟。
所以整体延迟最低可以低到 2 秒。
上述场景主要是考虑的网络良好的情况，如果在室外体验，丢包概率会大幅增加，延迟还会再往上波动。
但在客服等场景中还经常需要做 Planning 和 RAG，延迟会进一步增加
上述主要是可以用 First Token 来判断延迟的场景，对话内容比较简单。
像在类似客服等场景，在 First Token 前还需要先做 Planning 和 RAG，就可能还需要经历 1-2 次完整延迟，整体延迟就会远远超过 2 秒，可能到 4-5 秒或者更高。
GPT4o 优化延迟的机制
VAD（Voice Activity Detection）提升：VAD 主要用于尽早发现用户说完话，用于触发大模型，过去用停顿时间判断，现在可能有了语义理解能力。
端到端能力：端到端可以替换掉 ASR 和 TTS 的延迟，开发者未来可以用 GPT4o 的 ASR/TTS，也可以自己做。
其他延迟优化还包括流式处理、异步处理，多个模块在向量画的过程中如何统一，在 GPT4o 的设计上有很多巧思。
VAD 模块可能也应用了 LLM
之前有一些简单的 VAD 判断标准，比如停顿 1000 毫秒，就默认用户说完话了。
但现在 GPT4o 为了节省时间，单纯用停顿判断肯定不可能，应该要走到语义层面。
最极端或者暴力的方案，可以拿 GPT4o 的模型去 Finetune 一个小的 VAD 模型， 模型可以控制在 0.5B-1B 的规模，类似于向下降维打击的方式实现 VAD。
这样对于 VAD 模型来说，Input 是 Audio，Output 就是说完与否的 “Yes or No”。
GPT4o 后，还可以通过工程并发的方式进一步降低延迟
在 GPT4o 前，工程角度已经可以在一些特殊场景，提前做好 RAG 等检索工作，然后再将 TTS 与 Output 等场景做成并行，通过很多工程做法，在不考虑跨海传输的情况下，有机会将延迟控制在 1 秒以内。
现在在复杂一点的场景，甚至到 Planning 和 RAG 相关的场景，也可以尝试做并行进一步压缩延迟。
基于 DSL（Domain SPecific Language）结果做 RAG、对输入的 Vision 和 Audio 做向量化预处理、刚刚提到的 VAD，这三个部分也可以做并行。
现在还不确定 OpenAI 会不会开放着三个接口，从模型工程角度来说，如果这几个部分都做好，几乎可以把 RAG 的延迟都覆盖掉。
在做应用的时候还可以用一些鸡贼的产品体验进一步降低 “延迟感”
为了提高用户体验，可以在产品层面做一些改动。例如 OpenAI 的 Demo 中，在响应时间的过程里，手机中的画面会有波动的动画，在这个过程中，哪怕没有任何的实质性输出，人看到动画也会觉得亲切一些，对延迟的敏感度也会降低。
在下面杜金房老师演示的视频中，也可以通过 “嘟” 的方式给用户起到心理安慰，“AI 马上就要说话了”。
但这种场景也会有明显的局限，只适合用户已经知道对面是 AI 的情况，这种情况对延迟的容忍度也会相对较高。在不想让用户知道对面是 AI 的场景，这类产品功能也会容易暴露对面是 AI 不是真人。
2、GPT4o 怎么影响实时互动场景
有哪些实时互动场景可以开始做了
类似 Hume.AI 等各种陪伴产品。
VR 游戏=Vision Pro/PICO 场景的互动产品。
互动机器人，互动机器人加入实时互动能力后，对用户体验提升帮助很大。
AI 音箱，可能会出现新的落地场景。
还包括现在也有在讨论车载互动能力，让开车的过程中没那么无聊，以及解放双手做一些车内的控制任务。
还有一些典型的行业场景，也很适合实时互动需求
这些场景一般都非常个性化。
出现的时候会比较紧急，一点点延迟提高都能带来使用者的体验改善。
可以通过季节性、年龄等维度进行预处理，进一步减少延迟。
医疗进入实时互动可以大大减缓患者焦虑
远程诊断咨询，个性化建议，都可以做非常多的实时性提升。
疾病症状季节性集中度非常高，所以在 Planning 和 RAG 上可以做非常多预处理，可以压缩模型时间。
即时交互可以解决心理焦虑，从用户端体验会变得非常好。像美国有个机构 Hippocratic AI 正在做，延迟大概在 5 秒，那等 5 秒的过程患者会非常焦虑的。因为机构 Hippocratic AI 是用视频/语音方式来解决的，所以需要差不多 5 秒延迟。模型在延迟上小小提升，就可以解决患者焦虑的状态。
医疗场景中每个人都认为自己的小病是大事，但不一定很严重。如果能够更快的得到权威的回应，就在心理层面有很大的帮助， 甚至不一定要在物理层面上改善。只要是及时的回答，就可能能解决问题。
医疗也要分场景，疾病会有轻重之分。如果是重症，那调用 Planning 和 RAG 的成分就会非常多，但大部分的医疗场景中，高频发生的还是小病疾病。比如小朋友发烧、老人摔跤、吃过敏药后忘记医嘱喝了酒等场景，不需要调用非常厚的医疗词典，也不需要让很多专家模型介入，这些场景的延迟改善会更加明显一点。在这些场景，5 秒到 1 秒的改善，对于用户体验的提高是非常大的。
目前还没到 OTC 开药和重症阶段，现在短期还很难因为实时互动改变。但是比如心理辅助，比如患者就站在桥旁边，那实时互动就能立刻见效。
法律引入实时互动后适合现场处理场景
过去的处理周期非常长：形成文档，然后通过人去解决。比如车险报警，过去是拍照上传、交警介入。
现在有了 GPT4o 的实时机制后，非常多的裁决是可以现场发生的，当然最后处理部分还是需要人来介入。
除了车险和现场暴力事件，剩下的还是一定程度能接受延迟。
教育引入实时后适合在线解题和语言教学场景
GPT4o 的 Demo 上就有在线解题。
解题是个高度个性化的过程，还包括题库的应用，结合 RAG 和模型能力提高，再加上 RTC 的实时效果，在线教育领域的教学和辅助能力会有巨大提升，也可以做更多市场化的尝试了。
过去需要上传，需要等待。那现在变成了更像辅导和学习伴侣的过程，在语言教学等场景，会实质性的改变学生的学习曲线和接受度。
GPT4o 后最快会是哪些场景能跑出来
最直接的场景是陪伴，因为陪伴对 Planning 和 RAG 的要求低，只需要定义好角色背景和音色，而且非常适合应用到 GPT4o 的端到端场景。很容易就可以把延迟迅速降下来。
客服等场景稍微复杂点，需要用到 Planning 和 RAG，延迟没有陪伴降的这么厉害。在这类场景里，延迟不是主要取决于端到端和 First Token，还要取决于整个 Pipeline 的系统级延迟。但如果做好并行机制和各种优化，也可以到 1-2 秒的延迟。
3、GPT4o 应用到实时也有不完善的地方
在触发机制等问题上还无法做到完全实时
之前提到 VAD 的进步是延迟降低的一个关键是因素，需要尽早触发多模态模型，那就需要符合 VAD 的触发条件，在用户无法说话，或者 用户正在说话过程中的情况，大模型就无法触发。
举一个例子，在 OpenAI 的 Demo 里有一个例子是两个人 + 一个 AI 互动，但如果假设 A 停了几秒，B 再去说，就会发现 AI 提前介入，B 的话就会被 AI 抢了。就必须要提前设计好 AB 角色以及 AI 对应角色的角色分析，添加更多的限定条件。
在实时互动场景中，也需要 AI 能够在用户沟通中回复一些内容，可以更好激发用户去表达，现那也做不到。
如果你要他说话之前就能回答，那还需要做很多工程工作，中间可能还会有误触发方案，但长期应该可以解决。这更多是场景决定的需求，例如实时翻译和需要插话的场景，要设置提前触发的请求规则。但在类似 Assistant 的场景，就不需要设置插话的提前触发条件。
具体举一些场景来看的话
例如开着摄像头，要试试去看场景有什么变化，有什么危险，如果不设定定时触发机制，那 GPT4o 无法实时提醒。
例如同声传译和语法纠错场景，需要在说话过程中就进行处理，或者实时纠错。这里也不能直接应用，因为 VAD 机制需要判断说完话。
例如盲人眼睛场景，用户希望的是戴上眼镜就能实时感受路况。但现在的需要用户不断地问有没有违宪，或者工程上设置一个 1-2 秒的自动请求机制，来帮助 GPT4o 高频判断。
总体来讲，GPT4o 如果是从助手级别（接收完人类指令），已经几乎完美了。但到了上述要更进一步的实时交互，还存在失望的地方，可能到下一代 GPT5 可以满足。
4、GPT4o 为什么要用到 RTC
GPT4o 为什么需要 RTC？用 RTC 的 LLM 会产生时空穿越？？
在 GPT4o 的 RTC 场景中有两个方向，Input 和 Output。
Input 场景中，LLM 需要实时接收用户的视频，人不能加速产生内容，为了降低 100-200 毫秒的延迟，RTC 可以被视作是必须的解决方案。
Output 场景中，RTC 不一定是必须，也可以用 WebSocket 等方案，链路存在但是开发者还没有大范围集成。
与 Input 场景不同，在 Output 场景中， LLM 生成音视频未来可能做到两倍速，甚至四倍速、八倍速。那 Output 的 Token 生成速度会比时间还快，但是播放时候必须是一倍速，这就造成了在倍速场景中会有时空穿越的感觉，延迟实际上是负数。 只要解决首帧、First Token 的延迟就可以了。内容会因为生成比播放还快，而先预存在本地，然后再播放，就类似现在听网络小说、看视频一样。
如果开发者有很强的优化能力，或者传输数据量没那么大的情况，提前做好 ASR/TTS 等，那可能可以不用 RTC。
LLM 可能还会影响新的 RTC 技术
RTC 行业发展这么多年了，已经很成熟了，看不到明显的增长了，LLM 出来后大家很兴奋，觉得应该能做点事情。
最直接的交互方式还是语音和视频，也是 RTC 的强项，有些人在探索结合，也有直接转型 LLM 的。
GPT4o 出来后，大家又看了新挑战，比如做四倍速 RTC、八倍速 RTC，可能还会有新的 RTC 技术出来。
我们现在很多假设都是 RTC 一倍的情况，未来 RTC 可能是两倍、四倍场景。那在正常情况下，比如 RTC 是 500 毫秒延迟，但是弱网可能就是 1 秒，稍微慢一点也能接受。但如果未来有了两倍速 RTC，那可能网络条件差了点，延迟还是在 500 毫秒到 1 秒之间，那也会有很大帮助。
但目前的 LLM RTC 需求还不复杂
主要还是一进一出的场景。
以前 RTC 场景里复杂的比如小班课，一堂课可能有几十路 RTC，就比一进一出高很多。
难度可能还比不上直播连麦的难度，直播间里玩法也非常多样。
未来也要看 LLM 玩法的迭代，越复杂的玩法需求越大
RTC 国内最大的是社交娱乐和教育，后面来来回回想了很多场景要起来，比如 IoT 等，但最后还是没起来。现在还不确定 LLM 会不会也是这样一个需求，谨慎乐观。
除了直接延迟外，RTC 在网络不好的场景，以及对打断有需求的场景有明显优势
网络好的时候延迟差别不大。但是网络不好的时候差别很大，比如丢了个包那来回 200 毫秒就没了，如果再丢一个包那 20 毫秒又没了。TCP 是最后组件，前面的延迟炸了，后面也会累积。
RTC 做了很多抗弱网策略，加重传策略，包括猜测下一个声音做补全等。
没办法直接给出和 CDN 延迟差多少，还是 Case by Case，只能说不好的情况下差比较多。
RTC 也适合互相打断，流式传输必备。CDN 不适合打断场景。
5、怎么选择 RTC 供应商
先讲讲 RTC 的发展历史
Google 在 2010 年收购了 WebRTC 技术公司，然后再 2011 年通过 Chrome 开放了 WebRTC 源代码，相当于 Chrome 就具有了实时能力。因为要做一套 RTC 引擎成本还很高，涉及到算法、编解码、各种规范，Google 开放 WebRTC 之前 有能力把 RTC 做好的并不多。
2013-2014 就有第一波热潮，那时候出现了很多 RTC 创业公司，然后很快都接着死了。迎来了第一波低谷。
2015 年出现了声网，后面国内也有几家。2016-20187，国内出现了上千直播平台，开始有了连麦的需求。然后紧接着 2018 年在线教育跑起来了。
2020 年最大的一波来了，疫情期间，包括各种视频会议、在线教育等居家办公需求。
疫情热度过后，RTC 需求就开始降温了，进入第二次低谷。
OpenAI 目前选择了 LiveKit，但未来 API 可能可以不与 LiveKit 绑定
看全球的 RTC 供应商，除了国内的声网、腾讯 TRTC 等也多数不能打。
OpenAI 在选择方案的时候肯定非常谨慎，可能会更多考虑开放标准，也会考虑到中国公司的情况。如果是闭源方法，就会涉及到开发者怎么选择；不能绑定一家商业公司。在这个层面，LiveKit 是个非常好的生态位，你想用的话可以用 LiveKit 的 Cloud，也可以自己建。
OpenAI 现在也开始自己招人，那和 LiveKit 可能就是合作关系，前期可能会给一些咨询费一起共建，但后面可能还是会自建。
未来可能是 ChatGPT 产品用 LiveKit，API 端可能不绑定 RTC。
未来客户可能也能使用商业 RTC 方案
现在给不出一个准确的答案，这个要取决于 OpenAI 的决策。
但推测 OpenAI 可以采用一个开放的标准，让各家产品都可以接入，这是一个更加平台风格的选择。
比如客户想做成商业产品或者在全球应用，那就采用商用方案，这是最省研发成本的。
使用 GPT4o 不一定必须用其自带的 TTS
TTS 都在一个大模型里面，对开发者不是那么友好。
比如 Hume.AI，已经带有情感 TTS 的，那怎么和新 4o 去闭环；客户不一定能接受 OpenAI 现在给的几种声音模式，会有更多样化的需求，比如更像某个人的声音（定制化的），或者更卡通化等风格需求。
那可能 4o API 最好同时支持 Voice 出和 Text 出。
各方是怎么看要不要用 RTC 的
模型公司角度很可能会优选 RTC，成熟，可拓展性也好，同时可以开放给开发者不同选择。
开发者角度，延迟还是越少越好，越实时互动的场景越需要 RTC。
6、实时场景对端侧的影响
Vocie Assistant 场景对于端侧硬件的要求
如果全部使用 GPT4o，端侧只接收视频，就几乎不需要算力
如果要将 VAD 技术放在端侧，那端侧就需要一定算力。但总体会远远低于 LLM 的算力。
对 RTC/RTE 感兴趣的朋友也欢迎访问 RTE 开发者社区：
最后我们放一张本次活动的听众 Agent 创业者 王轶老师 参与互动后画的一张图，也比较清晰的展现了 RTC 引入后 LLM 的流程变化
