WebRTC在语音AI中的应用：2026年传输层的工作原理及其发展趋势

作者：Tsahi Levent-Levi
来源：https://bloggeek.me/voice-ai/

语音 AI 基于实时传输运行，到 2026 年，这种传输方式几乎无一例外都是 WebRTC。它是专为实时、低延迟音频设计的唯一浏览器原生方案，内置了 Opus 编解码器、回声消除和语音活动检测功能。WebSocket 和 WebTransport 虽是替代方案，但 WebRTC 才是务实的默认选择，且当会话规模超出“一人一机器人”时，它仍能保持良好的可扩展性。

本文描绘 2026 年语音代理底层传输层的图谱：实际可选方案有哪些、当前参与者使用什么、WebRTC 目前的表现如何，以及目前尚未有人进行的调整将在哪些方面发挥作用。

WebRTC、WebSocket 和 WebTransport：哪种传输方式更适合语音 AI？

在浏览器中，用户和语音代理之间传输音频有三种方式。原生应用则增加了第四种方式，即原始的 QUIC 或 UDP 路径，谷歌 Gemini Live 似乎就是使用这种方式。

这些差异为何重要：

• WebRTC 专为实时音频和视频而设计，这使其成为与大语言模型（LLM）进行对话的良好选择，虽非理想方案，但已相当合适。它是一项稳定且广为人知的技术，所有浏览器均支持，且客户端实现简便。这使其成为务实的默认选择。

• WebSocket 则将音频控制权完全交由客户端掌握。它采用高比特率的 base64-PCM 编码——约为 Opus 的 10 倍。将音频作为 Base64 编码嵌入 JSON 而非二进制帧，是出于实用考虑，而非设计初衷。WebSocket 还常用于后端到后端的通信，例如 ElevenLabs 等音频提供商与应用程序后端之间，其假设是数据中心之间的 TCP 连接更可靠且更不易丢失数据。但这不太适合我们这些普通用户连接的网络边缘。

• WebTransport 尚处于起步阶段。Safari 直到 2026 年才添加对它的支持。这种方法最终将与 WebSocket 类似，但不会出现“队头阻塞”问题。目前它更多是一种概念，而非成熟的解决方案。

关于 WebRTC，需要了解一点：它一直以来都专注于人与人之间的对话，无论是 1 对 1 还是群组对话。自诞生以来，它已被应用于直播和云游戏等其他领域，而语音 AI 在某种程度上也是其应用领域之一。WebRTC 目前的不足之处在于未能更好地适应 LLM（语言学习）行为。虽然假设 WebRTC 能够很好地适应人与人之间的 1 对 1 对话，但还需要针对第二个端点的非人类行为进行优化。

与其他传输解决方案相比，WebRTC 的优势在于，当你需要与虚拟代理进行对话并扩展到多个人类参与者时，WebRTC 无论如何都会介入。所以你最好尽早开始，从单个参与者开始。

WebRTC 中的数据通道是一个值得单独介绍的构建模块。目前，它作为控制和事件通道，传输文本，偶尔也传输 base64 编码的图像——这是回答“我正在看什么”的最简单方法，这对智能眼镜至关重要；另一种更复杂的方法是在服务器端解码视频流并选择最新帧。它也可能用于在交互过程中调整响应，尽管我们尚未在生产环境中看到这种情况。

STT-LLM-TTS 与 Speech-to-Speech：哪种语音循环更优？

撇开传输机制不谈，针对语音循环本身，目前有两种相互竞争的模型。

STT 到 LLM 到 TTS 是传统的管道，结构清晰，部件可互换：

• 类似 Whisper 的语音转文本模型。难点在于何时进行转录，因为这些模型是基于大约 30 秒的音频片段进行训练的。因此，语音活动检测 (VAD) 和回合结束逻辑必须在语音转文本 (STT) 之前运行并触发它。VAD 可以运行在服务器 CPU 上，例如使用 Silero-VAD 这样的软件包，它比 WebRTC 提供的 VAD 更准确。
• LLM 位于推理后​​端。它接收单个文本块，因此一个 GPU 可以而且应该服务于多个会话。响应通常以流式传输，以便 TTS 可以在 LLM 完成之前启动。
• 文本转语音模型，通常是目前最新、最好的开源解决方案。

