PipeCat - 打造实时语音 AI 应用的开源架构方案

发布日期：2025-01-24 07:02:40 浏览次数： 3859

作者：前端程序设计

微信搜一搜，关注“前端程序设计”

Pipecat 是一个用于实时、多模式 AI 的编排框架。在此用例中，Pipecat 在 WebRTC 媒体流（和 Pipecat 客户端/服务器事件）和多模式实时 API 之间进行转换。

图片来自@meng shao这位大神。

代码库：

https://github.com/pipecat-ai/gemini-webrtc-web-simple

此示例展示了如何使用 Gemini Multimodal Live API 和 WebRTC 构建一个非常简单的语音 AI 应用程序。

WebRTC 连接只是这段代码，加上用于设置音频播放和处理您想要连接到用户界面的任何事件的事件处理程序。

 const rtviClient = new RTVIClient({    transport,    params: {      baseUrl: "http://localhost:7860/",     },    enableMic: true,    enableCam: false,    timeout: 30 * 1000,  });

与直接从客户端连接到多模式 API WebSocket 基础设施相比，这种方法有几个优点。

WebRTC 为普通真实用户提供了更低的延迟和更好的稳定性。尽管我们使用代理/中继方法，但对于很大一部分用户来说，语音到语音的响应时间将比使用直接 WebSocket 连接更快。
您可以使用 Pipecat 的内置服务添加功能，或者用 Python 编写自定义服务器端实时逻辑。例如，此 Pipecat 管道通过将用户和模型音频发送到 Gemini 的标准（非 Live）API 来实现音频转录。
SDK 实现了AI 客户端-服务器事件的RTVI 开放标准。这组丰富的事件使实现语音对语音和多模式 AI 应用程序的核心功能变得容易。例如，Pipecat 的 React 组件就利用了这个事件系统。
兼容的 Web、React、React Native、iOS、Android、Python 和 C++ SDK，均由庞大而活跃的开源社区维护和开发。

以这种方式使用 WebRTC 还有两个缺点。

WebRTC 比 WebSockets 更复杂。您需要使用 SDK，而不是编写调用低级 WebRTC API 的代码。（对于 Web 应用程序来说，这通常是正确的，但争论对于具有不同网络经验水平的程序员来说，这是否正确超出了本自述文件的范围。对于本机移动应用程序来说，这绝对是正确的。）这是 Pipecat 开源客户端 SDK 旨在缓解的痛点。
在生产中，您可能不想运行自己的 WebRTC 服务器集群。从复杂性上讲，WebRTC 更接近电话，而不是 Web 服务器。您可能不会运行自己的 SIP/PSTN/SMS 基础设施。因此，您可能会按分钟或每 GB 为每个机器人会话向 WebRTC 基础设施提供商付费。Pipecat SDK 同时支持 WebSockets 和 WebRTC。您可以在开发中使用 WebSockets，然后在准备部署给实际用户时过渡到 WebRTC。

什么选择 WebRTC？

如果您刚开始使用语音 AI，您可能会倾向于使用 WebSocket 库进行联网。WebSocket 很常见、简单且受到广泛支持。它们非常适合服务器到服务器用例、延迟不是主要问题的用例，并且非常适合原型设计和一般黑客攻击。

但是 WebSocket 不应该在客户端-服务器、实时媒体连接的生产中使用。

对于生产应用，您需要使用 WebRTC。WebRTC 从一开始就被设计为互联网上的实时媒体协议。

WebSocket 在与最终用户设备进行实时媒体传输时的主要问题是：

WebSockets 建立在 TCP 上，因此音频流将受到队头阻塞，并且即使数据包延迟太多而无法用于播放，也会自动尝试重新发送数据包。
用于 WebRTC 的 Opus 音频编解码器与 WebRTC 的带宽估计和数据包调速（拥塞控制）逻辑紧密耦合，使得 WebRTC 音频流能够抵御各种可能导致 WebSocket 连接累积延迟的实际网络行为。
Opus 音频编解码器具有非常好的前向纠错功能，使音频流能够承受相对大量的数据包丢失。（不过，这仅当您的网络传输可以丢弃迟到的数据包并且不进行线头阻塞时才对您有帮助。）
通过 WebRTC 发送和接收的音频会自动加盖时间戳，因此播放和中断逻辑都很简单。使用 WebSocket 时，很难在所有极端情况下都正确处理这些逻辑。
WebRTC 包含用于详细性能和媒体质量统计的钩子。一个好的 WebRTC 平台将为您提供针对音频和视频的聚合和单个会话统计的详细仪表板和分析。对于 WebSockets 来说，这种级别的可观察性很难甚至不可能实现。
WebSocket 重新连接逻辑很难稳健地实现。您必须构建一个 ping/ack 框架（或全面测试并了解 WebSocket 库提供的框架）。TCP 超时和连接事件在不同平台上的行为不同。
最后，如今优秀的 WebRTC 实现具有非常好的回声消除、降噪和自动增益控制。您可能需要弄清楚如何将这种音频处理整合到使用 WebSockets 的应用中。

此外，无论底层网络协议是什么，长距离公共互联网路由都会对延迟和实时媒体可靠性造成问题。因此，如果您的最终用户距离 OpenAI 的服务器很远，则务必尝试将用户连接到尽可能靠近他们的媒体路由器。除了第一个“边缘”连接之外，您还可以使用更高效的主干路由。一个好的 WebRTC 平台会自动为您完成此操作。

例如，在此示例应用程序中，对于典型用户而言，通过 Daily 的 WebRTC 网络（该网络在世界各地拥有许多靠近网络边缘的服务器）进行路由，其延迟实际上会比通过公共互联网路由的“直接”WebSocket 服务器更快。（互联网上没有直接连接。每个数据包都通过多个路由器进行中继。更好的路由意味着更好的响应时间。）

--------------------------------------------------------

还有一位大神搞出了全网第一个多模态 Gemini 且支持多语言语音输出的版本，也就是说，你可以用中文跟 Gemini 视频聊天了！

参考网址：

https://www.dinopal.ai/