流式与实时链路：从 SSE 的坑到语音的 200 毫秒

截至 2026-08，OpenAI、Anthropic、Gemini 的文本推理流式全部是 SSE over HTTP POST，没有一家用 WebSocket，但事件语义互不兼容：

推论：所谓"换个 base_url 就能切模型"在流式场景是假的。 网关必须写一层事件翻译，这是 T6-3 里"跨厂商 fallback 没那么便宜"的第一条证据。Anthropic 的 delta 还分四种：text_delta、input_json_delta（工具入参的部分 JSON）、thinking_delta、signature_delta——能说出 input_json_delta 的人一定接过工具流式，因为那是坑最多的地方。

坑 1：EventSource 不能设请求头。 它的构造器只接受 url 和 { withCredentials }，没有 header 参数，所以带 Authorization 的 API 永远不能用它直连。实践上一律改成 fetch() + ReadableStream 自己解帧，代价是规范白送的自动重连、Last-Event-ID 续传、retry: 退避全要自己重写。

坑 2：代理缓冲。 就是开头那个故障。nginx 的 proxy_buffering 默认 on；上游可发 X-Accel-Buffering: no 关掉，但这个头可能被网关的 proxy_ignore_headers 吃掉。

坑 3：空闲超时。 nginx 的 proxy_read_timeout 默认 60 秒，算的是"两次成功读取之间"。模型长时间思考不吐字，60 秒后连接就被切——表现是"流到一半断"。规范给的解法很明白：每 15 秒左右发一个注释行当心跳。

坑 4：HTTP/1.1 的 6 连接限制。 浏览器对同一域名最多开 6 个连接，SSE 长期占用一个；开到第 7 个标签页就永远连不上。Chrome 和 Firefox 都标成 Won't fix。HTTP/2 下不再是问题——变成协商的并发流，默认上限 100。

坑 5：失败与重连的区别。 规范规定网络错误才自动重连；状态码不是 200、或 Content-Type 不是 text/event-stream，属永久失败，不重连。所以后端返回 500 时 SSE 是"静默死掉"的，前端必须自己兜。

只有满足任一条时才值得付出代价：真双向（客户端要在响应过程中持续发指令）、二进制音视频帧、单连接多路复用。文本推理三条都不满足——所以三家都没用它。代价这一侧同样清楚：

• 浏览器原生 WebSocket 同样不能设 Authorization 头（构造器只有 url 和 protocols），浏览器端一律要走临时凭证；
• 连接有状态，绑死单实例，滚动发布会踢掉活跃会话；SSE 每次是无状态 HTTP，重连即换实例；
• 断线补发要自己做——SSE 有规范级的 Last-Event-ID，WebSocket 没有对等机制。

一个 2026 的现成案例（截至 2026-08）：MCP 规范在 2026-07-28 那版把传输层进一步去状态化——移除协议级 session 与握手，也移除了 SSE 流的续传与消息补发（断流就重发新请求）。这是"有状态可靠传输"的代价被公开承认的一次：粘连、无法水平扩展、CDN 与网关不友好，最后被无状态 + 客户端重试换掉了。

① 和结构化输出的冲突不在文本，在工具入参。 结构化输出本身与流式兼容。真正的坑是工具参数：Anthropic 官方警告 API 不会在流式过程中缓冲或校验工具入参，你可能收到"部分或非法的 JSON"，且 max_tokens 截断会把参数切一半。两条路二选一：攒到 content_block_stop 再解析（牺牲 TTFT），或用容错解析器边流边补括号（牺牲正确性）。

② 响应侧护栏与流式架构性互斥。 Kong 官方原话是无法"对每个响应 token 查一次外部系统"。NeMo Guardrails 把取舍做成了参数：按 token 块检查（默认 200），而 stream_first 默认为 True——先吐给用户再检查。违规内容已经在用户屏幕上了，事后只能撤回 UI、撤不回截图；设成 False 则退化成每 200 token 一次审核延迟。

③ 限流精度必然下降。 Azure API Management 文档写得最直白：stream: true 时输入 token 强制估算（忽略配置），输出 token 也是估算——流式下要等流完才知道真实用量。

④ 计费与中断口径要自己实测。 三家官方文档都没明文说"客户端断开后上游会不会停止生成、按已生成还是已传输计费"，不要假设。另外 OpenAI 流式默认不返回用量，要显式打开 stream_options.include_usage，且只在最后一个 chunk 返回。

人类对话的基线是轮次之间约 200 毫秒。但同一份研究给了更有说服力的对照：说一个词的言语产出准备要 600 毫秒，短句要 1500 毫秒——人类是靠"边听边预测"做到 200 毫秒的，不是靠反应快。这正是 semantic VAD 想模仿的东西。

不要背"端到端一定更快"。 各家博客给的总延迟互相矛盾（有说级联 2 秒、端到端 200–300 毫秒的，也有厂商反过来说"工程良好的级联比部分端到端模型更快"的），原因是级联各段在流式下是重叠的，名义串行加总本就不成立。可靠的说法是：级联的瓶颈从来在 LLM 那一段，不在 ASR/TTS，所以杠杆在模型选型和流式重叠，不在换架构。

端到端确定的代价有五条，每条都有出处：

