流式输出完整原理｜SSE/WebSocket 大模型对话落地、卡顿调优全指南

步步糕升

导语

       打开 AI 聊天网页看到文字逐字弹出的打字机效果，底层技术就是流式输出。很多开发者分不清 SSE 与 WebSocket 适用场景，部署 vLLM 流式对话时频繁出现卡顿、断连、首 Token 延迟（TTFT）过高、Nginx 缓冲吞字等线上故障。本期从大模型自回归生成底层逻辑出发，拆解流式输出完整链路，对比 SSE、WebSocket、HTTP 分块传输三大通信方案，梳理 TTFT、TPOT 两大核心体验指标，给出反向代理、推理引擎、前端三层标准化优化方案，解决长对话断流、打字卡顿、响应慢等问题。

一、流式输出底层本质：模型天生逐 Token 生成

生活化类比

• 非阻塞一次性返回（传统接口）：厨师做完一整桌菜再全部端上桌，用户长时间空白加载；
• 流式输出：开放式厨房，做好一道菜立刻送上，用户几秒就能看到首段文字，等待感知大幅降低。
  

核心底层逻辑：大模型采用自回归生成机制，无法一次性输出完整文本。每一步只能基于现有上下文预测下一个 Token，天然是分段产出，流式输出只是把每一段生成结果实时推送给前端，而非等全文生成完毕再统一返回。关键区分：打字效果不是前端动画模拟，是模型真实分步推理的实时数据流。
两个核心行业性能指标

• TTFT（Time To First Token 首 Token 延迟）用户发送提问到前端收到第一个字符的耗时，是用户感知体验核心指标，行业优秀标准≤300ms；影响因素：Prompt 长度、GPU 排队、网络缓冲、网关超时。
• TPOT（Time Per Output Token 单 Token 生成间隔）每新增一个字的平均耗时，决定打字流畅度，数值越小越顺滑。
  

二、流式输出完整端到端链路

一套标准 LLM 网页对话分为五层流转：

• 前端层：浏览器 / APP 发起流式请求，监听数据流，增量追加渲染文本，不刷新页面；
• 反向代理层（Nginx/CLB）：转发长连接，必须关闭缓冲区，否则会积攒数据批量下发造成卡顿；
• AI 网关（FastAPI/LiteLLM）：封装模型接口，统一格式化 SSE/WebSocket 分片；
• 推理引擎（vLLM/Ollama）：执行 Prefill 预填充、Decode 逐 Token 生成，实时产出文本分片；
• 底层模型 Transformer：注意力计算，逐个输出 token 序列。
  

数据流规则：模型每生成少量 Token 打包为一个 Chunk 分片，立即通过长连接推送，不等待完整回答。区分概念：Token 是模型最小计算单位；Chunk 是网络传输最小数据包，一个 Chunk 可包含多个 Token。
三、三大主流流式传输方案对比

1 SSE（Server-Sent Events 服务器推送事件）

核心特性

基于标准 HTTP GET 长连接，单向通信（服务端→客户端），前端仅接收 AI 回答，无需频繁双向交互；响应头固定标识Content-Type: text/event-stream，数据以data:开头、\n\n换行分割，结束发送[DONE]标志。标准 SSE 数据流示例：

1. data: {"delta":{"content":"今"}}
   
2. 
   
3. data: {"delta":{"content":"天"}}
   
4. 
   
5. data: [DONE]
   

复制代码

优势

• 原生浏览器EventSource支持，无需额外前端 SDK；
• 防火墙、CDN 兼容性极强，不用升级 WebSocket 协议；
• 内置断线自动重连、消息 ID 断点续传；
• 后端开发成本低，FastAPI 直接通过yield生成分片。
  

短板

仅支持服务端单向推送，前端无法在流式中途发送新指令、终止对话。
适用场景

网页标准 AI 客服、知识库问答、纯文本对话（90% 静态 AI 官网首选）。
2 WebSocket 双向长连接

核心特性

TCP 全双工双向通道，客户端、服务端可随时互发消息；连接建立后协议升级脱离普通 HTTP，以二进制 / 文本帧传输数据。
优势

• 对话中途可发送停止生成、追问、修改指令；
• 极低帧开销，高并发实时语音、数字人场景表现更好；
• 支持复杂多端交互（多人协作 AI 助手）。
  

短板

• 部分 CDN、老旧网关对 WebSocket 兼容性差；
• 前端需手动实现重连、心跳保活逻辑；
• 无原生标准化分片格式，需自行封装 JSON。
  

适用场景

AI 数字人实时语音、多轮交互式编辑器、可中途打断对话的专业工具。
3 HTTP Chunked 分块传输（底层基础）

HTTP1.1 原生机制，不限制响应总长度，服务端分块写入响应流；SSE 本质基于 Chunked 封装专用事件格式，裸 Chunked 极少直接用于对话，多用于大文件实时下载。
SSE vs WebSocket 选型对照表

