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

大模型流式输出与 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 模式仅用于无法升级的技术栈。上线前务必进行断连恢复的混沌测试，验证客户端重连和服务端资源回收的可靠性。