Zerker AI Gateway 是一个典型的 AI 网关项目核心只有三件事route、guard、charge。简单说就是把多个大模型 API 统一收口到同一个入口在上游模型和下游调用方之间加一层负责请求路由、安全防护和用量计费。这类场景现在很常见公司内部多个项目都在调大模型有人用 A 模型的接口有人用 B 模型的产品每个项目申请一次密钥月底成本不知道该算给谁或者某个业务线把一个模型的 Key 写死在代码里升级模型、切换厂商都得改代码。Zerker AI Gateway 这类工具就是来解决这些问题的。如果你正在做多模型接入、统一 API 出口或者需要给不同团队做模型调用限额和成本分摊这篇文章值得看完。下面我不讲概念堆砌按落地顺序拆先理解三个核心能力再讲部署前置条件、路由配置、防护策略、计量计费最后给一套可执行的测试和排查流程。1. 先理解 AI Gateway 的 route、guard、charge 分别解决什么1.1 route 不是简单转发而是模型接入层的统一入口很多第一次接触 AI Gateway 的人以为“路由”就是反向代理把请求转发给上游模型就完了。如果只做转发Nginx 就够用没必要单独做一个网关。AI Gateway 的路由要解决的是模型层面的调度问题。举个例子。你的应用只调一个通用大模型接口这时候路由很简单直接写死一个上游地址就行。但实际业务里你可能是这样同一个提问在不同时间段调用不同模型白天用快模型晚上用便宜模型。同一个请求如果主打模型超时自动切换到备用模型。不同用户组走不同模型池VIP 用户绑定高能力模型普通用户绑定低成本模型。算法团队上线了一个私有化模型但它只支持特定输入格式需要网关转发前做一次格式转换。这些都属于路由。Zerker AI Gateway 这类项目在路由层要做得比普通 Nginx 多重点不是“转到哪个 IP”而是“这个请求应该交给哪个模型服务”。所以配置路由之前先想清楚你的上游模型有几个、每个模型能接受什么请求格式、不同来源的请求应该落到哪个模型。不要把路由规则设计得太复杂先用“用户维度”或“模型代次维度”分后面再逐步细化。1.2 guard 是权限、限流和审计而不是单纯防火墙guard 这个词容易让人想到防火墙但 AI 网关里的防护重点不太一样。普通防火墙防的是网络端口、IP、协议层面的攻击AI Gateway 的 guard 更关心调用方身份、调用频率和数据安全。第一层是身份认证。每个调用方不能直接拿上游模型的原始 Key 来用而是要在网关里申请一个独立的 API Key 或应用凭据。网关收到请求后先验 Key再放行。这样上游模型的 Key 不暴露给业务线Key 泄露后也可以在网关侧单独吊销不用重新生成模型厂商那边的密钥。第二层是限流和配额。AI 模型调用跟普通 HTTP 接口不一样一个请求可能消耗几千 token成本不低。只限 QPS 不够还要限制每分钟消耗的 token 数甚至限制单用户的每日预算。这一层做不好流量稍微涨一点账单就会失控。第三层是审计与输入输出安全。模型调用涉及的内容有可能包含敏感信息至少要在日志层面做脱敏。网关最好能记录谁在什么时间调了哪个模型、消耗了多少 token、返回状态是什么。这些东西对排查线上问题和后期成本分析非常重要。1.3 charge 是 token 计量和成本分摊不是必须做账单charge 在本项目里指的是计费计量不是说要做出一个电商级收费系统。对大多数团队来说它真正要解决的是成本归属问题。底层大模型按 token 计费不同模型单价不一样。同样是 1000 次请求有的模型可能消耗 500 万 token有的可能只有 50 万成本差很多。如果网关不记录 token只记录请求次数月底成本报表基本没法看。Zerker AI Gateway 这种项目里charge 一般包含三层用量采集记录每次请求的 prompt token、completion token、总 token。成本换算根据模型单价把 token 换算成金额或成本积分。配额扣减从调用方所属的预算或配额里扣掉本次消耗。这三层只要做扎实内部成本分摊、预算告警和异常流量识别就都有依据了。2. 部署前先把环境、依赖和接入模型理清楚2.1 硬件与部署方式容器、虚拟机还是物理机AI Gateway 本身不是大模型它不跑模型推理只是转发请求、做策略判断和记录日志所以对硬件要求不高。普通 2 核 4G 的机器就能跑学习环境如果公司内部请求量比较大建议 4 核 8G 起步磁盘尽量用 SSD。判断机器够不够不要只看 CPU 和内存还要看日志写入和网络连接数。网关每个请求都会写访问日志、用量数据如果磁盘 IO 慢日志会影响响应速度。部署方式上我建议优先用 Docker 或 Kubernetes。原因很简单网关项目依赖很多Python、Node 或 Go 版本容易冲突容器化之后版本升级和回滚都方便。如果你只是在本地测试也可以直接用 docker-compose 起一套。注意一个点如果你的 Windows 开发机启用了 Hyper-V 或 Credential GuardDocker Desktop 启动时可能会报虚拟化冲突。建议直接把 Docker 环境放到 Linux 虚拟机或服务器上省得在本地环境上折腾。2.2 上游模型服务的接入形式与协议配置网关之前先把上游模型服务列一个清单。每个上游需要确认几件事接口协议是 OpenAI 兼容格式还是厂商自有的 SDK 格式。地址内网地址还是公网地址是否需要带证书访问。认证方式API Key、签名、OAuth 还是 username/password。模型列表哪些模型可以对外提供哪些只允许内部测试。配额限制上游服务本身有没有 QPS 或 token 限制。为什么先列清单因为网关的路由规则、防护策略、计量换算都要围绕上游模型来写。如果上游的认证方式不一样网关做转发时可能要分别处理 Header 和签名逻辑。现在很多模型服务都兼容 OpenAI 格式但必须实际验证不能只看文档。我一般会在配置网关之前先用命令行或 Postman 直连上游模型确认能调通记录一条正常响应和一条异常响应再把这个响应和网关转发的响应做对比。这样后面定位问题时有基线。2.3 配置管理密钥、环境变量和目录规划网关项目里最容易被忽略的是配置目录和密钥管理。API Key 和密钥不要写在代码仓库里。本地开发可以放到 .env 文件但 .env 必须加到 .gitignore。生产环境建议用配置中心、密钥管理服务或 K8s Secret 注入。配置目录我会按功能拆分route、guard、charge、log每个目录放对应配置。比如路由规则放一个文件限流策略放一个文件模型单价和配额放一个文件。这样改路由的时候不用碰限流配置排查问题也更清晰。还要规划好日志和数据目录。网关运行一段时间后访问日志和用量记录会增长很快建议提前设置日志轮转比如按天切割保留 30 天。如果网关是容器部署数据目录必须挂载到宿主机或持久化卷否则容器一重建日志和计量数据就丢了。3. 路由配置从单模型转发到多模型策略3.1 先跑通最小路由一个 model 字段对应一个上游不管路由规则设计得多复杂第一步永远是最小可用配置一个入口一个上游模型能调通。通常网关的请求格式会设计成 OpenAI 兼容格式也就是请求体里带model、messages、max_tokens等字段。网关根据model字段判断要转发到哪个上游。最小配置大概是这样的思路routes: - name: chat match: model: gpt-4o-mini upstream: host: https://your-model-endpoint.example.com api_key_env: MODEL_KEY注意上面这段只是示例不同项目配置结构不一样不要照搬。重点是你先理解model名字是给调用方看的逻辑名称upstream才是真正的后端地址。调用方不需要知道后端在哪只需要知道模型叫什么。先跑通这一步。发一个最简单的聊天请求看返回结果是否正确、耗时是否正常、日志里是否记录了 token 数。能跑通再往下做多模型。3.2 多模型时的路由规则、权重和 failover多模型路由是 AI Gateway 的重点场景。我建议按两层来设计。第一层是“按模型名路由”。调用方明确指定model网关直接转发到对应上游。这是最直观的用法适合业务方需要明确用哪个模型的情况。第二层是“按策略路由”。调用方不指定具体模型只指定一个模型组或一个需求比如model: fast-chat。网关内部再决定fast-chat到底对应哪个上游模型。策略路由很适合做容量规划和成本控制。你可以动态调整fast-chat的权重80% 请求转发到 A 模型。20% 请求转发到 B 模型。如果 A 模型超时或返回 5xx自动切到 B 模型。这种 failover 能力特别重要。大模型服务经常出现限流、超时、不可用尤其是高峰期。如果网关不做故障切换一个上游抖动所有调用方都会受影响。配置 failover 时几个参数要重点看超时时间建议先设 30 秒如果多数请求在 10 秒内返回再逐步调低。重试次数不要无限重试建议 1 到 2 次。重试对象重试不等于把同一个请求发给同一个上游要实现 failover需要把请求转发到备用上游。幂等性聊天请求一般可以重试但如果请求有状态或造成重复扣费要小心。3.3 动态路由与请求改写根据用户、渠道、优先级转发再往上一层是动态路由。路由条件不只来自请求体还可以来自请求头、路径、用户身份、应用 ID。常见做法是这样网关接收请求。解析 API Key得到调用方身份部门、应用、用户组。根据身份匹配路由策略。如果路由策略要求改写模型名或参数网关先改写再转发。例如普通测试账号只能调用低成本模型生产账号可以调用高能力模型。这就要在网关里做身份解析和路由匹配。还有一个现实中常遇到的问题上游模型要求的参数格式不一样。比如 A 模型支持max_tokensB 模型要写成max_completion_tokensA 模型返回格式是某种结构B 模型是另一种。网关在这一层要有请求改写和响应规范化的能力。这一步不要一上来就做全。先做模型名改写再做参数改写最后做响应统一。每改一步都要用真实请求回归验证避免网关改动影响业务方。4. 防护配置认证、限流、防重放与审计4.1 API Key 和调用方身份怎么设计AI Gateway 的防护核心是 API Key。但 API Key 不等于只有一串随机字符串它背后要绑定调用方身份。我的建议是这样的 Key 设计每个调用方团队、应用、项目一个 Key。Key 可以设置过期时间、生效环境、调用的模型范围。Key 被吊销后网关立即拒绝该 Key 的后续请求。有些网关还会支持多级 Key租户级、应用级、用户级。如果公司规模不大建议先从应用级做起。每个应用一个 Key月底成本按应用归属比按用户归属简单很多。还要注意 Key 传递方式。请求到了网关网关解析并校验 Key 后就不要再把调用方原始 Key 传给上游而是使用网关自己维护的上游密钥。这样可以避免业务方拿到上游模型 Key。4.2 限流不要只限 QPS还要限并发和 token 速率限流是 guard 最容易做漏的地方。很多 AI 网关默认只限 QPS也就是每秒请求数。但大模型调用里一个请求可能消耗几千 token另一个请求可能只消耗几十 token。如果只看 QPS用户可以用少量大请求打爆你的 token 预算。所以限流至少要分三个维度QPS 限流每秒最多请求数。并发限流同时处理的最大请求数。Token 速率每分钟消耗的 token 总量。举例来说某个应用可以配置为每秒最多 10 个请求同时最多 5 个并发每分钟最多消耗 20 万 token。三个条件任何一个超过网关就返回限流错误。并发限流容易被忽略但它很重要。如果上游模型只支持 10 个并发网关却允许 50 个请求同时进来上游就直接超时或报错。这时候不是网关性能问题而是并发没有控制住。限流触发之后的返回值、错误消息和重试提示也要统一。不然调用方看到不同限流格式代码很难处理。4.3 输入输出日志和审计哪些数据必须脱敏AI 网关会经过所有模型请求和响应这些内容可能包含业务数据、用户隐私甚至内部代码。日志如果全量落盘风险很大。我建议做三层处理默认不记录消息内容只记录请求 ID、调用方、模型、token、耗时、状态码。如果必须记录输入输出用于问题排查要对字段做脱敏比如手机号、身份证号、邮箱、密钥等字段打码。日志权限按角色控制只有必要人员能查看完整内容。审计日志不一定需要很复杂但一定要能回答这几个问题谁调的什么时候调了哪个模型消耗多少 token返回成功还是失败这五条都是排障和成本分析的基础。5. 计费计量从 token 统计到成本分摊5.1 为什么不能只看调用次数要看 token 和模型单价AI 网关的 charge 模块如果只记录调用次数基本没有参考价值。不同模型的 token 单价差距很大。一个请求一次可能生成几千 token如果只按“一次调用”计费成本信息会严重失真。更准确的做法是网关从上游响应里解析 token 使用量。如果上游没有返回 token 数根据模型上下文长度估算 prompt 和 completion 的 token 数。用 token 数乘以模型单价得到本次调用的成本。模型单价要以你实际签订的采购价格为准不要写死在代码里。建议把价格放在独立配置文件中定期更新。这里要特别提醒token 统计口径要一致。有的模型返回的 token 数包含缓存 token有的不包含有的把系统提示也算进去有的不算。如果不同模型混在一起统计成本对比就没有意义。建议在计量表里增加“计费口径”字段记录用的是哪种统计方式。5.2 配额管理预算、告警、自动熔断有了 token 计量之后可以做配额管理。配额管理不是简单为了收钱而是为了不失控。常见的做法是给每个调用方设置每日或每月预算单位可以是 token也可以是金额。调用方消耗到预算的 70%、90% 时通过 Webhook 或邮件告警。达到 100% 时网关可以返回 429 或 403并在日志里标记“配额耗尽”。配额耗尽后不要自动放行否则告警没有意义。如果业务方确需临时增加配额可以走审批流程在网关里调整额度。自动熔断也建议做。比如某个调用方在短时间内消耗量突然暴增网关可以先限制这个调用方的并发等确认是正常业务再放开。这样能防止 Key 泄露或被脚本刷量。5.3 输出账单和报表按部门、项目、应用维度拆计费的最终输出是报表。报表不一定要做成花哨的数据大屏但至少要能按维度拆按部门研发部、运营部、市场部。按项目智能客服、内容生成、代码助手。按模型A 模型、B 模型、私有化模型。按时间按天、按周、按月。这些维度取决于前面 API Key 的层级设计。也就是说如果你一开始没有把调用方身份设计好后面报表只能按 Key 看不知道这个 Key 属于哪个部门。我见过不少团队先跑数据再做报表结果发现计量数据里没有部门和项目字段只能让各团队认领 Key非常痛苦。建议在网关初始化阶段就把维度信息整理好哪怕先只用 Excel 管理也要保证每次调用能关联到调用方身份。6. 上线前完整测试流程6.1 单条请求验证返回、耗时、token 统计、日志任何复杂配置都要先从单条请求开始验证。我一般会准备几个固定的测试样例普通文本对话。长文本输入。带特殊字符或 Markdown 格式的内容。明显异常的输入比如超长内容或异常参数。每发一条请求要检查四件事返回结果是否正确。响应耗时是否正常。上游日志里是否记录了 token 数。网关日志里是否记录了调用方、模型、状态码、配额扣减。如果单条请求都不通过不要急着调并发。先看是网关配置问题还是上游模型问题还是网络问题。6.2 并发和压测先小并发再逐步加压单条跑通之后再做并发测试。压测不是一上来就开到 100 并发。我从 1 并发、5 并发、10 并发开始逐级增加。每轮压测关注四个指标成功率有没有非预期报错。P95 和 P99 延迟响应是否稳定。网关 CPU、内存有没有暴涨。上游错误率是不是被网关的并发打挂了。如果压测时出现大量超时不要只加机器先看限流配置和上游并发限制。很多时候是网关层把请求放进来太多把上游压垮了。压测之后还要注意脏数据。压测请求也会消耗 token如果网关和上游都记录了计量数据月底要对账时可能会把压测数据也算进去。建议压测使用单独的 API Key 或测试模型并在报表里标注“压测流量”。6.3 故障演练上游超时、限流、异常返回上线前最好做一轮故障演练模拟上游模型不可用。具体可以这样做在网关配置里临时把上游地址改成一个不存在的地址。发请求看网关会不会快速失败而不是无限等待。配置 failover把主上游停掉看备用上游是否接管。配置限流短时间内发大量请求看返回的限流错误是否规范。这一步很有用。多数 AI 网关在正常路径上表现都很好但到了故障场景处理不好的网关会让所有调用方一起超时甚至把日志打爆。故障演练的目的就是提前暴露这些问题。7. 常见问题排查和落地建议7.1 请求失败先分清楚是网关问题还是上游模型问题排查 AI 网关问题我习惯按这个顺序来看网关返回的状态码和错误消息。看网关日志里有没有本次请求的记录。如果有记录看有没有转发到上游上游返回了什么。如果没有记录可能是请求没到网关先查网络、DNS、负载均衡。如果上游返回了错误直接用上游地址再发一次确认上游是否正常。很多问题最终都指向同一个原因调用方传的参数格式不对。比如messages字段结构不符合要求model命名不匹配或者缺少必要的请求头。这些问题在日志里都能看到但如果不先看日志往往会白折腾半天配置。7.2 计费不准检查 token 计算口径和缓存计费不准是 AI 网关上线后最容易遇到的投诉。我的排查顺序是核对上游返回的 token 字段。查看网关有没有正确解析usage结构。检查网关是否对响应做了缓存缓存命中的请求是否还计算 token。检查并发场景下 token 统计是否存在覆盖或丢失。缓存是一个非常隐蔽的坑。为了省成本有些网关会缓存相同请求的响应直接返回结果不调用上游。缓存命中时如果网关没有把 token 数按实际对话长度估算相当于所有缓存请求的计费都是 0报表立刻失真。如果你的网关开启了缓存一定要在计量模块里对缓存响应单独处理比如按比例估算 token或者在账单中标记为“缓存命中”。7.3 防护误伤区分正常用户和异常流量限流和防护设置得太严容易误伤正常用户。常见表现是业务方反馈接口时不时返回限流错误但看流量并不算高。这时要看的不是平均 QPS而是瞬时峰值。很多业务请求有很强的波峰比如每天早上 9 点到 10 点集中调用。如果限流阈值按全天平均值设置波峰时必然误伤。解决办法有两个方向限流阈值按波峰设计给正常业务预留足够空间。加一个权重放行机制对已认证的调用方放宽限制对匿名请求严格限制。还要看限流是作用在网关单节点还是全局。如果网关有多副本本地限流可能导致不同节点限流效果不一致。建议使用集中式限流存储例如 Redis保证多节点下配额统计是全局的。7.4 长期运行建议版本管理、日志轮转、监控大盘最后是长期运维建议。AI 网关一旦成为统一入口业务方就会依赖它。每次配置变更都要有版本管理习惯。路由、限流、计费配置最好走代码仓库带上 MR 或审批记录避免直接在服务器上改文件。日志建议保存两份一份原始日志用于排查问题一份结构化指标用于监控和报表。原始日志要定期轮转和归档结构化指标可以直接进时序数据库或数据仓库。监控大盘不需要很复杂至少要有四个视图流量视图请求量、QPS、成功率和错误率。延迟视图平均延迟、P95、P99。成本视图每日 token 消耗、按调用方统计的成本。上游健康视图每个上游模型的超时率、限流率、错误率。有了这四个视图大部分问题都能提前发现。等业务方来投诉的时候再补监控通常已经晚了。踩过几次之后我发现AI 网关真正难做的不是转发请求而是把路由、防护、计量三者的数据串起来。很多项目功能都有但配置分散日志对不上排查问题时只能逐个模块查。Zerker AI Gateway 这类工具的核心价值是让你在统一入口上同时完成这三件事。建议你先按最小配置跑通再逐步加上多模型策略、配额和报表。先把单条请求跑稳再考虑并发和自动化后面会顺手很多。