在接入大模型 API 的时候很多团队都会经历这样一个阶段业务代码里塞满各家厂商的 SDK不同的 Key 散落在多个服务中模型版本一升级就要改代码发版月底对账时才发现调用量完全没记录。原型阶段这些还能忍一旦要上生产问题就会集中爆发模型怎么切换、调用怎么鉴权、成本怎么控制。Zerker 这个项目名把答案浓缩成了三个词route、guard、charge。翻译过来就是路由、防护、计费。这三个词看起来都不新鲜但在 AI Gateway 的语境下它们的含义和传统 API 网关完全不同。如果只看表面很容易误以为 AI Gateway 就是个聚合 API 的中转代理真正的问题在于它把“调用大模型”这件事从业务代码里抽离出来变成了一个可配置、可观测、可管控的基础设施层。这篇文章会讲清楚三件事第一route、guard、charge 在 AI 网关里到底意味着什么第二为什么传统 API 网关很难直接拿来做 AI 网关第三如何用最小技术栈自己搭一个能跑通的网关样例并给出完整的代码、验证命令和排查清单。1. 这篇文章真正要解决的问题先给结论AI Gateway 不是锦上添花的工具而是大模型应用从原型走向生产的一道基础设施层。在开发阶段团队关心的是哪个模型效果更好、怎么快速切换模型。到了生产阶段问题就变了外部模型服务不稳定怎么办、不同业务线怎么隔离配额、每个 BU 花了多少 Token 成本怎么算。这些问题如果散落在业务代码里逐个解决每个接入方都要重复造轮子最终必然失控。拿调用 OpenAI、Anthropic、通义、文心这类不同厂商的模型来说。业务代码如果直接写死某一家 SDK后续模型选型一变就要动业务代码不同模型的价格差异很大没有统一计量就无法回答“这个月模型花费为什么涨了 30%”这种问题再把权限、限流、内容安全加上去复杂度会快速膨胀。AI Gateway 解决的就是这类共性问题。它把模型选择、权限校验、流量控制、用量计量这些能力集中到一个统一的接入层。业务方只关心“我要一个叫 chat-llm 的模型能力”至于这个能力背后是哪个厂商的哪个模型、走了哪条线路、花了多少钱不需要关心。什么样的读者最适合读这篇文章后端工程师、平台架构师、技术管理者以及正在做 AI 应用集成、企业内部模型平台、模型成本治理的人。如果你只是本地调一下 OpenAI SDK 写个 Demo这篇文章的很多内容可以暂时不用关注但只要你准备把模型调用做成团队或公司的公共能力route、guard、charge 这三个问题就绕不开。2. 三个关键词的真实含义route、guard、charge很多第一次接触 AI Gateway 的人会把 route 理解成负载均衡把 guard 理解成登录鉴权把 charge 理解成记账。这三个理解都不算错但都太窄了。在 AI 网关场景下每个词背后都有一组具体问题。2.1 route把模型选择变成策略而不是代码route 解决的核心问题是业务方请求一个抽象模型名网关来决定真正调用哪个上游模型。这里至少包含四个层次的能力。第一多模型映射。业务代码只写model: chat-llm网关通过配置把chat-llm映射到具体的供应商和模型例如 OpenAI 的某款模型、Anthropic 的某款模型、或者自建服务的某个模型。第二权重与灰度。同一个模型别名可以配置多个上游按权重分发流量。新模型先接 5% 流量观察效果再逐步放量不需要业务方参与。第三故障转移。当一个上游服务超时或返回 5xx 时网关自动把请求转到另一个可用的上游避免业务直接感知到某个厂商的故障。第四隔离与策略。不同业务线可以绑定不同的路由策略例如 A 业务走效果更好的模型B 业务走更便宜的模型还可以按请求来源、用户等级、功能场景做精细路由。这里的核心判断是route 让“模型选择”从一次性的代码决策变成了可持续调整的运行时策略。2.2 guard不只是鉴权而是多层防线guard 在 AI 网关里的职责远不止校验一个 API Key。它至少需要覆盖五类问题。认证与授权调用方是谁、有没有权限调用某个模型、不同业务线的数据是否隔离。限流与配额防止单个调用方打爆上游账号也防止异常调用导致成本飙升。内容安全对入站和出站内容做合规检查拦截敏感信息、Prompt 注入、恶意内容。数据保护识别并脱敏身份证号、手机号等敏感信息避免数据被明文发给外部模型。成本防护设置单次请求 Token 上限、单账号每日消耗上限超限直接拒绝防止模型 Token 爆炸。在实际项目中guard 层的价值往往不是某个单一能力而是把安全策略集中在一个位置统一管控。没有这一层每个业务方自己去处理鉴权和内容安全最终一定会出现有的业务做了、有的业务没做的漏洞。2.3 charge不是收钱而是让成本可观测、可控制charge 在 AI 网关里的含义是“计量与计费”但大部分内部平台做的不是向业务方收真钱而是把 Token 消耗变成可量化的数据。这包含几个动作记录每次请求的输入 Token、输出 Token根据模型单价计算本次调用的费用按租户、业务线、应用维度汇总用量生成日报、月报和成本趋势设置预算告警当月度成本达到阈值时通知负责人。为什么这件事重要因为大模型 API 的成本和传统服务器的固定成本完全不同它是随调用量线性增长的。没有计量就没有成本控制没有成本控制AI 应用的商业模式就无法成立。很多团队上线 AI 功能后第一个被财务找上门的场景就是月底没有模型账单业务方也不知道自己花了多少钱。2.4 与传统 API 网关的差异对照对比维度传统 API 网关AI 网关route/guard/charge核心流量内部服务间调用请求时长通常在毫秒级外部模型服务调用响应时长通常在秒级甚至更长路由依据路径、方法、Header、服务名模型别名、供应商、模型版本、成本预算、灰度策略失败处理负载均衡、重试、熔断多供应商故障转移、降级到备用模型、流式中断处理计量单位请求数、QPS、带宽Token 数、模型单价、输入/输出 Token 占比安全重点认证、权限、参数校验数据脱敏、Prompt 安全、内容合规、成本配额成本模型服务器和带宽成本相对固定按 Token 计费成本随用量线性增长这张表说明了一个问题AI Gateway 不是给传统 API 网关加几个插件就能完成的它的路由策略、计量模型、失败处理语义都变了。3. 为什么直接拿 API 网关做 AI 网关会遇到困难有些团队会想公司已经有 K8s Ingress、Nginx、Spring Cloud Gateway 之类的网关在它上面加个代理转发到模型 API 不就行了这个思路的瓶颈不在“转发”本身而在 AI 场景特有的几个问题。第一个问题是上游的高延迟和长连接。模型服务生成一段文本需要几秒甚至几十秒普通网关的超时配置和连接池参数是按毫秒级内部调用设计的拿到模型场景很容易误杀慢请求。直接调大超时时间又会对上游故障转移和路由控制造成困难。第二个问题是流式响应。大模型聊天普遍使用 SSEServer-Sent Events流式输出网关需要支持流式转发、流式中断、流结束时的 Token 计量。传统网关的日志和流量复制体系大多基于完整 HTTP 响应对流式响应的可观测性支持不足。第三个问题是错误和重试语义。模型接口偶发 5xx 很常见但直接重试并不安全某些模型请求不是幂等的重发可能导致用户收到重复内容或产生双倍费用。网关需要在重试、故障转移和费用计量之间做平衡这是传统网关很少考虑的。第四个问题是计量对象完全变了。传统网关关心 QPS、延迟、错误率AI 网关还要关心输入 Token、输出 Token、单价、成本。这些数据必须在网关层采集否则上游供应商只给你整体账单无法拆到业务线。所以更稳妥的判断是AI Gateway 适合作为独立的中间层来建设而不是在通用网关里堆插件。它要管理的状态、策略和计量逻辑已经超出了通用网关的设计范围。4. AI Gateway 的整体架构与核心模块设计一个清晰的 AI Gateway 架构可以分成五层每层职责单一通过接口划分边界。4.1 接入层负责接收业务方的请求包括 HTTP 入口、统一鉴权入口、请求格式校验、协议转换。对外只暴露一个统一的 OpenAI 兼容接口业务方不需要感知背后接入了哪家模型。推荐做法是对外接口统一使用/v1/chat/completions风格与 OpenAI 协议兼容这样业务方现有的 SDK 可以无痛切换。4.2 路由层根据请求中的模型别名结合配置、权重、健康状态、灰度规则决策真正调用哪个上游模型。路由层是 AI Gateway 的核心也是三类能力中变化最快、策略最丰富的一层。4.3 防护层在请求进入上游前做认证、限流、配额检查、内容安全、敏感信息脱敏在响应返回前做内容合规检查、Token 配额校验。防护层必须做到 fail-closed拿不准时宁可拒绝也不要放行。4.4 计量层采集每次请求的 Token 用量、模型信息、耗时、成本写入用量库或消息队列供后续对账、报表和告警使用。计量层不能阻塞主请求必须异步化。4.5 适配层将统一的内部请求格式转换为各厂商的 API 格式处理不同厂商的鉴权方式、模型名称映射、超时与重试策略。这一层让路由层和上游厂商解耦新增厂商只改适配器。一次完整的请求生命周期客户端请求到达接入层携带 API Key 和模型别名。防护层校验身份、配额、内容安全通过后进入路由层。路由层根据模型别名选择上游交给适配层。适配层调用外部模型 API等待响应或流式读取。计量层记录 Token 用量并异步写入费用报表。接入层将上游响应返回给客户端。这个架构的核心原则是上游供应商的变动不影响业务方业务方的模型需求不影响上游供应商的接入方式计费和防护能力对所有业务线保持一致。5. 环境准备用最小技术栈搭建一个 AI 网关样例下面用一个最小可运行的 Node.js 网关样例演示 route、guard、charge 的落地思路。技术选型不是唯一答案但 Node.js 对异步流式处理和 JSON API 对接非常友好适合用来讲解核心逻辑。本文重点演示通用实现思路不绑定 Zerker 的具体版本。版本信息请以实际项目为准。5.1 技术栈说明组件用途说明Node.js 18运行时原生支持 fetch 和 AbortSignal.timeout示例无需额外 HTTP 客户端TypeScript类型安全便于说明核心接口实际项目可按团队习惯选择expressHTTP 服务搭建网关入口rate-limiter-flexible限流支持令牌桶、滑动窗口等策略js-yaml配置解析读取模型路由与防护配置better-sqlite3本地用量存储演示用量写入生产可替换为 MySQL/PostgreSQL5.2 初始化项目mkdir zerker-gateway-demo cd zerker-gateway-demo npm init -y npm install express rate-limiter-flexible js-yaml better-sqlite3 npm install -D typescript ts-node types/node types/express5.3 目录结构规划zerker-gateway-demo/ ├── config/ │ └── gateway.yaml # 路由、防护、计费配置 ├── src/ │ ├── index.ts # 网关入口组装各层 │ ├── router.ts # 路由层模型选择与故障转移 │ ├── guard.ts # 防护层鉴权与限流 │ ├── billing.ts # 计量层Token 估算与用量记录 │ ├── config.ts # 配置加载 │ └── db.ts # SQLite 初始化 └── data/ # SQLite 数据文件目录6. 核心代码实现路由、防护、计费这一部分是全文的核心。先用一个精简但完整的配置再给出三个关键模块的代码。6.1 网关配置文件文件路径config/gateway.yamlmodels: chat-llm: # 权重路由80% 流量走主模型20% 走备用模型 - id: openai-chat provider: openai model: gpt-4o-mini base_url: https://api.openai.com/v1 weight: 80 timeout_ms: 30000 enabled: true - id: anthropic-chat provider: anthropic model: claude-3-5-haiku base_url: https://api.anthropic.com/v1 weight: 20 timeout_ms: 30000 enabled: true guards: api_key_check: true rate_limit: capacity: 100 refill_per_second: 10 billing: currency: USD price_per_1m_input_tokens: 0.15 price_per_1m_output_tokens: 0.60 cost_alert_threshold_usd: 1000这段配置表达了三层意思models段定义了模型别名chat-llm背后的两个上游以及权重比例guards段定义了 API Key 校验和限流参数billing段定义了模型单价和成本告警阈值。这里的模型名称没有特殊限制实际项目以你接入的厂商和模型版本为准重点是理解路由配置的结构一个别名对应多个上游每个上游有权重、超时和启用状态。6.2 路由层实现文件路径src/router.tsimport * as fs from fs; import * as yaml from js-yaml; export type UpstreamModel { id: string; provider: string; model: string; baseUrl: string; weight: number; timeoutMs: number; enabled: boolean; }; type GatewayConfig { models: Recordstring, UpstreamModel[]; guards: { api_key_check: boolean; rate_limit: { capacity: number; refill_per_second: number }; }; billing: { currency: string; price_per_1m_input_tokens: number; price_per_1m_output_tokens: number; cost_alert_threshold_usd: number; }; }; let config: GatewayConfig; export function loadConfig(path: string config/gateway.yaml): GatewayConfig { const raw fs.readFileSync(path, utf-8); config yaml.load(raw) as GatewayConfig; return config; } export function getConfig(): GatewayConfig { if (!config) { throw new Error(config not loaded, call loadConfig first); } return config; } /** * 根据模型别名按权重选择一个上游模型。 * failovertrue 时模拟跳过当前候选实际项目应结合健康状态过滤。 */ export function selectUpstream(alias: string): UpstreamModel { const candidates (getConfig().models[alias] ?? []).filter(m m.enabled); if (candidates.length 0) { throw new Error(no enabled upstream for model alias: ${alias}); } const totalWeight candidates.reduce((sum, m) sum m.weight, 0); let roll Math.random() * totalWeight; for (const candidate of candidates) { roll - candidate.weight; if (roll 0) { return candidate; } } return candidates[candidates.length - 1]; }路由层的逻辑要点候选模型被过滤掉禁用项后按权重区间做随机选择。这里的failover参数在真实工程中不应该只靠随机而是要结合熔断健康状态把近期失败的模型临时排除在候选集合外。6.3 防护层实现文件路径src/guard.tsimport { RateLimiterMemory } from rate-limiter-flexible; import { getConfig } from ./router; const API_KEYS new Setstring([ // 生产环境请换用数据库或 Redis 存储并保存哈希值 zk_live_demo_key_001, ]); const rateLimiter new RateLimiterMemory({ points: 10, // 窗口内允许的请求数 duration: 60, // 窗口时长秒 }); export type GuardError Error { status: number }; function makeGuardError(status: number, message: string): GuardError { const err new Error(message) as GuardError; err.status status; return err; } /** * 防护层入口认证 - 限流 - 配额检查。 * 后续可以继续扩展内容安全、数据脱敏等能力。 */ export async function guardRequest(req: any): Promisevoid { const guards getConfig().guards; // 1. API Key 认证 if (guards.api_key_check) { const apiKey req.headers[x-api-key] ?? ; if (!API_KEYS.has(apiKey)) { throw makeGuardError(401, invalid api key); } } // 2. 限流按租户维度隔离 const tenantId req.headers[x-tenant-id] ?? default; try { await rateLimiter.consume(tenantId); } catch { throw makeGuardError(429, rate limit exceeded, retry later); } // 3. 内容大小检查禁止超大请求体防止 Prompt 注入和成本炸弹 const rawBody JSON.stringify(req.body ?? {}); if (rawBody.length 50_000) { throw makeGuardError(413, request body too large); } }防护层的关键不是把代码写得复杂而是保证“所有请求都必须经过统一入口”。很多团队会在网关里做一部分鉴权业务代码里又做一部分最后两边对不上。正确做法是网关负责所有通用安全策略业务方只负责业务逻辑。6.4 计量层实现文件路径src/billing.tsimport Database from better-sqlite3; import { getConfig } from ./router; const db new Database(data/usage.db); db.exec( CREATE TABLE IF NOT EXISTS usage_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, tenant_id TEXT NOT NULL, request_id TEXT NOT NULL, model_alias TEXT NOT NULL, upstream_model TEXT NOT NULL, input_tokens INTEGER NOT NULL, output_tokens INTEGER NOT NULL, cost_usd REAL NOT NULL, created_at TEXT DEFAULT (datetime(now)) ); ); /** * 粗略估算输入 Token 数。 * 生产环境建议接入具体模型厂商的 tokenizer这里只做演示。 */ export function estimateInputTokens(messages: Array{ role: string; content: string }): number { let chars 0; for (const msg of messages) { chars msg.content.length; } // 中英文混合场景下按每 4 个字符约 1 个 token 做粗略估算 return Math.ceil(chars / 4); } /** * 写入用量记录。这里直接同步写 SQLite生产环境应改为异步队列。 */ export function billUsage(params: { tenantId: string; requestId: string; modelAlias: string; upstreamModel: string; usage: { inputTokens: number; outputTokens: number }; }): void { const billing getConfig().billing; const inputCost (params.usage.inputTokens / 1_000_000) * billing.price_per_1m_input_tokens; const outputCost (params.usage.outputTokens / 1_000_000) * billing.price_per_1m_output_tokens; const costUsd inputCost outputCost; const stmt db.prepare( INSERT INTO usage_records (tenant_id, request_id, model_alias, upstream_model, input_tokens, output_tokens, cost_usd) VALUES (tenant_id, request_id, model_alias, upstream_model, input_tokens, output_tokens, cost_usd) ); stmt.run({ tenant_id: params.tenantId, request_id: params.requestId, model_alias: params.modelAlias, upstream_model: params.upstreamModel, input_tokens: params.usage.inputTokens, output_tokens: params.usage.outputTokens, cost_usd: costUsd, }); console.log([billing] tenant${params.tenantId} cost${costUsd.toFixed(6)} USD); }计量层的重点在于Token 估算和单价模型都做成了可配置项上游响应里如果有usage字段应该优先使用上游返回的精确 Token 数估算只用于请求前预检。示例代码里没有写出输出 Token 的估算是为了强调响应 Token 的精确计量在上游返回后拿到不能靠估算。6.5 网关主服务组装文件路径src/index.tsimport express from express; import { randomUUID } from crypto; import { loadConfig, selectUpstream, getConfig } from ./router; import { guardRequest } from ./guard; import { billUsage, estimateInputTokens } from ./billing; loadConfig(); const app express(); app.use(express.json({ limit: 1mb })); const modelPrices new Mapstring, { input: number; output: number }(); modelPrices.set(openai-chat, { input: 0.15, output: 0.60 }); modelPrices.set(anthropic-chat, { input: 0.25, output: 1.25 }); async function callUpstream(upstream: any, body: any): Promiseany { const envKeyName API_KEY_${upstream.provider.toUpperCase()}; const apiKey process.env[envKeyName]; if (!apiKey) { throw new Error(missing env ${envKeyName}); } const res await fetch(${upstream.baseUrl}/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${apiKey}, }, body: JSON.stringify({ model: upstream.model, messages: body.messages, temperature: body.temperature ?? 0.7, stream: body.stream ?? false, }), signal: AbortSignal.timeout(upstream.timeoutMs), }); const data await res.json(); if (!res.ok) { throw new Error(upstream ${upstream.id} failed: ${res.status} ${JSON.stringify(data)}); } return data; } async function callWithFailover(alias: string, body: any, maxAttempts 2): Promiseany { let lastError: Error | null null; for (let attempt 0; attempt maxAttempts; attempt) { const upstream selectUpstream(alias); try { return await callUpstream(upstream, body); } catch (err) { lastError err as Error; console.warn([route] attempt ${attempt 1} failed for ${upstream.id}: ${err.message}); } } throw lastError ?? new Error(all upstream attempts failed); } app.post(/v1/chat/completions, async (req, res) { const requestId randomUUID(); try { // 1. guard认证、限流、内容检查 await guardRequest(req); const modelAlias req.body.model ?? chat-llm; const tenantId req.headers[x-tenant-id] ?? default; // 2. 请求前 Token 预估超过阈值直接拒绝 const estimateInput estimateInputTokens(req.body.messages ?? []); if (estimateInput 10_000) { return res.status(413).json({ error: estimated prompt too large }); } // 3. route按权重选择上游失败自动故障转移 const upstream selectUpstream(modelAlias); const data await callWithFailover(modelAlias, req.body); // 4. charge优先使用上游返回的精确用量 const usage data.usage; const inputTokens usage?.prompt_tokens ?? estimateInput; const outputTokens usage?.completion_tokens ?? 0; billUsage({ tenantId, requestId, modelAlias, upstreamModel: ${upstream.provider}:${upstream.model}, usage: { inputTokens, outputTokens }, }); res.json(data); } catch (err) { const status (err as any).status || 502; res.status(status).json({ error: { request_id: requestId, message: (err as Error).message, }, }); } }); app.get(/health, (_req, res) { res.json({ status: ok }); }); const port Number(process.env.PORT ?? 8080); app.listen(port, () { console.log(zerker-gateway demo listening on :${port}); });主服务把三层能力串联起来。guardRequest先做防护estimateInputTokens做请求前成本预检callWithFailover做路由和故障转移最后billUsage做计量。这样一次请求的完整链路就闭环了。7. 运行与验证用 curl 跑通一次完整请求7.1 准备环境变量示例代码里上游 API Key 从环境变量读取千万不要把真实 Key 写进配置文件。export API_KEY_OPENAIsk-你的真实key export API_KEY_ANTHROPICsk-ant-你的真实key7.2 启动网关npx ts-node src/index.ts出现以下日志说明启动成功zerker-gateway demo listening on :80807.3 正常请求验证打开一个终端执行以下命令curl -X POST http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -H x-api-key: zk_live_demo_key_001 \ -H x-tenant-id: tenant_a \ -d { model: chat-llm, messages: [ {role: user, content: 用一句话介绍 AI Gateway} ] }预期返回{ id: chatcmpl-xxx, object: chat.completion, choices: [ { index: 0, message: { role: assistant, content: AI Gateway 是连接应用与大模型服务的基础设施层。 } } ], usage: { prompt_tokens: 12, completion_tokens: 8, total_tokens: 20 } }同时在网关终端会输出计费日志[billing] tenanttenant_a cost0.000012 USD7.4 错误 Key 验证curl -X POST http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -H x-api-key: wrong_key \ -d {model: chat-llm, messages: [{role: user, content: hi}]}预期返回 HTTP 401这也是防护层在正常工作。7.5 限流验证连续发送超过限制的请求预期出现 HTTP 429{ error: { request_id: xxx, message: rate limit exceeded, retry later } }7.6 查看用量记录sqlite3 data/usage.db select tenant_id, model_alias, input_tokens, output_tokens, cost_usd from usage_records order by id desc limit 5;如果能看到记录说明计费链路已打通。8. 常见问题与排查方法问题现象可能原因排查方式解决方案提示missing env API_KEY_OPENAI环境变量未设置或命名与代码不一致确认 provider 字段检查环境变量名设置正确的环境变量重启网关请求返回 401API Key 不正确或已过期检查x-api-key请求头在 API Key 存储中确认 Key 是否存在限流误伤正常用户限流窗口过小或所有租户共用一个限流器查看限流日志确认租户维度按租户动态扩容配额或调整参数路由总走同一个模型权重配比相差过大或上游状态被熔断检查配置里的 weight 和 enabled 状态调整权重检查健康状态标记上游超时导致网关报 502timeout_ms 设置过小或上游服务真故障查看网关错误日志区分超时和连接失败调大超时时间增加故障转移次数Token 用量记录为 0上游响应没有 usage 字段或字段名不匹配打印上游响应原始 JSON适配层做字段映射适配不同厂商响应格式流式请求无法返回内容网关未实现 SSE 转发确认客户端请求里是否带了stream: true接入层增加 SSE 流式转发支持排查的基本原则是先在接入层确认请求是否到达网关再确认防护层是否放行然后确认路由层选到了哪个上游最后确认上游响应是否正常返回。按这个顺序看日志基本能定位 80% 的问题。9. 最佳实践与工程建议9.1 配置与代码严格分离模型路由、单价、限流参数都应该放在配置中心或环境变量中而不是写死在代码里。这样做的好处是调整模型权重、切换模型版本、修改单价时不需要发版重启服务。9.2 上游密钥放进密钥管理系统代码示例里用环境变量演示生产环境建议使用密钥管理服务或内部 Secret 系统。不同供应商的 Key 要严格隔离不要出现一个 Key 泄露导致所有模型账号受影响的情况。9.3 计量层异步化计量写入如果同步阻塞主流程会在高并发时拖慢响应。推荐把用量记录写入消息队列由消费服务批量落库。注意即使计费系统短暂故障也不能让正常请求失败计量应该做到失败不影响主链路。9.4 故障转移要配合熔断和健康检查示例里的 failover 是随机选下一个上游实际工程需要更完整的熔断器上游连续失败 N 次后临时标记为不可用冷却一段时间后再放量试探。否则故障转移可能反复选到已经故障的上游。9.5 限流必须按租户隔离所有租户共用限流池容易出现一个业务线刷爆配额、其他业务线全部被拒的情况。建议以tenant_id作为限流和计费的维度并提供每秒、每分钟、每天不同粒度的配额。9.6 内容安全不能只做一层网关可以做关键词拦截、敏感信息脱敏、Prompt 注入检测但要明白这层检测是概率性的不能完全依赖。更稳妥的做法是网关做基础合规业务方做业务层的内容策略两者互补。9.7 日志要结构化每次请求至少记录请求 ID、租户 ID、模型别名、上游模型、输入 Token、输出 Token、耗时、成本、错误信息。这些字段是后续调优路由权重、分析成本、定位线上问题的依据。10. 总结与后续学习方向从 Zerker 这个标题可以提炼出一个很清晰的判断route、guard、charge 是 AI 网关的三大支柱它们分别解决了模型可控性、访问安全性和成本可观测性三个问题。这篇文章用最小代码样例演示了三条链路模型别名如何映射到多上游并做权重路由API Key 校验和限流如何在请求入口统一生效Token 用量和成本如何记录到数据库。理解这三条链路之后你会发现 AI Gateway 的复杂度并不在于某个单一技术而在于如何把路由、防护、计费组合成一个整体同时保持各层可扩展。下一步可以继续深入的方向包括接入流式响应SSE并完成流式场景的 Token 计量引入 Redis 实现分布式限流增加多租户配额和预算告警接入统一的内容安全服务以及把网关接入公司的统一认证体系。给实际项目的提醒是不要一开始就追求把所有能力都做完。建议先从最基础的路由加 API Key 管理开始跑通一条链路确认业务方愿意通过网关调用模型再逐步补充限流、计费、内容安全等能力。AI 网关建设的难点不是写代码而是定义清楚哪些能力放在网关层、哪些能力留在业务层以及如何用最小成本让业务方接受这层中间件。