SSE(Server-Sent Events)实现渐进式结果返回

般若之镜

1150人浏览 · 2026-01-05 09:29:13

般若之镜 · 2026-01-05 09:29:13 发布

SSE 实现渐进式结果返回：让 AI 的思考过程“看得见”

在构建现代智能应用时，我们常常面临一个矛盾：用户希望立刻看到反馈，而复杂的推理任务却需要时间。尤其是在使用大语言模型解决数学题、编写算法或进行逻辑推导时，传统“输入—等待—输出”的模式显得尤为笨拙。用户盯着空白页面数秒甚至十几秒，极易产生系统卡顿的错觉。

有没有一种方式，能让模型一边算，一边说？答案是肯定的——Server-Sent Events（SSE） 正是实现这一目标的关键技术。

不同于 WebSocket 那样复杂的双向通信，SSE 以极简的方式实现了服务器向客户端的持续数据推送。它基于 HTTP 协议，天然兼容现有基础设施，无需额外握手或维护长连接状态，特别适合用于展示 AI 模型逐步推理的过程。当我们将这种流式传输机制与像 VibeThinker-1.5B-APP 这类专精于数学与算法推理的小参数高性能模型结合时，便能构建出一种全新的交互体验：让用户实时“看见”模型的思考路径。

为什么选择 SSE？

要理解 SSE 的价值，不妨先看看其他方案的局限性。

轮询是最原始的做法：客户端每隔几秒发一次请求，询问“好了吗？”这种方式不仅延迟高，还浪费大量带宽和服务器资源。想象一下，如果每个用户每秒发起一次请求来检查一个耗时 8 秒的推理任务，平均每个任务就要触发 8 次无效查询。

WebSocket 虽然支持全双工通信，但其协议复杂、实现成本高，且多数 AI 推理场景并不需要客户端频繁回传消息。对于只需要“服务器讲，客户端听”的场景来说，WebSocket 显得有些“杀鸡用牛刀”。

而 SSE 刚好填补了这个空白：

它是单向的，仅由服务器向浏览器推送；
基于标准 HTTP，可穿越大多数防火墙和代理；
浏览器原生支持 EventSource API，前端几乎零配置；
支持自动重连、事件标识、消息 ID 等实用功能；
最关键的是，它可以利用 HTTP/1.1 的分块传输编码（chunked encoding），做到边生成边发送。

这意味着，只要后端开始输出第一个 token，前端就能立即收到并渲染，真正实现“低延迟感知响应”。

协议细节：简单却不简陋

SSE 的消息格式非常直观。每条消息由若干字段组成，以 \n\n 结尾。最常见的就是 data: 字段：

data: 正在解析问题...\n\n
data: 构建递归关系式中...\n\n

你也可以添加事件类型：

event: thinking
data: 尝试动态规划优化\n\n

或者设置重连间隔：

retry: 5000
data: 连接恢复，继续推理\n\n

浏览器会自动解析这些内容，并根据事件类型触发不同的处理函数。整个过程对开发者透明，调试也极为方便——打开 Chrome 开发者工具的 Network 标签页，直接查看响应体即可看到实时流动的数据流。

如何用 FastAPI 实现 SSE 流式输出？

在实际工程中，Python 生态中的 FastAPI 是实现 SSE 推送的理想选择。它内置了对异步生成器的支持，配合 StreamingResponse，可以轻松将模型推理的中间结果逐段返回。

以下是一个模拟 VibeThinker-1.5B-APP 推理过程的示例：

from fastapi import FastAPI, Request, HTTPException
from fastapi.responses import StreamingResponse
import asyncio

app = FastAPI()

async def generate_reasoning_stream(prompt: str):
    steps = [
        "正在解析问题...",
        "识别关键变量与约束条件",
        "构建递归关系式",
        "尝试动态规划优化",
        "验证边界情况",
        "得出最终解：f(n) = O(n log n)"
    ]

    for step in steps:
        await asyncio.sleep(0.8)  # 模拟模型处理延迟
        yield f"data: {step}\n\n"

