大模型语音接入选型：WebSocket还是WebRTC？

1. 这个选型问题，先说说我的结论

做了一段时间的大模型语音交互，接到最多的问题就是：客户端想把语音喂给大模型，到底是走 WebSocket 还是 WebRTC？

先给结论：绝大多数场景，WebSocket 就够了；只有对实时性和弱网抗性要求极其苛刻、或者要双向音视频通话的场景，才需要 WebRTC。

这两年大模型语音接入的火爆，主要是两类应用：一类是语音助手（比如给智能客服加语音入口），另一类是对接实时语音大模型（比如能直接听懂语气、情绪的多模态对话）。两类应用的技术链路差别很大，选型逻辑也完全不同。我分别踩过坑，把整个过程梳理出来，希望能帮你少走弯路。

WebSocket 和 WebRTC 不是同一个维度的东西。WebSocket 是应用层协议，解决的是"客户端和服务端之间建立一个双向、持久、低延迟的通道"；WebRTC 是一整套实时音视频通信框架，解决的是"如何在不可控的网络上把音视频数据以尽可能低的延迟、尽可能高的质量传过去"。所以严格说，这不是二选一，而是"用 WebSocket 拼装一条语音链路"还是"直接上 WebRTC 这套重型武器"的问题。

2. 为什么大模型语音需要"实时通道"

2.1 大模型对话的端到端延迟预算

先看一个真实的语音对话链路。用户说一句话，整个过程要经过：

音频采集 -> 编码 -> 网络传输 -> 语音识别（ASR）-> 大模型推理（LLM）-> 文本生成 -> 语音合成（TTS）-> 编码 -> 传输回客户端 -> 播放

每个环节都有延迟。实测下来，通用 ASR 识别一句话大约 300-800ms（流式模式首字更快），大模型推理首 token 大约 300-1000ms，TTS 首次出声约 200-500ms。还不算网络 RTT。整个链路的端到端延迟通常会到 1.5-3 秒。

这个延迟预算意味着，网络传输本身不是瓶颈。WebSocket 在正常网络下的传输延迟也就几十毫秒，完全在可接受范围内。真正要优化的反而是 ASR、LLM 推理和 TTS 这三段。所以大多数场景根本不需要 WebRTC 的极致低延迟。

2.2 全双工不等于同传

很多人被"全双工"这个词迷惑了。WebSocket 确实是全双工协议，服务端和客户端可以同时发消息。但在大模型语音场景里，多数产品的交互模式是"你说一句，它回一句"，本质上还是半双工的人机对话模式。

真正常见的瓶颈反而是：客户端采集音频 -> 推到服务端 -> 服务端在做 ASR 和 LLM 推理的这几秒里，客户端不能打断、不能叠加发送。这跟协议无关，是产品逻辑和状态机的问题。

2.3 大模型 API 的接入方式决定了选型

这是关键。目前市面上能接的大模型 API，绝大多数提供的流式接口就是 HTTP SSE 或者 WebSocket。你服务端拿到的是一段文本流、或者一个音频流，转发给客户端最自然的方式就是 WebSocket。

换句话说，服务端怎么接大模型，决定了客户端该怎么连服务端。如果大模型给的是 WebSocket 流式接口，你客户端搞 WebRTC 就得多加一层适配，得不偿失。

3. WebSocket + 大模型语音：我的主力方案

3.1 一条完整的 WebSocket 语音链路怎么搭

我实际落地过的一套方案是这样的：

• 浏览器端用 AudioWorklet 采集音频，opus 编码（或者直接取 PCM16 压缩编码），通过 WebSocket 二进制帧推给服务端。
• 服务端收到音频帧，转发给 ASR 服务做流式识别。
• ASR 给出中间结果和最终结果，文本送入大模型。
• 大模型流式返回 token，经过 TTS 合成音频，服务端把音频帧通过同一个 WebSocket 推回客户端。
• 客户端播放音频。

这套链路的好处是：一条连接走到底，服务端逻辑简单，调试方便。浏览器端只要处理数据收发和播放，不需要管 NAT 穿透、ICE 协商这些糟心事。

3.2 音频帧怎么发才不卡

很多新手犯的错误是：把整个音频文件一次性发过去。这没法流式。正确做法是按固定帧长切片，比如每 20ms 或者 40ms 一个 block，带上 seq 序号和时间戳。服务端按序处理。

