博客
让同传跟上对话：ParleyVoice 如何用 RTC 减少实时翻译的等待
你刚在跨国会议上回答了一个问题，对方却迟迟没有接话。你以为他没听清，又重复了一遍；与此同时，他刚听到上一句译音，也开始说话。
一次本来很自然的交流，就这样变成了等待、重复和相互打断。
这也是实时同传与普通文本翻译最大的体验差异之一：一句话不仅要翻得准确，还要及时出现在对话里。
为了减少模型之外的等待，ParleyVoice 在支持 RTC 的托管会议链路中引入了实时音频传输，并协调采集、发送和播放的节奏。我们希望让同传尽可能贴近模型本身的响应速度，让技术处理少占用一点交流的时间。[4]
一、延迟为什么如此重要？
在一场会议里，人们不只是在交换句子，也在判断什么时候可以接话、什么时候需要解释、什么时候应该停下来听。
译音来得太晚，你可能还在听上一句话，对方已经进入下一个问题。双方都在等，却又不确定对方是否听见；想补充一句，也容易错过合适的时机。
连续演讲中的延迟同样影响理解。讲者已经切换到下一页，耳边的译音还停留在上一页，听众就需要额外花精力，把声音与画面重新对应起来。
因此，降低延迟带来的价值很具体：更容易及时回应，更少重复和抢话，也更容易跟上会议与演讲的节奏。
二、从说话到听见译音，时间都花在哪里？
提到 AI 翻译延迟，很多人首先想到模型。实际上，模型只是整条音频链路中的一个环节。
一段声音进入麦克风后，需要被采集、整理成音频帧，经过网络送达翻译服务；模型理解语义并生成译音后，声音还要返回设备，经过播放缓冲，最终从耳机或扬声器里播出来。
可以把主要等待概括为：
同传总延迟 ≈ 采集与组包等待 + 上下行传输及服务转发 + 模型理解与生成 + 播放缓冲与设备输出。
这里的“模型理解与生成”，也包括模型为获得足够上下文而产生的等待。使用语音到语音模型时，这些处理可能发生在同一个流式模型内部，并不一定是三个独立串行的“识别、翻译、合成”服务。
模型变快，当然能改善体验。但如果音频在传输和播放过程中不断排队，用户仍然会感觉慢。
例如，音频包为了传输等一次，到服务端后为了组包再等一次，返回设备后又积累一段才播放。每个环节看起来只增加了一点时间，加在一起，就可能变成明显的停顿。
网络波动还会让这些等待忽快忽慢。因此，实时同传既要关注延迟大小，也要关注声音能否持续、稳定地向前流动。
三、RTC 是什么？为什么它适合实时同传？
RTC 是 Real-Time Communication 的缩写，意思是“实时通信”。语音通话和视频会议，是它最典型的应用场景。
它围绕一个明确目标来组织音频链路：让声音及时、连续地到达，支持人们自然地交流。
这与实时同传的需求高度一致。实际作用主要体现在三个方面。
1. 让声音以小片段持续向前传输
实时同传需要采集、发送、模型处理和播放尽量并行推进。声音采集出一小段，就可以开始往后传；模型开始产生可播放的译音，后续环节也可以逐步接收与播放。
RTC 为这种连续音频提供了专门的传输和播放机制，减少在应用各层反复积攒音频的必要。
WebSocket 同样能够流式传音频。RTC 的价值在于，它进一步把音频的时间要求、网络适应和播放连续性纳入整条链路的设计。
2. 减少网络丢包引起的额外等待
在常见的 TCP 可靠有序传输中，如果前面的数据包需要补发，后面已经到达的数据也可能暂时等待。这种现象叫“队头阻塞”。对于正在进行的对话，这会成为额外的停顿。[1]
RTC 音频通常优先采用适合实时媒体的传输方式，并结合纠错、丢包补偿等机制，在声音质量与播放时限之间做平衡，降低短暂网络波动拖慢后续语音的机会。具体效果取决于网络条件和实际实现。[1][2]
3. 控制缓冲，在连贯与及时之间找到平衡
互联网上的音频包不会完全匀速到达。有时快一点，有时慢一点，接收端需要短暂缓冲，才能保持声音连续。
缓冲太短，声音容易断；缓冲太长，又会增加等待。成熟的 RTC 音频处理会根据到包情况调整播放缓冲，尽量用必要的等待换取连续的声音。[2]
对于会议同传，这意味着我们既追求更快的响应，也关注一场对话能否始终保持稳定的节奏。
四、ParleyVoice 如何把这些优化用在同传里？
在支持 RTC 的托管会议模式中，ParleyVoice 把客户端与翻译服务之间的音频传输交给实时媒体链路，同时优化音频进入模型和返回设备的节奏。[4]
首先，持续传递音频。 采集到的声音以连续小帧进入链路，模型返回的译音也按片段推进，减少不必要的整段等待。
其次，让发送节奏跟上采集节奏。 如果每发送一段音频，都把处理时间额外叠加到下一次发送之前，持续输入就可能逐渐积压。我们调整了发送时钟，让正常的处理开销尽量包含在既定周期中，减少声音越聊越落后的风险。
同时，控制播放端的等待。 译音进入播放队列后，系统保留用于连贯播放的短缓冲，并控制后续排队规模，避免不同环节重复增加起播等待。[4]
这些工作共同服务于同一个目标：模型已经能及时处理的声音，尽快交到用户耳边。
五、延迟能够降到什么程度？
我们希望达到的体验，可以用一句话表达：
让实时同传的总延迟尽量接近模型本身的响应延迟，再加一小段音频传输与播放开销。
这个“一小段”，可以参考百毫秒量级的 RTC 音频链路能力。
公开 RTC 技术文档给出的典型音频链路延迟为 150–300 毫秒，也就是约 0.15–0.3 秒，涵盖音频采集、编码、网络传输、解码与播放等环节。[3]
这个数字说明，通信与音频处理有机会只占整体等待中的一小部分，让同传速度更多取决于模型的语义理解和译音生成。
需要准确理解的是：150–300 毫秒是公开技术资料中的典型链路参考值，并非 ParleyVoice 整条翻译链路的实测保证。 我们的实际链路还包含模型接入、组包和应用播放缓冲，具体体验也会受到网络、模型、设备和使用模式影响。[4]
RTC 优化的方向很明确：把模型之外能够减少的等待逐步压低。模型越快，用户越能直接感受到它的速度。
对 ParleyVoice 来说，低延迟最终要落到真实交流中：客户的问题能更快得到回应，会议中的补充更容易接上，演讲中的译音更贴近讲者的节奏。
我们希望每一次跨语言交流，都能少一点等待，多一点自然。
技术资料
- IETF RFC 8835：WebRTC 传输机制，其中讨论了 TCP 与 UDP、网络回退及队头阻塞。
- WebRTC NetEq：音频抖动缓冲与丢包补偿。用于解释通用 RTC 原理，不表示 ParleyVoice 自行开发或直接采用了文中所有模块。
- RTC 官方技术文档：端到端延迟构成，页面更新日期为 2026-07-21。150–300 毫秒为该文对话式 AI 场景中的 RTC 典型值，用于说明技术量级，不代表对其他架构或所有网络条件的承诺。
- 产品实现依据：ParleyVoice
release/1024中 RTC 主链路、发送节奏与播放缓冲相关说明（内部工程文档，公开发布不附仓库链接）。