@app.get("/reason")
async def reasoning_endpoint(request: Request):
    prompt = request.query_params.get("q")
    if not prompt:
        raise HTTPException(status_code=400, detail="缺少查询参数 'q'")

    return StreamingResponse(
        generate_reasoning_stream(prompt),
        media_type="text/event-stream"
    )

这里的关键在于 yield 和 StreamingResponse 的配合。每当模型完成一步推理，就通过 yield 发送一条符合 SSE 规范的消息。FastAPI 会将其封装为 chunked response，逐步写入 TCP 缓冲区，最终送达浏览器。

值得注意的是，media_type="text/event-stream" 是必须的，否则客户端不会按事件流解析。此外，建议关闭某些中间件（如 Gzip 压缩），因为压缩会缓冲全部内容，破坏“边生成边发送”的效果。

前端如何接收并展示流式结果？

前端实现反而更简单。得益于浏览器原生支持，只需几行 JavaScript 即可建立 SSE 连接：

<script>
const eventSource = new EventSource("/reason?q=solve+recurrence+relation");

eventSource.onmessage = function(event) {
    const outputDiv = document.getElementById("output");
    const newLine = document.createElement("p");
    newLine.textContent = "🧠 " + event.data;
    outputDiv.appendChild(newLine);
};

eventSource.onerror = function(err) {
    console.error("SSE连接出错:", err);
    eventSource.close();
};
</script>

<div id="output"></div>

EventSource 会自动处理连接建立、断线重连（默认约3秒重试）、以及消息解析。每次服务器发送一条 data: 消息，都会触发 onmessage 回调。你可以在这里做进一步处理，比如高亮关键词、插入代码块、甚至播放提示音。

当然，也要考虑降级策略。IE 全系列不支持 EventSource，此时可以切换为长轮询或引入 polyfill 库。生产环境中建议检测环境后动态选择通信方式。

VibeThinker-1.5B-APP：小模型为何适合流式输出？

提到渐进式返回，很多人第一反应是：“这不是所有 LLM 都能做到吗？”确实，大多数语言模型都是自回归生成的，即逐 token 输出。但并非所有模型都适合流式展示。

VibeThinker-1.5B-APP 的独特之处在于它的设计定位：专精而非通用。

这款仅 15 亿参数的模型，训练成本控制在 7800 美元以内，却在多个专业基准上超越更大规模的通用模型。例如：

基准测试	得分	对比对象
AIME24	80.3	超过 DeepSeek R1（79.8）
HMMT25	50.4	显著优于同体量模型
LiveCodeBench v6	51.1	略高于 Magistral Medium（50.3）

它的成功源于高度定向的训练策略：

数据集中于数学证明、编程题、形式化逻辑等结构化任务；
引入思维链（Chain-of-Thought）标注，强化多步推理能力；
使用强化学习微调，提升解题成功率。

更重要的是，它的推理过程具有明显的阶段性。不像通用模型那样“想到哪说到哪”，VibeThinker 会按照“分析→建模→验证→总结”的逻辑链条有序输出。这使得它的中间结果本身就具备语义完整性，非常适合通过 SSE 分段呈现。

举个例子，面对一道动态规划题目，它可能依次输出：
1. “定义状态 dp[i][w] 表示前 i 个物品在容量 w 下的最大价值”
2. “状态转移方程为 dp[i][w] = max(dp[i-1][w], dp[i-1][w-weight[i]] + value[i])”
3. “初始化边界：dp[0][*] = 0”
4. “最终答案为 dp[n][W]”

每一句话都是独立有效的知识单元，用户即使未等到结尾，也能获得实质性帮助。

实际部署中的关键考量

尽管 SSE 实现简单，但在真实系统中仍需注意几个关键点。

1. 反向代理超时设置

Nginx、Apache 或云网关通常会对连接设置读取超时（如 60 秒）。若推理时间较长，连接可能被强制中断。解决方案是在配置中延长超时：

location /reason {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    proxy_buffering off;

    # 关键：延长读取超时
    proxy_read_timeout 300s;
}

同时确保 proxy_buffering off，防止代理缓存整个响应。