给一个简单的发送逻辑示例（浏览器端 AudioWorklet 配合 WebSocket）：

javascript复制const ws = new WebSocket('wss://your-server/audio');
const audioContext = new AudioContext({ sampleRate: 16000 });
const source = await navigator.mediaDevices.getUserMedia({ audio: true });

const workletNode = new AudioWorkletNode(audioContext, 'audio-capture');
workletNode.port.onmessage = (event) => {
  // Float32Array 转 Int16 PCM 再发送
  const pcm = float32ToInt16(event.data);
  ws.send(pcm.buffer);
};

const micSource = audioContext.createMediaStreamSource(stream);
micSource.connect(workletNode);

服务端收到 ArrayBuffer，先解析出 PCM 数据，再转给 ASR。这个方案我在本地和公网都测过，60 秒以内的对话，音频断帧率不到 1%。

3.3 断线重连和心跳

WebSocket 在大模型这种长连接场景里，一个容易忽略的问题是中间设备（比如代理、网络切换）会悄悄断开 TCP 连接，而两端都感知不到。解决方案是心跳机制：客户端每 15 秒发一个 ping，服务端收到回 pong，连续 2 次超时判定为掉线。然后客户端自动重连，同时带上音频会话 ID 让服务端恢复上下文。

断线恢复要格外小心。语音对话的上下文不能丢，重连后服务端要能通过 session_id 把之前 ASR 的中间过程和 LLM 的上下文找回来，否则用户说了一半就断，重连后大模型根本不记得之前聊了什么。

4. WebRTC + 大模型语音：实力很强，但代价不小

4.1 WebRTC 到底提供了什么

WebRTC 不是一句"低延迟"就能概括的。它内置了一整套音视频工程能力：Opus 编码、回声消除（AEC）、降噪（NR）、自动增益（AGC）、抖动缓冲（Jitter Buffer）、丢包重传（NACK）、前向纠错（FEC）、带宽估计和自适应码率。

这就意味着，如果你要做的是"用户对着手机或者网页说话，要求背景噪音环境下也能识别清楚"，WebRTC 开箱即用地帮你处理掉噪音环境下的高质量音频采集。而 WebSocket 方案里，这些全得你自己做或者靠 ASR 服务端硬撑。

4.2 WebRTC 接入大模型的两条路线

路线一：整条链路走 WebRTC，大模型服务端也接入 MediaStream 轨道。

服务端跑一个 SFU（比如 mediasoup、Janus、LiveKit）收客户端的音频，再过一个推理节点，将大模型的音频输出推回来。

这个方案的好处是端到端延迟低、实时性强，降噪处理全部内置；坏处是架构复杂度直接翻倍——你得维护媒体服务器、ICE/STUN/TURN、证书信令服务，还得处理大模型推理服务的音频适配。

路线二：WebRTC 只负责采集和播放，后端中转给普通大模型 API。也就是 WebRTC 作为"高质量音频采集 + 低延迟播放"组件，真正的对话逻辑还是靠 HTTP 或者 WebSocket 调用大模型。

这个方案相对折中：前端体验好，后端不用大改，但实现上还是得处理 WebRTC 的协商、重连等逻辑，工作量不见得小。

4.3 弱网能力是 WebRTC 的护城河

我实测过同一个网络环境（Wi-Fi 信号差、丢包 10% 上下），WebSocket 发送音频的 MOS 质量分数明显下降，语音识别准确率掉了差不多 8-10 个百分点；而 WebRTC 因为有 NACK 和 FEC，再加上 Opus 自带的丢包隐藏，同样的网络条件下还能维持不错的识别率。

如果你的用户群体里有大量移动网络弱网环境（地铁、高铁、电梯、地下室），WebRTC 的抗弱网能力是实打实的优势。WebSocket 在这种环境里，尤其是音频流发送，对网络抖动非常敏感，因为 TCP 的拥塞控制会把延迟瞬间拉高。

5. 核心指标对比：延迟 / 成本 / 复杂度

这张表不是否定 WebRTC，而是告诉你：选 WebRTC 一定是有明确理由的，而不是因为"听起来更高级"。

6. 实操：WebSocket 接入大模型语音的完整代码链路

6.1 服务端怎么设计连接、会话、转发

我把服务端拆成三个角色：

