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

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

流式输出(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

【2025实测】10大AI模型API中转/聚合平台横评:一键集成GPT/Claude/文心一言,拒绝重复造轮子

【2025实测】10大AI模型API中转/聚合平台横评:一键集成GPT/Claude/文心一言,拒绝重复造轮子

当你需要同时调用GPT-4、Claude 3和文心一言时,是否还在为每个平台分别调试接口?2025年的AI开发,正在经历从“单个模型调用”到“多模型智能调度”的范式转变。 随着AI模型生态的日益繁荣,开发者面临的挑战不再是“没有选择”,而是“选择太多”。不同的API接口、各异的认证方式、分散的计费体系和波动的服务可用性,让原本聚焦业务创新的团队疲于应付基础设施的复杂性。 2025年的AI模型API中转平台正在成为解决这一痛点的关键基础设施。这些平台通过统一的接口协议、智能的路由策略和聚合的管理能力,让开发者可以像使用本地服务一样调用全球领先的AI能力。 01 2025年度十大API中转平台全景对比 本次横评基于2025年第一季度实际测试数据,从模型覆盖广度、接口统一程度、稳定可用性、成本效益和开发者体验五个核心维度,对主流API中转平台进行了系统评估。 平台名称核心功能与定位支持模型覆盖2025实测关键表现适用场景综合推荐指数PoloAPI统一接入层与智能调度中心GPT全系列、Claude、Gemini、文心一言、通义千问等20+接口响应延迟稳定在150ms内;智能路由

每日同步热门权重:Llama/Qwen/GLM等优先保障

每日同步热门权重:Llama/Qwen/GLM等优先保障 在大模型技术日新月异的今天,一个开发者最怕遇到什么?不是算法看不懂,也不是数据难清洗——而是当你准备动手微调最新版Qwen或Llama时,发现权重还没发布、镜像源拉不动、显存爆了跑不起来……更别提推理延迟高得没法上线服务。 这正是当前AI研发中普遍存在的“落地断层”:前沿模型迭代飞快,但工程支持跟不上节奏。训练要拼配置,部署靠手动搭轮子,评测没有统一标准,整个流程像是在“用乐高积木造火箭”。 有没有一种可能,让这一切变得像启动Docker容器一样简单? 答案是肯定的。基于魔搭社区(ModelScope)推出的 ms-swift 框架,正在重新定义大模型开发的效率边界。它不只是一个工具集,而是一整套面向生产级应用的全链路解决方案——从你打开终端那一刻起,直到模型上线提供API服务,全程几乎无需写代码。 更重要的是,这套系统每天都会自动同步 Llama、Qwen、GLM 等主流大模型的最新公开权重,确保你在第一时间就能用上刚发布的模型版本。这种“时效性+可用性”的双重保障,在实际项目推进中往往是决定成败的关键。 想象一下

超全实测!llama.cpp性能基准库:从参数调优到多场景测试全攻略

超全实测!llama.cpp性能基准库:从参数调优到多场景测试全攻略 【免费下载链接】llama.cppPort of Facebook's LLaMA model in C/C++ 项目地址: https://gitcode.com/GitHub_Trending/ll/llama.cpp 你是否还在为本地部署大语言模型(LLM)时的性能瓶颈发愁?同样的硬件配置,为何有人能跑100 tokens/秒,而你却卡在20 tokens/秒?本文将带你深度掌握llama.cpp官方性能测试工具——llama-bench,通过标准化测试流程和参数调优技巧,让你的模型性能提升300%! 读完本文你将获得: * 3分钟上手的性能测试命令模板 * 4组关键参数(线程数/GPU层/批处理大小)调优指南 * 5种输出格式(CSV/JSON/

普通的笔记本电脑使用Faster-Whisper 如何选择模式?

普通的笔记本电脑使用Faster-Whisper 如何选择模式?

CPU 环境下使用 Faster-Whisper 并开启 int8 量化,这几个模型模式(tiny、base、distil-whisper)的主要区别在于识别准确率(WER)、运行速度(RTF)以及对上下文的理解能力。 在 CPU + int8 模式下,你的瓶颈主要在于计算速度和内存带宽。以下是详细的对比分析和建议: 1. 核心区别概览 模型模式参数量速度 (CPU int8)准确率核心优势适用场景Tiny~39M🚀 极快⭐ 基础资源占用极低,响应最快简单的语音指令、极低延迟需求的实时字幕Base~74M⚡ 快⭐⭐ 良好速度与准确率的平衡点日常会议记录、清晰的播客转录Distil-Whisper~756M🐢 较慢⭐⭐⭐⭐ 优秀接近 Large 模型的准确率,抗噪性强复杂口音、背景噪音大、专业术语较多的场景 2. 详细模式解析 🟢 Tiny 模式:极致速度,资源敏感