1. 从能跑通到敢上生产LLM 网关到底卡在哪大模型应用从 Demo 走向生产环境最先撞上的往往不是模型效果问题而是工程治理问题。我见过太多团队Demo 阶段直接在前端代码里硬编码一个 API Key调一个模型跑得挺欢一旦要接入多个业务线、多个模型供应商、多个租户整个系统就开始失控——账单对不上、某个供应商限流导致全线雪崩、敏感数据被无意间发到了外部接口、想换个模型发现业务代码里到处是耦合。这些问题的根源在于缺少一个统一的 LLM 网关层。所谓 LLM 网关你可以把它理解成所有大模型调用的总闸口——所有业务方不直接调用模型 API而是先经过网关由网关统一完成鉴权、计价、路由、限流、缓存、审计、降级等一系列治理动作。它和传统 API Gateway比如 Nginx、Kong的思路一脉相承但针对 LLM 场景有大量特殊设计Token 计量、流式响应、多模型协议适配、语义缓存、成本归因等等。这篇文章要聊的是我在实际项目中总结出的一套LLM 网关五级演进路径。之所以叫五级演进是因为我踩过一个很深的坑一开始就想做一个大而全的网关结果三个月没上线业务方等不及全都绕过网关直连了。后来我换了个思路——按能力成熟度分五级逐步演进每一级都能独立交付价值每一级都为下一级打基础。这套路径后来在三个不同规模的项目里验证过从日调用量几千次到几百万次都能适配。如果你正在做 AI 平台、AI 中台、或者任何一个需要统一管理多个大模型调用的系统这篇文章应该能帮你少走不少弯路。我会把每一级的设计动机、核心实现、踩坑经验都讲清楚尤其是那些文档里不会写的细节。2. 第一级统一接入层——先把入口收拢2.1 为什么第一级不是计价而是接入很多人一上来就想做计价系统觉得钱最重要。但我的经验是没有统一入口计价根本无从谈起。你连调用都散落在各个业务代码里怎么统计怎么归因所以第一级的目标非常朴素——把所有模型调用收拢到一个统一的 HTTP 入口。这一级要解决的核心问题是协议适配。市面上的大模型 API 协议并不统一有的用 OpenAI 兼容格式有的用自家私有格式请求体字段名、响应结构、流式返回的 SSE 格式都有差异。网关的第一件事就是把这些差异屏蔽掉对上暴露一套统一的接口。我通常的做法是定义一个内部标准协议直接对齐 OpenAI 的 Chat Completions 格式因为生态最成熟然后为每个供应商写一个 Adapterclass BaseAdapter: def to_standard_request(self, raw_request: dict) - dict: raise NotImplementedError def from_standard_response(self, raw_response: dict) - dict: raise NotImplementedError def stream_transform(self, chunk: bytes) - bytes: raise NotImplementedErrorstream_transform这个方法特别关键也是新手最容易忽略的地方。流式响应不是简单地把字节转发出去不同供应商的 SSE 事件格式、结束标记、错误帧都不一样。我踩过的坑是某供应商在流式返回中途遇到限流会发一个特殊的 error 事件而不是直接断开连接如果不处理前端会一直挂着等用户体验极差。2.2 接入层最容易被忽略的三个细节第一个细节是超时与重试的边界。LLM 请求动辄几十秒传统的 3 秒超时完全不够用。但超时设太长连接池会被占满。我的经验是分两段设置连接超时 5 秒读取超时按模型类型区分——普通对话 60 秒长文本生成 180 秒推理类模型可以到 300 秒。重试要特别小心流式请求一旦开始返回内容就绝对不能重试否则用户会看到重复内容。第二个细节是请求体的规范化。不同业务方传上来的参数五花八门有的用max_tokens有的用max_new_tokens有的 temperature 传字符串。网关必须做一层参数校验和归一化把非法参数挡在门外。我见过因为 temperature 传了0.7字符串导致某供应商直接 500 的案例。第三个细节是连接池的隔离。不同供应商的连接池必须隔离否则一个供应商响应慢会把整个网关的连接池拖垮。这个在压测时特别明显我建议每个供应商独立配置连接池大小并且设置独立的熔断阈值。提示第一级不要追求功能完备能跑通统一入口 协议适配 基础校验就够了。我见过太多团队卡在第一级非要一次做完美结果业务方等不了直接绕过。3. 第二级计量与计价——把每一分钱算清楚3.1 Token 计量的三种口径与选择统一入口建好之后第二级就是算账。LLM 的计价核心是 Token 计量但这里有个容易被忽略的问题Token 到底按谁的数算我总结有三种口径口径说明优点缺点供应商返回直接用 API 响应里的 usage 字段准确、省算力部分供应商流式不返回、有延迟网关本地计算用 tokenizer 在网关侧计算实时、可控与供应商口径可能有偏差混合模式优先用供应商返回缺失时本地补算兼顾准确与实时实现复杂度高我的建议是混合模式。具体做法是非流式请求直接用供应商返回的 usage流式请求因为很多供应商在最后一个 chunk 才返回 usage网关需要本地用 tokenizer 预估等最终 usage 到了再校正。这里要注意不同模型的 tokenizer 不一样本地计算必须按模型加载对应的 tokenizer不能图省事全用一套。本地计算 tokenizer 有个性能坑每次请求都加载 tokenizer 会很慢。我的做法是用 LRU 缓存把 tokenizer 实例缓存起来并且对超长文本做分片计算。实测下来一个 8K 上下文的请求本地计算耗时在 5ms 以内对整体延迟影响可以忽略。3.2 计价模型的设计不只是单价乘 Token计价听起来简单——单价乘 Token 数嘛。但实际做起来你会发现要考虑的维度非常多输入输出分开计价几乎所有供应商的输入和输出单价都不同输出通常贵 2-4 倍。缓存命中折扣很多供应商对命中 prompt cache 的部分有折扣计价时必须区分。阶梯定价部分供应商按调用量阶梯降价需要累计统计。模型版本差异同一个模型名不同版本单价可能不同。汇率与结算周期海外供应商涉及汇率且结算周期不同。我设计计价模块时核心是一张价格配置表把上述维度都参数化PRICING { gpt-4o: { input: 0.005, # 每 1K token output: 0.015, cached_input: 0.0025, currency: USD, effective_from: 2024-05-13, }, # ... }价格配置一定要支持版本化和生效时间因为供应商调价很频繁。我踩过的坑是某次供应商半夜调价第二天对账发现所有账单都算错了因为没有价格版本管理历史账单无法复现。3.3 成本归因让每个业务方知道自己的账计价做完下一个问题是这笔钱算谁的。成本归因的核心是给每个请求打上足够的标签租户 ID、业务线、应用 ID、用户 ID、甚至具体的功能模块。这些标签从请求头里透传进来网关负责采集和聚合。我建议在网关层强制要求请求头里带X-Tenant-Id和X-App-Id没有的直接拒绝。一开始业务方会抱怨麻烦但一旦他们看到自己的成本报表就会主动配合了。归因数据我通常按小时聚合写入时序数据库按天生成账单快照这样既能实时看趋势又能保证账单的稳定性。注意成本归因的粒度不是越细越好。我试过细到单个用户级别结果数据量爆炸查询慢得没法用。后来改成租户 应用 模型三个维度既够用又高效。4. 第三级智能路由——在成本、质量、可用性之间找平衡4.1 路由策略的四种典型场景计量计价解决的是算清楚路由解决的是算得省、算得稳。LLM 网关的路由策略我归纳为四类典型场景场景一成本优先路由。同一个任务优先选便宜的模型。比如简单的意图识别、文本分类用小模型就够了没必要上大模型。我通常配置一个任务类型到模型的映射表业务方声明任务类型网关自动选模型。场景二质量优先路由。复杂推理、代码生成这类任务必须用能力强的模型。这时候路由策略是指定模型 备用模型主模型不可用时自动切换。场景三可用性优先路由。同一个模型有多个供应商提供比如多个云厂商都部署了开源模型网关做负载均衡和故障转移。这里要注意健康检查不能只看 HTTP 状态码还要看响应质量——我见过供应商返回 200 但内容是空的情况。场景四灰度路由。新模型上线时按比例把流量切过去观察效果再逐步放量。灰度路由的关键是流量标记的一致性同一个用户应该稳定命中同一个版本否则体验会割裂。4.2 路由决策的实现规则引擎还是策略链路由决策的实现方式我试过两种规则引擎和策略链。规则引擎比如用 JSON 配置规则灵活但性能差每次请求都要解析规则策略链代码里定义一系列策略按顺序执行性能好但改策略要发版。最后我的选择是混合方案核心路由逻辑用策略链实现保证性能策略的参数比如权重、阈值、映射表用配置中心下发保证灵活。这样既不用频繁发版又能保证性能。路由决策里有个容易被忽略的点决策要可观测。每次路由为什么选了这个模型必须记录下来。我见过线上出问题排查半天最后发现是路由配置写错了但没有任何日志能证明。所以我在路由层强制记录决策链路命中了哪条规则、候选模型有哪些、最终为什么选它。4.3 故障转移的坑不是所有失败都该重试故障转移听起来简单——主模型失败就切备用。但实际做起来判断失败本身就是个难题。我总结了几类情况明确失败HTTP 5xx、连接超时这类直接重试没问题。限流失败429 状态码这类要区分是短时限流还是长时限流短时可以用指数退避重试长时应该直接切备用。内容失败返回 200 但内容是空的、或者触发了内容安全拦截这类不应该重试因为重试大概率还是同样结果应该直接返回错误。流式中断流式响应中途断开这类要特别小心如果已经返回了部分内容重试会导致内容重复我的做法是直接终止并返回错误让业务方决定是否重新发起。这里有个血泪教训早期我没区分这些情况所有失败都无脑重试三次结果遇到内容安全拦截时同一个违规请求被重试了三次触发了供应商的风控整个账号被限流了。后来加了失败分类才解决这个问题。5. 第四级治理能力——限流、缓存、审计一个都不能少5.1 限流保护自己也保护供应商限流是网关的保险丝。LLM 网关的限流比传统 API 限流复杂因为要限的维度多按租户限流防止单个租户把配额用光影响其他人。按模型限流不同模型的配额不同要分别限制。按供应商限流供应商有 QPS 和 TPM每分钟 Token 数双重限制都要遵守。全局限流兜底保护防止整体过载。实现上我推荐令牌桶 滑动窗口组合。令牌桶控制瞬时突发滑动窗口控制长期速率。Token 维度的限流要特别注意因为 Token 数是请求完成后才知道的所以需要预扣 校正机制请求进来时按预估 Token 预扣配额请求完成后按实际 Token 校正。限流触发后的处理也很讲究。直接返回 429 是最简单的但体验差。我的做法是分级降级先尝试排队等待短时排队超时再降级到备用模型备用模型也不可用才返回 429。这样大部分限流场景用户是无感知的。5.2 缓存省钱的利器但别乱用LLM 网关的缓存分两种精确缓存和语义缓存。精确缓存就是请求体完全一致时直接返回缓存结果。这个实现简单命中率取决于业务场景。对于同一个问题反复问的场景比如 FAQ命中率能到 30% 以上。语义缓存是通过向量相似度判断意思相近的请求返回缓存结果。这个省钱效果更明显但风险也更大——语义相似不等于答案相同。我踩过的坑是用户问北京今天天气和北京明天天气语义相似度很高但答案完全不同如果命中缓存就出大错了。所以语义缓存必须设置高相似度阈值我一般设 0.95 以上并且对时间敏感、个性化强的场景直接禁用。缓存还要设置合理的 TTLLLM 的回答有时效性缓存太久会返回过时信息。5.3 审计与合规日志里不能有的东西审计是很多团队最后才做、但出事时最需要的功能。LLM 网关的审计日志要记录谁、什么时候、调用了什么模型、输入输出是什么、花了多少 Token、结果如何。但这里有个大坑审计日志里绝对不能明文存储用户的输入输出因为可能包含敏感信息。我的做法是脱敏 加密双管齐下对明显的敏感字段手机号、身份证、邮箱做脱敏整体内容加密存储只有授权人员才能解密查看。同时要设置日志保留期限到期自动清理。审计日志的另一个用途是问题回溯。线上出现模型回答错误的投诉时能快速定位到具体的请求和响应。我建议给每个请求生成一个全局唯一的 trace ID贯穿整个调用链路排查问题时一查到底。6. 第五级平台化与生态——从工具到基础设施6.1 自助化让业务方自己管自己前四级做完网关已经能用了。但第五级的目标是让网关成为基础设施业务方不需要找平台团队自己就能完成大部分操作。这需要几个能力自助接入业务方自己注册应用、申请配额、获取 API Key。自助配置路由策略、限流阈值、缓存规则都能自己配。自助看板实时看到自己的调用量、成本、错误率。自助告警配额快用完、错误率飙升时自动通知。自助化的核心是权限隔离。每个业务方只能看到和操作自己的资源不能越权。这个用 RBAC基于角色的访问控制实现角色分平台管理员、租户管理员、普通用户三级。6.2 可观测性从能看到能预测可观测性不只是看板而是能提前发现问题。我在网关里做了几个预测性告警配额预测根据当前消耗速率预测配额什么时候用完提前通知。成本预测预测本月成本超出预算时告警。异常检测调用量、错误率、延迟出现异常波动时告警。这些预测基于历史数据做简单的时间序列分析就够了不需要复杂的机器学习。关键是告警要准宁可少报也不要误报否则业务方会直接屏蔽告警。6.3 生态扩展网关不只是转发到了第五级网关的角色从转发器变成能力平台。可以在网关上扩展很多能力Prompt 管理集中管理 Prompt 模板支持版本化和 A/B 测试。评测集成新模型上线前自动跑评测集达标才放量。Agent 编排把多个模型调用编排成一个 Agent 流程。内容安全统一的内容审核输入输出都过一遍。这些扩展能力让网关的价值从省钱升级到提效业务方会越来越依赖网关网关也就真正成为了基础设施。7. 五级演进中的几个关键决策点7.1 什么时候该演进到下一级五级演进不是必须按顺序走完而是按需演进。我的判断标准是信号说明该做哪一级调用散落各处无法统计第一级统一接入账单对不上成本失控第二级计量计价单一模型不够用或成本太高第三级智能路由出现限流、雪崩、合规问题第四级治理能力业务方需求多样平台团队疲于奔命第五级平台化不要为了技术先进而提前做高级能力。我见过团队在第一级还没做稳的情况下就去做语义缓存结果缓存命中率低、维护成本高最后不了了之。7.2 自研还是用开源LLM 网关有开源方案比如 One API、LiteLLM 等也有商业方案。我的建议是第一、二级直接用开源方案快速上线。第三、四级开源方案 自研扩展因为路由和治理策略往往和业务强相关。第五级基本要自研因为平台化涉及大量业务定制。自研的核心不是重复造轮子而是在开源基础上做业务适配。我通常的做法是用开源方案做协议适配和基础转发自研的部分集中在路由决策、计价模型、治理策略这些业务强相关的模块。7.3 性能与成本的平衡网关本身也会消耗资源尤其是做 Token 本地计算、语义缓存、内容审核时。我的经验是Token 计算用轻量 tokenizer必要时异步计算。语义缓存向量检索用专门的向量库不要用关系数据库硬扛。内容审核能用规则就不用模型能用小模型就不用大模型。网关的延迟增加要控制在50ms 以内超过这个数业务方就会有感知。压测时重点关注 P99 延迟而不是平均值。8. 我在实际项目里踩过的几个坑第一个坑是过度设计。早期我想做一个万能网关支持所有供应商、所有模型、所有场景结果配置复杂到没人会用。后来砍掉一半功能只保留核心场景反而用起来了。教训是网关的价值在于统一不在于全能。第二个坑是忽视流式场景。我一开始按非流式请求设计上线后才发现 80% 的请求是流式的很多设计要推倒重来。流式场景对超时、重试、缓存、计量的要求都和非流式不同必须从一开始就考虑。第三个坑是计价精度。早期我用浮点数算钱结果累计误差导致账单对不上。后来改成用整数以最小货币单位计算才解决这个问题。涉及钱的代码永远不要用浮点数。第四个坑是配置热更新。路由策略、限流阈值这些配置早期改一次要发一次版运维苦不堪言。后来接入配置中心支持热更新效率提升明显。但热更新要小心配置一致性多个网关实例的配置必须同步否则会出现路由不一致的问题。第五个坑是监控盲区。早期只监控了网关自身的指标没监控供应商的健康度。结果某供应商悄悄降级了服务质量我们过了两天才发现。后来加了供应商健康度监控包括响应时间、错误率、内容质量抽检才做到提前发现。9. 给正在做 LLM 网关的同行几句实在话做 LLM 网关这两年我最大的体会是技术难度不在网关本身而在平衡。平衡成本和体验、平衡灵活和稳定、平衡自研和开源、平衡当前需求和未来扩展。每一个决策都没有标准答案只有适合当前阶段的答案。如果你刚开始做我的建议是从第一级老老实实做起别想着一步到位。统一接入做扎实了后面的计价、路由、治理都是水到渠成的事。如果你已经做到第三、四级那重点应该放在可观测性和自助化上让网关从平台团队的负担变成业务方的工具。最后分享一个我一直在用的小技巧给网关的每个能力都设计一个开关。新能力上线时默认关闭业务方按需开启。这样既能快速迭代又不会影响存量业务。这个开关机制帮我避免了好几次线上事故——新功能出问题时一键关闭就能恢复不用紧急发版。网关这个事做深了是无底洞做浅了又不够用。找到自己团队的甜点区比追求技术完美重要得多。