1. 从荒天帝的修炼境界说起为什么大模型网关需要他化自在法第一次看到荒天帝炼大模型网关这个标题我脑子里蹦出来的不是玄幻小说的剧情而是一个很现实的技术问题当一个团队从调用单个大模型API进化到管理几十个模型、上百个应用、每天千万级请求的时候网关这个角色到底该怎么设计标题里的他化自在法是玄幻设定里的顶级神通能化身万千、自在无碍。放到技术语境里它对应的正是大模型网关最核心的能力——把异构的模型服务、不同的协议、不同的计费方式、不同的限流策略统一抽象成一套对外稳定的接口。而云上生产封帝这个说法说白了就是这套东西不能只跑在本地Demo里得真正扛住生产环境的流量、故障和成本压力。这篇文章适合三类人看一是正在做AI应用后端、被多模型接入搞得焦头烂额的Java工程师二是需要把大模型能力集成进现有微服务体系的架构师三是对LLM Gateway这个方向感兴趣、想了解生产级实现细节的技术负责人。我会围绕Java技术栈、Kubernetes部署、Redis中间件、SSE流式传输这几个关键词把一个大模型网关从设计到上生产的完整链路拆开讲。先给一个整体判断大模型网关和传统的API Gateway比如Spring Cloud Gateway、Nginx有本质区别。传统网关处理的是无状态、短连接、响应体小的请求而大模型网关要处理的是长连接、流式响应、Token级计费、模型级限流、上下文透传这些新问题。你如果直接拿Nginx或者普通网关套上去大概率会在SSE超时、连接数爆炸、计费不准这几个坑里反复摔跤。2. 网关的核心抽象层模型路由、协议适配与统一鉴权2.1 为什么不能直接让业务代码调各家SDK很多团队起步阶段的写法是这样的业务代码里直接引入某家模型的Java SDK然后client.chat()一把梭。单模型、单应用的时候没问题但一旦出现下面这些情况代码就会迅速腐化产品要求同时接入三家模型按成本和质量动态切换不同业务线要用不同的API Key需要做额度隔离某家模型服务抖动需要自动降级到备用模型要统计每个租户、每个应用的Token消耗和费用。这时候如果还在业务层写if-else判断用哪家维护成本会指数级上升。网关的第一个价值就是把模型选择这件事从业务代码里抽出来变成一个可配置、可动态调整的路由决策。我的做法是定义一个统一的请求模型比如ChatRequest里面包含model、messages、stream、temperature这些标准字段然后通过一个ModelRouter组件根据路由规则决定实际调用哪个后端。路由规则可以基于模型名映射、基于租户配置、基于负载情况甚至基于Prompt长度做成本优化。2.2 协议适配层的设计要点不同模型厂商的接口协议差异很大有的用OpenAI兼容格式有的用自家私有格式流式返回的SSE事件结构也不一样。协议适配层的职责就是把各家差异屏蔽在网关内部对外只暴露一套标准协议。这里有个容易忽略的细节SSE事件的解析不能简单按行读取。标准SSE格式是data: xxx\n\n但实际传输中一个事件可能被TCP拆成多个包也可能多个事件挤在一个包里。我见过有同学直接用BufferedReader.readLine()逐行读结果遇到跨包的事件就解析失败。正确做法是用一个带缓冲的状态机按\n\n作为事件分隔符做累积解析。// SSE事件累积解析的核心逻辑示意 StringBuilder buffer new StringBuilder(); byte[] chunk new byte[4096]; int len; while ((len inputStream.read(chunk)) ! -1) { buffer.append(new String(chunk, 0, len, StandardCharsets.UTF_8)); int idx; while ((idx buffer.indexOf(\n\n)) 0) { String event buffer.substring(0, idx); buffer.delete(0, idx 2); handleSseEvent(event); // 解析 data: 行并处理 } }2.3 统一鉴权与租户隔离网关对外暴露的Key和真实模型厂商的Key必须解耦。对外发给业务方的是网关自己签发的虚拟Key网关内部维护一张映射表记录这个虚拟Key对应哪个租户、能用哪些模型、额度还剩多少。这张映射表我建议放在Redis里原因有两个一是鉴权是高频操作需要低延迟二是多实例部署时额度扣减必须原子化。用Redis的INCRBY配合Lua脚本可以做到检查扣减的原子性避免并发场景下超额。注意不要把厂商的真实API Key写死在代码或配置文件里明文存储。生产环境建议用K8s Secret或者配置中心加密存储网关启动时解密加载到内存。3. Redis在网关里的三重身份缓存、限流与分布式协调3.1 不只是缓存Redis承担的状态管理职责很多人一提Redis就想到缓存但在大模型网关里Redis的角色要复杂得多。我把它归纳为三类用途用途数据结构典型场景鉴权与额度Hash String虚拟Key映射、Token余额限流计数String Lua租户级QPS、模型级并发会话与幂等String Set请求去重、流式会话状态额度扣减这块有个坑流式请求的Token数在请求开始时是未知的。你不能等响应结束再扣因为那样并发场景下会超发。我的做法是预扣结算请求进来先按预估上限预扣响应结束后按实际用量结算多退少补。预扣上限可以根据max_tokens参数或者历史平均值来定。3.2 分布式限流的实现细节限流算法选型上令牌桶适合平滑限流滑动窗口适合精确控制。大模型网关我推荐用滑动窗口Redis Lua因为模型调用本身耗时较长几秒到几十秒固定窗口在窗口边界容易出现流量尖刺。-- 滑动窗口限流的Lua脚本核心逻辑 local key KEYS[1] local now tonumber(ARGV[1]) local window tonumber(ARGV[2]) local limit tonumber(ARGV[3]) redis.call(ZREMRANGEBYSCORE, key, 0, now - window) local count redis.call(ZCARD, key) if count limit then redis.call(ZADD, key, now, now .. - .. math.random()) redis.call(EXPIRE, key, window / 1000 1) return 1 else return 0 end这里有个实操经验Lua脚本里的math.random()在高并发下可能产生重复成员导致ZADD覆盖。更稳妥的做法是用请求ID作为member或者用now加上一个自增序列。我早期就因为这个细节在压测时发现限流计数比实际少了将近10%。3.3 连接池与超时配置Redis客户端我用的Lettuce默认是共享连接。但在网关这种高并发场景下命令超时redis command timed out是高频问题。排查下来通常有三个原因一是网络抖动二是Redis单线程被大Key阻塞三是客户端超时设置过短。我的配置经验是命令超时设2秒连接超时设3秒同时开启自动重连。另外一定要监控Redis的慢查询日志网关里如果出现KEYS *这种操作基本就是灾难。提示如果用了Redis集群注意Lua脚本涉及的所有Key必须在同一个slot否则会报CROSSSLOT错误。可以用hash tag比如{tenant:123}:quota强制路由到同一节点。4. SSE流式传输从idle timeout到稳定长连接4.1 那个让人头疼的stream disconnected before completion关键词里有一条特别扎眼stream disconnected before completion: idle timeout waiting for sse。这个报错我太熟悉了几乎每个做流式网关的团队都会遇到。它的本质是客户端和服务端之间的连接在两次SSE事件之间空闲时间过长被中间某一层负载均衡、反向代理、网关自身判定为超时并断开。大模型生成第一个Token可能需要几秒甚至十几秒如果这期间没有任何数据下发连接就可能被掐断。解决思路分三层应用层在等待模型首Token期间定期发送SSE注释行以:开头作为心跳保持连接活跃网关层配置合理的读超时比如60秒以上而不是默认的几秒基础设施层Nginx的proxy_read_timeout、云负载均衡的空闲超时都要相应调大。# Nginx作为SSE反向代理的关键配置 location /v1/chat/completions { proxy_pass http://gateway-backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_buffering off; # 关键关闭缓冲否则流式失效 proxy_cache off; proxy_read_timeout 300s; # 读超时调大 chunked_transfer_encoding on; }proxy_buffering off这一行是重中之重。如果开着缓冲Nginx会攒够一定数据才转发流式效果直接消失用户会感觉卡半天然后一次性出来。4.2 网关自身的流式转发实现网关收到后端的SSE流之后需要一边解析一边转发给客户端。这里用Spring WebFlux的FluxServerSentEvent会比较顺手但要注意背压backpressure处理。如果客户端消费慢而后端还在猛推内存会堆积。我的做法是在转发链路上加一个带缓冲的队列队列满了就暂停从后端读取通过Reactive Streams的request(n)机制等客户端消费后再继续。这样即使某个慢客户端也不会拖垮整个网关。// WebFlux流式转发的简化示意 public FluxServerSentEventString proxyStream(ChatRequest req) { return modelClient.streamChat(req) .map(chunk - ServerSentEvent.builder(chunk).build()) .onErrorResume(e - { log.warn(stream error, fallback, e); return Flux.just(ServerSentEvent.builder([DONE]).build()); }); }4.3 断线重连与幂等流式请求断线后客户端往往会重试。如果网关不做幂等重试会导致重复计费和重复生成。我的方案是给每个请求分配一个requestId网关在Redis里记录这个ID的处理状态。重试请求带着相同ID进来时如果发现已经处理过直接返回缓存的结果或者拒绝重复执行。对于流式场景完整的断点续传实现比较复杂因为Token是逐步生成的。折中方案是记录已生成的Token序列重连时从断点继续推送。这需要后端模型支持类似的能力或者网关自己缓存已生成内容。实际落地时我更多是让客户端做整段重试网关只保证不重复计费。5. Kubernetes上的生产部署从单副本到弹性伸缩5.1 网关的有状态与无状态之辨大模型网关整体上是无状态的会话状态和限流计数都放在Redis里所以理论上可以随意扩缩容。但有两个地方需要注意SSE长连接会导致连接数分布不均。如果K8s的负载均衡是四层的长连接可能集中在少数Pod上。建议用七层Ingress并且开启连接级别的负载均衡。优雅关闭。Pod被销毁时正在进行的流式请求不能直接掐断。需要配置preStop钩子等待一段时间让存量请求处理完同时从服务注册中摘除。# 网关Deployment的关键配置片段 spec: template: spec: terminationGracePeriodSeconds: 60 containers: - name: llm-gateway lifecycle: preStop: exec: command: [sh, -c, sleep 15] readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 10terminationGracePeriodSeconds要大于最长请求的处理时间。大模型请求可能跑几十秒所以设60秒比较稳妥。5.2 弹性伸缩的指标选择HPA默认按CPU和内存伸缩但网关的瓶颈往往不在CPU而在并发连接数和请求队列长度。我建议暴露自定义指标比如gateway_active_streams用它来驱动HPA。另外要注意冷启动问题。Java应用启动慢如果流量突增时扩容来不及会有一段时间请求失败。缓解办法是保持一个合理的最小副本数并且用就绪探针确保新Pod真正能服务了才接入流量。5.3 配置与密钥管理模型厂商的API Key、Redis密码、数据库连接串这些敏感信息绝对不要打进镜像。用K8s Secret挂载成环境变量或者文件配合配置中心做动态刷新。我见过有团队把Key写在application.yml里提交到Git结果泄露后被刷了几万块这个教训很贵。6. 生产环境踩过的坑与排查链路6.1 一次典型的请求卡住排查有段时间线上反馈部分流式请求会卡在正在生成状态既不返回也不报错。排查链路是这样的先看网关日志发现请求已经发到后端模型但迟迟没有收到首Token查后端模型的监控发现该时段有大量请求排队再查网关到模型的连接池发现连接数被打满新请求在等待连接根因是连接池最大连接数设置过小而模型响应变慢导致连接被长时间占用。修复方案是调大连接池同时给模型调用加上超时熔断。这个案例的教训是网关的每一个资源池都要有上限和超时否则一个慢依赖会拖垮整个网关。6.2 计费不准的问题定位另一个坑是Token计费对不上账。排查后发现两个原因一是流式响应的最后一个chunk里才带usage信息如果中途断线就丢了二是并发扣减时用了非原子操作导致少扣。解决办法对于断线场景按预扣上限结算对于并发扣减全部改用Lua脚本保证原子性。同时增加对账任务每天比对网关记录和厂商账单发现差异及时告警。6.3 几个值得记住的经验SSE的data:字段里如果有换行需要拆成多个data:行否则客户端解析会出错Redis的大Key要警惕比如把整个会话历史存成一个String随着对话变长会越来越大建议用List或者分片存储压测一定要用真实的长连接场景用ab或者普通wrk测不出SSE的问题得用能保持长连接的工具日志里不要打印完整的Prompt和响应既有隐私风险也会让日志量爆炸建议只打印长度和摘要。7. 写在最后的一点个人体会这套网关从最初的单机Demo到现在的生产集群我最大的感受是大模型网关的难点不在转发而在状态管理和边界处理。转发逻辑本身很简单但一旦涉及计费、限流、断线、并发复杂度就上来了。如果让我给正在做类似项目的同学一个建议那就是先把Redis的数据模型设计清楚再写业务代码。额度、限流、会话、幂等这些东西数据结构定好了后面的实现会顺很多。反过来如果一开始随手用String存一切后期改起来会很痛苦。另外K8s部署这块不要追求一步到位。先跑通单副本把SSE和Redis的问题解决掉再考虑多副本和弹性伸缩。我见过太多团队在基础设施上过度设计结果核心的流式稳定性还没搞定。 
长河君 · 2026/10/7 12:08:02 · 阅读 1.2k 大模型网关生产级设计：Java、K8s、Redis与SSE流式传输实战
1. 从荒天帝的修炼境界说起为什么大模型网关需要他化自在法第一次看到荒天帝炼大模型网关这个标题我脑子里蹦出来的不是玄幻小说的剧情而是一个很现实的技术问题当一个团队从调用单个大模型API进化到管理几十个模型、上百个应用、每天千万级请求的时候网关这个角色到底该怎么设计标题里的他化自在法是玄幻设定里的顶级神通能化身万千、自在无碍。放到技术语境里它对应的正是大模型网关最核心的能力——把异构的模型服务、不同的协议、不同的计费方式、不同的限流策略统一抽象成一套对外稳定的接口。而云上生产封帝这个说法说白了就是这套东西不能只跑在本地Demo里得真正扛住生产环境的流量、故障和成本压力。这篇文章适合三类人看一是正在做AI应用后端、被多模型接入搞得焦头烂额的Java工程师二是需要把大模型能力集成进现有微服务体系的架构师三是对LLM Gateway这个方向感兴趣、想了解生产级实现细节的技术负责人。我会围绕Java技术栈、Kubernetes部署、Redis中间件、SSE流式传输这几个关键词把一个大模型网关从设计到上生产的完整链路拆开讲。先给一个整体判断大模型网关和传统的API Gateway比如Spring Cloud Gateway、Nginx有本质区别。传统网关处理的是无状态、短连接、响应体小的请求而大模型网关要处理的是长连接、流式响应、Token级计费、模型级限流、上下文透传这些新问题。你如果直接拿Nginx或者普通网关套上去大概率会在SSE超时、连接数爆炸、计费不准这几个坑里反复摔跤。2. 网关的核心抽象层模型路由、协议适配与统一鉴权2.1 为什么不能直接让业务代码调各家SDK很多团队起步阶段的写法是这样的业务代码里直接引入某家模型的Java SDK然后client.chat()一把梭。单模型、单应用的时候没问题但一旦出现下面这些情况代码就会迅速腐化产品要求同时接入三家模型按成本和质量动态切换不同业务线要用不同的API Key需要做额度隔离某家模型服务抖动需要自动降级到备用模型要统计每个租户、每个应用的Token消耗和费用。这时候如果还在业务层写if-else判断用哪家维护成本会指数级上升。网关的第一个价值就是把模型选择这件事从业务代码里抽出来变成一个可配置、可动态调整的路由决策。我的做法是定义一个统一的请求模型比如ChatRequest里面包含model、messages、stream、temperature这些标准字段然后通过一个ModelRouter组件根据路由规则决定实际调用哪个后端。路由规则可以基于模型名映射、基于租户配置、基于负载情况甚至基于Prompt长度做成本优化。2.2 协议适配层的设计要点不同模型厂商的接口协议差异很大有的用OpenAI兼容格式有的用自家私有格式流式返回的SSE事件结构也不一样。协议适配层的职责就是把各家差异屏蔽在网关内部对外只暴露一套标准协议。这里有个容易忽略的细节SSE事件的解析不能简单按行读取。标准SSE格式是data: xxx\n\n但实际传输中一个事件可能被TCP拆成多个包也可能多个事件挤在一个包里。我见过有同学直接用BufferedReader.readLine()逐行读结果遇到跨包的事件就解析失败。正确做法是用一个带缓冲的状态机按\n\n作为事件分隔符做累积解析。// SSE事件累积解析的核心逻辑示意 StringBuilder buffer new StringBuilder(); byte[] chunk new byte[4096]; int len; while ((len inputStream.read(chunk)) ! -1) { buffer.append(new String(chunk, 0, len, StandardCharsets.UTF_8)); int idx; while ((idx buffer.indexOf(\n\n)) 0) { String event buffer.substring(0, idx); buffer.delete(0, idx 2); handleSseEvent(event); // 解析 data: 行并处理 } }2.3 统一鉴权与租户隔离网关对外暴露的Key和真实模型厂商的Key必须解耦。对外发给业务方的是网关自己签发的虚拟Key网关内部维护一张映射表记录这个虚拟Key对应哪个租户、能用哪些模型、额度还剩多少。这张映射表我建议放在Redis里原因有两个一是鉴权是高频操作需要低延迟二是多实例部署时额度扣减必须原子化。用Redis的INCRBY配合Lua脚本可以做到检查扣减的原子性避免并发场景下超额。注意不要把厂商的真实API Key写死在代码或配置文件里明文存储。生产环境建议用K8s Secret或者配置中心加密存储网关启动时解密加载到内存。3. Redis在网关里的三重身份缓存、限流与分布式协调3.1 不只是缓存Redis承担的状态管理职责很多人一提Redis就想到缓存但在大模型网关里Redis的角色要复杂得多。我把它归纳为三类用途用途数据结构典型场景鉴权与额度Hash String虚拟Key映射、Token余额限流计数String Lua租户级QPS、模型级并发会话与幂等String Set请求去重、流式会话状态额度扣减这块有个坑流式请求的Token数在请求开始时是未知的。你不能等响应结束再扣因为那样并发场景下会超发。我的做法是预扣结算请求进来先按预估上限预扣响应结束后按实际用量结算多退少补。预扣上限可以根据max_tokens参数或者历史平均值来定。3.2 分布式限流的实现细节限流算法选型上令牌桶适合平滑限流滑动窗口适合精确控制。大模型网关我推荐用滑动窗口Redis Lua因为模型调用本身耗时较长几秒到几十秒固定窗口在窗口边界容易出现流量尖刺。-- 滑动窗口限流的Lua脚本核心逻辑 local key KEYS[1] local now tonumber(ARGV[1]) local window tonumber(ARGV[2]) local limit tonumber(ARGV[3]) redis.call(ZREMRANGEBYSCORE, key, 0, now - window) local count redis.call(ZCARD, key) if count limit then redis.call(ZADD, key, now, now .. - .. math.random()) redis.call(EXPIRE, key, window / 1000 1) return 1 else return 0 end这里有个实操经验Lua脚本里的math.random()在高并发下可能产生重复成员导致ZADD覆盖。更稳妥的做法是用请求ID作为member或者用now加上一个自增序列。我早期就因为这个细节在压测时发现限流计数比实际少了将近10%。3.3 连接池与超时配置Redis客户端我用的Lettuce默认是共享连接。但在网关这种高并发场景下命令超时redis command timed out是高频问题。排查下来通常有三个原因一是网络抖动二是Redis单线程被大Key阻塞三是客户端超时设置过短。我的配置经验是命令超时设2秒连接超时设3秒同时开启自动重连。另外一定要监控Redis的慢查询日志网关里如果出现KEYS *这种操作基本就是灾难。提示如果用了Redis集群注意Lua脚本涉及的所有Key必须在同一个slot否则会报CROSSSLOT错误。可以用hash tag比如{tenant:123}:quota强制路由到同一节点。4. SSE流式传输从idle timeout到稳定长连接4.1 那个让人头疼的stream disconnected before completion关键词里有一条特别扎眼stream disconnected before completion: idle timeout waiting for sse。这个报错我太熟悉了几乎每个做流式网关的团队都会遇到。它的本质是客户端和服务端之间的连接在两次SSE事件之间空闲时间过长被中间某一层负载均衡、反向代理、网关自身判定为超时并断开。大模型生成第一个Token可能需要几秒甚至十几秒如果这期间没有任何数据下发连接就可能被掐断。解决思路分三层应用层在等待模型首Token期间定期发送SSE注释行以:开头作为心跳保持连接活跃网关层配置合理的读超时比如60秒以上而不是默认的几秒基础设施层Nginx的proxy_read_timeout、云负载均衡的空闲超时都要相应调大。# Nginx作为SSE反向代理的关键配置 location /v1/chat/completions { proxy_pass http://gateway-backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_buffering off; # 关键关闭缓冲否则流式失效 proxy_cache off; proxy_read_timeout 300s; # 读超时调大 chunked_transfer_encoding on; }proxy_buffering off这一行是重中之重。如果开着缓冲Nginx会攒够一定数据才转发流式效果直接消失用户会感觉卡半天然后一次性出来。4.2 网关自身的流式转发实现网关收到后端的SSE流之后需要一边解析一边转发给客户端。这里用Spring WebFlux的FluxServerSentEvent会比较顺手但要注意背压backpressure处理。如果客户端消费慢而后端还在猛推内存会堆积。我的做法是在转发链路上加一个带缓冲的队列队列满了就暂停从后端读取通过Reactive Streams的request(n)机制等客户端消费后再继续。这样即使某个慢客户端也不会拖垮整个网关。// WebFlux流式转发的简化示意 public FluxServerSentEventString proxyStream(ChatRequest req) { return modelClient.streamChat(req) .map(chunk - ServerSentEvent.builder(chunk).build()) .onErrorResume(e - { log.warn(stream error, fallback, e); return Flux.just(ServerSentEvent.builder([DONE]).build()); }); }4.3 断线重连与幂等流式请求断线后客户端往往会重试。如果网关不做幂等重试会导致重复计费和重复生成。我的方案是给每个请求分配一个requestId网关在Redis里记录这个ID的处理状态。重试请求带着相同ID进来时如果发现已经处理过直接返回缓存的结果或者拒绝重复执行。对于流式场景完整的断点续传实现比较复杂因为Token是逐步生成的。折中方案是记录已生成的Token序列重连时从断点继续推送。这需要后端模型支持类似的能力或者网关自己缓存已生成内容。实际落地时我更多是让客户端做整段重试网关只保证不重复计费。5. Kubernetes上的生产部署从单副本到弹性伸缩5.1 网关的有状态与无状态之辨大模型网关整体上是无状态的会话状态和限流计数都放在Redis里所以理论上可以随意扩缩容。但有两个地方需要注意SSE长连接会导致连接数分布不均。如果K8s的负载均衡是四层的长连接可能集中在少数Pod上。建议用七层Ingress并且开启连接级别的负载均衡。优雅关闭。Pod被销毁时正在进行的流式请求不能直接掐断。需要配置preStop钩子等待一段时间让存量请求处理完同时从服务注册中摘除。# 网关Deployment的关键配置片段 spec: template: spec: terminationGracePeriodSeconds: 60 containers: - name: llm-gateway lifecycle: preStop: exec: command: [sh, -c, sleep 15] readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 10terminationGracePeriodSeconds要大于最长请求的处理时间。大模型请求可能跑几十秒所以设60秒比较稳妥。5.2 弹性伸缩的指标选择HPA默认按CPU和内存伸缩但网关的瓶颈往往不在CPU而在并发连接数和请求队列长度。我建议暴露自定义指标比如gateway_active_streams用它来驱动HPA。另外要注意冷启动问题。Java应用启动慢如果流量突增时扩容来不及会有一段时间请求失败。缓解办法是保持一个合理的最小副本数并且用就绪探针确保新Pod真正能服务了才接入流量。5.3 配置与密钥管理模型厂商的API Key、Redis密码、数据库连接串这些敏感信息绝对不要打进镜像。用K8s Secret挂载成环境变量或者文件配合配置中心做动态刷新。我见过有团队把Key写在application.yml里提交到Git结果泄露后被刷了几万块这个教训很贵。6. 生产环境踩过的坑与排查链路6.1 一次典型的请求卡住排查有段时间线上反馈部分流式请求会卡在正在生成状态既不返回也不报错。排查链路是这样的先看网关日志发现请求已经发到后端模型但迟迟没有收到首Token查后端模型的监控发现该时段有大量请求排队再查网关到模型的连接池发现连接数被打满新请求在等待连接根因是连接池最大连接数设置过小而模型响应变慢导致连接被长时间占用。修复方案是调大连接池同时给模型调用加上超时熔断。这个案例的教训是网关的每一个资源池都要有上限和超时否则一个慢依赖会拖垮整个网关。6.2 计费不准的问题定位另一个坑是Token计费对不上账。排查后发现两个原因一是流式响应的最后一个chunk里才带usage信息如果中途断线就丢了二是并发扣减时用了非原子操作导致少扣。解决办法对于断线场景按预扣上限结算对于并发扣减全部改用Lua脚本保证原子性。同时增加对账任务每天比对网关记录和厂商账单发现差异及时告警。6.3 几个值得记住的经验SSE的data:字段里如果有换行需要拆成多个data:行否则客户端解析会出错Redis的大Key要警惕比如把整个会话历史存成一个String随着对话变长会越来越大建议用List或者分片存储压测一定要用真实的长连接场景用ab或者普通wrk测不出SSE的问题得用能保持长连接的工具日志里不要打印完整的Prompt和响应既有隐私风险也会让日志量爆炸建议只打印长度和摘要。7. 写在最后的一点个人体会这套网关从最初的单机Demo到现在的生产集群我最大的感受是大模型网关的难点不在转发而在状态管理和边界处理。转发逻辑本身很简单但一旦涉及计费、限流、断线、并发复杂度就上来了。如果让我给正在做类似项目的同学一个建议那就是先把Redis的数据模型设计清楚再写业务代码。额度、限流、会话、幂等这些东西数据结构定好了后面的实现会顺很多。反过来如果一开始随手用String存一切后期改起来会很痛苦。另外K8s部署这块不要追求一步到位。先跑通单副本把SSE和Redis的问题解决掉再考虑多副本和弹性伸缩。我见过太多团队在基础设施上过度设计结果核心的流式稳定性还没搞定。