语音到语音转换直接将编码后的 PCM 音频（而非 Opus 音频）输入模型。这样，模型就可以利用转录过程中丢失的音高和时间信息。缺点是，对于 WebRTC 开发人员来说，它更像是一个黑匣子，而且随着底层 LLM 的发展，也更难进行适配。

这里有个重要的信息：在语音转语音 (STT)、文本转语音 (TTS) 和语音对语音 (Speech-to-Speech) 中，传输协议几乎从不使用 WebRTC 和 Opus。它主要使用 WebSocket 和未压缩的原始音频 (L16)。多年前，在 ChatGPT 和 LLM 出现之前，情况就是这样；现在依然如此。

OpenAI、LiveKit、Gemini 和 ElevenLabs 如何使用 WebRTC 实现语音 AI？

WebRTC 在浏览器中一项由来已久的优势在于其可视性：chrome://webrtc-internals 能准确展示该堆栈的工作原理。以下是该页面显示的当前播放器相关信息。

大多数部署中的情况都相当典型：未经过优化的 WebRTC。

来自视频会议领域的供应商仍在持续提供基于会议室的 API，这些 API 会重新协商流，且思维模式局限于会议室范畴。语音 AI 主要以一对一通话为主，而这向来是 WebRTC 中规模较小的应用场景。

十多年来，WebRTC一直针对人类用户进行优化，而人类对故障的容忍度远低于 LLM。突破这一默认模式才是关键所在。

自建 vs 采购

我们看到整个行业都在采用 WebRTC 基础设施进行语音 AI 传输。

通常情况下，人们会选择 Daily Pipecat 和 LiveKit Agents。大多数生产服务都会选择其中之一，并根据需要混合搭配一些组件。即使是像 OpenAI 这样最大的供应商，在构建自己的 WebRTC 基础设施之前，最初也是基于 LiveKit 起步的。

从 WebRTC 的发展历程来看，大型厂商通常会选择基于云的 WebRTC 基础设施，然后再迁移到自己的服务器上来控制整个流程。Pipecat 和 LiveKit Agents 的吸引力在于它们的开源特性，至少从理论上讲，它们简化了这种迁移过程。而实际的迁移则是构建一个经过精心调校的 WebRTC 基础设施，以更好地适配他们的语音 AI 后端基础设施以及他们想要的应用场景。

我们已经看到 WebRTC 目前在语音 AI 领域的应用情况。对此我们持保留态度。它更适合用于概念验证，而非实际的生产服务。

随着语音AI服务的普及和规模扩大，将有更多时间和精力用于对其进行精细调优，优化处理流程的每个环节，包括其中的 WebRTC 组件。这正是优质服务开始脱颖而出的关键所在——针对语音AI量身定制的、经过精细调优的 WebRTC 实现方案，远胜于默认的 WebRTC 解决方案。

我们预见到以下情况：