1. 上下文窄一个量级：实时语音模型多在 32K–128K，同期文本模型是 200K–1M。
2. 音频 token 贵得多（截至 2026-08）：OpenAI 音频输入是文本的 8 倍、输出 2.7 倍；百炼 omni-realtime 音频输入约 8.2 倍、含音频输出约 5.4 倍。
3. 没有精确的文本-音频对齐——OpenAI 官方自己写的：打断截断时"会同时删掉未播放的音频和它对应的文本"。对齐不准 ⇒ transcript 不可靠 ⇒ 评测与合规审计都难做。
4. 指令跟随会退化：有学术评测量化过语音模型相对其纯文本底座的"遗忘率"，最差超过 −50%。
5. 审核无法前置：级联能在用户听到之前过滤，端到端做不到——音频已经在扬声器上了。

打断答到"用 VAD 检测"只是及格。 完整链路是三层：

这是 Q6-05 最锋利的一刀，三家殊途同归：

• 浏览器原生 WebSocket 设不了 Authorization 头（MDN 构造器签名摆在那），不能拿长期密钥直连；
• WebRTC 的 SDP 交换受 CORS 限制，也不能直接 POST 给厂商服务端——阿里云百炼官方文档逐字写了这条，并明确"正式使用时由业务 AppServer 代理完成"；
• OpenAI 的 client_secrets、Google 的 ephemeral token，都是同一问题的另一种答法。

结论：浏览器端实时语音一定要有一个自建 AppServer 做 signaling 与临时凭证签发。任何声称"纯前端直连"的方案，一定在某处泄露了长期密钥。

至于 WebRTC 为什么比 WebSocket 适合语音：TCP 的队头阻塞会让丢包变成"先静音一段、再一口气爆出积压音频"，而丢一个 20 毫秒的音频帧几乎听不出来，等 200 毫秒重传却非常明显。WebRTC 还自带抖动缓冲和媒体专用拥塞控制。好消息是接大厂 Realtime API 时 STUN/TURN 通常由厂商兜住（百炼文档明确写"无需配置 ICE 服务器"）——只有自建 SFU、多方会议或私有化部署时，这笔成本才回到你头上。

一个值得咀嚼的现实：Google 下线 half-cascade 后，官方论坛出现了持续数月的请愿——开发者反馈半级联版本工具调用成功率明显更高，而原生音频版本强制产出音频，纯文本场景被迫白付音频 token。"端到端"不是免费升级。

• 网关三件套先配好：proxy_buffering off、15 秒心跳、proxy_read_timeout 调大。
• TTFT 拆两个指标上报；语音场景另测"首个音频块"。
• 工具入参流式默认不开，除非已有容错 JSON 解析器且处理了截断。
• 上了流式别指望响应侧同步护栏：要么接受"先出后审"并做撤回 UI，要么关键场景关流式。
• 语音打断一定要做"截断已播放位置"，否则会话历史会静默漂移。

Q6-04 是一面的工程基础题，一句"你们流式怎么做的"就能问出来，分水岭在追问："本地好好的，上线后不流式了，你怎么查？" Q6-05 是进阶题，多出现在做语音的团队，真正的考点在"端到端更快，为什么不全用它"这个反问上。

Q6-04：先定性——"SSE 不是新协议，是 HTTP 响应体的约定格式，单向、自带重连"；再给判据"只有真双向、二进制、多路复用才值得上 WebSocket"；最后主动抛一个坑（代理缓冲或 EventSource 不能设 header），把话题从概念拉到工程。

Q6-05：用 Q2-25 的五步结构。澄清（浏览器端还是服务端？延迟预算？要不要审核前置？）→ 基线（级联，因为有中间文本态）→ 加挂并说代价（端到端换自然感，代价是上下文窄、音频贵、对齐不准、指令跟随退化、审核不能前置）→ 评测（打断成功率、误打断率、对齐质量）→ 演进（先级联跑通业务，再对高价值场景切端到端）。

暴露只读过：

• 只会说"SSE 单向、WebSocket 双向，看场景"，报不出任何一个具体事件名
• 遇到"上线后不流式了"先怀疑模型和前端，不问"中间过了几层代理"
• 说"前端用 EventSource 就行"——不知道它不能带鉴权头
• 背"端到端更快"却说不出它的代价；打断只答到"用 VAD 检测"
• 认为浏览器可以直连厂商的实时语音服务

证明真做过：

• 随口说出 Anthropic 没有 [DONE]、OpenAI Chat 有，并补一句"所以网关得写事件翻译层"
• 主动把 TTFT 拆成 Pipeline 与 Model 两个指标，并说"两者背离就说明问题在非模型环节"
• 知道 X-Accel-Buffering: no 可能被 proxy_ignore_headers 吃掉；知道换 fetch 手工解帧的代价是重连与续传全得自己写
• 说得出流式会同时让限流精度、响应侧护栏、结构化输出三件事降级
• 打断答到"必须把未播放部分从服务端历史里删掉"，并知道 WebRTC 自动处理、裸 WebSocket 要自己管
• 一句话点破"浏览器端必须有自建 AppServer"，并说得出两条约束（设不了 header、SDP 受 CORS 限制）