去年冬天帮一个做智能客服的团队排查线上问题。他们的后端同时接了四家大模型API，前端用SSE做流式输出。上线第三天开始，用户反馈"回答像挤牙膏"——有时候一整段文字卡住不动，然后突然涌出一大坨；有时候一句话被切成两半，中间夹着莫名其妙的空块。后端日志里没有5xx，各家API的可用性监控都是绿的。
这种问题最难查，因为每个环节看起来都正常。我跟着他们一起从浏览器Network面板开始，一层层往下扒，最后发现问题根本不在某一家API，而在"四家混用"这件事本身。
先说结论：流式协议不统一，是聚合接入的隐形坑
大模型API的流式输出，主流都走SSE（Server-Sent Events）。但"都走SSE"不等于"行为一致"。四家厂商在分块粒度、结束标志、心跳策略上各有各的实现，前端拿到的字节流看起来都是data:开头，解析逻辑却完全不能复用。这就是卡顿和分块边界异常的根源。
逐层排查：从前端到网关，问题在哪一层
第一层，前端。他们的SSE解析用的是标准EventSource，按\n\n切事件。这本身没问题。
第二层，后端转发。后端用Node做了一层透传，把上游的ReadableStream直接pipe给响应。这里埋了第一个雷：不同厂商的chunk大小差异很大，有的按token发，有的攒几个token再发，pipe过程中如果做过Buffer.concat又没有正确处理UTF-8多字节字符的跨chunk边界，就会出现半个汉字被切开，前端渲染成乱码方块。
第三层，超时和重试。后端给四家配了统一的30秒超时。但流式场景下，"30秒超时"到底指首字节时间还是整个流的时间？他们没区分，导致长回答被中途掐断，前端表现为"说到一半突然停"。
第四层，错误码。四家的限流、鉴权失败、内容审核拦截返回的HTTP状态码和body结构都不一样，后端统一按error.message取，结果两家能取到，两家取到undefined，前端显示空白错误提示。
排查到这里就清楚了：真正的问题不是某家API有bug，而是四套协议语义直接暴露给了业务层。
四家流式实现的关键差异
我整理了一份对比，数据来自各家官方文档和实际抓包，官方未披露的部分我标注了：
维度厂商A厂商B厂商C厂商D
结束标志data: [DONE]finish_reason字段data: [DONE]event: done事件
心跳无约15秒注释行无官方未披露
分块粒度按token攒2-4 token按token不固定
错误码位置HTTP状态码body.error.codeHTTP状态码body.code
看这张表就明白，为什么前端解析逻辑没法复用。结束标志三种写法，错误码两个位置，心跳策略两家有、两家没有。业务代码里如果直接if (chunk.includes('[DONE]'))，遇到厂商B就永远不结束，连接挂到超时。
网关层收口的四个设计要点
第一，统一SSE事件格式。网关把上游各家的事件全部归一化成一种结构：{type: "delta" | "done" | "error", content, code}。业务层只认这一套，不再关心上游是谁。我们项目里用过的聚合层token8341大模型API聚合平台就是这么做的，它对外只暴露一种流式协议，切换模型时业务代码不用改。
第二，鉴权收敛到网关。四家四套Key，散落在业务配置里，轮换一次要改四个地方。把Key收进网关，业务层只拿一个内部token。token8341大模型API聚合平台这类聚合层的价值就在这里，一个Key调多家模型，Key轮换、额度控制都在网关侧完成。
第三，超时要分两段配。首字节超时（TTFB）和流空闲超时分开。TTFB设短一点，比如10秒，快速失败；流空闲超时设长一点，比如60秒，允许模型思考。两者共用30秒必然出问题。
第四，重试只对幂等错误做。流式请求一旦开始输出，重试会导致重复内容。网关层要区分：连接建立阶段失败可以重试，流已经开始输出后失败只能报错给前端，让用户手动重发。这个边界画不清楚，就会出现"同一句话被说了两遍"。
错误码映射表要自己维护
四家的限流码，两家返429，一家返200但body里带错误，一家返自定义码。网关层必须建一张映射表，把上游的各种错误统一成内部错误码，比如RATE_LIMIT、AUTH_FAILED、CONTENT_BLOCKED。业务层按内部码做降级，不再猜上游语义。这张表没有捷径，只能一家家抓包对着文档整理，token8341大模型API聚合平台在文档里给了一份现成的映射参考，省了不少事。
什么情况下直连反而更简单
得承认，不是所有场景都值得上网关。如果项目只接一家模型，或者只做非流式的批量推理，直连官方SDK代码最少、链路最短、排查最简单。网关层解决的是"多模型统一接入"带来的复杂度，单模型场景引入网关是多一层转发、多一个故障点。判断标准很直接：接的模型超过两家，或者需要在运行时切换模型，网关的收益才盖过成本。
写在最后
那次故障最后是加了网关层收口解决的，前端SSE解析逻辑从四套分支砍到一套，卡顿和分块异常随之消失。回头看，问题从来不在某一家大模型API，而在"把多家的协议差异直接透传给了业务层"。如果你也在做多模型接入，先把流式协议、错误码、鉴权、超时这四件事在网关层对齐，再谈上层功能。
作者：孙浩然
发布日期：2026年10月25日