大模型流式输出与 SSE 推送：Spring Boot 中的实时响应架构设计

一、等待焦虑与超时风险：大模型实时响应的工程困境

大模型推理的延迟通常在数秒到数十秒之间，传统 HTTP 请求-响应模式下，客户端必须等待模型完成全部生成后才能收到响应。这种"黑盒等待"带来三个核心问题：其一，用户面对长时间白屏，体验极差，对话类场景的容忍阈值通常在 3 秒以内；其二，网关和负载均衡器的超时配置通常为 30-60 秒，长文本生成极易触发超时断连；其三，服务端在生成期间持有连接资源，高并发下线程池和连接池压力巨大。

流式输出（Streaming）是解决上述问题的标准方案——模型每生成一个 Token 就立即推送给客户端，用户看到"逐字打印"的效果。但流式输出在工程实现上并非简单的"边生成边返回"，它涉及 SSE 协议适配、背压控制、异常恢复和资源回收等一系列问题。

二、SSE 协议与流式推理架构：从模型输出到客户端渲染

Server-Sent Events（SSE）是基于 HTTP 的单向推送协议，与 WebSocket 相比更轻量，天然适配大模型的"服务端生成、客户端消费"模式。Spring Boot 中通过 SseEmitter 或 WebFlux 的 Flux<ServerSentEvent> 实现流式推送。

sequenceDiagram
    participant C as 客户端
    participant G as Spring Gateway
    participant S as LLM Service
    participant M as 大模型 API

    C->>G: POST /chat/stream (SSE)
    G->>S: 转发请求
    S->>M: 发起流式调用
    loop Token 生成循环
        M-->>S: Token Chunk
        S-->>G: SSE: data: {token}
        G-->>C: SSE: data: {token}
    end
    M-->>S: [DONE] 信号
    S-->>G: SSE: data: [DONE]
    G-->>C: SSE: data: [DONE]
    C->>C: 关闭 EventSource

关键设计点在于"流式透传"——中间层不应缓冲完整响应再转发，而应逐 Chunk 推送。Spring WebFlux 的响应式模型天然支持这种模式，而传统 Servlet 模型需要借助异步 Servlet 或 SseEmitter 实现。

三、生产级代码实现：流式调用、背压控制与异常恢复

3.1 基于 WebFlux 的流式调用

@Service
public class StreamingLlmService {

    private final WebClient llmClient;
    private final TokenMeter tokenMeter;

    // 构造器注入，省略

    public Flux<ServerSentEvent<ChatChunk>> streamChat(ChatRequest request) {
        return llmClient.post()
            .uri("/v1/chat/completions")
            .bodyValue(buildStreamRequest(request))
            .retrieve()
            .bodyToFlux(String.class)
            .takeUntil(data -> "[DONE]".equals(data))
            .map(this::parseChunk)
            .map(chunk -> ServerSentEvent.<ChatChunk>builder()
                .data(chunk)
                .build())
            // 背压控制：限制内存中缓冲的 Token 数
            .onBackpressureBuffer(64,
                () -> log.warn("背压缓冲区溢出，丢弃最旧数据"),
                BufferOverflowStrategy.DROP_OLDEST)
            .doOnNext(chunk -> {
                if (chunk.data() != null) {
                    tokenMeter.record(chunk.data().getTokens());
                }
            })
            .doOnError(e -> log.error("流式调用异常: {}", e.getMessage()))
            .doFinally(signal -> log.info("流结束: signal={}", signal));
    }
}

3.2 Servlet 模式下的 SseEmitter 方案

@RestController
@RequestMapping("/api/chat")
public class ChatStreamController {

    private final StreamingLlmService llmService;

    @GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public SseEmitter streamChat(@RequestParam String message) {
        // 超时设置为 5 分钟，覆盖长文本生成场景
        SseEmitter emitter = new SseEmitter(300_000L);

        llmService.streamChat(new ChatRequest(message))
            .subscribe(
                event -> {
                    try {
                        emitter.send(event);
                    } catch (IOException e) {
                        // 客户端断连，取消上游订阅
                        emitter.completeWithError(e);
                    }
                },
                emitter::completeWithError,
                emitter::complete
            );

        // 客户端主动断连时的清理逻辑
        emitter.onCompletion(() -> log.info("SSE 连接正常关闭"));
        emitter.onTimeout(() -> {
            log.warn("SSE 连接超时");
            emitter.complete();
        });

        return emitter;
    }
}

3.3 异常恢复与重试

public Flux<ServerSentEvent<ChatChunk>> streamWithRetry(ChatRequest request) {
    return llmService.streamChat(request)
        // 单个 Chunk 解析失败不中断整个流
        .onErrorResume(ParseException.class, e -> {
            log.warn("Chunk 解析失败，跳过: {}", e.getMessage());
            return Flux.empty();
        })
        // 上游连接断开时，携带上下文重试
        .retryWhen(Retry.backoff(3, Duration.ofSeconds(1))
            .filter(e -> e instanceof WebClientException)
            .doBeforeRetry(signal -> log.info(
                "流式重试: attempt={}", signal.totalRetries()))
        );
}

四、流式架构的隐性代价：背压、一致性与资源回收

背压控制的精度权衡：onBackpressureBuffer 的缓冲区大小直接影响内存占用和延迟。缓冲区过小（如 16）会导致频繁丢数据，客户端看到的文本出现跳跃；缓冲区过大（如 1024）则在高并发场景下内存压力显著。生产环境建议根据下游消费速度动态调整，或采用 onBackpressureDrop 策略配合客户端重连补全。

SSE 的断连恢复局限：SSE 协议本身不支持断点续传。一旦网络中断，客户端只能重新发起请求，而大模型无法从断点继续生成。工程上可以通过"已生成文本回放"策略缓解——客户端重连时携带已接收的 Token 列表，服务端将其作为上下文前缀重新发起调用。但这会增加 Token 消耗和重复计算成本。

Servlet 模式的线程占用：SseEmitter 虽然是异步的，但在 Tomcat 默认配置下仍占用一个 Servlet 线程。当并发流式连接数超过线程池容量时，新请求会被拒绝。WebFlux 基于事件循环模型，单线程可处理数千并发连接，是流式场景的首选方案。

Token 计量的精度问题：流式场景下，Token 计量需要逐 Chunk 累加，而非一次性获取。部分大模型 API 在流式响应中不返回 Token 使用量，只能在流结束后通过单独的 API 查询，增加了计量延迟和一致性风险。

五、总结

大模型流式输出将"等待完整响应"转化为"逐 Token 推送"，本质上是将服务端的生成延迟分散到客户端的渐进渲染中。本文方案的核心链路为：WebFlux 流式调用 → 背压控制 → SSE 推送 → 异常恢复。落地时需重点关注三个参数：SseEmitter 超时时间（建议 5 分钟起）、背压缓冲区大小（建议 64-128）、重试次数（建议 3 次）。推荐优先采用 WebFlux 方案，Servlet 模式仅用于无法升级的技术栈。上线前务必进行断连恢复的混沌测试，验证客户端重连和服务端资源回收的可靠性。