大模型流式网关：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 只是传输方式，不是架构本身。把流式能力做成稳定网关，后续业务接入模型才会更可控。