大模型流式网关：Java 后端别把 SSE 当简单转发

一、流式响应不是把模型输出原样吐给前端

大模型接入企业后端时，流式输出常用 SSE 或 WebSocket。很多团队第一版会直接把模型供应商的流式结果转发给前端，看起来很快能跑通。但生产环境里，流式网关要处理鉴权、限流、审计、取消、超时、异常收口和成本统计，绝不是简单转发。

一旦前端断开连接，后端是否取消模型请求？用户刷新页面后，任务状态怎么记录？模型中途报错，前端看到的是半段文本还是明确错误？这些问题如果不在网关层设计，后续每个业务接口都会重复踩坑。

二、流式网关要把模型事件标准化

不同模型供应商的事件格式、错误码和结束标记都不一样。业务层不应该直接依赖供应商协议。

flowchart TD
  A[前端请求] --> B[Java 流式网关]
  B --> C[鉴权与限流]
  C --> D[模型供应商适配器]
  D --> E[标准化事件]
  E --> F[SSE 输出]
  E --> G[审计与成本记录]

网关要把 token、message、tool_call、error、done 等事件统一成内部协议。以后替换模型或接入多供应商，业务代码才不会被供应商细节绑死。

三、接口契约要包含取消和超时

下面是一个简化的事件结构。

public record ModelStreamEvent(
    String requestId,
    String type,
    String content,
    boolean terminal,
    String errorCode
) {}

terminal 标记很重要。前端不能靠连接关闭判断任务完成，因为连接关闭可能是网络中断，也可能是网关超时。明确结束事件能让前端状态机更可靠。

四、流式链路要能审计和补偿

流式响应中途失败时，要记录已经输出到哪里、模型调用是否取消、是否计费、用户是否需要重试。没有这些记录，客服和排障都会很痛苦。

还要处理背压。前端消费慢、网络抖动或浏览器暂停标签页时，后端不能无限缓存模型输出。可以设置发送缓冲上限，超过后取消下游请求并返回明确错误。

模型输出也要做内容边界处理。流式输出可能先吐出部分不合规内容，再在后面修正。网关如果要做安全过滤，就不能只在最终文本完成后检查。至少要有分段检测和终止能力。

最后，流式网关要统计首 token 延迟、总耗时、输出 token 数、取消率和错误类型。流式体验的核心不只是总耗时，首 token 延迟往往更影响用户感受。

还要处理重试边界。普通 HTTP 接口失败后可以重试，流式生成已经输出了一半内容时，重试就可能造成重复文本或语义断裂。网关可以把“请求未开始”“已收到首 token”“已结束”分成不同状态，只允许在安全状态自动重试。

企业场景里还要考虑租户隔离。不同租户的并发、速率、模型配额和审计保留周期可能不同。流式连接占用时间长，如果不按租户限流，一个大客户的长连接就可能挤占其他业务的可用连接。

最后，前后端协议要约定心跳。模型长时间没有 token 输出时，网关应该发送轻量心跳，避免代理、浏览器或负载均衡误判连接空闲。心跳不是业务内容，但能显著提升长响应链路的稳定性。

网关还要统一错误分层。供应商超时、用户取消、内容拦截、账户额度不足、网关内部异常，应该有不同错误码。前端可以据此展示继续等待、重新生成、联系管理员或稍后重试。错误都写成“生成失败”，只会把复杂度推给用户。

五、总结

Java 大模型流式网关要承担协议标准化、鉴权限流、取消超时、审计成本和异常收口。SSE 只是传输方式，不是架构本身。把流式能力做成稳定网关，后续业务接入模型才会更可控。