2026/8/30 5:24:10
FEATURED · 精选文章 
如果你的团队已经接入了两个以上的大模型 API我相信你迟早会遇到下面这三个问题。第一业务代码里到处是不同厂商的接口调用OpenAI 一段、通义千问一段、DeepSeek 一段混在一起没人敢动每次想切换模型供应商都像拆炸弹。第二API Key 散落在各个服务、各个环境变量、甚至代码仓库里谁在调用、能不能调用、调了多少完全没有人能说得清楚。第三月底账单出来了财务问你“这个月花了多少 token、是哪个部门消耗的、哪个模型最烧钱”你只能支支吾吾。这三个问题分别对应了一个 AI 网关必须具备的三项核心能力路由、守卫、计费。而 Zerker AI Gateway 这个项目的命名用最简单的三个动词把这套能力抽象了出来route, guard and charge。这篇文章不是 API 文档的翻译。我想借 Zerker 的设计理念把 AI 网关中 route、guard、charge 这三件事讲透它解决的到底是什么问题、适合谁用、实际项目中应该怎么落地以及新手最容易在哪里翻车。即使你暂时不打算用 Zerker这套分析框架也可以直接迁移到其他网关方案上。1. AI Gateway 是什么为什么要关注它先下一个结论AI Gateway 的本质不是又一个 API 转发代理而是让大模型接入从“代码直连”走向“平台治理”的中间层。没有网关的时候业务系统是直接对着模型供应商的 API 发请求的。这个模式在只有一个模型、一个调用方的时候没问题但一旦出现下面任何一种情况代码直连就会迅速失控公司同时接入了多家模型供应商每个供应商的请求格式、鉴权方式、限流策略都不一样不同的业务线需要调用不同的模型但密钥统一由平台团队管理不能下发给每个业务方需要限制某些内部服务的调用频率防止有人误写了一个死循环把月度预算跑穿月底需要按部门、按项目、按模型维度统计 token 消耗和费用。这些问题靠业务代码里的 if-else 解决不了靠“在代码里多封装一层”也解决不了。因为它们本质上是治理问题不是编码问题。AI Gateway 做的事情就是把这个治理层从业务代码中抽出来放到请求路径上。所有对大模型 API 的调用先经过网关再由网关统一完成路由转发、安全校验、用量计量。这样一来业务方只需要面对一个稳定的网关入口模型供应商的切换、升级、降级对下游调用方几乎无感。这也是我关注 Zerker 这类项目的原因。它把 AI 网关必须做的事压缩成了三个词route、guard、charge。这三个词看着简单但真正把一个网关落地到生产环境每个词展开都是一套完整的设计。读完这篇文章你会得到三样东西一套理解 AI 网关的思维框架一份围绕 Zerker 设计理念展开的核心机制拆解一个可以直接上手跑通的最小网关实现。2. 先分清传统 route/guard 和 AI Gateway 中的 route/guard在展开 Zerker 之前有必要先解决一个容易混淆的问题。如果你在搜索引擎里输入 route 和 guard会看到大量传统 IT 领域的结果route add命令怎么添加多跳路由、Windows 的 Credential Guard / Device Guard 是什么、VMware 报“检测到 Hyper-V 或 Credential Guard”怎么处理、Oracle Data Guard 怎么做主备同步。这些内容都很有价值但它们和 AI Gateway 里的 route、guard 不是一回事。如果带着传统网络和系统安全的概念去理解 Zerker很容易出现偏差。我做了个对比表方便你快速建立区分维度传统网络/系统领域AI Gateway 领域route 的含义数据包要从哪个网关走路由表决定下一跳大模型请求要转发给哪个供应商路由策略决定模型选择典型工具route add、路由器协议、SDN 控制面模型路由、provider 抽象、故障转移guard 的含义系统凭据保护、设备访问控制API 认证、授权、限流、防滥用典型工具Credential Guard、Device GuardAPI Key、JWT、RBAC、限流中间件charge 的含义网络流量计费、带宽结算token 用量计量、成本分摊、预算控制传统网络里的 route 关心的是“数据包走哪条物理链路”而 AI Gateway 里的 route 关心的是“这个模型请求应该交给哪家供应商、哪个模型”。两者都叫路由但解决的问题层次完全不同。传统领域里的 guard 关心的是“操作系统凭据是否被隔离保护”而 AI Gateway 里的 guard 关心的是“谁有资格调用这个模型、调用频率是否在允许范围内”。前者保护系统安全边界后者保护 AI 服务边界。理解了这个区别后面再看 Zerker 的三个词就不会走偏。它的 route 解决的是“把请求送到最合适的地方”guard 解决的是“请求进来之前先做检查”charge 解决的是“每次请求花了多少钱”。3. Zerker 核心能力拆解route 模型路由3.1 为什么需要模型路由模型路由是整个 AI Gateway 最核心的能力也是最容易被低估的部分。很多团队刚开始接入大模型时只有一个供应商、一个模型代码里写死调用地址就行。但当模型数量多起来之后你会发现“调用一个模型”这件事本身变成了一个决策问题同样的场景用顶配模型效果好但贵用轻量模型便宜但可能效果不够。同一个模型的低峰期和高峰期响应延迟差异很大。某个供应商出现故障或限流时请求是否能在不改造代码的情况下自动切换到另一个供应商新模型上线后如何先让少量流量试运行再逐步放量这些问题都是“路由”的范畴。Zerker 的核心思路是把“请求最终打到哪个模型”从业务代码中剥离出来变成一个由网关统一决策的过程。业务方不需要关心背后的供应商是哪家只需要告诉网关“我要什么样的能力、什么等级的质量”剩下的路由决策交给网关完成。3.2 路由策略的类型从实际落地经验看模型路由策略可以分为三个层次。第一层是静态路由。最简单把请求的某个属性映射到固定的模型上。比如内部测试流量全部走 DeepSeek生产流量全部走 OpenAI或者按用户等级划分普通用户用轻量模型企业用户用旗舰模型。第二层是动态路由。网关根据实时的成本、延迟、可用率、token 消耗等指标决定把请求发送给哪个供应商。比如在两家供应商之间按权重分配流量或者当某一家 API 连续报错时自动把流量切换到另一家。第三层是语义路由。将请求的提示词内容做一定的分析判断它属于代码生成、文本总结、角色对话还是知识问答然后分发到对应能力最合适的模型上。这层路由对网关的智能程度要求更高一般作为演进方向而不是第一阶段的目标。3.3 一个参考路由配置下面是一份基于 Zerker 设计思路编写的参考配置。它演示的是如何通过配置文件把“不同用户等级走不同模型”和“供应商故障自动转移”表达出来。# zerker-gateway-config.yaml # 参考 Zerker route/guard/charge 设计理念的示例配置字段为通用风格 providers: - name: provider-openai base_url: https://api.openai.com models: [gpt-4o, gpt-4o-mini] weight: 80 timeout_ms: 30000 health_check: enabled: true interval_sec: 30 - name: provider-deepseek base_url: https://api.deepseek.com models: [deepseek-chat] weight: 20 timeout_ms: 30000 health_check: enabled: true interval_sec: 30 routes: - name: chat-completions-route path: /v1/chat/completions strategy: weight-round-robin rules: - if: user.tier enterprise provider: provider-openai model: gpt-4o - else: provider: provider-deepseek model: deepseek-chat fallback: - provider: provider-deepseek model: deepseek-chat这份配置表达了三层意思定义了两家供应商OpenAI 和 DeepSeek分别声明支持哪些模型、超时时间和健康检查策略。定义了一条路由规则匹配路径/v1/chat/completions企业用户走 OpenAI其他用户走 DeepSeek。配置了降级回退当主供应商不可用时自动把请求切换到备选供应商。这里的核心设计是业务代码不需要感知供应商的存在。下游应用只需要请求网关的同一个地址由网关根据配置决定到底转发给谁。3.4 路由落地时最容易踩的坑路由看起来不过是“转发请求”但实际落地时有几个坑非常隐蔽。第一个坑是超时传播。模型 API 的响应时间通常比普通 HTTP 接口长得多。如果网关层只给上游设置 5 秒超时遇到长文本生成任务几乎必然超时。网关的超时设置必须按模型和任务类型分别配置不能一刀切。第二个坑是流式响应。大模型应用大量使用 SSE 流式输出客户端是一个字一个字看到响应内容的。如果网关在转发时不支持流式模式或者缓冲了全部内容才返回用户的体验会完全毁掉。选型网关时必须确认它对 SSE 和流式转发的支持程度。第三个坑是健康检查过于简单。只看“供应商的 API 能不能 ping 通”是不够的。真实故障可能是某个具体模型返回 429 限流或者某个 API Key 欠费被禁用而这些并不会让供应商的基础域名完全不可达。健康检查的粒度要细化到“模型级别”而不是“供应商级别”。4. Zerker 核心能力拆解guard 安全守卫4.1 guard 解决什么问题只要网关一天开着就会有人试图滥用它。这里的“滥用”不只是恶意攻击更多时候是内部误操作实习生写了一个循环调用的脚本忘了加退出条件某个内部工具在测试环境跑了一晚上把月度预算烧掉了上游业务的 API Key 泄露到 GitHub被外部扫描到后盗刷。guard 要做的就是在请求真正到达模型供应商之前完成认证、授权、限流、审计等所有安全动作。如果拿操作系统来类比传统 Windows 的 Credential Guard 是用虚拟化技术把系统凭据隔离在受保护的内存区域里防止被恶意进程读取。AI Gateway 里的 guard 思想是类似的网关要把所有调用方的身份、权限、用量信息统一管理起来而不是让每个调用方自己控制。4.2 guard 的四层防护第一层是身份认证。网关需要验证请求方是谁。最常见的方式是 API Key 或 JWT。API Key 适合服务端到服务端的调用JWT 适合带有用户身份的调用场景。第二层是授权。认证解决“你是谁”授权解决“你能做什么”。一个测试环境的服务不应该被允许调用生产环境的付费模型一个普通业务方不应该有权限调用企业级的旗舰模型。第三层是行为防护。包括限流、配额、内容安全。限流保证某个调用方不会一瞬间打爆网关配额保证某个项目组不会提前耗尽月度预算内容安全则根据合规要求对输入输出进行必要的过滤。第四层是审计。每一次请求谁调的、调了哪个模型、输入了多少 token、返回了多少 token、耗时多久、是否成功都要有日志。审计不只为了安全它还是计费的数据基础。4.3 一个参考 guard 配置# zerker-guard.yaml # 参考 Zerker guard 能力设计的示例配置 guards: - name: api-key-auth type: apikey header: X-Zerker-Key keys: - key: sk-test-user-a user: alice tier: enterprise enabled: true - key: sk-test-user-b user: bob tier: free enabled: true - name: rate-limit type: token-bucket capacity: 1000 # 桶容量 refill_rate: 100 # 每秒补充的令牌数 scope: user # 按用户维度限制 - name: quota type: monthly-budget scope: project limit: 1000 # 单位美元 alert_at: 80 # 使用量达到 80% 时告警这份配置的特点是把安全规则从业务代码中剥离出来变成声明式的策略。业务方不需要在自己的代码里实现限流只需要在网关注册自己的 Key并声明自己的使用限制。4.4 guard 设计中的一个关键取舍在 guard 的设计上有一个关键取舍值得展开到底应该提升防护强度还是保证请求顺畅任何安全机制都是成本。过强的防护会让正常请求被误杀。这就像 VMware 在启用了 Hyper-V 或 Credential Guard 的机器上运行虚拟化时经常报“检测到 Hyper-V 或 Credential Guard”的错误——安全机制和业务功能之间出现了冲突。AI 网关的 guard 同样如此。如果限流阈值设置得过于严格某个真实业务在促销流量下可能会被误限流如果审计日志记录得过于详细存储成本会迅速上升如果认证链路过于复杂网关本身的延迟就会变得不可接受。我的建议是生产环境的 guard 策略应该有一个灰度放大的过程。先记录不做限制观察正常流量峰值再根据真实数据设定限流阈值先只对核心接口开启认证再逐步扩大到全部接口。安全策略要能随时调整而不是一上来就全量锁死。5. Zerker 核心能力拆解charge 计量计费5.1 为什么计费是 AI 网关的必备能力模型 API 的计费和传统 IT 资源计费有本质区别。传统服务器计费按 CPU 核数、内存大小、磁盘容量算这些资源是“可预期的”。而大模型 API 是按 token 计费的你无法在请求发出前精确预知这次对话会消耗多少 token同一个问题不同模型的回答长度不同价格差异巨大。更麻烦的是token 消耗量不仅取决于用户输入还取决于模型输出长度、上下文窗口大小、系统提示词的长度等等。这就带来一个尴尬的事实项目上线前你很难准确估算 AI 成本。charge 能力要解决的就是让“看不见的 token 消耗”变成“可计量、可追溯、可控制”的数字。5.2 charge 的三层能力第一层是计量。网关每一次转发请求都要记录请求模型、输入 token 数、输出 token 数、缓存命中情况。这些原始数据是计费的基础。第二层是计价。根据供应商的单价计算出每一次请求的费用。这里要注意不同模型的计价维度不同有的按输入和输出分开计价有的还要算缓存命中价。计费系统必须支持灵活的计价规则配置。第三层是分摊与控制。把费用按项目、部门、业务线、调用方分摊让每个团队都能看到自己的消耗。同时支持预算上限控制和告警防止单个项目把整个公司的大模型预算跑穿。5.3 一个参考 charge 配置# zerker-charge.yaml # 参考 Zerker charge 能力设计的示例配置 charge: meter: type: token fields: [input_tokens, output_tokens, cache_hit_tokens, total_tokens] pricing: - model: gpt-4o input_price: 5 # 每百万 token 的价格 output_price: 15 cache_hit_price: 0.5 - model: deepseek-chat input_price: 1 output_price: 2 cache_hit_price: 0.1 allocation: - project: search-team budget_usd: 2000 alert_at: 80 - project:>simple-ai-gateway/ ├── config.yaml ├── main.py └── requirements.txtrequirements.txt 内容fastapi uvicorn pyyaml httpx安装依赖pip install fastapi uvicorn pyyaml httpx6.2 主程序代码# main.py import time import uuid import yaml import httpx from fastapi import FastAPI, Request, Response from fastapi.responses import StreamingResponse app FastAPI() # 加载配置 with open(config.yaml, r, encodingutf-8) as f: CONFIG yaml.safe_load(f) # 模拟数据库API Key - 用户信息 API_KEYS { sk-test-user-a: {user: alice, tier: enterprise}, sk-test-user-b: {user: bob, tier: free}, } # 用量记录表 USAGE_LOG [] def resolve_route(tier: str): 根据用户等级解析目标供应商和模型 for route in CONFIG[routes]: for rule in route[rules]: if rule[if] fuser.tier {tier}: return rule[provider], rule[model] # 默认走第一个供应商 p CONFIG[providers][0] return p[name], p[models][0] def check_guard(request: Request) - dict: 认证 限流返回用户信息不通过则抛异常 api_key request.headers.get(X-Zerker-Key) if not api_key or api_key not in API_KEYS: raise PermissionError(invalid or missing api key) user API_KEYS[api_key] # 极端简化版限流同一用户在 1 秒内最多 5 次 now time.time() recent [r for r in USAGE_LOG if r[user] user[user] and now - r[ts] 1] if len(recent) 5: raise RuntimeError(rate limit exceeded) return user def record_charge(user: dict, provider: str, model: str, input_tokens: int, output_tokens: int): 记录用量charge 的最基础动作 usage { id: str(uuid.uuid4()), ts: time.time(), user: user[user], tier: user[tier], provider: provider, model: model, input_tokens: input_tokens, output_tokens: output_tokens, total_tokens: input_tokens output_tokens, } USAGE_LOG.append(usage) print(f[charge] {usage}) return usage app.post(/v1/chat/completions) async def chat_completions(request: Request): # 1. guard认证限流 try: user check_guard(request) except PermissionError as e: return Response(contentstr(e), status_code401) except RuntimeError as e: return Response(contentstr(e), status_code429) # 2. 读取请求体 body await request.json() # 3. route根据用户等级选择供应商和模型 provider_name, model resolve_route(user[tier]) provider next(p for p in CONFIG[providers] if p[name] provider_name) # 实际项目中需要从供应商配置读取真实 api_key 并做加密管理 upstream_url f{provider[base_url]}/v1/chat/completions body[model] model # 4. 转发请求 async with httpx.AsyncClient(timeout60) as client: upstream_resp await client.post(upstream_url, jsonbody) # 5. charge记录 token 用量 # 说明真实项目中 token 从响应体 usage 字段读取这里做保护性处理 resp_json upstream_resp.json() usage resp_json.get(usage, {}) if usage: record_charge( user, provider_name, model, usage.get(prompt_tokens, 0), usage.get(completion_tokens, 0), ) return Response(contentupstream_resp.text, status_codeupstream_resp.status_code, media_typeapplication/json)这份代码虽然简单但把 route、guard、charge 三个核心能力的骨架搭出来了。guard 在请求入口完成 API Key 校验和简单限流route 根据用户等级决定请求转发的目标供应商和模型charge 在响应返回后从响应体里取出 usage 字段记录 token 消耗。代码里值得注意的细节是转发使用的是 httpx 的 AsyncClient因为 FastAPI 的请求处理是异步的不能使用 requests 这种同步库否则生产环境一有并发就会阻塞事件循环。6.3 配置文件# config.yaml providers: - name: provider-openai base_url: https://api.openai.com models: [gpt-4o, gpt-4o-mini] - name: provider-deepseek base_url: https://api.deepseek.com models: [deepseek-chat] routes: - name: chat-route path: /v1/chat/completions rules: - if: user.tier enterprise provider: provider-openai model: gpt-4o - if: user.tier free provider: provider-deepseek model: deepseek-chat由于这个示例没有真实的供应商 API Key直接运行无法真正完成上游调用。但这不影响它演示网关的核心逻辑。你可以把它指向任何本地 mock 服务验证 route 和 guard 的行为是否按预期工作。7. 运行与效果验证启动这个最小网关uvicorn main:app --host 0.0.0.0 --port 8000然后可以分三种情况验证。7.1 验证 guard无 Key 请求被拦截curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {messages:[{role:user,content:hello}]}预期结果是返回 401内容是 invalid or missing api key。7.2 验证 route不同用户等级路由到不同模型带上 enterprise 用户的 Keycurl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -H X-Zerker-Key: sk-test-user-a \ -d {messages:[{role:user,content:hello}]}由于当前没有真实上游而本地也没有 mock 服务你会看到上游连接失败的报错。但你可以关注服务端日志确认代码在路由阶段已经选择了provider-openai和gpt-4o而不是 DeepSeek。7.3 验证 charge用量日志每次成功转发后终端会打印类似下面的记录[charge] {id: xxx, ts: 1730000000.123, user: alice, tier: enterprise, provider: provider-openai, model: gpt-4o, input_tokens: 12, output_tokens: 45, total_tokens: 57}这说明请求已经被计量并记录。生产环境中这条记录应该流入 PostgreSQL、ClickHouse 或者时序数据库统一做聚合分析。8. 常见问题与排查思路在部署和使用 AI 网关的过程中下面几个问题出现的频率非常高建议收藏备用。问题现象可能原因排查方式解决方案网关收到请求但转发超时上游模型 API 响应较慢网关超时设置过短查看网关日志中的上游耗时按模型和任务类型分别调大超时时间流式输出不生效网关缓冲了全部响应后才返回破坏了 SSE 流用 curl 观察响应是否为 chunked确认网关支持流式透传或改用原生流式接口API Key 被冒用Key 写入前端代码或代码仓库检查 Git 历史、前端请求抓包轮换 Key接入审计日志按最小权限原则下发限流误杀正常请求限流阈值设置过严未考虑批量任务查看被限流的请求来源和频率分布先观察后限制按用户或项目维度差异化配置计费金额和供应商账单不一致token 计算口径不同或未计缓存命中对比网关记录和供应商账单明细记录原始 token 字段支持按口径重算某一路由突然大量失败供应商单个模型限流但健康检查只检查了域名连通性检查模型级别错误率和状态码分布将健康检查细化到模型级别配置故障转移9. 最佳实践与工程建议把网关从 Demo 做到生产可用的过程中有几点经验值得分享。第一API Key 不要直接写在业务代码里。网关自身持有的各供应商 Key应该加密存储或者接入公司的密钥管理系统。内部业务方使用的 Key按需签发、定期轮换泄露后可以单独吊销不影响其他调用方。第二路由策略先简单后复杂。不要一上来就搞语义路由、动态加权。先用用户等级或项目维度的静态路由跑通积累真实的流量数据后再引入按成本、延迟的动态策略。第三guard 的限流策略应该基于真实流量曲线设计。建议先以审计模式运行一段时间记录每个调用方的正常流量峰值再根据数据设定限流阈值。阈值要留出必要余量避免误伤。第四计费数据要从第一天就规范化。记录字段至少包括调用方、项目、用户等级、供应商、模型、输入 token、输出 token、缓存 token、耗时、状态码、时间戳。这些字段就是后续成本分析、成本优化、异常发现的数据底座。第五网关层要保留完整的请求日志链路。把网关的请求 ID 透传到上游模型调用中出了问题才能快速定位是网关的问题、供应商的问题、还是业务方的问题。第六安全策略和路由策略要走灰度发布。先让测试流量验证再放量到部分核心业务最后全量生效。网关是流量入口任何策略变更都影响所有下游业务。10. 总结与后续学习方向这一节不打算给你写什么“AI 时代已经到来”的空话。真正想提醒你的是只要你的团队在用大模型 API 做生产业务route、guard、charge 这三件事迟早要做区别只是主动做和被动补的区别。Zerker 的项目命名恰好把这套治理逻辑压缩成了三个词。无论你最终选择用 Zerker、自研网关还是使用云厂商的网关产品都可以用这三个维度去评估方案的完整性路由是否灵活、安全防护是否到位、计量计费是否可靠。下一步建议你亲手做两件事。第一把文章第六节的最小网关代码跑起来。不需要接真实模型用本地 mock 服务模拟上游先把 route 和 guard 的流程走通再考虑接入真实 API。第二盘点一下你团队目前的模型调用方式。回答三个问题代码里直接调了多少家供应商API Key 存在哪里月底的模型费用能按部门拆分吗这三个问题的答案基本就决定了你对 AI 网关的改造优先级。如果你已经用的是现成网关也可以对照第九节的建议检查一下自己的配置有没有遗漏项。成本治理和安全治理没有一劳永逸上了网关只是一个开始。
从“代码直连”到“平台治理”：AI网关的route、guard与charge核心机制解析
如果你的团队已经接入了两个以上的大模型 API我相信你迟早会遇到下面这三个问题。第一业务代码里到处是不同厂商的接口调用OpenAI 一段、通义千问一段、DeepSeek 一段混在一起没人敢动每次想切换模型供应商都像拆炸弹。第二API Key 散落在各个服务、各个环境变量、甚至代码仓库里谁在调用、能不能调用、调了多少完全没有人能说得清楚。第三月底账单出来了财务问你“这个月花了多少 token、是哪个部门消耗的、哪个模型最烧钱”你只能支支吾吾。这三个问题分别对应了一个 AI 网关必须具备的三项核心能力路由、守卫、计费。而 Zerker AI Gateway 这个项目的命名用最简单的三个动词把这套能力抽象了出来route, guard and charge。这篇文章不是 API 文档的翻译。我想借 Zerker 的设计理念把 AI 网关中 route、guard、charge 这三件事讲透它解决的到底是什么问题、适合谁用、实际项目中应该怎么落地以及新手最容易在哪里翻车。即使你暂时不打算用 Zerker这套分析框架也可以直接迁移到其他网关方案上。1. AI Gateway 是什么为什么要关注它先下一个结论AI Gateway 的本质不是又一个 API 转发代理而是让大模型接入从“代码直连”走向“平台治理”的中间层。没有网关的时候业务系统是直接对着模型供应商的 API 发请求的。这个模式在只有一个模型、一个调用方的时候没问题但一旦出现下面任何一种情况代码直连就会迅速失控公司同时接入了多家模型供应商每个供应商的请求格式、鉴权方式、限流策略都不一样不同的业务线需要调用不同的模型但密钥统一由平台团队管理不能下发给每个业务方需要限制某些内部服务的调用频率防止有人误写了一个死循环把月度预算跑穿月底需要按部门、按项目、按模型维度统计 token 消耗和费用。这些问题靠业务代码里的 if-else 解决不了靠“在代码里多封装一层”也解决不了。因为它们本质上是治理问题不是编码问题。AI Gateway 做的事情就是把这个治理层从业务代码中抽出来放到请求路径上。所有对大模型 API 的调用先经过网关再由网关统一完成路由转发、安全校验、用量计量。这样一来业务方只需要面对一个稳定的网关入口模型供应商的切换、升级、降级对下游调用方几乎无感。这也是我关注 Zerker 这类项目的原因。它把 AI 网关必须做的事压缩成了三个词route、guard、charge。这三个词看着简单但真正把一个网关落地到生产环境每个词展开都是一套完整的设计。读完这篇文章你会得到三样东西一套理解 AI 网关的思维框架一份围绕 Zerker 设计理念展开的核心机制拆解一个可以直接上手跑通的最小网关实现。2. 先分清传统 route/guard 和 AI Gateway 中的 route/guard在展开 Zerker 之前有必要先解决一个容易混淆的问题。如果你在搜索引擎里输入 route 和 guard会看到大量传统 IT 领域的结果route add命令怎么添加多跳路由、Windows 的 Credential Guard / Device Guard 是什么、VMware 报“检测到 Hyper-V 或 Credential Guard”怎么处理、Oracle Data Guard 怎么做主备同步。这些内容都很有价值但它们和 AI Gateway 里的 route、guard 不是一回事。如果带着传统网络和系统安全的概念去理解 Zerker很容易出现偏差。我做了个对比表方便你快速建立区分维度传统网络/系统领域AI Gateway 领域route 的含义数据包要从哪个网关走路由表决定下一跳大模型请求要转发给哪个供应商路由策略决定模型选择典型工具route add、路由器协议、SDN 控制面模型路由、provider 抽象、故障转移guard 的含义系统凭据保护、设备访问控制API 认证、授权、限流、防滥用典型工具Credential Guard、Device GuardAPI Key、JWT、RBAC、限流中间件charge 的含义网络流量计费、带宽结算token 用量计量、成本分摊、预算控制传统网络里的 route 关心的是“数据包走哪条物理链路”而 AI Gateway 里的 route 关心的是“这个模型请求应该交给哪家供应商、哪个模型”。两者都叫路由但解决的问题层次完全不同。传统领域里的 guard 关心的是“操作系统凭据是否被隔离保护”而 AI Gateway 里的 guard 关心的是“谁有资格调用这个模型、调用频率是否在允许范围内”。前者保护系统安全边界后者保护 AI 服务边界。理解了这个区别后面再看 Zerker 的三个词就不会走偏。它的 route 解决的是“把请求送到最合适的地方”guard 解决的是“请求进来之前先做检查”charge 解决的是“每次请求花了多少钱”。3. Zerker 核心能力拆解route 模型路由3.1 为什么需要模型路由模型路由是整个 AI Gateway 最核心的能力也是最容易被低估的部分。很多团队刚开始接入大模型时只有一个供应商、一个模型代码里写死调用地址就行。但当模型数量多起来之后你会发现“调用一个模型”这件事本身变成了一个决策问题同样的场景用顶配模型效果好但贵用轻量模型便宜但可能效果不够。同一个模型的低峰期和高峰期响应延迟差异很大。某个供应商出现故障或限流时请求是否能在不改造代码的情况下自动切换到另一个供应商新模型上线后如何先让少量流量试运行再逐步放量这些问题都是“路由”的范畴。Zerker 的核心思路是把“请求最终打到哪个模型”从业务代码中剥离出来变成一个由网关统一决策的过程。业务方不需要关心背后的供应商是哪家只需要告诉网关“我要什么样的能力、什么等级的质量”剩下的路由决策交给网关完成。3.2 路由策略的类型从实际落地经验看模型路由策略可以分为三个层次。第一层是静态路由。最简单把请求的某个属性映射到固定的模型上。比如内部测试流量全部走 DeepSeek生产流量全部走 OpenAI或者按用户等级划分普通用户用轻量模型企业用户用旗舰模型。第二层是动态路由。网关根据实时的成本、延迟、可用率、token 消耗等指标决定把请求发送给哪个供应商。比如在两家供应商之间按权重分配流量或者当某一家 API 连续报错时自动把流量切换到另一家。第三层是语义路由。将请求的提示词内容做一定的分析判断它属于代码生成、文本总结、角色对话还是知识问答然后分发到对应能力最合适的模型上。这层路由对网关的智能程度要求更高一般作为演进方向而不是第一阶段的目标。3.3 一个参考路由配置下面是一份基于 Zerker 设计思路编写的参考配置。它演示的是如何通过配置文件把“不同用户等级走不同模型”和“供应商故障自动转移”表达出来。# zerker-gateway-config.yaml # 参考 Zerker route/guard/charge 设计理念的示例配置字段为通用风格 providers: - name: provider-openai base_url: https://api.openai.com models: [gpt-4o, gpt-4o-mini] weight: 80 timeout_ms: 30000 health_check: enabled: true interval_sec: 30 - name: provider-deepseek base_url: https://api.deepseek.com models: [deepseek-chat] weight: 20 timeout_ms: 30000 health_check: enabled: true interval_sec: 30 routes: - name: chat-completions-route path: /v1/chat/completions strategy: weight-round-robin rules: - if: user.tier enterprise provider: provider-openai model: gpt-4o - else: provider: provider-deepseek model: deepseek-chat fallback: - provider: provider-deepseek model: deepseek-chat这份配置表达了三层意思定义了两家供应商OpenAI 和 DeepSeek分别声明支持哪些模型、超时时间和健康检查策略。定义了一条路由规则匹配路径/v1/chat/completions企业用户走 OpenAI其他用户走 DeepSeek。配置了降级回退当主供应商不可用时自动把请求切换到备选供应商。这里的核心设计是业务代码不需要感知供应商的存在。下游应用只需要请求网关的同一个地址由网关根据配置决定到底转发给谁。3.4 路由落地时最容易踩的坑路由看起来不过是“转发请求”但实际落地时有几个坑非常隐蔽。第一个坑是超时传播。模型 API 的响应时间通常比普通 HTTP 接口长得多。如果网关层只给上游设置 5 秒超时遇到长文本生成任务几乎必然超时。网关的超时设置必须按模型和任务类型分别配置不能一刀切。第二个坑是流式响应。大模型应用大量使用 SSE 流式输出客户端是一个字一个字看到响应内容的。如果网关在转发时不支持流式模式或者缓冲了全部内容才返回用户的体验会完全毁掉。选型网关时必须确认它对 SSE 和流式转发的支持程度。第三个坑是健康检查过于简单。只看“供应商的 API 能不能 ping 通”是不够的。真实故障可能是某个具体模型返回 429 限流或者某个 API Key 欠费被禁用而这些并不会让供应商的基础域名完全不可达。健康检查的粒度要细化到“模型级别”而不是“供应商级别”。4. Zerker 核心能力拆解guard 安全守卫4.1 guard 解决什么问题只要网关一天开着就会有人试图滥用它。这里的“滥用”不只是恶意攻击更多时候是内部误操作实习生写了一个循环调用的脚本忘了加退出条件某个内部工具在测试环境跑了一晚上把月度预算烧掉了上游业务的 API Key 泄露到 GitHub被外部扫描到后盗刷。guard 要做的就是在请求真正到达模型供应商之前完成认证、授权、限流、审计等所有安全动作。如果拿操作系统来类比传统 Windows 的 Credential Guard 是用虚拟化技术把系统凭据隔离在受保护的内存区域里防止被恶意进程读取。AI Gateway 里的 guard 思想是类似的网关要把所有调用方的身份、权限、用量信息统一管理起来而不是让每个调用方自己控制。4.2 guard 的四层防护第一层是身份认证。网关需要验证请求方是谁。最常见的方式是 API Key 或 JWT。API Key 适合服务端到服务端的调用JWT 适合带有用户身份的调用场景。第二层是授权。认证解决“你是谁”授权解决“你能做什么”。一个测试环境的服务不应该被允许调用生产环境的付费模型一个普通业务方不应该有权限调用企业级的旗舰模型。第三层是行为防护。包括限流、配额、内容安全。限流保证某个调用方不会一瞬间打爆网关配额保证某个项目组不会提前耗尽月度预算内容安全则根据合规要求对输入输出进行必要的过滤。第四层是审计。每一次请求谁调的、调了哪个模型、输入了多少 token、返回了多少 token、耗时多久、是否成功都要有日志。审计不只为了安全它还是计费的数据基础。4.3 一个参考 guard 配置# zerker-guard.yaml # 参考 Zerker guard 能力设计的示例配置 guards: - name: api-key-auth type: apikey header: X-Zerker-Key keys: - key: sk-test-user-a user: alice tier: enterprise enabled: true - key: sk-test-user-b user: bob tier: free enabled: true - name: rate-limit type: token-bucket capacity: 1000 # 桶容量 refill_rate: 100 # 每秒补充的令牌数 scope: user # 按用户维度限制 - name: quota type: monthly-budget scope: project limit: 1000 # 单位美元 alert_at: 80 # 使用量达到 80% 时告警这份配置的特点是把安全规则从业务代码中剥离出来变成声明式的策略。业务方不需要在自己的代码里实现限流只需要在网关注册自己的 Key并声明自己的使用限制。4.4 guard 设计中的一个关键取舍在 guard 的设计上有一个关键取舍值得展开到底应该提升防护强度还是保证请求顺畅任何安全机制都是成本。过强的防护会让正常请求被误杀。这就像 VMware 在启用了 Hyper-V 或 Credential Guard 的机器上运行虚拟化时经常报“检测到 Hyper-V 或 Credential Guard”的错误——安全机制和业务功能之间出现了冲突。AI 网关的 guard 同样如此。如果限流阈值设置得过于严格某个真实业务在促销流量下可能会被误限流如果审计日志记录得过于详细存储成本会迅速上升如果认证链路过于复杂网关本身的延迟就会变得不可接受。我的建议是生产环境的 guard 策略应该有一个灰度放大的过程。先记录不做限制观察正常流量峰值再根据真实数据设定限流阈值先只对核心接口开启认证再逐步扩大到全部接口。安全策略要能随时调整而不是一上来就全量锁死。5. Zerker 核心能力拆解charge 计量计费5.1 为什么计费是 AI 网关的必备能力模型 API 的计费和传统 IT 资源计费有本质区别。传统服务器计费按 CPU 核数、内存大小、磁盘容量算这些资源是“可预期的”。而大模型 API 是按 token 计费的你无法在请求发出前精确预知这次对话会消耗多少 token同一个问题不同模型的回答长度不同价格差异巨大。更麻烦的是token 消耗量不仅取决于用户输入还取决于模型输出长度、上下文窗口大小、系统提示词的长度等等。这就带来一个尴尬的事实项目上线前你很难准确估算 AI 成本。charge 能力要解决的就是让“看不见的 token 消耗”变成“可计量、可追溯、可控制”的数字。5.2 charge 的三层能力第一层是计量。网关每一次转发请求都要记录请求模型、输入 token 数、输出 token 数、缓存命中情况。这些原始数据是计费的基础。第二层是计价。根据供应商的单价计算出每一次请求的费用。这里要注意不同模型的计价维度不同有的按输入和输出分开计价有的还要算缓存命中价。计费系统必须支持灵活的计价规则配置。第三层是分摊与控制。把费用按项目、部门、业务线、调用方分摊让每个团队都能看到自己的消耗。同时支持预算上限控制和告警防止单个项目把整个公司的大模型预算跑穿。5.3 一个参考 charge 配置# zerker-charge.yaml # 参考 Zerker charge 能力设计的示例配置 charge: meter: type: token fields: [input_tokens, output_tokens, cache_hit_tokens, total_tokens] pricing: - model: gpt-4o input_price: 5 # 每百万 token 的价格 output_price: 15 cache_hit_price: 0.5 - model: deepseek-chat input_price: 1 output_price: 2 cache_hit_price: 0.1 allocation: - project: search-team budget_usd: 2000 alert_at: 80 - project:>simple-ai-gateway/ ├── config.yaml ├── main.py └── requirements.txtrequirements.txt 内容fastapi uvicorn pyyaml httpx安装依赖pip install fastapi uvicorn pyyaml httpx6.2 主程序代码# main.py import time import uuid import yaml import httpx from fastapi import FastAPI, Request, Response from fastapi.responses import StreamingResponse app FastAPI() # 加载配置 with open(config.yaml, r, encodingutf-8) as f: CONFIG yaml.safe_load(f) # 模拟数据库API Key - 用户信息 API_KEYS { sk-test-user-a: {user: alice, tier: enterprise}, sk-test-user-b: {user: bob, tier: free}, } # 用量记录表 USAGE_LOG [] def resolve_route(tier: str): 根据用户等级解析目标供应商和模型 for route in CONFIG[routes]: for rule in route[rules]: if rule[if] fuser.tier {tier}: return rule[provider], rule[model] # 默认走第一个供应商 p CONFIG[providers][0] return p[name], p[models][0] def check_guard(request: Request) - dict: 认证 限流返回用户信息不通过则抛异常 api_key request.headers.get(X-Zerker-Key) if not api_key or api_key not in API_KEYS: raise PermissionError(invalid or missing api key) user API_KEYS[api_key] # 极端简化版限流同一用户在 1 秒内最多 5 次 now time.time() recent [r for r in USAGE_LOG if r[user] user[user] and now - r[ts] 1] if len(recent) 5: raise RuntimeError(rate limit exceeded) return user def record_charge(user: dict, provider: str, model: str, input_tokens: int, output_tokens: int): 记录用量charge 的最基础动作 usage { id: str(uuid.uuid4()), ts: time.time(), user: user[user], tier: user[tier], provider: provider, model: model, input_tokens: input_tokens, output_tokens: output_tokens, total_tokens: input_tokens output_tokens, } USAGE_LOG.append(usage) print(f[charge] {usage}) return usage app.post(/v1/chat/completions) async def chat_completions(request: Request): # 1. guard认证限流 try: user check_guard(request) except PermissionError as e: return Response(contentstr(e), status_code401) except RuntimeError as e: return Response(contentstr(e), status_code429) # 2. 读取请求体 body await request.json() # 3. route根据用户等级选择供应商和模型 provider_name, model resolve_route(user[tier]) provider next(p for p in CONFIG[providers] if p[name] provider_name) # 实际项目中需要从供应商配置读取真实 api_key 并做加密管理 upstream_url f{provider[base_url]}/v1/chat/completions body[model] model # 4. 转发请求 async with httpx.AsyncClient(timeout60) as client: upstream_resp await client.post(upstream_url, jsonbody) # 5. charge记录 token 用量 # 说明真实项目中 token 从响应体 usage 字段读取这里做保护性处理 resp_json upstream_resp.json() usage resp_json.get(usage, {}) if usage: record_charge( user, provider_name, model, usage.get(prompt_tokens, 0), usage.get(completion_tokens, 0), ) return Response(contentupstream_resp.text, status_codeupstream_resp.status_code, media_typeapplication/json)这份代码虽然简单但把 route、guard、charge 三个核心能力的骨架搭出来了。guard 在请求入口完成 API Key 校验和简单限流route 根据用户等级决定请求转发的目标供应商和模型charge 在响应返回后从响应体里取出 usage 字段记录 token 消耗。代码里值得注意的细节是转发使用的是 httpx 的 AsyncClient因为 FastAPI 的请求处理是异步的不能使用 requests 这种同步库否则生产环境一有并发就会阻塞事件循环。6.3 配置文件# config.yaml providers: - name: provider-openai base_url: https://api.openai.com models: [gpt-4o, gpt-4o-mini] - name: provider-deepseek base_url: https://api.deepseek.com models: [deepseek-chat] routes: - name: chat-route path: /v1/chat/completions rules: - if: user.tier enterprise provider: provider-openai model: gpt-4o - if: user.tier free provider: provider-deepseek model: deepseek-chat由于这个示例没有真实的供应商 API Key直接运行无法真正完成上游调用。但这不影响它演示网关的核心逻辑。你可以把它指向任何本地 mock 服务验证 route 和 guard 的行为是否按预期工作。7. 运行与效果验证启动这个最小网关uvicorn main:app --host 0.0.0.0 --port 8000然后可以分三种情况验证。7.1 验证 guard无 Key 请求被拦截curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {messages:[{role:user,content:hello}]}预期结果是返回 401内容是 invalid or missing api key。7.2 验证 route不同用户等级路由到不同模型带上 enterprise 用户的 Keycurl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -H X-Zerker-Key: sk-test-user-a \ -d {messages:[{role:user,content:hello}]}由于当前没有真实上游而本地也没有 mock 服务你会看到上游连接失败的报错。但你可以关注服务端日志确认代码在路由阶段已经选择了provider-openai和gpt-4o而不是 DeepSeek。7.3 验证 charge用量日志每次成功转发后终端会打印类似下面的记录[charge] {id: xxx, ts: 1730000000.123, user: alice, tier: enterprise, provider: provider-openai, model: gpt-4o, input_tokens: 12, output_tokens: 45, total_tokens: 57}这说明请求已经被计量并记录。生产环境中这条记录应该流入 PostgreSQL、ClickHouse 或者时序数据库统一做聚合分析。8. 常见问题与排查思路在部署和使用 AI 网关的过程中下面几个问题出现的频率非常高建议收藏备用。问题现象可能原因排查方式解决方案网关收到请求但转发超时上游模型 API 响应较慢网关超时设置过短查看网关日志中的上游耗时按模型和任务类型分别调大超时时间流式输出不生效网关缓冲了全部响应后才返回破坏了 SSE 流用 curl 观察响应是否为 chunked确认网关支持流式透传或改用原生流式接口API Key 被冒用Key 写入前端代码或代码仓库检查 Git 历史、前端请求抓包轮换 Key接入审计日志按最小权限原则下发限流误杀正常请求限流阈值设置过严未考虑批量任务查看被限流的请求来源和频率分布先观察后限制按用户或项目维度差异化配置计费金额和供应商账单不一致token 计算口径不同或未计缓存命中对比网关记录和供应商账单明细记录原始 token 字段支持按口径重算某一路由突然大量失败供应商单个模型限流但健康检查只检查了域名连通性检查模型级别错误率和状态码分布将健康检查细化到模型级别配置故障转移9. 最佳实践与工程建议把网关从 Demo 做到生产可用的过程中有几点经验值得分享。第一API Key 不要直接写在业务代码里。网关自身持有的各供应商 Key应该加密存储或者接入公司的密钥管理系统。内部业务方使用的 Key按需签发、定期轮换泄露后可以单独吊销不影响其他调用方。第二路由策略先简单后复杂。不要一上来就搞语义路由、动态加权。先用用户等级或项目维度的静态路由跑通积累真实的流量数据后再引入按成本、延迟的动态策略。第三guard 的限流策略应该基于真实流量曲线设计。建议先以审计模式运行一段时间记录每个调用方的正常流量峰值再根据数据设定限流阈值。阈值要留出必要余量避免误伤。第四计费数据要从第一天就规范化。记录字段至少包括调用方、项目、用户等级、供应商、模型、输入 token、输出 token、缓存 token、耗时、状态码、时间戳。这些字段就是后续成本分析、成本优化、异常发现的数据底座。第五网关层要保留完整的请求日志链路。把网关的请求 ID 透传到上游模型调用中出了问题才能快速定位是网关的问题、供应商的问题、还是业务方的问题。第六安全策略和路由策略要走灰度发布。先让测试流量验证再放量到部分核心业务最后全量生效。网关是流量入口任何策略变更都影响所有下游业务。10. 总结与后续学习方向这一节不打算给你写什么“AI 时代已经到来”的空话。真正想提醒你的是只要你的团队在用大模型 API 做生产业务route、guard、charge 这三件事迟早要做区别只是主动做和被动补的区别。Zerker 的项目命名恰好把这套治理逻辑压缩成了三个词。无论你最终选择用 Zerker、自研网关还是使用云厂商的网关产品都可以用这三个维度去评估方案的完整性路由是否灵活、安全防护是否到位、计量计费是否可靠。下一步建议你亲手做两件事。第一把文章第六节的最小网关代码跑起来。不需要接真实模型用本地 mock 服务模拟上游先把 route 和 guard 的流程走通再考虑接入真实 API。第二盘点一下你团队目前的模型调用方式。回答三个问题代码里直接调了多少家供应商API Key 存在哪里月底的模型费用能按部门拆分吗这三个问题的答案基本就决定了你对 AI 网关的改造优先级。如果你已经用的是现成网关也可以对照第九节的建议检查一下自己的配置有没有遗漏项。成本治理和安全治理没有一劳永逸上了网关只是一个开始。 
