跳到主要内容
AI News HubLIVE
站内改写1 分钟阅读

OpenAI如何为9亿用户提供低延迟语音AI

文章摘要

本文详细介绍了OpenAI如何通过WebRTC和创新的架构分离策略,为9亿用户提供低延迟的语音AI服务。文章分析了传统WebRTC部署在Kubernetes上的问题,并展示了OpenAI如何通过无状态中继和有状态收发器的分离,利用ICE ufrag进行路由,以及全球中继部署来优化延迟。

来源Hacker News AI作者: gmays
OpenAI如何为9亿用户提供低延迟语音AI
报告错误

纠错通道尚未开通,可先复制下方文章信息留存。

查看更正说明
直接读正文

OpenAI每周为9亿用户提供语音AI服务,为了实现低延迟,他们选择了WebRTC协议。WebRTC最初是为具有稳定IP和端口的服务器设计的,而Kubernetes将地址视为可丢弃的,这给部署带来了挑战。传统的解决方案是使用SFU(选择性转发单元),但OpenAI的流量主要是用户与模型的一对一对话,因此他们选择了一种更高效的架构。

该架构将系统分为两部分:一个无状态中继,负责协议感知的数据包路由,位于地理边缘;一个有状态收发器,负责所有WebRTC状态。两者之间的关键连接是利用ICE用户名片段(ufrag),该字段在连接建立期间交换,中继可以从新会话的第一个数据包中读取它,并将其作为路由密钥。此方法避免了热路径上的数据库查找或随机路由带来的延迟。

在信令阶段,收发器生成一个共享中继VIP和UDP端口,客户端将数据包发送到该稳定地址。中继维护一个内存中的源地址到收发器目的地的映射,用于后续数据包。如果中继重启,Redis缓存可快速恢复映射。为了进一步降低延迟,OpenAI部署了全球中继,即分布在全球的中继入口点。所有中继运行相同的包转发行为,仅地理位置不同。这减少了客户端到OpenAI网络的第一个网络跳数,从而降低了延迟并提高了稳定性。

除了架构本身,OpenAI还进行了套接字级优化,例如使用共享UDP套接字来避免端口耗尽,并实现了用户空间Go实现以提高性能。这些优化共同确保了语音AI体验的流畅性,使其如同真实对话而非对讲机。此外,OpenAI的工程团队还考虑了SFU和TURN等替代方案,但最终选择了中继-收发器分离架构,因为它在1:1对话场景下更高效。整个系统依赖于ICE ufrag中的编码路由元数据,使得第一包路由无需额外数据库查询,从而在保持低延迟的同时实现了全球可扩展性。

展开要点与分析

文章情报

工程师进阶

要点

  • OpenAI使用WebRTC为9亿用户提供语音AI,但Kubernetes的弹性与WebRTC的状态需求存在冲突。
  • 架构将无状态中继和有状态收发器分离,中继负责包路由,收发器处理WebRTC状态。
  • 利用ICE用户名片段(ufrag)作为路由密钥,无需额外数据库查询。
  • 全球中继部署缩短客户端到服务器的网络距离,降低延迟。

要点与分析由自动化流程生成,可能有误,请结合原始来源核实。