LLM网关生产化落地：架构权衡、流式转发与成本治理

很多团队接入大模型的方式最初都是从“在业务代码里直接调 SDK”开始的。单个模型、单个供应商、单条业务链路的时候这样写确实够快申请一个 API Key把官方 SDK 引进来封装一个 Client业务方拿着 prompt 去调用就行。真正的麻烦从第二个模型接入开始出现不同供应商的请求格式不一样错误码含义不一样限流策略不一样token 计费口径也不一样再往后团队多了、业务多了有人想用 A 模型做摘要有人想用 B 模型做意图识别还有人要求失败后自动切到 C 模型兜底这时候你才会意识到缺的不是“调模型的代码”而是一层统一的管理入口。这就是 LLM 网关要解决的问题。它不是简单地把多个 API 再包一层而是把模型访问从业务系统里剥离开让路由、安全、观测、成本、限流这些事情沉淀成平台能力。很多团队掉进过一个误区以为 LLM 网关就是把“换成另一个 URL 地址”结果上线后才发现流式响应没有处理、token 账单对不上、一方供应商抖动导致全站大模型功能不可用。生产化一个 LLM 网关真正难的并不是把它跑起来而是在架构设计阶段做出正确的权衡并理解每个权衡背后的代价。这篇文章会围绕 LLM 网关在生产环境落地时的架构选择展开先梳理网关的核心职责和边界再分析几个关键的架构权衡点然后给出一套最小可用的路由和流式转发设计接着讨论可观测性与成本计量最后结合常见的故障场景给出排查思路和工程建议。如果你正在设计内部的大模型接入平台或者准备把网关从开发环境推到生产环境这篇文章应该能帮你减少一些弯路。1. LLM 网关到底解决什么问题要判断一个中间件值不值得引入先要回答一个问题没有它的时候开发团队在经历什么。直连模型的典型处境是这样的业务同学需要在代码里维护供应商 SDK模型一升级就要改依赖每个需要大模型能力的服务都要单独处理 API Key、超时时间和错误重试网上抄来的 prompt 模板散落在各种业务模块里模型行为调整只能靠“谁改谁负责”最痛的是月底对账每个业务方用了多少 token成本该算在哪个团队头上基本靠手工从账单里翻。这些问题的本质是一致的模型调用行为和业务逻辑耦合得太紧接入方式、治理方式、计量方式全都长在了业务代码里改一个模型价格策略都要动业务代码。LLM 网关的价值在于把“怎么连模型”这件事从业务中抽出来。业务方向网关发出一个请求网关负责选择模型、注入提示词、处理重试、计量 token、记录日志、返回结果。业务不需要知道这次请求最终落到哪家供应商、用的是哪个模型。还需要区分的是LLM 网关和传统 API 网关不是一回事。传统 API 网关解决的是服务发现、负载均衡、路径转发、熔断限流它面对的是“服务的接口”LLM 网关面对的是“模型和提示词”它需要处理的是模型路由、上下文拼装、token 计数、流式转发这些在模型世界里才有的问题。两者可以共存但职责不是互相替代。如果团队已经有成熟的 API 网关比较好的做法是让 API 网关负责南北向流量和安全认证LLM 网关在更靠近模型的一侧负责模型接入治理。一句话概括LLM 网关是模型接入的治理层。它把路由、安全、可观测、成本、限流这些能力从业务代码里收归到一个统一层目标是让业务方用最简单的方式获得模型能力同时让平台方掌握完整的控制权和可见性。2. LLM 网关的核心职责与功能边界在设计网关之前需要先把“该管什么”和“不该管什么”界定清楚。职责过少网关会沦为一块没有价值的转发板职责过多网关又会变成一个什么都做、什么都做不好的“大泥球”。2.1 模型路由与供应商切换这是 LLM 网关最基本也最核心的职责。路由通常从两个维度展开一是按请求维度路由比如某个业务方的请求需要低延迟就路由到更快的模型需要长文本理解就路由到上下文更大的模型二是按可用性路由比如主供应商返回 429 或 5xx 时网关自动把请求切换到备用供应商。供应商切换不是简单地把 URL 换掉。不同供应商的鉴权方式、请求格式、流式协议、错误码都有差异网关内部需要做协议适配。从工程实践看路由配置应该放在配置中心或者单独的配置文件中而不是写死在代码里否则每一次模型调整都要重新发版。2.2 语义缓存很多团队容易忽略语义缓存的价值。同一个问题、同一段知识库内容的检索结果在一天内被大量重复请求如果每次都真实调用模型成本会迅速上升。语义缓存的做法是把用户输入转化为向量在缓存池中判断是否存在语义相近的请求如果命中就直接返回相同结果。这里的关键权衡是缓存命中和语义漂移。阈值设置过宽会把语义不同的请求误判成相同阈值设置过窄缓存几乎不会命中。建议在网关中把缓存策略做成可配置并且区分“精确缓存”和“语义缓存”两种级别让业务方根据自己的场景选择。2.3 可观测性与成本计量没有可观测性的网关是不适合上生产的。LLM 网关至少要记录请求来源、目标模型、输入 token 数、输出 token 数、时延、状态码、重试次数、费用估算。这些数据同时服务于稳定性管理和成本治理。成本计量尤其容易出现分歧。供应商账单反映的是一个时间窗口内的总数情况而业务方需要一个请求级别的分摊结果。网关在做 token 计量的同时要为每个请求打上业务标签。后续对账时网关记录的分摊数据与供应商账单之间可能出现不一致处理不一致不能只靠概括还需要通过定期对账任务来校准。2.4 限流、认证与失败回退网关作为统一入口天然适合做限流和认证。认证方面网关对外暴露的是它自己的 API Key而不是供应商的原始 Key这样供应商 Key 不会散落在业务服务中可以定期轮换而不影响业务方。限流方面需要考虑两层一层是网关对业务方的配额限制另一层是网关对供应商调用频率的保护避免多个业务方共同打爆供应商配额。失败回退同样值得认真设计。不要只做“请求失败就换一个供应商”这种最简单的重试还要考虑降级策略。比如上游模型不可用是返回友好错误还是用本地缓存兜底还是切换到一个质量更低但更稳定的模型这需要结合业务场景来决定。2.5 提示词模板与模型策略管理如果提示词工程的结果都散落在业务代码里模型优化就无法规模化推进。网关层可以集中管理一批提示词模板把模板版本和模型版本关联起来。真正生产环境的使用方式往往更快一个模板调整后先在测试环境验证再通过灰度流量逐步放量。但是这里有一个明显的边界问题。提示词模板的管理权在业务团队还是平台团队需要在组织层面先达成一致。网关只是提供一个机制它不解决权限和协作的问题。如果强制把所有提示词收归到网关而业务团队又需要快速迭代那么网关很快就会成为瓶颈。2.6 不该做的事别让网关变成“万能调度器”网关最需要抵制的诱惑是“什么逻辑都往里面加”。有的团队会把业务校验、领域规则、数据过滤、甚至用户对话状态全塞进网关理由是“反正网关是统一入口”。这样的后果是网关逻辑越来越重稳定性风险越来越大最后网关成了整个系统的单点一挂全挂。一个相对清晰的边界是网关只处理“模型接入的通用问题”不做“特定业务的定制逻辑”。业务特有规则应该放在更上层的业务服务里。网关的重心是路由、安全、观测、计量和稳定性。3. 架构选型中的关键权衡3.1 单网关还是多网关单网关的优势是统一管理所有模型流量都经过同一个入口成本计量、安全控制和模型策略都可以集中制定。缺点是故障域太大一旦网关出问题所有模型能力全部不可用同时不同业务场景的稳定性诉求不同用一套基础设施去满足所有场景往往只能取最低共同标准。多网关在隔离性上更优比如内部办公场景和生产业务场景分开部署每个场景有自己独立的配额和告警但运维成本会成倍增加路由策略也无法做到全局集中。工程上较稳妥的做法是“逻辑统一、物理可分”。使用同一套网关代码、同一套配置规范但在不同的命名空间或区域部署多个实例组分别服务不同等级的流量。必要时可以通过配置中心动态调整某个实例组的模型路由策略把灵活性和稳定性兼顾起来。3.2 网关嵌入业务代码还是独立部署独立部署几乎是生产环境的必然选择。独立部署的好处有三个一是模型 Key 可以集中在网关侧不向业务代码暴露二是网关的版本升级和扩展不依赖业务发布流程三是不同业务方可以接入同一个网关避免重复建设。嵌入业务代码的方式只适合早期的轻量尝试或者在单体应用的迁移阶段作为过渡不适合作为长期架构。因为一旦每个服务都内嵌一个“网关 SDK”配置管理、版本兼容和故障排查的成本会迅速上升本质上还是没有治理。3.3 同步响应还是流式响应LLM 网关生产化中最容易出问题的点之一就是流式响应。早期很多网关在转发流式响应时直接把整个响应缓存到底层等模型输出完毕后再一次性返回给客户端。这种做法在短文本场景下问题不大但在对话、生成、流式输出场景下用户等待时间会明显拉长体验很差。流式转发的正确做法是实时转发。网关收到上游的数据块后立即透传给下游客户端网关本身不对内容做缓冲只做透传和统计。这里需要处理连接生命周期管理、客户端断开后的资源释放、上游持续发送但下游已不可写时的背压处理。生产环境中建议对同一个模型接口同时提供同步和流式两种接入方式业务方根据场景自己选择。网关内部的转发逻辑要彻底分开不要在同步代码里硬塞流式逻辑。3.4 多租户隔离与配额管理一旦网关开始服务多个团队就必须考虑多租户隔离。最核心的是配额隔离A 团队的突发流量不应该占掉 B 团队的配额。常见做法是为每个业务方或每个团队建立独立的桶在网关层做配额隔离。另一方面是数据隔离。多租户场景下请求日志中可能包含业务敏感信息网关在记录日志时需要做字段级别控制敏感字段可以脱敏或只记录散列值避免不同团队之间不必要的数据暴露。这既是一个技术问题也是一个合规问题。3.5 有状态还是无状态从架构上看网关本身应该保持无状态这样才方便水平扩展和滚动发布。但限流和缓存这两个功能天然带有状态处理方式是将状态外置到 Redis 等共享存储同时避免 Redis 高频访问成为瓶颈。这里有一个实践教训在网关引入高并发共享存储依赖后任何对外部存储的访问都可能成为新的故障点。Redis 抖动一次网关延迟就会大幅上升。解决思路是给外部存储访问加上超时控制和降级逻辑Redis 不可用时网关自动退化为局部限流或暂时关闭语义缓存而不是整站失败。4. 网关部署架构与前置条件在进入代码示例之前先明确一套典型的生产部署拓扑后续的示例都基于这个拓扑来组织。网关独立部署为一个或多个无状态服务实例前端与整个系统的 API 入口保持一致自身不保存会话状态。网关后端通过配置中心加载供应商密钥、路由策略、模型白名单通过 Redis 实现限流计数和语义缓存通过消息队列把访问日志和 token 计量数据异步发送给日志和账单系统。网关的外部依赖包括上游模型 API、配置中心、Redis、日志系统和可观测性系统。这个拓扑有三个值得注意的点。第一网关的存储依赖尽量简单不引入数据库业务状态数据一律不落库只有日志和计量走异步管道。第二供应商密钥保存在配置中心或密钥管理系统而不是写入环境变量或配置文件明文这会在第 8 部分继续展开。第三网关到上游模型之间要单独设置超时和重试策略不能依赖默认的 HTTP 客户端行为。环境方面没有必须绑定的语言或框架用 Java、Go、Node.js 都可以实现一个合格的网关。实际选型时主要看团队已有的技术栈和维护成本。本文的示例代码以 Java 伪代码为主重点是阐明设计思路代码可以迁移到任何语言。5. 一个最小可用网关的路由与回退设计这一节通过代码演示网关最核心的一条链路接收业务请求根据路由策略选择模型调用上游在失败时执行回退。5.1 供应商配置抽象不同供应商的请求格式和鉴权方式不一样网关内部需要建立一个统一的模型调用接口。最核心的接口可以抽象成“给定模型名和消息列表返回模型响应”把底层差异隔离在适配器内部。// ModelGateway.java /** * 模型调用网关的核心接口。 * 所有供应商适配器都实现该接口上层路由逻辑只依赖这个抽象。 */ public interface ModelGateway { String name(); ModelResponse chat(ModelRequest request); void chatStream(ModelRequest request, StreamObserverModelChunk observer); }对应地供应商配置从外部文件加载标准结构如下# providers.yaml providers: - name: vendor-a type: openai-compatible base-url: https://api.vendor-a.example.com/v1 api-key-ref: secret/vendor-a/api-key enabled: true weight: 80 models: - model: chat-model-lite timeout-millis: 15000 - name: vendor-b type: openai-compatible base-url: https://api.vendor-b.example.com/v1 api-key-ref: secret/vendor-b/api-key enabled: true weight: 20 models: - model: chat-model-lite timeout-millis: 20000这段配置表达了一个关键设计网关面向业务方暴露的是逻辑模型名chat-model-lite是一个逻辑概念不代表某一个供应商的具体型号。业务方只依赖逻辑名平台方在后面把逻辑名映射到具体的供应商和物理模型。这样换供应商时业务方零感知。5.2 路由与回退实现路由逻辑的核心是“主供应商优先 失败回退”。一个不需要过度设计的实现方式是先尝试权重最高的主供应商如果它返回 429、5xx 或者超时网关按配置顺序尝试备用供应商。// RoutingService.java public ModelResponse routeWithFallback(ModelRequest request) { ListString modelRoute routeResolver.resolve(request.getModelName()); ListProviderHealth candidates buildCandidates(modelRoute); // 主供应商重试一次 ProviderHealth primary candidates.remove(0); try { return invokeWithTimeout(primary, request); } catch (RateLimitException | ServerErrorException ex) { log.warn(primary provider failed, reason{}, fallback chain{}, ex.getClass().getSimpleName(), candidates); } // 备用供应商逐个尝试 for (ProviderHealth candidate : candidates) { try { return invokeWithTimeout(candidate, request); } catch (Exception ex) { log.warn(candidate failed, provider{}, reason{}, candidate.getProviderName(), ex.getMessage()); } } throw new NoAvailableProviderException(request.getModelName()); }这里有三处容易被忽略的细节第一主供应商失败后要不要重试要区分错误类型。对 429 和 5xx 可以重试对 400 这类请求参数错误没有重试意义立即回退或者抛错更合理。第二回退策略的复杂度和可观测性直接相关。如果回退链很长必须在上面的日志中记录完整链路否则出问题时无法判断最终是哪个供应商响应了请求。第三回退会引入结果不一致的风险。不同供应商的模型能力有差异业务方需要知道“本意是 A 模型回退后实际是 B 模型”因此响应中要携带实际生效的模型信息比如用响应头或者响应体字段标记。6. 流式转发与超时控制流式转发是 LLM 网关生产化过程中最容易制造隐藏故障的环节。很多团队第一次实现时只做了“上游返回数据块网关转发数据块”这个主流程等到线上才发现客户端断开连接后网关与上游之间的连接还一直保持着甚至源源不断地拉取数据造成资源浪费和上游配额消耗。6.1 流式转发的核心逻辑流式转发的关键不只是转发而是连接生命周期管理。网关收到客户端请求后向上游建立流式连接此时必须注册客户端断开回调。客户端一旦断开网关要立即取消上游请求释放连接池连接。// StreamingProxyHandler.java public void handle(HttpServletRequest request, HttpServletResponse response) { ModelRequest modelRequest buildRequest(request); String modelName modelRequest.getModelName(); // 开启 SSE 响应 response.setContentType(text/event-stream); response.setCharacterEncoding(UTF-8); SseEmitter emitter new SseEmitter(0L); // 0L 表示不在网关侧主动超时 emitter.onTimeout(emitter::complete); emitter.onError(throwable - log.warn(client stream error, model{}, modelName)); modelGateway.chatStream(modelRequest, new StreamObserverModelChunk() { Override public void onNext(ModelChunk chunk) { try { response.getWriter().write(formatSse(chunk)); response.getWriter().flush(); } catch (IOException e) { // 客户端不可写触发取消 cancelUpstreamRequest(modelRequest.getRequestId()); emitter.complete(); } } Override public void onCompleted() { emitter.complete(); } Override public void onError(Throwable t) { log.error(upstream stream error, requestId{}, model{}, modelRequest.getRequestId(), modelName, t); emitter.completeWithError(t); } }); }这段内容想表达的重点在于配置 SSE 时不能简单地把网关的超时时间设置为 0 就完事还需要关注上游可能长时间不返回数据的场景。模型推理阻塞、供应商网络异常、上游服务假死都会导致流式通道既没结束也没数据。这种情况下网关如果不做任何兜底客户端会一直转圈最终依赖客户端自己的超时来结束体验不可控。更合适的做法是设置一个“首包超时”策略。网关在发出请求后如果在一个合理时间窗口内没有收到任何数据块就主动终止连接并返回错误。6.2 超时分层LLM 调用链路中涉及多个阶段从客户端到网关的连接建立时间、网关到上游的连接建立时间、上游首包时间、上游流式传输整体时间、网关空闲等待时间。每个阶段都应该有自己的超时上限不要混成一个全局超时。一个常见的配置方案是连接超时 3 秒、首包超时 30 秒、空闲块间隔 60 秒、整体超时根据模型和场景单独配置。其中首包超时最容易踩坑因为大模型在长上下文场景下需要更长的预填充时间如果超时设得太短请求会被误杀。首包超时必须比该供应商论文中报告的首 token 延迟更宽松。同时流式过程中如果两个数据块之间间隔太久也要通过空闲超时断开避免网络假死。6.3 背压与连接池流式转发是典型的“客户端消费速度可能低于上游生产速度”的场景。如果客户端消费能力弱而上游数据持续到达网关内会出现消息累积。解决思路不是无限增大缓冲区而是及时断开或降速。比如通过信号量控制每个实例上的并发流式连接数量超过阈值后直接返回 503让客户端进行退避重试这比无限拖住连接更健康。连接池管理也需要针对流式“长连接”的特点做调整。普通 HTTP 短连接场景下连接池大小和 QPS 可以近似对应流式场景下一个连接可能持续数十秒连接池很容易被打满。生产中要注意给连接池预留足够余量并分开配置“同步调用连接池”和“流式调用连接池”避免一种流量把另一种流量的连接耗尽。7. 可观测性token 计量、成本分摊与告警可观测性对 LLM 网关来说不只是监控状态还承担了成本治理的功能。模型调用的成本不像普通 API 调用那样几乎为零一次复杂推理可能消耗大量 token成本以不可预估的方式增长。没有计量成本失控往往要等到账单出来后才能发现。7.1 访问日志应该记录什么网关在每完成一次请求后都应该生成一条结构化的访问日志。字段建议包括请求 ID、客户端来源、业务方标识、逻辑模型名、实际供应商、实际物理模型、输入 token 数量、输出 token 数量、总 token 数量、首包时延、总时延、是否命中缓存、是否发生回退、重试次数、调用方 IP、提示词模板版本。其中“输入 token 数量”和实际计费之间的关系需要特别说明不同供应商对计费 token 的统计口径可能不一致有的按字符数估算有的按 tokenizer 实际统计有的在请求中会返回 usage 字段。网关优先使用供应商返回的 usage 字段拿不到时才做估算。对账时要允许一定偏差区间不要追求账单一分不差。7.2 成本分摊模型多业务方共用网关后成本分摊会成为管理层关注的问题。推荐做法是在网关注入阶段要求业务方传递“业务线路”或“组织部门信息”网关把该信息写入日志和计量数据。后续按场景聚合一个业务方一个月消耗多少 token按模型拆分、按接口拆分、按提示词模板拆分。{ timestamp: 2025-06-12T10:23:44.125Z, request_id: req_8f3a2b9c1d4e, biz_line: search_recommend, tenant_id: recsys, model_alias: chat-model-lite, actual_provider: vendor-a, actual_model: gpt-style-mini, usage: { prompt_tokens: 1280, completion_tokens: 512, total_tokens: 1792 }, latency: { first_byte_ms: 780, total_ms: 3200 }, cached: false, fallback: false, retry_count: 0, status: success }这里最关键的一个设计是同时记录逻辑模型名和实际模型名。如果发生回退只有逻辑模型名会把成本算错只有实际模型名则无法统计某个业务接口到底想要什么模型。两列对照才能同时支撑成本归因和模型策略分析。7.3 告警规则告警规则不要一上来就很多条建议从三个与稳定性和成本强相关的维度开始第一错误率与回退率。某个逻辑模型名的错误率或回退率在短时间内显著上升说明主供应商大概率出现了问题需要团队介入决策。第二时延异常。首包时延 P95 升高可能意味着上游模型负载变高需要评估是否需要调整路由权重或扩容。第三成本异常。当日累计 token 消耗环比大幅上升说明可能存在异常调用常见原因有循环任务、缓存失效、prompt token 膨胀等。设告警时要区分基础设施指标和业务指标。基础设施指标用的是服务整体的 CPU、内存、连接数业务指标要按模型、租户、接口分别统计。毕竟一个供应商的抖动对部分租户产生的局部影响必须使用局部维度告警才能更早发现问题。8. 常见问题与排查方法网关在生产环境中最常见的故障模式其实很有规律这里整理一份排查清单可以作为上线后的速查表。问题现象可能原因排查方式解决方案请求整体超时上游供应商响应慢或连接阻塞查看“首包时延”和“总时延”指标区分是哪一段耗时调整对应阶段的超时配置或切换备用供应商首包时间过长上下文过长导致预填充时间增长检查请求的 prompt token 数量优化提示词长度或改用支持长上下文的模型客户端断连但上游仍在消耗未注册断连回调或没有取消上游请求查看网关与上游之间的活动连接数与客户端连接数是否一致在断连回调中取消上游请求释放资源部分租户限流失效限流计数使用了共享变量多实例部署时计数不准确检查网关实例数以及限流是否通过分布式存储实现使用 Redis 等共享存储做原子计数成本账单与网关计量不一致供应商 token 统计口径与网关估算口径不同比对供应商 usage 字段与网关的估算逻辑优先使用供应商 usage 字段建立定期对账任务上游返回 429多个业务方共用账号超过供应商配额查看网关限流日志和供应商配额用量在网关层实施全局并发控制和租户配额回退后结果不符合预期备用供应商的模型能力与主供应商有差异检查日志中的 actual_model 字段明确回退策略必要时关闭某些场景的回退网关内存持续上涨流式响应缓冲未清理或者日志队列积压查看堆内存和日志消费速率在流式转发中避免缓冲整个响应增加背压控制排查时建议遵循“由外到内”的顺序先看客户端收到什么状态码和耗时再看网关日志中的实际供应商和耗时分段最后才看上游的响应详情。不要在刚接手的系统里直接怀疑网关注入的代码逻辑大部分问题其实出在配置和资源边界上。9. 最佳实践与工程建议9.1 秘钥管理与最小权限供应商 API Key 是网关最敏感的资源。生产环境中必须做到密钥不写入代码仓库不写入环境变量明文统一存储在密钥管理服务中网关启动时读取到内存。同时要为不同场景分配不同的 Key比如测试环境和生产环境使用不同的供应商账号避免下游把配额限制互相打满。业务方访问网关的凭证也按照最小权限原则分配每个租户只能使用平台允许的模型月底按租户输出成本报表。9.2 灰度发布与回滚网关的任何变更都要遵循灰度发布原则包括路由策略变更、模型版本切换、网关代码升级。建议把“模型路由配置”和“网关代码”分离管理路由配置通过配置中心实时下发支持秒级回滚代码变更通过标准发布流程经过测试环境验证后再放量。具体灰度时可以先让一个低流量业务方接入新模型路由观察错误率和首包时延没有明显变化再逐步扩大到更多流量。如果新模型上线后效果不达预期直接回滚路由配置即可业务不需要重新发布。9.3 预留关键容量网关的容量规划经常被忽略。很多团队以为只要网关本身无状态就可以无限扩展但实际上游模型的 QPS 配额、Redis 连接数、出网带宽都会成为瓶颈。上线前至少要厘清本地模型未来一段时间预计 QPS、平均 token 长度、流式请求占比、模型供应商配额上限。按照峰值估算后的 1.5 倍预留资源并及时梳理供应商 limit 与网关限流配置的匹配情况。9.4 故障预案生产环境里的很多问题不是暴露在初次上线而是暴露在供应商故障、大流量冲击、配置误操作这些异常时刻。建议针对以下场景单独准备预案主供应商全节点故障、Redis 不可用、配置中心下发错误配置、突发流量超过供应商配额。每个预案至少包含自动降级策略、通知人员、回滚步骤。这里必须强调涉及生产环境的变更都应先在测试环境验证并保留完整的配置备份便于快速恢复。9.5 定期复盘网关运行一段时间后建议每两周或每月做一次成本与稳定性复盘。查一查哪些模型的调用在增长、哪些接口的提示词 token 在膨胀、哪些业务方经常触发限流。这些数据可以直接指导模型选型和成本优化也是网关存在的意义所在不只是当个通道。10. 留给后来者的几条教训LLM 网关的架构并不复杂复杂的是在“平台统一性”和“业务灵活性”之间持续做取舍。第一别把网关设计成“什么都能做”的万能中间件。每增加一个职责网关上线的稳定系数的置信度就下降一截如果新职责本身带有复杂的业务逻辑它在网关上的部署会使模型流量可回归的难度进一步上升。好的网关是在功能边界上非常克制、在可观测性上非常充分的服务。当业务方提出一个新需求时先判断这是不是一个“模型接入通用问题”而是反复要被挑战的。第二路由回退不是越大越全越好。回退链越长响应质量方差越大。你可以让流量在主模型不可用时切到备用模型但一定要把“本次实际用了什么模型”告诉业务方并严格控制回退使用的业务范围。第三流式和同步必须当成两个独立的能力来设计和压测。很多线上事故都源于“同步能通、流式没测透”或“流式能通、断连没处理”。对网关来说稳定不仅仅是“能返回结果”也包括“不泄漏连接、不积压缓冲、不误杀慢请求”。第四成本计量从第一天就要接入。等模型流量上千亿之后再补计量成本分摊会变成一团乱麻。上线第一天就把请求维度 token 记录做好后面只是聚合的问题。第五架构选型没有绝对正确关键是让权衡透明。单网关还是多网关、同步还是流式、状态外置还是状态本地每种选择都有代价。团队决策时把代价讲清楚比单方面追求某种架构“正统”更有价值。如果一个团队能把上面这些问题梳理清楚LLM 网关就不会只是一个代理层而会成为整个团队从“能调模型”走向“能治理模型能力”的关键一步。这也是“生产化”和“能跑通”之间的真正差距。