• ConnectionManager 管理 WebSocket 连接，负责心跳、断线检测。
• AudioSession 管理会话状态，包含 ASR 流、大模型调用、TTS 流的串联。
• LLMAdapter 封装大模型 API 调用，支持流式返回。

伪代码大致是这样：

python复制class ConnectionManager:
    async def handle_websocket(self, ws, path):
        async for msg in ws:
            if isinstance(msg, bytes):
                await self.session.push_audio(msg)  # 音频帧
            elif isinstance(msg, str):
                if msg == 'ping':
                    await ws.send('pong')
                # 其他控制消息

关键点：handle_websocket 和 push_audio 之间不要有耗时操作，音频帧到了就立即投递给 ASR 客户端。如果在 ASR 回调里同步调大模型，音频肯定处理不过来。应该让 ASR 的结果异步进入一个队列，由一个独立的 worker 拉取并调用大模型。

6.2 前端的完整状态机

前端不能只管发音频，得维护对话状态：

javascript复制const state = {
  IDLE: 'IDLE',
  LISTENING: 'LISTENING',   // 客户端录音中，发送音频
  SPEAKING: 'SPEAKING',     // 大模型回复中，播放音频
  WAITING: 'WAITING'        // 音频已发完，等大模型回复
};

对话开始时进入 LISTENING，音频帧一直发；用户说完话，前端静音检测（VAD）判断停顿超过 600ms 就切换到 WAITING，发送一个 "end_of_speech" 控制消息；服务端收到后完成 ASR 最终识别，调大模型；大模型返回结果后，如果 TTS 音频流开启，客户端播放时就进入 SPEAKING，同时允许用户按打断键终止播放、重新进入 LISTENING。

6.3 音频格式对齐：最容易踩的坑

浏览器采集的音频默认是 48kHz 的 Float32 数据，而很多 ASR 服务要求 16kHz 的 Int16 PCM。很多人就在这一步翻车。必须在 AudioWorklet 里做重采样和类型转换：

javascript复制function float32ToInt16(float32Array) {
  const int16Array = new Int16Array(float32Array.length);
  for (let i = 0; i < float32Array.length; i++) {
    const s = Math.max(-1, Math.min(1, float32Array[i]));
    int16Array[i] = s < 0 ? s * 0x8000 : s * 0x7FFF;
  }
  return int16Array;
}

重采样可以用 AudioContext({ sampleRate: 16000 }) 直接设置，浏览器会自动做重采样。这个技巧实测很稳，省了很多麻烦。

7. 实操：WebRTC 场景的两种落地姿势

7.1 纯采集型：WebRTC 只负责收音

这是我第二个项目采用的方式。场景是需要抗噪的语音助手，但是对话逻辑依旧走 WebSocket。整个架构是这样的：

客户端先建立 WebRTC RTCPeerConnection，只发送音频轨道（不做播放），同时通过信令服务器交换 SDP。服务端收到音频轨道后，用 MediaStream 导出 PCM 数据，再转给 ASR。

这种方式的好处是，前端不用自己做降噪和 VAD，getUserMedia + WebRTC 底层的 AGC 和降噪效果比我手写的好太多。缺点是需要维护信令服务，而且服务端必须跑媒体处理（比如用 GStreamer 或者编解码器把 Opus 转 PCM），复杂度确实上来了。

7.2 全链路型：双向音视频和低延迟对话都要

如果你的产品是数字人、虚拟形象这种"既要听到用户说话，又要用高质量音频和形象回话"的场景，那就全链路走 WebRTC 吧。选择开源的 mediasoup 做 SFU，服务端把 WebRTC 的音频接入推理服务。推理服务需要支持连续音频流输入，否则你还要在服务端做一个音频拼接器。

实测这种全链路方案，首字延迟可以压到 800ms 以内（在网络好的内网环境下），比 WebSocket + 多段 API 拼接方案快不少。代价就是排查问题的时候，你需要同时看 WebRTC 协商日志、SFU 状态、推理服务 CPU 和内存，调试成本翻了几倍。

7.3 何时必须用 TURN Server

WebRTC 有一个永远绕不开的话题：NAT 穿透。P2P 打不通的时候，必须走 TURN 中转。而 TURN 服务器开销很大，纯中转每个月流量成本可能是媒体服务器本身的几倍。

