Simon Willison's Weblog
来自Luke Curley的一段话
7.2Score
TL;DR · AI 摘要
Luke Curley批评WebRTC在弱网下强制丢包以维持低延迟，导致语音提示质量下降，而用户更希望等待200ms换取准确响应。
核心要点
- WebRTC在弱网下会主动丢弃音频包以保持低延迟（<100ms）
- 用户更愿等200ms获得准确LLM响应而非实时但失真的语音
- 浏览器端无法重传WebRTC音频包，因实现被硬编码为‘实时或失败’
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- WebRTC语音AI问题
- 设计哲学
- 优先低延迟（<100ms）
- 容忍音质损失
- 用户需求冲突
- 愿等200ms换准确LLM响应
- 当前体验差：垃圾提示=垃圾输出
- 技术障碍
- 浏览器不支持重传
- 实现硬编码为实时或失败
金句 / Highlights
值得收藏与分享的关键句。
WebRTC aggressively drops audio packets to keep latency low. If you’ve ever heard distorted audio on a conference call, that’s WebRTC baybee.
I would much rather wait an extra 200ms for my slow/expensive prompt to be accurate. After all, I’m paying good money to boil the ocean, and a garbage prompt means a garbage response.
It’s impossible to even retransmit a WebRTC audio packet within a browser; we tried at Discord. The implementation is hard-coded for real-time latency or else.
#WebRTC#LLM#语音AI#前端
打开原文Luke Curley 的一句话
[Simon Willison 的博客](https://simonwillison.net/)
赞助商：WorkOS — 通过 SSO、SCIM、RBAC 等功能让你的应用具备企业级能力。
2026年5月9日
WebRTC 在网络状况不佳时会 降级并丢弃我的提示。
我的天啊，兄弟
WebRTC 为了保持低延迟会主动丢弃音频包。如果你曾在视频会议中听到过失真的音频，那就是 WebRTC 啦宝贝。其设计思路是：会议通话依赖快速来回交流，因此等待音频到达是不可接受的。
…但作为用户，我更愿意多等 200 毫秒，让我的慢速/昂贵的提示变得准确。毕竟我花了不少钱来“煮沸海洋”，一个垃圾提示就意味着一个垃圾响应。而且 LLM 本来就不怎么快。
但我不能等。在浏览器中甚至无法重传一个 WebRTC 音频包；我们在 Discord 尝过了。这个实现被硬编码为必须实时延迟 否则就放弃。
—— Luke Curley，《OpenAI 的 WebRTC 问题》，回应 OpenAI 如何规模化实现低延迟语音 AI
发布于 2026年5月9日 凌晨1:03
最近文章
- 关于 xAI / Anthropic 数据中心合作的笔记 - 2026年5月7日
- 直播博客：用 Claude 2026 编程 - 2026年5月6日
- 氛围编程和代理工程正变得比我想象中更接近 - 2026年5月6日
这是由 Simon Willison 收集的一句引言，发布于 2026年5月9日。