引用 Luke Curley
摘要
技术评论：Luke Curley探讨WebRTC的设计如何通过激进丢弃音频数据包来优先保障低延迟，这与LLM语音应用中提示词准确度比速度更重要的需求相矛盾。他讲述了在浏览器限制下在Discord实现重传所面临的挑战。
暂无内容
查看缓存全文
缓存时间: 2026/05/09 02:28
# 来自 Luke Curley 的引用
来源：https://simonwillison.net/2026/May/9/luke-curley/
2026年5月9日
> WebRTC 的设计初衷是在网络条件不佳时**丢弃我的提示词**。wtf 老兄，WebRTC 会激进地丢弃音频数据包以保持低延迟。如果你曾在会议通话中听到过失真的音频，那就是 WebRTC 的手笔。想法是这样的：会议通话依赖于快速的来回互动，所以暂停等待音频是不可接受的。...但作为用户，我宁愿多等 200ms 来确保我的慢速/昂贵的提示词是准确的。毕竟，我花了不少钱来"烧开海洋"（指大量计算资源），而垃圾提示词意味着垃圾回复。更何况 LLM 本身的响应速度也不怎么样。**但我不被允许等待**。这*不可能*在浏览器中重传 WebRTC 音频数据包；我们在 Discord 试过了。该*实现*被硬编码为实时延迟**否则免谈**。
—Luke Curley (https://moq.dev/blog/webrtc-is-the-problem/)，OpenAI 的 WebRTC 问题，回应自《OpenAI 如何大规模提供低延迟语音 AI》(https://openai.com/index/delivering-low-latency-voice-ai-at-scale/)
相似文章
OpenAI 的 WebRTC 问题
一篇技术博客文章中，一位自称 WebRTC 专家的作者批评了 OpenAI 将 WebRTC 应用于语音 AI 的做法，认为该协议设计用于实时会议，采用激进的丢包机制，这与语音 AI 的应用场景相悖——在语音 AI 中，准确性比极低延迟更为关键。
OpenAI 如何实现大规模低延迟语音 AI 部署
OpenAI 详细介绍了其重新架构的 WebRTC 技术栈，旨在为超过 9 亿用户提供大规模低延迟语音 AI 服务。文章阐述了全新的 split-relay 和 transceiver 架构如何优化媒体路由与连接建立，以支持 ChatGPT 语音等实时交互场景。
基于LLM并行文本生成的低延迟实时音频游戏解说系统
本文介绍了一种低延迟实时音频游戏解说系统，该系统利用基于LLM的并行文本生成技术，将语句间的静默时间从9.6秒减少到0.3秒，与顺序基线相比显著改善了感知到的说话节奏。
你的语音助手响应慢可能不是因为大语言模型。
一位开发者驳斥了常见的观点，即LLM延迟是语音助手响应慢的主要原因，并解释说，延迟往往源于更早的阶段，如音频捕获、语音活动检测（VAD）和语音转文字（STT）。他建议记录特定的延迟指标，并测试不同的STT/TTS提供商和编排框架来诊断问题。
我们如何将Discord语音迁移到边缘
Discord将其超过80%的语音和视频流量迁移至Cloudflare覆盖300多个城市的边缘网络，显著降低了全球延迟和丢包率，例如法兰克福的ping值降低了34%。