什么是流式输出,后端怎么生成,前端怎么渲染

什么是流式输出,后端怎么生成,前端怎么渲染

流式输出(Streaming Output) 就像是在看视频直播,内容是一边产生一边传输给你的,而不是像下载电影那样,必须等整个文件下完才能开始看。

在 AI 领域(比如 ChatGPT),流式输出表现为文字一个接一个地“蹦”出来,而不是转半天圈圈后突然甩出一大段话。


什么是流式输出,有什么特点

1. 它是怎么实现的?

流式输出的核心技术通常是 SSE (Server-Sent Events,服务器发送事件)

在传统的 HTTP 请求中,模式是“一问一答”:客户端发请求,服务器处理完全部逻辑,打成一个大包发回客户端。而在流式输出中,过程如下:

  1. 建立持久连接:客户端发送一个请求,并在 HTTP 头部声明 Accept: text/event-stream
  2. 分块传输:服务器每生成一个字(或一个 Token),就立即将其封装成一个小数据块发送出去。
  3. 保持连接:直到内容生成完毕,服务器才会发送一个特殊的结束标志(如 [DONE]),随后关闭连接。

2. 流式输出的特点

特点说明
低首字节延迟 (TTFB)用户能瞬间看到反馈,大大缓解了等待焦虑。
实时性适合长文本生成。如果是普通模式,生成 1000 字可能需要 20 秒,流式模式下第 1 秒就开始显示。
单向通讯不同于 WebSocket 的双向奔跑,SSE 主要是服务器向客户端“单向投喂”数据。
资源占用因为要长时间维持一个 HTTP 连接,对服务器的并发处理能力有一定要求。

3. 为什么 AI 必须用它?

大语言模型(LLM)的推理过程是自回归的。简单来说,它每生成一个词,都要基于前面所有的词重新算一遍概率。

P(wt+1∣w1,w2,...,wt)P(w_{t+1} | w_1, w_2, ..., w_t)P(wt+1​∣w1​,w2​,...,wt​)

这个过程本身就很耗时。如果等 2000 个 Token 全部算完再给用户,用户可能以为网页卡死了。流式输出完美契合了模型“一个一个词往外蹦”的运行逻辑。

后端怎么实现

在后端实现流式输出,本质上是打破“处理完全部逻辑再返回”的传统模式,改为利用 HTTP 分块传输(Chunked Transfer Encoding) 持续向客户端推送数据。

最常见的方法是使用 SSE (Server-Sent Events)。下面我以 Python (FastAPI) 和 Node.js (Express) 为例展示核心逻辑。


1. Python 实现 (以 FastAPI 为例)

FastAPI 内置了 StreamingResponse,非常适合配合大模型的生成器(Generator)使用。


2. Node.js 实现 (以 Express 为例)

在 Node.js 中,通过手动设置 HTTP 响应头并使用 res.write() 来持续发送数据。


3. 实现的关键要素

要确保后端流式输出成功,必须满足以下几个条件:

  • 正确的 Content-Type: 必须设置为 text/event-stream
  • 禁用缓冲 (Buffering):
    • 如果你使用了 Nginx 等反向代理,它可能会默认缓存后端的数据,攒够一波再发给前端。
    • 解决方法: 在 Nginx 配置中设置 proxy_buffering off;,或者让后端返回 X-Accel-Buffering: no 响应头。
  • 特定的数据格式:
    • 每条消息必须以 data: 开头。
    • 每条消息必须以两个换行符 \n\n 结尾。

4. 进阶:如何对接大模型 (LLM)

如果你是在调用 OpenAI 或 Anthropic 的 API,它们通常提供 stream=True 参数。你的后端实际上充当了一个中转站(Proxy)

  1. 后端调用 AI API(开启流式)。
  2. 后端迭代接收 AI 返回的每一个 Chunk。
  3. 后端立刻将这个 Chunk 转发给前端。

前端怎么实现

在前端捕获流式数据,主要有两种主流方案:传统的 EventSource 和现代的 fetch + ReadableStream

由于现在的 AI 接口(如 OpenAI)大多使用 POST 请求,方案二 (fetch) 是目前最通用的做法。


方案一:使用 fetch 结合 ReadableStream (推荐)

fetch API 本身支持流式读取。通过 response.body,你可以获取一个读取器(Reader),逐块解析数据。


方案二:使用 EventSource (仅限 GET)

如果你的后端接口支持 GET 请求,EventSource 是最简单的原生实现,它会自动处理重连和心跳。


核心难点:如何优雅地“渲染”?

在处理 AI 流式输出时,你可能会遇到以下两个坑:

  1. Markdown 渲染:数据是一点点出来的,如果你每出一个字就渲染一次 Markdown,性能会炸掉。
    • 对策:使用带缓存的渲染库(如 markdown-it),并限制渲染频率(如 100ms 刷新一次)。
  2. 数据截断:有时候一个 Unicode 字符或者一个 JSON 字符串会被拆分到两个不同的 Data Chunk 中。
    • 对策:在前端维护一个缓冲区(Buffer),将接收到的 value 累加,直到匹配到完整的 \n\n 再进行解析。