对比维度	SSE	WebSocket
通信方向	单向（服务推前端）	全双工双向互通
底层协议	HTTP GET，无需协议升级	HTTP 握手后升级 TCP 帧
浏览器原生能力	EventSource 自动重连	需手动心跳保活
部署兼容性	CDN / 防火墙友好	部分运营商网关拦截
典型业务	网页纯文本问答	语音 / 数字人 / 可打断对话
开发成本	低，后端 yield 分片	高，需封装双向消息

四、Nginx 反向代理流式必配生产配置

绝大多数打字卡顿、整段弹出问题根源是 Nginx 开启缓冲区，积攒大量分片再一次性下发，核心配置必须关闭缓冲、延长超时：

1. location /v1/chat/stream {
   
2.     proxy_pass http://127.0.0.1:8000;
   
3.     proxy_http_version 1.1;
   
4.     proxy_set_header Connection "";
   
5.     # 核心：关闭代理缓冲，实时下发分片
   
6.     proxy_buffering off;
   
7.     proxy_cache off;
   
8.     # 长对话超时设5分钟以上
   
9.     proxy_read_timeout 360s;
   
10.     proxy_send_timeout 360s;
    
11.     # 关闭Nginx内部缓冲池
    
12.     X-Accel-Buffering: no;
    
13. }
    

复制代码

关键说明：不关闭proxy_buffering时，Nginx 会缓存多条 chunk，用户看到的不是逐字弹出，而是几秒整段刷新。
五、vLLM 推理引擎流式专属优化

vLLM 是商用流式对话主流推理后端，配套优化直接降低 TTFT、减少断流：

• 开启连续批处理（Continuous Batching）新用户请求不阻塞已有会话的 Token 生成，GPU 利用率稳定 90% 以上，避免对话卡顿排队；
• 前缀 KV 缓存复用统一系统提示词只计算一次 KV 向量，大幅缩短首 Token TTFT；
• 合理配置批参数
  

1. --max_num_batched_tokens 8192
   
2. --gpu_memory_utilization 0.75
   

复制代码

限制单次批处理上限，防止长上下文挤占新会话算力；4. 分片输出阈值每生成 2~4 个 Token 立即打包 Chunk 推送，不要攒长文本，保证打字顺滑。

六、线上流式输出四大高频故障与解决方案

故障 1：对话不逐字，几秒整段弹出

根因 Nginx/CDN 开启响应缓冲；修复：全局关闭proxy_buffering，配置X-Accel-Buffering: no。
故障 2 长对话几十秒自动断连

根因反向代理默认 60 秒读取超时；修复 Nginx 延长proxy_read_timeout至 300s 以上，服务端添加心跳分片（空 data 消息）保活连接。
故障 3 TTFT 首 Token 延迟超过 1 秒

根因 Prompt 过长、GPU 并发排队、未开启前缀 KV 缓存；优化：精简系统提示、会话摘要压缩历史、vLLM 开启 Prefix Cache、扩容推理节点负载均衡。
故障 4 流式中途报错，半截回答消失

根因异常分片无统一 error 事件；规范：推理异常时单独推送event: error分片，前端保留已渲染文本，仅提示后半段生成失败。

七、前端流式渲染规范（顺滑打字关键）

• 增量追加 DOM，不整体重绘对话气泡，防止页面闪烁；
• 节流合并微小分片，单帧合并 2~3 个 Token，避免高频 DOM 操作卡顿；
• 兼容未闭合 Markdown 代码块、表格，临时渲染纯文本，完整生成后再格式化；
• 监听连接断开，自动触发重连逻辑，缓存已有对话上下文。
  

八、新手高频认知误区澄清

误区 1 流式输出是前端 JS 动画模拟打字

纠正：是模型实时逐 Token 推理的真实数据流，前端仅负责增量渲染。
误区 2 所有 AI 对话都用 WebSocket 更好

纠正纯网页文本问答 SSE 开发成本更低、兼容性更强，无需双向交互无需 WebSocket。
误区 3 不加长超时也能跑长对话

纠正 Nginx 默认 60 秒超时，超过一分钟无新分片直接切断连接。
误区 4 一次性生成短 Prompt 不需要流式

纠正开启流式可显著降低用户等待焦虑，哪怕简短回答也推荐 stream 模式。
误区 5 缓冲开大能降低网络开销

纠正缓冲会破坏实时打字体验，流式场景必须完全关闭。

九、本期全文总结

• 流式输出依托大模型自回归逐 Token 生成特性，实时推送推理分片，核心指标 TTFT 决定用户等待感知；
• SSE 单向长连接适合网页纯文本问答，WebSocket 适配语音、可打断交互式 AI；
• Nginx 反向代理必须关闭缓冲、延长超时，否则出现整段弹出、对话断连；
• vLLM 通过连续批处理、前缀 KV 缓存优化流式并发与首字符延迟；
• 完整链路优化三层：Nginx 网关、推理引擎、前端增量渲染；
• 流式核心价值不是缩短总生成时间，而是消除空白加载，大幅提升交互体验。