LLM网关这个词最近被频繁提起但很多团队其实还停留在“直接调各家模型接口然后在业务代码里写重试”的阶段。我做过一段时间模型基础设施相关的工作这里想认真聊一聊网关生产化过程中真正让人头疼的架构权衡以及那些只有把服务部署到线上之后才会暴露出来的教训。如果你正在设计公司内部的统一大模型接入层或者准备把散落在各个业务服务里的 LLM 调用代码抽成一个独立网关这篇文章会比较适合你。我会从“为什么需要网关”讲起一直聊到多租户、成本控制、可观测性和故障复盘。这不是纯概念科普更像一轮完整生产化改造后的经验记录。1. 先想清楚LLM 网关到底在解决什么问题什么时候才需要引入很多团队第一次产生做网关的念头不是因为架构规划而是因为重复劳动。三个业务线都在调模型接口每个服务里都有一份 API Key、一套超时重试逻辑、一份返回结构解析代码。模型服务商那边稍微改一下模型名称或者某个接口超时时间变长所有服务都要跟着改一遍。这时候自然会想能不能在中间加一层统一收口。1.1 直接调各家大模型接口问题出在哪直接调接口本身没有错问题出在规模上来之后。最初只有一个小功能代码里写一个 HTTP 请求就够了。但模型调用一旦散布到多个服务你会连续遇到这几类问题第一模型提供方的接口参数不统一。有的支持max_tokens有的叫max_completion_tokens有的用temperature有的推荐用top_p。聊天消息格式、工具调用格式、流式返回格式都有差异。每个业务开发都要去读不同平台的文档学习成本重复。第二认证和密钥管理混乱。代码里到处出现 API Key环境变量、配置文件、甚至前端代码里都可能有。一旦密钥轮换你根本不知道哪些服务会挂。第三错误处理完全靠各自发挥。上游限流了怎么办超时了重试几次返回 5xx 是直接抛异常还是先降级每家业务都有自己的写法。线上系统真正依赖模型响应时这些细节会放大成故障。第四账单和流量无法统一复盘。每个服务各自记录消耗管理层问“这个月模型花了多少钱、哪些业务消耗最大、哪些请求失败率最高”时你拿不出一份统一报表。1.2 网关层的核心能力清单成熟的 LLM 网关本质上是在模型服务商和业务应用之间加一个统一入口层。它不是简单转发请求而是把大模型接入相关的公共能力集中到一层统一协议转换把业务侧的请求格式转成不同模型服务商需要的格式返回时再转成统一结构。认证与租户隔离校验调用方身份区分团队、项目、环境按不同维度分配额度。限流与配额管理防止某个业务刷爆预算防止单点请求阻塞整个集群。重试、超时、熔断与降级对上游临时故障做容错对长时间不可用做快速失败。模型路由与多模型切换支持按策略选择模型保留主备或灰度切换能力。缓存对幂等请求做语义级缓存降低成本和延迟。审计日志与可观测性记录调用方、模型、消耗 token 数、响应延迟、错误类型。成本核算按租户、项目、模型维度统计消耗输出账单。1.3 什么阶段可以不用网关什么时候必须上网关我的建议是如果业务里只有一两个模块调用模型调用量每天几百次那不需要网关。直接写一个共享库把封装函数、重试逻辑、日志结构统一起来已经能解决 80% 的问题。但出现下面这些信号就该认真考虑网关层了超过三个业务服务直接调模型接口密钥分散在各处。需要做多模型切换或供应商容灾但改动业务代码成本太高。有成本和配额管控需求不能接受某个业务无限调用。需要给前端直接提供模型能力但不想把密钥暴露在浏览器端。安全审计要求记录每一笔模型调用至少要知道谁在何时调用、用了什么模型、输入输出是什么。反过来说如果团队规模很小业务刚验证阶段就别急着上一套完整的网关平台。先跑通业务再考虑集中管控这是更务实的顺序。2. 从方法封装到服务化LLM 网关的三种演进形态与架构选择网关不是一步到位的。大多数团队会经历从“代码函数”到“独立服务”再到“平台化产品”的过程。理解这个演进路径能帮你判断自己正处在哪个阶段以及下一阶段该改什么。2.1 第一阶段业务代码里的统一函数封装最早期的形态是共享库。把chat_completion()、embedding()、count_tokens()这类函数封装到公共库业务方调用库而不是直接写 HTTP 请求。共享库内部可以统一处理 API Key、超时、重试和基础日志。这个方案的优点是很轻改动成本低适合项目初期。缺点是逻辑都拼在调用进程内升级库就需要所有业务服务重新发版。尤其当网关逻辑逐渐膨胀之后每次升级对业务团队都是一次负担。而且每个服务仍然自己维护连接池没有集中式的流量视图。如果你在这个阶段注意别让公共库过于膨胀。做了统一封装还不够还得同时约定返回结构、错误码、重试上限和日志规范。否则每个服务还是各写一套。2.2 第二阶段独立部署的轻量代理服务当公共库已经无法满足集中管控需求团队通常会进入第二阶段把网关拆成独立服务。业务服务不再直接调模型服务商而是统一请求内网网关由网关转发到上游模型供应商。这个阶段有几个关键动作业务应用 - 内网 LLM 网关 - 模型服务商独立网关可以集中做这些事API Key 放在网关环境变量或密钥管理系统中业务侧不再持有。限流、RBAC 权限、租户识别统一实现。请求日志统一落盘方便排查问题和审计。上游模型配置集中在网关层切换模型时业务代码不需要改。但这个阶段也有陷阱。如果网关只是“改了个转发地址”没有补上错误处理、超时、重试和监控它反而会成为新的单点。一旦网关挂掉所有业务的模型能力都不可用。我一般建议在这个阶段就加上基础健康检查、限流、熔断、监控面板和告警。否则独立网关带来的集中风险会大于收益。2.3 第三阶段带控制面、数据面和策略面的平台化网关当使用规模进一步扩大比如多个团队、多条产品线都要接入网关就需要从“代理服务”升级成“平台”。这时候典型的架构会分成几个面数据面负责实际转发请求。高并发、低延迟处理流式响应、重连、缓冲。控制面负责配置下发、模型路由、灰度策略、租户配额管理。策略引擎负责把认证、限流、缓存、审计、内容过滤等策略从代码中抽出来做成可配置规则。平台化的核心价值是标准化模型供应商从两家变成五家新增一家不需要每个业务都改代码新租户接入时不需要开发专门给自己定制逻辑模型切换通过控制台操作不用发版。平台化也会带来复杂性控制面和数据面之间需要同步配置多副本网关的限流需要分布式计数配置错误可能影响所有租户。所以平台化不是越高越好要和你公司的业务规模匹配。有超过五个业务团队、每月模型调用量达到百万次级别时平台化收益会变得明显。3. 关键架构权衡中心化、边车、厚薄网关与异步改造生产化过程中最难的往往不是功能开发而是架构取舍。同一个问题换一个团队、换一批业务最佳答案不同。下面这几个权衡点我基本每次设计网关都要重新过一遍。3.1 中心化网关和边车网关怎么选中心化网关像公司里统一的 API 网关所有流量先集中到这里再分发给上游模型服务。它的优势是集中治理、全局视野、配额管控方便、密钥不会散落到业务侧。适合多团队共享模型能力的场景。它的代价也很明显请求多一跳延迟多了几毫秒到十几毫秒网关成为潜在单点必须做高可用流量集中后限流逻辑要支持分布式。边车网关则在每个业务服务旁边部署一个本地进程业务请求先走本机边车再由边车转发到模型服务商。这种模式借鉴了服务网格的思路优点是延迟低、故障爆炸半径小、单个业务网关可以按自己的节奏升级。边车的缺点是治理分散。每个业务网关的配置如果不同最终又会演化成“各写各的规则”。而且边车数量多了以后运维成本不会比中心化低限流和配额同样需要控制面来收口。我个人建议大模型能力在公司内部是“共享基础设施”时优先中心化。某个业务对延迟极度敏感、且模型能力只被这个业务独享时边车方案更合适。混合模式也常见核心高并发业务用边车普通业务走中心网关。3.2 薄网关与厚网关别让业务逻辑住进网关薄网关只做“转发 鉴权 基础限流 日志”大部分处理和业务语义都留在业务服务里。优点是逻辑清晰、职责单一、不容易出现网关层乱改请求导致业务回归。适合模型能力比较单一、调用方自己知道怎么处理参数的场景。厚网关则会在网关内做 Prompt 模板管理、语义缓存、RAG 检索、模型路由、内容改写、A/B 测试等复杂逻辑。好处是业务方接入简单但坏处是网关和强耦合改动风险变大。我见过最容易失败的情况是把业务逻辑越堆越多业务 A 要在网关注入一个 Prompt 模板业务 B 希望在网关层做向量检索业务 C 想在网关里做输出格式化。最后网关变成一个大泥球上线一个功能影响所有调用方排障困难。更稳妥的做法是让网关保持相对薄业务强相关的逻辑放在业务侧或独立插件层。网关只统一接入、安全、路由、可观测性和基础策略。如果确实需要扩展考虑插件机制而不是把所有功能都硬编码进网关主流程。3.3 同步转发还是异步任务取决于上游响应速度和用户体验模型接口分为两种同步返回结果和异步任务。同步模式下网关请求上游等待结果返回异步模式下网关先把任务提交到队列拿到任务 ID然后通过轮询或回调获取结果。同步适合大多数交互式场景比如聊天、单轮问答、代码生成预览。异步适合长耗时任务比如批量文档摘要、视频字幕生成、复杂 Agent 任务链。网关设计时要同时支持这两种类型。同步链路重点关注超时、流式响应和连接池大小异步链路重点关注任务队列、状态存储、回调通知和失败重试。很多团队只做了同步等遇到批量任务后才发现网关缺少“任务级”的状态管理。如果同步请求特别多还要考虑流式响应。模型边生成边返回用户体验更顺滑。流式模式下网关不只是转发一个响应体而是要转发一个持续输出的事件流同时把原生流格式转成业务侧统一的流格式。这比普通转发复杂需要注意缓冲、断连、心跳和客户端取消请求时是否及时断掉上游连接。4. 生产化必修课认证、重试、缓存、成本与可观测性一个网关能在本地跑通 Demo并不代表它能上线。真正进入生产环境有五个能力必须补齐。它们不是“额外加分项”而是稳定性的底线。4.1 认证、租户隔离与额度管理生产环境里网关不能是“谁拿到地址就能调”。第一步是统一认证。常见做法是给每个调用方分配一个服务账号或 API Key走网关时校验身份再根据身份决定它属于哪个租户、哪个项目、有哪些模型权限。租户隔离不只是“登录认证”的问题还包括数据隔离日志、用量、配置不可跨租户查看。配额隔离一个租户的调用量不能耗尽另一个租户的额度。速率隔离一个租户的大量请求不能打垮共享网关。额度管理要区分两层一层是上游模型服务商的预算另一层是公司内部各业务的预算。网关需要同时约束这两层。比如某业务每天最多只能消耗 500 万 token一旦超了就限流或告警。密钥管理也必须在网关层收口。API Key只存在于网关的配置中心或密钥管理系统里业务服务不应该持有模型服务商的密钥。这样密钥轮换只影响网关不影响几十个下游服务。4.2 超时、重试、熔断与降级策略模型 API 的稳定性通常比传统接口更差。高峰期延迟可能从 1 秒涨到 10 秒限流返回率也会飙升。所以网关必须有完整的容错策略。超时设置要分层。连接超时、读取超时和总请求超时要分开。模型响应通常是流式的如果只看“连接超时”可能发现连接已经建立但一直等不到第一个 token。更稳妥的判断标准是“首 token 延迟”和“总响应时间”。重试策略要克制。模型接口的 429 和 5xx 可以重试但要加抖动和退避。不要做成“失败就无限重试”否则上游故障时网关会变成放大故障的放大器。更安全的做法是设置最多 2 到 3 次重试每次重试间隔随时间指数退避并增加随机抖动。熔断更关键。当某个模型服务商连续出现高错误率或高延迟时网关应该自动进入熔断状态快速失败或把请求切换到备用模型而不是继续往坏的上游打流量。熔断恢复也要小心可以先用少量流量试探确认上游恢复后再放全量。降级策略至少有两种一是模型降级比如主模型失败后切换到备用模型或更便宜的模型二是功能降级比如模型不可用时直接返回缓存结果或者提示用户稍后再试。具体降级方式要看业务容忍度但网关至少要能给业务提供“降级结果”的通道。4.3 缓存、路由策略与成本控制模型调用成本不低缓存是最有效的成本控制手段之一。适合缓存的请求通常是确定性的相同输入模型参数固定输出可以复用。例如特定文案的分类、固定模板的摘要、初步判题或相似问题答案。缓存要注意几个细节不要只看完整字符串完全相等。语义缓存可以做到“问法不同但语义相似”时复用结果但实现复杂度和服务质量评估都更重。缓存 key 要包含模型、参数、Prompt 哈希。否则同一问题在不同模型之间复用缓存结果可能不一致。缓存要有过期策略和失效机制。模型版本更新后旧缓存可能需要清理。日志里要标注“是否命中缓存”方便评估命中率和成本节省。路由策略是另一个成本杠杆。不同模型价格差别很大网关可以根据请求的复杂度、调用方身份、目标时延要求选择不同模型。比如内部测试用便宜模型生产环境用高性能模型简单请求用小模型复杂推理用大模型。还可以在高峰期把部分请求降级到低档模型保证整体吞吐。成本控制不能只做“事后统计”要做“事中限制”。网关需要实时统计 token 消耗在接近预算阈值时降级或阻断新增请求。比如某租户月度预算是 1000 元跑掉 900 元时就要告警超过 1000 元时直接拒绝新请求等待人工审批。4.4 日志、指标、追踪与告警模型网关的排障问题和普通服务不一样。输入是一段文本或对话输出是生成结果出问题时不一定是“报错”也可能是“生成质量差”。所以可观测性要兼顾系统指标和业务内容指标。关键指标至少包括请求总量、成功量、失败量、限流量。首 token 延迟TTFT和总延迟。不同租户、不同模型、不同接口维度的消耗 token 数。上游各供应商的错误率和延迟分布。缓存命中率。重试次数和熔断次数。日志要记录请求 ID、租户、调用方、模型、输入摘要、输出摘要或完整内容、消耗 token、延迟、错误码。如果业务涉及敏感数据还要评估是否需要对输入输出做脱敏或加密存储。追踪需要把一次请求链路串起来业务服务到网关网关到模型供应商模型供应商内部如果返回延迟是靠哪一段。网关最好能生成 trace ID并能和业务服务的 trace 体系打通。故障时通过 trace ID 能快速定位到具体请求。告警不能只看“进程是否存活”还要关注看不见的劣化。比如某个模型供应商延迟从 2 秒涨到 8 秒但还没到超时上限前端已经感觉到变慢或者某个租户的失败率在缓步爬升但总量不大。建议设置差异化告警阈值总额错误率、单租户错误率、延迟分位数、配额接近上限。4.5 输入输出过滤与内容合规生产网关处理的是真实业务请求输入输出都可能包含内部敏感信息或不合规内容。网关需要在转发前后做过滤。输入过滤主要防止两类问题一是敏感数据外泄比如日志、代码、客户信息等不应该被发送到外部模型服务商的文本被误传二是注入类风险虽然这更多是业务和应用层的责任但网关可以在边界加一层防护。输出过滤主要是对模型生成内容做合规校验。比较常见的处理方式是把输入输出接到内容审核服务命中风险词或风险类别时阻断返回或告警。过滤本身也有成本和误杀风险。如果策略太严格会导致某些正常请求被误拦截太宽松又形同虚设。建议按租户或业务场景配置不同严格程度并保留人工复审通道。5. 我踩过的网关坑重试风暴、缓存污染与日志失控这一节写的是真实运维里比较容易踩中的问题。这些问题在文档和 Demo 里不容易暴露但只要线上流量一上来就会逐个爆出来。5.1 重试风暴集中式网关放大了上游故障我第一次做网关时给所有上游异常配置了最多三次重试三次之间退避一秒、两秒、四秒。单看这个策略没有大问题但忽略了“并发放大”的效应。某天一个模型供应商出现 5 分钟故障网关同时在处理几百个请求。每个请求都重试三次上游收到的流量瞬间变成原来的四五倍。上游恢复后这些积压请求又同时冲进去导致新的限流和超时故障时间被拉长。后来调整了几个策略重试前检查上游状态如果熔断打开直接快速失败。根据错误类型决定是否重试网络错误和 5xx 可以重试4xx 一般不建议重试429 要等 Retry-After 头。加随机抖动避免同一时间点大量请求重试。对批量任务优先用消息队列做异步重试而不是同步阻塞重试。网关不光是入口也是流量阀门。重试逻辑做不好它会变成故障放大器让一个小问题变成全局故障。5.2 缓存污染相同前缀或模糊哈希会踩出什么问题缓存看起来很简单输入一样就返回一样的结果。但实际用起来有很多边角情况。有一段时间我们给网关加了语义缓存按输入文本的向量相似度判断是否复用结果。刚开始测试效果很好很多相似问题都命中缓存。后来出现了一个诡异问题用户输入“帮我改写这段话让它更正式”碰巧和另一个用户“帮我改写这段话让它更幽默”在向量空间里相似度很高于是直接返回了幽默版改写结果。这就是语义缓存的误命中。这类问题不是机器 bug而是缓存策略过度激进。如果你的业务对输出多样性要求很高不要轻易用语义缓存。确定性强、输出可复现的任务才适合语义复用。普通哈希缓存相对安全但也要注意 key 的设计。如果把整个请求体做 JSON 序列化后哈希客户端调整一下字段顺序就会 miss如果只取 Prompt 内容做哈希又可能忽略温度参数变化导致的输出差异。更稳的做法是key 由租户、模型、请求参数和归一化后的输入文本共同计算。5.3 日志与审计量一大成本比模型费用还高模型调用日志和其他日志最大的区别就是体积大。一次请求如果记录完整输入输出几百 token 还好几千 token 的长文本一次就是几 KB 到几十 KB。一天百万次调用日志存储量就会非常可怕。我有一次在季度复盘时发现日志存储和检索费用已经接近模型调用费用的一半。这才意识到日志不是“存得越多越好”要分级处理全量请求元数据必须存保留期按审计要求但只存请求 ID、租户、模型、token 数、延迟、错误码不存完整内容。输入输出内容默认不落库只有开启了“内容审计”的租户才保留且设置短保留期。异常样本只存失败请求、限流请求、高延迟请求。采样日志对大批量重复请求做百分比采样用于质量分析。日志治理不是上线后才做的事。网关设计阶段就要想清楚哪些必存、哪些选存、哪些不存。不然等到日志量上来再改会非常被动。5.4 配置和灰度网关版本升级不一定是平滑的网关升级和普通业务服务升级不太一样。它直接影响所有调用方而且模型供应商的接口结构也会变。我们曾遇到一次网关升级只是修改了内部连接池配置结果因为配置下发顺序不一致部分节点是旧配置、部分节点是新配置导致流量分配不均一批请求超时。生产环境里网关升级至少要遵守几条先在小流量环境或灰度租户验证确认指标正常再放全量。配置变更和代码变更分开做不要在一次发布里同时改代码、改配置、换模型路由。升级前记录当前版本的关键指标基线升级后逐个对比不要只看“没有报错”。核心网关服务建议做蓝绿发布或金丝雀发布不要原地重启。另外网关配置和模型配置最好进入版本管理。每次变更都能回溯到“哪个配置、什么时间、由谁改的、影响哪些租户”。5.5 不要把网关做成“万能中间件”也不要把策略写死在代码里网关非常容易往“万能中间件”方向演化。今天加一个 Prompt 优化模块明天加一个向量检索后天加一个内容改写。每次看起来都很合理但积累一年后网关代码会非常重。我倾向于把网关拆成两层核心转发层和策略插件层。核心转发层保持稳定只做协议转换、认证、路由、限流、缓存、日志这些基础能力。策略插件层处理具体业务规则通过配置文件或独立服务注册进来。策略也不要写死在代码里。比如“哪个租户可以用哪个模型”“哪些场景需要内容审核”“重试次数是多少”这些都应该配置化。配置化是为了让运维和平台团队在故障时能快速调整不需要发版。但配置过多也会带来“配置爆炸”问题所以还需要配套默认值和校验规则。6. 生产化路线图与判断标准从内部工具走向多租户平台最后聊一聊网关的落地路线。很多团队卡在“准备好了所有组件但不知道怎么排期”。下面是我认为比较合理的推进顺序以及每一步的验收标准。6.1 起步期先保证单租户能稳定跑起来第一步不要做多租户不要做复杂路由不要引入几十个插件。先把最小可用闭环跑通一个网关注入统一的鉴权方式。支持至少两家模型服务商接入能按配置切换。实现基础限流、重试、超时和日志。接入最核心的业务调用取消这些业务直连模型服务商的密钥。监控面板能实时看到请求量、失败率、延迟和 token 消耗。验收标准核心业务已经通过网关调用模型持续运行一个月没有出现因网关导致的严重故障排障时通过看网关日志能找到问题密钥已经从业务环境变量中移除。6.2 扩展期从单环境到多环境从自用到开放起步期跑稳之后再开始扩展增加多环境支持开发、测试、生产环境独立网关但共享控制面板和策略模型。增加租户和配额管理不同团队申请独立 Key配置不同模型权限和预算上限。增加缓存、语义路由、内容审核等增强能力。完善告警体系支持按租户和模型维度做告警。提供自助接入文档让新业务可以不依赖研发团队自己接入。验收标准有 5 个以上业务团队通过自助方式接入网关每个租户能查看自己的调用量、费用和错误日志业务方不需要知道模型服务商的密钥也能完成模型调用。6.3 成熟期平台化运营的指标与组织配套到这个阶段网关已经不只是工具而是公司内部的模型基础设施平台。重点关注成本分摊每月自动生成各租户的费用账单支持按项目维度拆分。模型治理对模型版本、供应商、废弃模型做统一管理避免业务继续使用下线模型。稳定性保障建立 SLO比如“网关可用性 99.9%”“p95 延迟低于 X 秒”并按季度复盘。故障演练定期模拟上游模型故障、网关单节点宕机、限流触发确认降级策略有效。容量规划根据业务增长趋势预估模型调用量和网关资源需求。成熟期的难点不是技术而是组织协同。网关平台必须有明确负责人模型采购、成本预算、安全合规、业务接入评审每个环节都要有人拍板。如果只靠一个开发团队义务维护最终会因资源不足而停滞。6.4 落地检查清单如果你准备在公司内部启动 LLM 网关项目可以按这张清单自我检查项目判断标准接入方式业务方不需要持有模型服务商 API Key只需持有网关颁发的密钥协议兼容至少兼容两家主流模型服务商且能统一返回结构流式支持聊天、补全类请求支持标准流式返回限流与配额支持按租户、按模型、按接口配置配额和速率限制重试与熔断有重试次数限制、指数退避、快速失败和上游熔断机制缓存策略有明确缓存命中率指标能按租户控制是否启用缓存和过期时间日志与审计有全量元数据日志和可选的内容留存策略可观测性有延迟、错误率、token 消耗、限流数、缓存命中率等核心指标内容合规支持输入输出过滤可按租户配置严格程度配置管理模型路由、限流阈值、配额等配置支持灰度发布和版本回滚成本核算能生成按月、按租户、按模型的费用报表故障预案有上游故障、网关节点宕机、流量突增三类演练记录最后留几句经验LLM 网关不是“搭一个代理服务”那么简单。它真正的价值是把模型调用从“业务开发自己处理”变成“平台统一治理”。它在架构层面需要做的权衡不比业务系统少甚至更复杂因为上游模型服务商的行为你控制不了只能适应和兜底。如果你现在正准备做网关我的核心建议是先画清楚调用链和收益场景不要为了“架构完整性”去建一个庞大平台。从单租户最小闭环开始跑稳一个月再考虑多租户和平台化。踩过几次故障之后你会发现很多问题不是网关能力不够而是重试策略太激进、日志没有治理、配置改得太随意、上游状态没有感知。把这些基础问题先解决掉网关的稳定性就会上来一大截。
LLM网关这个词最近被频繁提起但很多团队其实还停留在“直接调各家模型接口然后在业务代码里写重试”的阶段。我做过一段时间模型基础设施相关的工作这里想认真聊一聊网关生产化过程中真正让人头疼的架构权衡以及那些只有把服务部署到线上之后才会暴露出来的教训。如果你正在设计公司内部的统一大模型接入层或者准备把散落在各个业务服务里的 LLM 调用代码抽成一个独立网关这篇文章会比较适合你。我会从“为什么需要网关”讲起一直聊到多租户、成本控制、可观测性和故障复盘。这不是纯概念科普更像一轮完整生产化改造后的经验记录。1. 先想清楚LLM 网关到底在解决什么问题什么时候才需要引入很多团队第一次产生做网关的念头不是因为架构规划而是因为重复劳动。三个业务线都在调模型接口每个服务里都有一份 API Key、一套超时重试逻辑、一份返回结构解析代码。模型服务商那边稍微改一下模型名称或者某个接口超时时间变长所有服务都要跟着改一遍。这时候自然会想能不能在中间加一层统一收口。1.1 直接调各家大模型接口问题出在哪直接调接口本身没有错问题出在规模上来之后。最初只有一个小功能代码里写一个 HTTP 请求就够了。但模型调用一旦散布到多个服务你会连续遇到这几类问题第一模型提供方的接口参数不统一。有的支持max_tokens有的叫max_completion_tokens有的用temperature有的推荐用top_p。聊天消息格式、工具调用格式、流式返回格式都有差异。每个业务开发都要去读不同平台的文档学习成本重复。第二认证和密钥管理混乱。代码里到处出现 API Key环境变量、配置文件、甚至前端代码里都可能有。一旦密钥轮换你根本不知道哪些服务会挂。第三错误处理完全靠各自发挥。上游限流了怎么办超时了重试几次返回 5xx 是直接抛异常还是先降级每家业务都有自己的写法。线上系统真正依赖模型响应时这些细节会放大成故障。第四账单和流量无法统一复盘。每个服务各自记录消耗管理层问“这个月模型花了多少钱、哪些业务消耗最大、哪些请求失败率最高”时你拿不出一份统一报表。1.2 网关层的核心能力清单成熟的 LLM 网关本质上是在模型服务商和业务应用之间加一个统一入口层。它不是简单转发请求而是把大模型接入相关的公共能力集中到一层统一协议转换把业务侧的请求格式转成不同模型服务商需要的格式返回时再转成统一结构。认证与租户隔离校验调用方身份区分团队、项目、环境按不同维度分配额度。限流与配额管理防止某个业务刷爆预算防止单点请求阻塞整个集群。重试、超时、熔断与降级对上游临时故障做容错对长时间不可用做快速失败。模型路由与多模型切换支持按策略选择模型保留主备或灰度切换能力。缓存对幂等请求做语义级缓存降低成本和延迟。审计日志与可观测性记录调用方、模型、消耗 token 数、响应延迟、错误类型。成本核算按租户、项目、模型维度统计消耗输出账单。1.3 什么阶段可以不用网关什么时候必须上网关我的建议是如果业务里只有一两个模块调用模型调用量每天几百次那不需要网关。直接写一个共享库把封装函数、重试逻辑、日志结构统一起来已经能解决 80% 的问题。但出现下面这些信号就该认真考虑网关层了超过三个业务服务直接调模型接口密钥分散在各处。需要做多模型切换或供应商容灾但改动业务代码成本太高。有成本和配额管控需求不能接受某个业务无限调用。需要给前端直接提供模型能力但不想把密钥暴露在浏览器端。安全审计要求记录每一笔模型调用至少要知道谁在何时调用、用了什么模型、输入输出是什么。反过来说如果团队规模很小业务刚验证阶段就别急着上一套完整的网关平台。先跑通业务再考虑集中管控这是更务实的顺序。2. 从方法封装到服务化LLM 网关的三种演进形态与架构选择网关不是一步到位的。大多数团队会经历从“代码函数”到“独立服务”再到“平台化产品”的过程。理解这个演进路径能帮你判断自己正处在哪个阶段以及下一阶段该改什么。2.1 第一阶段业务代码里的统一函数封装最早期的形态是共享库。把chat_completion()、embedding()、count_tokens()这类函数封装到公共库业务方调用库而不是直接写 HTTP 请求。共享库内部可以统一处理 API Key、超时、重试和基础日志。这个方案的优点是很轻改动成本低适合项目初期。缺点是逻辑都拼在调用进程内升级库就需要所有业务服务重新发版。尤其当网关逻辑逐渐膨胀之后每次升级对业务团队都是一次负担。而且每个服务仍然自己维护连接池没有集中式的流量视图。如果你在这个阶段注意别让公共库过于膨胀。做了统一封装还不够还得同时约定返回结构、错误码、重试上限和日志规范。否则每个服务还是各写一套。2.2 第二阶段独立部署的轻量代理服务当公共库已经无法满足集中管控需求团队通常会进入第二阶段把网关拆成独立服务。业务服务不再直接调模型服务商而是统一请求内网网关由网关转发到上游模型供应商。这个阶段有几个关键动作业务应用 - 内网 LLM 网关 - 模型服务商独立网关可以集中做这些事API Key 放在网关环境变量或密钥管理系统中业务侧不再持有。限流、RBAC 权限、租户识别统一实现。请求日志统一落盘方便排查问题和审计。上游模型配置集中在网关层切换模型时业务代码不需要改。但这个阶段也有陷阱。如果网关只是“改了个转发地址”没有补上错误处理、超时、重试和监控它反而会成为新的单点。一旦网关挂掉所有业务的模型能力都不可用。我一般建议在这个阶段就加上基础健康检查、限流、熔断、监控面板和告警。否则独立网关带来的集中风险会大于收益。2.3 第三阶段带控制面、数据面和策略面的平台化网关当使用规模进一步扩大比如多个团队、多条产品线都要接入网关就需要从“代理服务”升级成“平台”。这时候典型的架构会分成几个面数据面负责实际转发请求。高并发、低延迟处理流式响应、重连、缓冲。控制面负责配置下发、模型路由、灰度策略、租户配额管理。策略引擎负责把认证、限流、缓存、审计、内容过滤等策略从代码中抽出来做成可配置规则。平台化的核心价值是标准化模型供应商从两家变成五家新增一家不需要每个业务都改代码新租户接入时不需要开发专门给自己定制逻辑模型切换通过控制台操作不用发版。平台化也会带来复杂性控制面和数据面之间需要同步配置多副本网关的限流需要分布式计数配置错误可能影响所有租户。所以平台化不是越高越好要和你公司的业务规模匹配。有超过五个业务团队、每月模型调用量达到百万次级别时平台化收益会变得明显。3. 关键架构权衡中心化、边车、厚薄网关与异步改造生产化过程中最难的往往不是功能开发而是架构取舍。同一个问题换一个团队、换一批业务最佳答案不同。下面这几个权衡点我基本每次设计网关都要重新过一遍。3.1 中心化网关和边车网关怎么选中心化网关像公司里统一的 API 网关所有流量先集中到这里再分发给上游模型服务。它的优势是集中治理、全局视野、配额管控方便、密钥不会散落到业务侧。适合多团队共享模型能力的场景。它的代价也很明显请求多一跳延迟多了几毫秒到十几毫秒网关成为潜在单点必须做高可用流量集中后限流逻辑要支持分布式。边车网关则在每个业务服务旁边部署一个本地进程业务请求先走本机边车再由边车转发到模型服务商。这种模式借鉴了服务网格的思路优点是延迟低、故障爆炸半径小、单个业务网关可以按自己的节奏升级。边车的缺点是治理分散。每个业务网关的配置如果不同最终又会演化成“各写各的规则”。而且边车数量多了以后运维成本不会比中心化低限流和配额同样需要控制面来收口。我个人建议大模型能力在公司内部是“共享基础设施”时优先中心化。某个业务对延迟极度敏感、且模型能力只被这个业务独享时边车方案更合适。混合模式也常见核心高并发业务用边车普通业务走中心网关。3.2 薄网关与厚网关别让业务逻辑住进网关薄网关只做“转发 鉴权 基础限流 日志”大部分处理和业务语义都留在业务服务里。优点是逻辑清晰、职责单一、不容易出现网关层乱改请求导致业务回归。适合模型能力比较单一、调用方自己知道怎么处理参数的场景。厚网关则会在网关内做 Prompt 模板管理、语义缓存、RAG 检索、模型路由、内容改写、A/B 测试等复杂逻辑。好处是业务方接入简单但坏处是网关和强耦合改动风险变大。我见过最容易失败的情况是把业务逻辑越堆越多业务 A 要在网关注入一个 Prompt 模板业务 B 希望在网关层做向量检索业务 C 想在网关里做输出格式化。最后网关变成一个大泥球上线一个功能影响所有调用方排障困难。更稳妥的做法是让网关保持相对薄业务强相关的逻辑放在业务侧或独立插件层。网关只统一接入、安全、路由、可观测性和基础策略。如果确实需要扩展考虑插件机制而不是把所有功能都硬编码进网关主流程。3.3 同步转发还是异步任务取决于上游响应速度和用户体验模型接口分为两种同步返回结果和异步任务。同步模式下网关请求上游等待结果返回异步模式下网关先把任务提交到队列拿到任务 ID然后通过轮询或回调获取结果。同步适合大多数交互式场景比如聊天、单轮问答、代码生成预览。异步适合长耗时任务比如批量文档摘要、视频字幕生成、复杂 Agent 任务链。网关设计时要同时支持这两种类型。同步链路重点关注超时、流式响应和连接池大小异步链路重点关注任务队列、状态存储、回调通知和失败重试。很多团队只做了同步等遇到批量任务后才发现网关缺少“任务级”的状态管理。如果同步请求特别多还要考虑流式响应。模型边生成边返回用户体验更顺滑。流式模式下网关不只是转发一个响应体而是要转发一个持续输出的事件流同时把原生流格式转成业务侧统一的流格式。这比普通转发复杂需要注意缓冲、断连、心跳和客户端取消请求时是否及时断掉上游连接。4. 生产化必修课认证、重试、缓存、成本与可观测性一个网关能在本地跑通 Demo并不代表它能上线。真正进入生产环境有五个能力必须补齐。它们不是“额外加分项”而是稳定性的底线。4.1 认证、租户隔离与额度管理生产环境里网关不能是“谁拿到地址就能调”。第一步是统一认证。常见做法是给每个调用方分配一个服务账号或 API Key走网关时校验身份再根据身份决定它属于哪个租户、哪个项目、有哪些模型权限。租户隔离不只是“登录认证”的问题还包括数据隔离日志、用量、配置不可跨租户查看。配额隔离一个租户的调用量不能耗尽另一个租户的额度。速率隔离一个租户的大量请求不能打垮共享网关。额度管理要区分两层一层是上游模型服务商的预算另一层是公司内部各业务的预算。网关需要同时约束这两层。比如某业务每天最多只能消耗 500 万 token一旦超了就限流或告警。密钥管理也必须在网关层收口。API Key只存在于网关的配置中心或密钥管理系统里业务服务不应该持有模型服务商的密钥。这样密钥轮换只影响网关不影响几十个下游服务。4.2 超时、重试、熔断与降级策略模型 API 的稳定性通常比传统接口更差。高峰期延迟可能从 1 秒涨到 10 秒限流返回率也会飙升。所以网关必须有完整的容错策略。超时设置要分层。连接超时、读取超时和总请求超时要分开。模型响应通常是流式的如果只看“连接超时”可能发现连接已经建立但一直等不到第一个 token。更稳妥的判断标准是“首 token 延迟”和“总响应时间”。重试策略要克制。模型接口的 429 和 5xx 可以重试但要加抖动和退避。不要做成“失败就无限重试”否则上游故障时网关会变成放大故障的放大器。更安全的做法是设置最多 2 到 3 次重试每次重试间隔随时间指数退避并增加随机抖动。熔断更关键。当某个模型服务商连续出现高错误率或高延迟时网关应该自动进入熔断状态快速失败或把请求切换到备用模型而不是继续往坏的上游打流量。熔断恢复也要小心可以先用少量流量试探确认上游恢复后再放全量。降级策略至少有两种一是模型降级比如主模型失败后切换到备用模型或更便宜的模型二是功能降级比如模型不可用时直接返回缓存结果或者提示用户稍后再试。具体降级方式要看业务容忍度但网关至少要能给业务提供“降级结果”的通道。4.3 缓存、路由策略与成本控制模型调用成本不低缓存是最有效的成本控制手段之一。适合缓存的请求通常是确定性的相同输入模型参数固定输出可以复用。例如特定文案的分类、固定模板的摘要、初步判题或相似问题答案。缓存要注意几个细节不要只看完整字符串完全相等。语义缓存可以做到“问法不同但语义相似”时复用结果但实现复杂度和服务质量评估都更重。缓存 key 要包含模型、参数、Prompt 哈希。否则同一问题在不同模型之间复用缓存结果可能不一致。缓存要有过期策略和失效机制。模型版本更新后旧缓存可能需要清理。日志里要标注“是否命中缓存”方便评估命中率和成本节省。路由策略是另一个成本杠杆。不同模型价格差别很大网关可以根据请求的复杂度、调用方身份、目标时延要求选择不同模型。比如内部测试用便宜模型生产环境用高性能模型简单请求用小模型复杂推理用大模型。还可以在高峰期把部分请求降级到低档模型保证整体吞吐。成本控制不能只做“事后统计”要做“事中限制”。网关需要实时统计 token 消耗在接近预算阈值时降级或阻断新增请求。比如某租户月度预算是 1000 元跑掉 900 元时就要告警超过 1000 元时直接拒绝新请求等待人工审批。4.4 日志、指标、追踪与告警模型网关的排障问题和普通服务不一样。输入是一段文本或对话输出是生成结果出问题时不一定是“报错”也可能是“生成质量差”。所以可观测性要兼顾系统指标和业务内容指标。关键指标至少包括请求总量、成功量、失败量、限流量。首 token 延迟TTFT和总延迟。不同租户、不同模型、不同接口维度的消耗 token 数。上游各供应商的错误率和延迟分布。缓存命中率。重试次数和熔断次数。日志要记录请求 ID、租户、调用方、模型、输入摘要、输出摘要或完整内容、消耗 token、延迟、错误码。如果业务涉及敏感数据还要评估是否需要对输入输出做脱敏或加密存储。追踪需要把一次请求链路串起来业务服务到网关网关到模型供应商模型供应商内部如果返回延迟是靠哪一段。网关最好能生成 trace ID并能和业务服务的 trace 体系打通。故障时通过 trace ID 能快速定位到具体请求。告警不能只看“进程是否存活”还要关注看不见的劣化。比如某个模型供应商延迟从 2 秒涨到 8 秒但还没到超时上限前端已经感觉到变慢或者某个租户的失败率在缓步爬升但总量不大。建议设置差异化告警阈值总额错误率、单租户错误率、延迟分位数、配额接近上限。4.5 输入输出过滤与内容合规生产网关处理的是真实业务请求输入输出都可能包含内部敏感信息或不合规内容。网关需要在转发前后做过滤。输入过滤主要防止两类问题一是敏感数据外泄比如日志、代码、客户信息等不应该被发送到外部模型服务商的文本被误传二是注入类风险虽然这更多是业务和应用层的责任但网关可以在边界加一层防护。输出过滤主要是对模型生成内容做合规校验。比较常见的处理方式是把输入输出接到内容审核服务命中风险词或风险类别时阻断返回或告警。过滤本身也有成本和误杀风险。如果策略太严格会导致某些正常请求被误拦截太宽松又形同虚设。建议按租户或业务场景配置不同严格程度并保留人工复审通道。5. 我踩过的网关坑重试风暴、缓存污染与日志失控这一节写的是真实运维里比较容易踩中的问题。这些问题在文档和 Demo 里不容易暴露但只要线上流量一上来就会逐个爆出来。5.1 重试风暴集中式网关放大了上游故障我第一次做网关时给所有上游异常配置了最多三次重试三次之间退避一秒、两秒、四秒。单看这个策略没有大问题但忽略了“并发放大”的效应。某天一个模型供应商出现 5 分钟故障网关同时在处理几百个请求。每个请求都重试三次上游收到的流量瞬间变成原来的四五倍。上游恢复后这些积压请求又同时冲进去导致新的限流和超时故障时间被拉长。后来调整了几个策略重试前检查上游状态如果熔断打开直接快速失败。根据错误类型决定是否重试网络错误和 5xx 可以重试4xx 一般不建议重试429 要等 Retry-After 头。加随机抖动避免同一时间点大量请求重试。对批量任务优先用消息队列做异步重试而不是同步阻塞重试。网关不光是入口也是流量阀门。重试逻辑做不好它会变成故障放大器让一个小问题变成全局故障。5.2 缓存污染相同前缀或模糊哈希会踩出什么问题缓存看起来很简单输入一样就返回一样的结果。但实际用起来有很多边角情况。有一段时间我们给网关加了语义缓存按输入文本的向量相似度判断是否复用结果。刚开始测试效果很好很多相似问题都命中缓存。后来出现了一个诡异问题用户输入“帮我改写这段话让它更正式”碰巧和另一个用户“帮我改写这段话让它更幽默”在向量空间里相似度很高于是直接返回了幽默版改写结果。这就是语义缓存的误命中。这类问题不是机器 bug而是缓存策略过度激进。如果你的业务对输出多样性要求很高不要轻易用语义缓存。确定性强、输出可复现的任务才适合语义复用。普通哈希缓存相对安全但也要注意 key 的设计。如果把整个请求体做 JSON 序列化后哈希客户端调整一下字段顺序就会 miss如果只取 Prompt 内容做哈希又可能忽略温度参数变化导致的输出差异。更稳的做法是key 由租户、模型、请求参数和归一化后的输入文本共同计算。5.3 日志与审计量一大成本比模型费用还高模型调用日志和其他日志最大的区别就是体积大。一次请求如果记录完整输入输出几百 token 还好几千 token 的长文本一次就是几 KB 到几十 KB。一天百万次调用日志存储量就会非常可怕。我有一次在季度复盘时发现日志存储和检索费用已经接近模型调用费用的一半。这才意识到日志不是“存得越多越好”要分级处理全量请求元数据必须存保留期按审计要求但只存请求 ID、租户、模型、token 数、延迟、错误码不存完整内容。输入输出内容默认不落库只有开启了“内容审计”的租户才保留且设置短保留期。异常样本只存失败请求、限流请求、高延迟请求。采样日志对大批量重复请求做百分比采样用于质量分析。日志治理不是上线后才做的事。网关设计阶段就要想清楚哪些必存、哪些选存、哪些不存。不然等到日志量上来再改会非常被动。5.4 配置和灰度网关版本升级不一定是平滑的网关升级和普通业务服务升级不太一样。它直接影响所有调用方而且模型供应商的接口结构也会变。我们曾遇到一次网关升级只是修改了内部连接池配置结果因为配置下发顺序不一致部分节点是旧配置、部分节点是新配置导致流量分配不均一批请求超时。生产环境里网关升级至少要遵守几条先在小流量环境或灰度租户验证确认指标正常再放全量。配置变更和代码变更分开做不要在一次发布里同时改代码、改配置、换模型路由。升级前记录当前版本的关键指标基线升级后逐个对比不要只看“没有报错”。核心网关服务建议做蓝绿发布或金丝雀发布不要原地重启。另外网关配置和模型配置最好进入版本管理。每次变更都能回溯到“哪个配置、什么时间、由谁改的、影响哪些租户”。5.5 不要把网关做成“万能中间件”也不要把策略写死在代码里网关非常容易往“万能中间件”方向演化。今天加一个 Prompt 优化模块明天加一个向量检索后天加一个内容改写。每次看起来都很合理但积累一年后网关代码会非常重。我倾向于把网关拆成两层核心转发层和策略插件层。核心转发层保持稳定只做协议转换、认证、路由、限流、缓存、日志这些基础能力。策略插件层处理具体业务规则通过配置文件或独立服务注册进来。策略也不要写死在代码里。比如“哪个租户可以用哪个模型”“哪些场景需要内容审核”“重试次数是多少”这些都应该配置化。配置化是为了让运维和平台团队在故障时能快速调整不需要发版。但配置过多也会带来“配置爆炸”问题所以还需要配套默认值和校验规则。6. 生产化路线图与判断标准从内部工具走向多租户平台最后聊一聊网关的落地路线。很多团队卡在“准备好了所有组件但不知道怎么排期”。下面是我认为比较合理的推进顺序以及每一步的验收标准。6.1 起步期先保证单租户能稳定跑起来第一步不要做多租户不要做复杂路由不要引入几十个插件。先把最小可用闭环跑通一个网关注入统一的鉴权方式。支持至少两家模型服务商接入能按配置切换。实现基础限流、重试、超时和日志。接入最核心的业务调用取消这些业务直连模型服务商的密钥。监控面板能实时看到请求量、失败率、延迟和 token 消耗。验收标准核心业务已经通过网关调用模型持续运行一个月没有出现因网关导致的严重故障排障时通过看网关日志能找到问题密钥已经从业务环境变量中移除。6.2 扩展期从单环境到多环境从自用到开放起步期跑稳之后再开始扩展增加多环境支持开发、测试、生产环境独立网关但共享控制面板和策略模型。增加租户和配额管理不同团队申请独立 Key配置不同模型权限和预算上限。增加缓存、语义路由、内容审核等增强能力。完善告警体系支持按租户和模型维度做告警。提供自助接入文档让新业务可以不依赖研发团队自己接入。验收标准有 5 个以上业务团队通过自助方式接入网关每个租户能查看自己的调用量、费用和错误日志业务方不需要知道模型服务商的密钥也能完成模型调用。6.3 成熟期平台化运营的指标与组织配套到这个阶段网关已经不只是工具而是公司内部的模型基础设施平台。重点关注成本分摊每月自动生成各租户的费用账单支持按项目维度拆分。模型治理对模型版本、供应商、废弃模型做统一管理避免业务继续使用下线模型。稳定性保障建立 SLO比如“网关可用性 99.9%”“p95 延迟低于 X 秒”并按季度复盘。故障演练定期模拟上游模型故障、网关单节点宕机、限流触发确认降级策略有效。容量规划根据业务增长趋势预估模型调用量和网关资源需求。成熟期的难点不是技术而是组织协同。网关平台必须有明确负责人模型采购、成本预算、安全合规、业务接入评审每个环节都要有人拍板。如果只靠一个开发团队义务维护最终会因资源不足而停滞。6.4 落地检查清单如果你准备在公司内部启动 LLM 网关项目可以按这张清单自我检查项目判断标准接入方式业务方不需要持有模型服务商 API Key只需持有网关颁发的密钥协议兼容至少兼容两家主流模型服务商且能统一返回结构流式支持聊天、补全类请求支持标准流式返回限流与配额支持按租户、按模型、按接口配置配额和速率限制重试与熔断有重试次数限制、指数退避、快速失败和上游熔断机制缓存策略有明确缓存命中率指标能按租户控制是否启用缓存和过期时间日志与审计有全量元数据日志和可选的内容留存策略可观测性有延迟、错误率、token 消耗、限流数、缓存命中率等核心指标内容合规支持输入输出过滤可按租户配置严格程度配置管理模型路由、限流阈值、配额等配置支持灰度发布和版本回滚成本核算能生成按月、按租户、按模型的费用报表故障预案有上游故障、网关节点宕机、流量突增三类演练记录最后留几句经验LLM 网关不是“搭一个代理服务”那么简单。它真正的价值是把模型调用从“业务开发自己处理”变成“平台统一治理”。它在架构层面需要做的权衡不比业务系统少甚至更复杂因为上游模型服务商的行为你控制不了只能适应和兜底。如果你现在正准备做网关我的核心建议是先画清楚调用链和收益场景不要为了“架构完整性”去建一个庞大平台。从单租户最小闭环开始跑稳一个月再考虑多租户和平台化。踩过几次故障之后你会发现很多问题不是网关能力不够而是重试策略太激进、日志没有治理、配置改得太随意、上游状态没有感知。把这些基础问题先解决掉网关的稳定性就会上来一大截。
![第5章，[Win32 章节] ：圆角矩形教学插图绘制程序](http://pic.xiahunao.cn/yaotu/第5章，[Win32 章节] ：圆角矩形教学插图绘制程序)