• 信令。从 SFU 模型迁移到 WebRTC-LLM 网关。这减少了网络跃点，消除了不必要的信令重协商，并实现了更好的控制和优化机会。OpenAI 在将其实时语音服务从 LiveKit 重构为自研解决方案时，就采用了这种方法。
• 语音和编解码器。客户端使用标准的 32 kbps Opus 编解码器，平均码率约为 20 kbps。DTX不应与服务器端 VAD 一起使用。服务器到客户端的音频传输不应默认使用立体声，而应仅用于需要立体声的场景。在轮流通话过程中，以低码率而非恒定码率编码静音可以节省大量字节。RED 功能非常实用。音频 NACK 应优先采用。噪声抑制（可插入流加 RNNoise）可以在 VAD 之前在客户端或服务器端运行。通过经过充分验证的 WebRTC 回声消除路径，可以避免代理听到自己的回声。
• 视频功能仍处于起步阶段。目前，视频主要指发送给用户的头像视频，与语音同步，通常采用 H.264 编码，比特率、帧率和分辨率会根据具体应用场景进行调整。用户上传视频的功能尚未普及，但“我正在观看什么”这一应用场景对于智能眼镜而言至关重要。
• WebRTC 和 LLM 分离了。WebRTC在靠近用户的终端上终止，并与推理后端中的 LLM 通信。这种分离主要是为了提高可扩展性：昂贵的 GPU 需要服务大量会话，而 WebRTC 是有状态的，并且面向计算。往返延迟的问题并没有消失，只是转移到了数据中心。OpenAI 的规模化文档详细记录了从 LiveKit 到自有堆栈的这种转变。

重要的指标

目前最受关注的是延迟和往返时间，重点关注用户到LLM的端到端体验。例如，优化流量传输、在整个媒体管道中节省毫秒级时间等等。

最终目标是确保会话流畅。延迟只是需要解决的诸多问题之一。抖动、丢包和其他网络行为也需要解决和优化。有时，这可能需要更改基础设施以及服务器和路由的位置。有时，则需要优化代码及其行为。

我们服务于人机交互。人机交互方面需要用专门针对人类的指标来衡量，就像我们目前在 WebRTC 中使用的指标一样。这就是我们十多年来一直使用的标准 getStats API。我们会考察比特率、帧率、往返时间、丢包率、呼叫建立时间和数据通道打开时间等等指标。

前沿在哪里（以及应该投资在哪里）

这张“真实”的地图留有未填补的空白。这些正是目前仍在推进的工作领域：

• 更快的连接速度。呼叫建立时间和数据信道打开时间是需要关注的指标，均可通过 getStats 获取。缩短这些时间的具体技术仍在开发中。
• 音频 NACK。目前在语音 AI 领域尚未应用，但在高级会议系统中已是标准配置。这能在几乎不占用比特率预算的情况下，显著提升系统韧性。这是一项尚未开发的潜力。
• 语义轮次交接与引导。从基于 VAD 的静默检测转向基于 LLM 的轮次检测，并最终实现轮次中的引导，这正是实现自然对话的关键所在。

适用对象

本文面向两类从不同角度聚焦同一问题的受众：一方面是如今被要求支持语音 AI 的 WebRTC 开发者；另一方面是需要使用 WebRTC 的语音 AI 开发者，无论他们是通过 LiveKit Agents 和 Pipecat，还是直接使用 WebRTC。

常见问题

语音AI使用的是WebRTC还是WebSocket？

大多数基于浏览器的语音AI都使用WebRTC，因为它专为低延迟实时音频而设计。一些服务（尤其是ElevenLabs）以及后端到后端通信使用WebSocket，但比特率要高得多（base64 PCM，大约是Opus的10倍）。

实时语音 AI 需要多大的延迟？

自然对话需要毫秒级的往返传输。WebRTC 的设计优先考虑低延迟而非保证传输速度，因此它比基于 TCP 的传输方式更适合语音 AI。

我需要为语音AI代理配置SFU吗？

不，对于使用服务器端虚拟应用交付的一对一人机交互会话来说，SFU 并不适用。只有当对话涉及多人和机器人时，SFU 才真正发挥作用。

我应该自己搭建语音AI系统，还是购买现成的？

大多数开发团队都会购买现成的框架（例如 Daily/Pipecat、LiveKit）。虽然也尝试过直接基于 Pion/Go 构建，但这种做法尚不成熟。OpenAI 最初是基于 LiveKit 开发的，之后才构建了自己的框架，考虑到其规模，这种做法是合理的。

语音AI在WebRTC上使用哪种编解码器？

Opus 的目标码率约为 32 kbps，客户端平均码率约为 20 kbps。语音对语音模型采用的是原始 PCM/G.711 格式，而非 Opus 格式。