传统请求的困境与流式输出的诞生

一、传统请求的困境与流式输出的诞生

在与大语言模型（如 MiMo）交互时，用户输入一个问题，模型需要生成一段可能相当长的文本作为回答。在传统的 HTTP 请求-响应模型中，客户端发送请求后，必须耐心等待服务器完成整个回答的生成，然后才能一次性收到完整的响应。这个过程存在两个明显问题：等待时间过长，用户体验差；用户无法在生成过程中进行干预或提前获取部分结果。

流式输出（Streaming） 应运而生。它就像打开一个水龙头：客户端发送请求后，服务器不是等水接满一桶再给你，而是立刻开始滴水，并且水流持续不断。具体到 AI 对话场景，服务器每生成一小段文本（可能是一个词、一个句子），就立即将其“推送”给客户端。客户端可以边接收边显示，实现 “打字机”效果，极大提升了交互的实时感和流畅度。

二、SSE 协议：流式输出的理想载体

要实现流式传输，需要一个应用层协议来支持服务器向客户端单向、持续地发送事件。SSE（Server-Sent Events） 就是专为此设计的 W3C 标准。它基于 HTTP，但并非传统的请求-响应循环。客户端通过一个普通的 HTTP 请求声明自己接收 text/event-stream，随后服务器便保持这个 HTTP 连接打开，并可以多次发送数据块。

每个数据块遵循一个非常简单的文本格式，主要包含两个字段：

data: 传输的实际数据，比如一段模型生成的文本。
event: 可选的事件类型标识，客户端可以据此监听不同类型的事件。

一个典型的 SSE 消息格式如下：

id: 1
event: message
data: 你好
data: ，我是MiMo。

提示：SSE 与 WebSocket 的核心区别在于通信方向。SSE 是单向的（服务器到客户端），非常适合服务器主动推送信息的场景；WebSocket 是全双工的，适用于需要实时双向通信（如在线游戏、协同编辑）的场景。对于大模型输出，SSE 通常更轻量、更易实现。

三、为何大模型流式输出青睐 SSE？

将 MiMo 等大模型的流式输出与 SSE 结合，是一种非常经典且高效的架构选择。这主要归功于 SSE 协议的几个天然优势：

首先，基于 HTTP/HTTPS。这意味着它能轻松穿透绝大多数网络防火墙和代理服务器，无需特殊配置。前端开发者可以使用浏览器原生的 EventSource API 或任何支持 HTTP 的库来接收数据，接入成本极低。

其次，协议简单，资源友好。相比 WebSocket 需要额外的握手升级，SSE 连接就是一个保持打开的 HTTP 连接，协议头更小。服务器端实现也简单，只需在生成 token 的间隙，按照 SSE 格式将数据写入响应流即可。这对于需要长时间维持连接的流式 API 来说，降低了服务器的负担。

最后，自带重连与事件机制。EventSource API 内置了自动重连逻辑（当连接意外断开时）。同时，通过 event 字段，我们可以区分普通文本、状态码、错误信息等不同类型的事件，使控制流更加清晰。

四、实践：使用 Python 模拟 MiMo 流式 SSE 服务

下面我们用 Python 的 Flask 框架，模拟一个最简单的、具备流式输出能力的 MiMo API 服务端。这个例子会展示如何将文本逐步“流”出去。

from flask import Flask, Response
import time

app = Flask(__name__)

def generate_mimo_response(question):
    # 模拟 MiMo 模型生成回答的过程
    response_chunks = [
        "我是",
        "小米的",
        "智能助手",
        "MiMo，",
        "很高兴",
        "为您服务！",
        "请问",
        "有什么",
        "可以",
        "帮您？"
    ]
    for chunk in response_chunks:
        # 按照 SSE 格式包装每个文本块
        yield f"data: {chunk}\n\n"
        time.sleep(0.5)  # 模拟模型思考/生成的时间

@app.route('/chat', methods=['GET'])
def chat():
    # 创建流式响应，MIME 类型为 text/event-stream
    return Response(
        generate_mimo_response("你好"),
        mimetype='text/event-stream'
    )

if __name__ == '__main__':
    app.run(debug=True, port=5000)

代码解读：关键在 generate_mimo_response 这个生成器函数。它每次 yield 一个符合 SSE 格式的字符串（data: ...\n\n）。Flask 的 Response 接收这个生成器，保持连接打开，数据块会随着时间推移依次发送到客户端。客户端会看到类似“我是”、“小米的”、“智能助手”… 逐词出现的效果。

五、客户端接收与事件处理

在前端（Web）侧，使用 JavaScript 的 EventSource 对象可以轻松对接上述服务。

const eventSource = new EventSource('http://localhost:5000/chat');

// 监听默认的 message 事件（即没有 event 字段，或 event 为 message 的消息）
eventSource.onmessage = function(event) {
    const data = event.data;
    console.log('收到文本块:', data);
    // 将 data 追加到页面的显示区域，实现流式渲染
    document.getElementById('response').innerHTML += data;
};

// 连接建立时触发
eventSource.onopen = function() {
    console.log('SSE连接已建立');
};

// 发生错误时触发（包含自动重连逻辑）
eventSource.onerror = function(err) {
    console.error('EventSource 错误:', err);
    // 根据 readyState 判断是否在重连
    if (eventSource.readyState === EventSource.CLOSED) {
        console.log('连接已关闭，将尝试重连...');
    }
};

客户端通过监听 message 事件，就能实时接收到来自服务器的文本片段并拼接显示，整个过程用户感知到的就是流畅的“输出”。

六、关键点与最佳实践

在实际的 MiMo 或类似大模型 API 中，流式 SSE 还需要注意以下几点，这些细节关乎系统的健壮性和用户体验：

事件标识与控制：服务器通常会定义不同的 event 类型。例如，event: data 携带文本内容，event: done 表示生成结束，event: error 传递错误信息。客户端应分别监听这些事件类型。
保持活动心跳：如果模型思考时间较长，可能会导致中间无数据发送，从而触发中间网络设备（如负载均衡器）断开空闲连接。服务器需要定时发送一个“心跳”包（例如：: ping\n\n，这是一个 SSE 注释，不会被客户端分发），以维持连接活跃。
状态与上下文管理：流式连接是无状态的，但大模型对话通常是多轮的。需要在客户端或通过额外的请求头（如 Session-ID）来维护会话上下文，将历史消息一并传给服务器，以确保模型能进行连贯的对话。

核心思想：流式输出不仅仅是技术实现，更是一种以用户为中心的设计。通过 SSE 协议，我们将大模型复杂的生成过程，转化为用户可感知、可期待的实时反馈，这极大地优化了人机交互的体验。