我建议在项目早期就做好评估：如果你的用户 80% 在办公网或家庭宽带，NAT 穿透率能到 85% 以上；如果是大型企业网或者运营商级 NAT，穿透率可能只有 50%，那 TURN 的成本会非常高。WebSocket 方案没有这个问题，因为它本来就走服务器中转。

8. 大模型 API 对流式的支持程度，决定技术路线

现在的大模型接口，流式能力差别很大。有的只支持 HTTP SSE，有的支持 WebSocket，有的甚至只支持普通 HTTP 一次性提交。

这个叫做 stream 参数的东西，千万不要忽略。我在一个项目里踩过坑：大模型 API 不支持流式返回，我却在客户端用 WebSocket 加了"打字机"效果，结果发现服务端要等整个回复生成完才能推送，毫无实时性。后来换了支持流式的模型接口，体验才正常。

选型时先搞清楚大模型 API 的流式协议，再决定你的传输层。如果大模型侧走 SSE，你完全可以让服务端用 SSE 对接大模型，WebSocket 只负责和客户端通信，这样两边都不委屈。

9. 我实际测过的两组数据

放两组实测数据供参考。测试环境：同一台云服务器部署，客户端分别是 Chrome 和微信内置浏览器，网络分别用有线宽带和 4G 弱网（模拟）。

第一组：WebSocket + ASR + 通用大模型（非实时语音大模型）

• 正常宽带：端到端延迟约 1.8-2.5 秒，偶发 0.5 秒级抖动。
• 4G 弱网（丢包 5%）：延迟飙升到 4-6 秒，偶尔重连。
• 体验评价：可用，但弱网下明显发闷。

第二组：WebRTC + 实时语音大模型（支持音频流式输入）

• 正常宽带：端到端延迟约 0.9-1.2 秒。
• 4G 弱网（丢包 5%）：延迟约 1.5-2 秒，无明显断音。
• 体验评价：接近真人对话节奏，弱网下依然自然。

差距很明显，但也要算笔账：第二组的开发量是第一组的 2.5 倍左右，而且实时语音大模型的接口认证、配额和计费模式跟普通文本模型还不一样，成本也要高不少。

10. 选型决策清单：照这个判断就行

我整理了一张决策清单，直接对号入座：

1. 你只是做语音问答助手，用户不说话时不需要保持连接，选 WebSocket。
2. 你需要实时打断、多轮对话且延迟必须低于 1.5 秒，可以考虑 WebRTC。
3. 你的用户大量处于弱网环境（地铁、高铁、野外），WebRTC 的弱网优化更值得投入。
4. 你的产品是数字人、语音视频双通道交互，直接选 WebRTC。
5. 你的团队后端经验多但音视频经验少，先 WebSocket 做 MVP，等数据证明需要再迁移。
6. 大模型 API 只支持 HTTP SSE，那就 WebSocket 做前端通道，别硬上 WebRTC。
7. 你的公司有严格的内网环境限制 UDP 流量，那 WebRTC 可能根本跑不通，老老实实 WebSocket。

这个清单不是教条。我走了不少弯路，最后发现核心就一句话：延迟敏感度和弱网占比，是选型的唯一决定性因素。 如果你的产品两个指标都没到瓶颈，就不要让 WebRTC 的复杂度来拖慢你的迭代速度。

11. 最后分享一个经验：不要怕后面换方案

我第一个语音项目就是 WebSocket 起步的，当时没有想太多，一个月上线了 MVP。后来用户反馈中确实有弱网卡顿投诉，比率大约 12% 左右，我们用埋点统计了网络类型和延迟分布，才下决心在 2.0 版本迁移到 WebRTC。迁移的核心价值在于：WebSocket 阶段的会话管理、VAD 分段、状态机设计，在 WebRTC 迁移时原样保留下来了，只重写了传输层。

所以不要一上来就追求"完美的架构"。先把 WebSocket 链路跑通，把产品逻辑打磨好，用数据说话。当你真的需要 WebRTC 的时候，你会有充分的数据支撑，而且迁移路径也是清晰的。反过来，如果你一开始就选了 WebRTC，后面发现复杂度拖垮了团队，回退到 WebSocket 反而要砍掉很多东西。

更适合自己的技术方案，永远不是纸面上的最优解，而是团队能力、产品阶段和用户场景叠加后的那个解。