前言

自大模型问世以来，在基础模型、应用场景等多个方面呈现出了百花齐放的场景，但人与模型的交流方式却呈现了高度统一。在人与模型对话的方式上，虽然也出现过Manus、Coze工作流、ComfyUI等基于工作流编排的方式，但这种方式始终局限在小众的应用场景中，并且具备较高的门槛，并没有真正推广到大众使用。事实上，拟人对话的方式已经成为了人与模型交互的既定标准。

在传统的IM工具中，无论是微信类的即时交互工具还是邮件类的非即使交互工具，其本质都是基于Request-Response 方式进行工作，即发送方将所有消息完整输出后再发送。而人与大模型的交互方式却是流式输出，就像是人与人之间面对面的交流，逐字逐句输出带来最直观的感受是科技感与拟人化。

但细究一下，选用流式输出而非打包整体输出，也许起初并不是为了科技感与拟人化而考虑的，流式输出的底层技术也非大模型革命所带来的新技术。

流式输出的底层技术

在绝大多数的AI对话交互方式，包括OpenAI的API接入方案中，都明确使用了SSE（Server-Send-Event）的方式来实现对话的流式输出。如下图OpenAI的ChatGpt对话，存在一个 conversation 请求来开启SSE。

SSE作为一个轻量级的服务器推送技术，在设计之初主要被用来解决传统轮询（Polling）和长轮询（Long-Polling）的效率问题。主要应用于以下场景：

1. 实时信息流推送
   • 新闻/社交平台更新：自动刷新头条新闻、微博/推特的新消息流
   • 金融行情播报：股票价格波动、外汇汇率变化的Tick级推送
   • 赛事实时比分：体育赛事得分、电竞游戏战况的秒级更新
   • 案例：早期Twitter曾用SSE实现用户时间线的实时更新，每个新推文通过data: {tweet}\n\n格式推送至浏览器。
2. 状态监控类应用
   • 服务器日志流：运维人员实时查看Nginx/Apache访问日志
   • IoT设备状态：温度传感器、生产线设备的实时数据仪表盘
   • 文件处理进度：大文件上传/视频转码的进度百分比反馈（如data: {"progress":75%}）
3. 低复杂度通知系统
   • 邮件到达提醒、日程事件提醒、系统公告推送
   • 电商网站的库存变更通知（如限量商品抢购倒计时） 后来部分核心场景逐步被其他协议所取代，如IoT设备状态被 MQTT 所取代、需要更精确时间和双向通信的场景被 WebSocket 所取代、通知系统也更多的使用第三方推送服务。

SSE是一个基于HTTP协议的技术，有如下几个特点：

1. 可复用HTTP协议下的所有认证方式，具备可快速接入的特性
2. 得益于HTTP2的多路复用技术，SSE的并发获得了较大幅度的提升
3. 无状态设计，每个会话就是单独的一个SSE事件流
4. 单向事件流，只能从服务方向客户端推送事件

为什么选用流式输出

至于为什么大模型会选择SSE作为主流的流式输出方式，目前也没什么主流声音去分析。我结合大模型技术、流式技术和人机交互易用性进行了一些猜测，可能有以下几个原因：

1. 大模型其本身就是流式输出。当前所有的大模型技术均为生成式AI，通过"当前词 -> 下一个词 -> 再下一个词"逐步推理。如果采用非流式的输出，会额外产生内存开销和输出延迟。
2. 在人与模型对话场景下的性能和单向交流诉求，SSE刚好契合。
   • 在人机交互的场景中采用的是对话式的方式，并不是严格意义的实时双向交互过程，所以SSE的单向输出刚好契合。把交流文本当作数据流，打断输出作为控制流来看，数据流的交互是单向的，控制流是简单系统，可以使用HTTP请求作为补充（OpenAI的实现）。
   • 由于目前人机交互的实现技术仍然是一个中心式服务器提供服务，对并发有较高的要求，SSE相比于Websocket有比较明显的性能提升。
3. 流式输出增强了人机交互的自然感和参与感。
   • 流式输出很好的模拟了人与人之间的交流方式，使得交流更自然。
   • 由于大模型的推理速度比较慢，加之 DeepSeek 爆火之后模型呈现出短输入长输出的特点，流式输出可以极大的降低结果获得延迟，优化使用体验。
   • 流式输出可以随时打断，方便使用者在发现大模型思路不对时及时打断并纠正。