Read more

【Python实战】像人类一样思考:AI绘画模型TwiG-RL深度解析(完整代码)

【Python实战】像人类一样思考:AI绘画模型TwiG-RL深度解析(完整代码)

【Python实战】像人类一样思考:AI绘画模型TwiG-RL深度解析(完整代码) 摘要 本文深入解析港中文与美团联合推出的TwiG-RL模型,该模型通过"生成-思考-再生成"的循环机制,让AI在绘画过程中能够"停下来看一眼",像人类画家一样边画边想。我们将从原理分析到Python代码实现,带你掌握这一突破性技术。 1. 背景与问题:传统AI绘画的"黑盒"困境 1.1 传统生成模型的局限性 在传统的文本到图像(T2I)模型中,生成过程是一个连续的黑盒操作: 输入文本提示 → 模型一次性生成 → 输出图像 这种方式存在三大问题: 1. 缺乏中间控制:无法在生成过程中调整方向 2. 错误传播:早期错误会持续影响后续生成 3. 不可解释性:无法理解模型"为什么"这样生成 1.

Pix4Dmapper处理大疆无人机影像数据教程

Pix4Dmapper处理大疆无人机影像数据教程

初次接触无人机数据处理时,我完全找不到清晰的流程指引,甚至对大疆采集的数据如何使用都毫无头绪。查阅了不少资料,发现信息也相当有限。为避免日后遗忘,特此记录下摸索出的操作流程,权当备忘。 1. 想要使用Pix4D软件的朋友请注意:这款软件需要付费购买。我查阅了网上资源,发现大多数人都没有提供免费版本。我已经购买了“正版”软件,有需要的朋友可以私信我,我会分享下载链接给你。 2. 结束,到这里 下面是软件处理影像过程 (1)、首先打开Pix4DTool,点击start或者Auto start以后,立马会将软件的网进行断开,这样就可以进行使用pix4d软件了。 (2)、此时打开软件的界面如下所示 (3)、拷贝数据到电脑然后打开软件新建项目输入项目名称并选好路径点击下一步 (4)、添加无人机照片路径或选择添加照片完成并点击下一步 (5)、因为精灵RTK照片自带POS信息这里就直接默认坐标系,相机参数是写入在照片里可以自动读取,如果不确定就用记事本打开照片找到XMP把相机信息参数输入点击下一步 (6)、输出坐标系选择自己需要的坐标系,和像控点一致的

Vivado使用教程:图解说明管脚分配全过程

Vivado管脚分配实战指南:从原理到避坑全解析 你有没有遇到过这样的情况?逻辑代码写得完美无缺,仿真波形也完全正确,结果下载到FPGA板子上——灯不亮、通信失败、甚至芯片发热异常。排查半天,最后发现是某个引脚接错了电压标准? 别笑,这在FPGA开发中太常见了。 尤其是在初学阶段,很多人把注意力都放在Verilog或VHDL的语法和状态机设计上,却忽略了 一个比代码更底层、更关键的环节:管脚分配 。 今天我们就来彻底拆解这个“隐形杀手”——用最贴近工程实践的方式,带你一步步搞懂 Vivado中的管脚分配全过程 ,不只是点几下鼠标那么简单,而是理解背后的电气规则、约束机制与系统级影响。 为什么管脚分配不是“随便连一下”? FPGA不像MCU那样有固定的外设映射。它的每个IO引脚都是可编程的,这意味着你可以自由定义哪个引脚做时钟输入、哪个输出控制LED。但自由的背后是责任: 每一个引脚配置都必须符合物理世界的电气法则 。 举个真实案例: 某工程师将一个来自3.3V系统的复位信号接入Bank 14(VCCO=1.8V),没有加电平转换。虽然一开始功能似乎正常,但在高温环境下

(6-4-02)IMU融合与机体状态估计:综合实战:腿式机器人的IMU关节融合与状态估计(2)

(6-4-02)IMU融合与机体状态估计:综合实战:腿式机器人的IMU关节融合与状态估计(2)

6.4.3  状态估计 “src”目录包含本项目状态估计的核心算法实现和工具模块,涵盖惯性导航与人形机器人运动状态估计的完整流程,包括EKF状态预测与更新、IMU数据补偿与积分、机器人足端运动学计算、静态初始对准、导航结果与误差输出、数据流生成及可视化工具,整体提供从原始传感器数据到导航状态估计和分析的全链路功能,实现机器人高精度运动导航和状态监控。 1. IMU数据的传播与补偿 文件src/imuPropagation.py的功能是提供IMU数据的传播与补偿机制,用于惯性导航系统(INS)中状态更新。INSMech 类实现了基于前一时刻和当前IMU测量的速度、位置和姿态传播,同时对IMU角速度和加速度进行偏差与缩放误差补偿。_wrap_yaw_inplace用于将偏航角限制在 -π,π 范围内。 import numpy as np from scipy.spatial.transform import Rotation as R def _wrap_yaw_inplace(euler_