AI Knowledge

外观

LLM 流式输出是如何实现的？ ​

3 分钟速学卡 ​

30 秒口述： 我理解的 LLM 流式输出，是服务端在模型逐 Token 解码时，把增量事件持续转发给客户端，而不是等待完整答案后一次返回。实现上需要定义 start/delta/usage/error/done 事件协议，处理缓冲、断连取消、背压、超时和最终完成状态。流式只改善首 Token 体验，不等于降低总生成耗时，必须分别监控 TTFT、生成速率和端到端完成率。

  • 本质： 流式输出是有状态的增量事件协议，不是把最终答案机械切片。
  • 核心机制： 定义 start、delta、error、usage 和 done 的明确语义；同时处理缓冲、背压、心跳、断连与取消。
  • 关键判断： TTFT、生成速率和完整耗时要分开观测；只有收到合法完成事件的结果才能按完整回答处理。
  • 项目落地： 生产风险演练：用户关闭页面后，上游模型仍继续生成。先按连接生命周期取消后台 Task，再检查 ASGI 断连检测、SDK 取消能力和反向代理超时。
  • 边界与坑： “流式就是分块传输”：忽略模型增量解码、事件语义和完成状态；“用了 SSE 就会更快”：SSE 通常改善感知延迟，不保证总耗时下降。

目录 ​

面试官为什么问 ​

面试官想确认你是否理解生成过程、HTTP 长连接、事件协议和资源生命周期，并能处理“页面停止了但上游仍在扣费”这类生产问题。

小白先看懂 ​

饭店开放式厨房不会等整桌菜齐了才上菜，而是凉菜、热菜、汤按完成顺序送到桌上。厨房对应模型，传菜口对应服务端流，服务员对应 SSE 或 WebSocket，桌上的上菜记录对应事件序号。

真实机制不是把完整字符串切成小块，而是消费上游增量事件并及时刷新网络缓冲。类比忽略了客户端断开、代理缓冲和事件重放，所以生产系统还要有心跳、取消传播和明确的结束事件。

主题图与核心原理 ​

图：教学图片｜LLM 流式输出是如何实现的？

替代文本： 围绕“LLM 流式输出是如何实现的？”组织的中文教学图，通过分区、箭头和标签解释核心机制。

LLM 流式输出是如何实现的？教学图片

读图结论： 流式降低首字等待，不等于缩短总耗时。

这张图片用于建立主题机制的直觉。精确公式、参数、失败分支和事实边界仍以正文与 Mermaid 为准。

图片生成记录： model=gpt-image-2，generated=2026-07-15，prompt_version=v1，reviewed=2026-07-16，review_basis=user-confirmed；查看生成 Prompt。

图：LLM 增量事件从解码器到浏览器

替代文本： 模型逐步产生 Token，经 SDK 事件、服务端规范化和 SSE 通道送到浏览器；断连信号反向取消上游调用。

图表加载中…

读图结论： 流式链路既有向前的增量数据，也有向后的取消信号，完成事件决定结果能否被当作完整答案。

SSE 适合服务端单向推送和自动重连，WebSocket 适合双向实时交互；两者都要防代理缓冲。服务端应保存少量聚合状态用于校验和用量统计，但不能无限缓存慢客户端的数据。

项目和生产视角 ​

生产风险演练： 用户关闭页面后，上游模型仍继续生成。先按连接生命周期取消后台 Task，再检查 ASGI 断连检测、SDK 取消能力和反向代理超时；通过带 request_id 的客户端断连、服务端取消和供应商结束时间证明修复。

验收至少测首事件、连续 delta、结构化 error、唯一 done、慢客户端背压和中途取消；指标分开记录 TTFT、tokens/s、完整耗时、断连率、取消传播延迟和不完整响应率。

常见错误回答 ​

  • “流式就是分块传输”：忽略模型增量解码、事件语义和完成状态。
  • “用了 SSE 就会更快”：SSE 通常改善感知延迟，不保证总耗时下降。
  • “断连交给框架处理”：若取消没有传到供应商，资源和费用仍在消耗。

递进追问 ​

  1. SSE 与 WebSocket 的选择标准是什么？
  2. 为什么代理层可能把流式响应缓冲成一次返回？
  3. 如何判断一次流式回答是完整、取消还是失败？
  4. 慢客户端怎样造成内存增长，如何做背压？
  5. 流式结构化输出应该何时进行 Schema 校验？

关联阅读 ​

总结 ​

一句话记忆： 流式输出是有状态的增量事件协议，不是把最终答案机械切片。

  • 定义 start、delta、error、usage 和 done 的明确语义。
  • 同时处理缓冲、背压、心跳、断连与取消。
  • TTFT、生成速率和完整耗时要分开观测。
  • 只有收到合法完成事件的结果才能按完整回答处理。