【MAI Gateway】企业级 AI 网关到底在管什么？拆解魔芋企业AI网关的四层架构

当我们在说AI 网关的时候到底在说什么本文从架构设计的角度拆解一次大模型调用背后的完整链路。前言最近在技术社区看到不少关于AI 网关的讨论。有人觉得它就是个 API 转发代理有人觉得它是套了壳的 NewAPI。说实话我一开始也是这么想的。直到认真研究了几款企业级 AI 网关产品的架构设计才发现事情没那么简单。一个真正的企业级 AI 网关远不止转发请求这么简单——它要处理协议适配、路由调度、身份鉴权、配额管控、安全过滤、成本核算、日志审计……每一个环节都有设计上的考量。这篇文章我以魔芋 MAI Gateway 为例拆解它的四层架构设计。它的架构文档比较完整适合做分析样本。文中的架构思路对于理解同类产品同样适用。MaiGateway-企业级大模型API网关|多模型统一调度与AI流量治理平台MaiGateway企业级LLM API网关统一兼容国内外大模型提供智能路由、密钥管控、限流熔断、Token计费、数据脱敏、全链路审计私有化部署解决企业多模型接入混乱、成本失控、数据安全合规难题。https://mai.moyu.cn一、先说清楚AI 网关不是什么在拆架构之前先排除几个常见误解误解 1AI 网关 API 代理API 代理只做请求转发不关心请求内容。AI 网关需要理解请求的结构模型、Token、消息体并根据内容做路由决策、成本计算和安全检查。误解 2AI 网关 聚合网关市面上有不少开源聚合网关如 NewAPI、OneAPI它们的核心能力是把多个模型供应商的接口聚合到一个入口。这在个人开发者场景下够用但企业场景还需要组织架构同步、项目隔离、预算管控、安全合规等能力这些聚合网关基本不具备。误解 3AI 网关 MLOps 平台MLOps 平台管的是模型训练、部署、版本管理和推理调度。AI 网关不管模型训练它管的是模型已经部署好之后企业内部如何安全、可控、可核算地调用这些模型。搞清楚边界后我们来看架构。二、四层架构总览MAI Gateway 的架构从上到下分为四层┌─────────────────────────────────────────────┐│ 应用层 (Application) ││ 智能体 / AI编程 / 知识库 / 客服 / 内容生成 │├─────────────────────────────────────────────┤│ 分发与管理层 (Management) ││ 组织 / 角色 / 项目 / 令牌 / 配额 / 预算 │├─────────────────────────────────────────────┤│ 智能调度层 (Scheduling) ││ 协议转换 / 路由选择 / 负载分配 / 限流 / 缓存 │├─────────────────────────────────────────────┤│ 模型与算力接入层 (Integration) ││ 公共API / 私有模型 / 云端算力 / 本地GPU │└─────────────────────────────────────────────┘三、应用层统一的调用入口应用层是离业务最近的。包括智能体平台、AI 编程工具、知识库与 RAG 系统、智能客服、办公助手、内容生成工具等。这些应用通过统一接口向网关发请求携带包括受控令牌和模型标识等重要信息。设计要点接口兼容性MAI Gateway 对外暴露的接口兼容 OpenAI 协议。这是一个很务实的选择——市面上绝大多数 AI 应用和 SDK 都支持 OpenAI 接口规范兼容它意味着应用侧的改造成本极低通常只需要替换 Base URL 和 API Key。但这里有个细节值得注意兼容 OpenAI 协议不等于只支持 OpenAI 协议。对于供应商专有参数如某些多模态接口、文件上传接口网关需要做协议适配和参数映射。四、分发与管理层治理的核心这一层是我认为企业级 AI 网关和普通聚合网关差距最大的地方。它管的是谁能用什么模型、花多少钱、归到哪个项目。4.1 组织与角色MAI Gateway 支持与钉钉、飞书、企业微信、AD 等组织目录对接同步部门和人员信息。这意味着不需要在网关里手动建组织架构企业已有的组织体系可以直接复用。角色体系分为多级超级管理员├── 部门/项目管理员│ ├── 运维人员│ ├── 财务审计人员│ ├── 安全人员│ └── 普通用户每个角色的权限边界清晰超级管理员平台初始化、全局策略配置部门/项目管理员成员管理、模型范围分配、预算设定运维人员链路监控、告警处理、容量查看财务审计人员账单查看、费用归集、日志审计普通用户在授权范围内使用模型、创建个人令牌设计要点项目作为管理单元这里有个设计思路值得说说。MAI Gateway 把项目作为连接业务和资源的核心单元。一个项目可以绑定负责人、成员、可用模型、令牌、配额、预算和报表。这样做的好处是所有模型调用都能归属到具体的业务场景。不再是某个人用了某个模型而是某个项目的某个业务场景用了某个模型花了多少钱。这对于成本归因非常重要。4.2 令牌全生命周期管理令牌是企业应用访问网关的凭证。MAI Gateway 对令牌的管理覆盖了完整生命周期创建 → 绑定关联责任人/部门/项目→ 授权设置模型范围、有效期、IP白名单→ 使用 → 轮换 → 撤销/失效几个关键设计令牌与供应商 Key 解耦应用侧拿到的是网关令牌不是供应商的 API Key。供应商 Key 只在网关后台保管应用侧永远接触不到。可设置有效期和模型范围某个令牌只能调用指定模型过期自动失效。支持 IP 黑白名单即使令牌泄露非授信 IP 也无法调用。强制轮换定期轮换缩短密钥泄露的风险窗口。操作记录入审计日志令牌的创建、变更、撤销全过程可追溯。这个设计解决了一个实际问题以前 API Key 散落在代码和配置里人员离职或项目结束后 Key 还在用没人管。现在令牌绑定了责任人和项目人员离职时直接撤销相关令牌就行。4.3 配额与流量控制配额可以按企业、组织、部门、项目、用户、令牌或模型设置周期可按日/周/月计算控制指标包括金额、Token 数量、请求频率RPM和并发数。配额层级企业总额 → 部门配额 → 项目配额 → 用户/令牌配额 → 模型配额接近阈值时触发告警超限后按规则执行限速、阻断或模型降级。设计要点针对智能体的流控自动化智能体是 Token 消耗的重灾区。一个有 Bug 的 Agent 可能陷入循环调用短时间内消耗大量 Token。MAI Gateway 支持为智能体单独配置 RPM、TPM 和最大费用一旦触发熔断毫秒级切断调用。这个能力在实际使用中非常关键。没有它一个 Agent 的 Bug 可能在一夜之间烧掉几万块的 Token 费用。五、智能调度层这一层处理协议转换、路由选择、负载分配、限流、缓存和故障切换。5.1 路由策略MAI Gateway 支持多种路由模式路由模式说明适用场景权重路由按预设权重分配流量到不同供应商日常负载均衡主备路由主链路异常时切换备用服务高可用保障成本路由将符合条件的请求分配给费用较低的模型成本优化智能路由根据请求复杂度匹配模型阶梯式成本优化智能路由是最有意思的一个。它的思路是不是所有请求都需要最贵的模型。简单的 FAQ 问答用低成本模型就够了复杂推理才需要高端模型。网关根据请求内容判断复杂度自动路由到合适的模型。5.2 故障转移网关定期检查各模型链路的健康状态。检测指标包括延迟、错误率和可用性健康检查流程定期探测 → 连续报错? → 临时下线该链路 → 流量切到备用链路↓原链路恢复? → 重新加入路由关键设计点故障切换对应用侧透明。应用侧看到的是一个稳定的接口地址底层切了哪个供应商它不需要知道。5.3 缓存与上下文优化网关支持语义缓存——对于重复或高度相似的请求直接从缓存返回结果不再调用上游模型。这能显著减少 Token 消耗。上下文压缩也是一个降本手段。对于长上下文请求在不影响语义的前提下压缩 prompt减少输入 Token 数。注意缓存和上下文压缩都有适用边界。对实时性要求高、上下文经常变化的场景缓存可能不适用。上下文压缩可能在极端情况下影响模型理解。是否启用需要结合业务场景判断。六、模型与算力接入层连接一切最底层负责连接各种模型来源公共大模型 APIOpenAI、Anthropic、通义千问、MiniMax 等企业私有模型自建的 DeepSeek、Qwen 等云端算力云上的 GPU 推理服务本地 GPU企业自有的 GPU 服务器网关为每个模型记录供应商、模型名称、接口协议、计费单价、启用状态和可用范围。这些数据是路由决策、费用核算和权限判断的基础。设计要点混合部署的路由在混合部署场景下普通任务可以调用公共模型按 Token 计费涉及敏感数据的任务路由到本地私有模型固定算力成本。路由条件由企业根据数据类型、模型效果、成本和可用性设置。这种设计让企业在用公共模型省事和用本地模型保安全之间找到平衡点。七、一次请求的完整链路把四层串起来一次模型调用的完整链路是这样的1. 应用发送请求携带网关令牌↓2. 【分发与管理层】身份校验 → 令牌是否有效模型是否在授权范围↓3. 【分发与管理层】配额检查 → 预算是否超限是否触发限流↓4. 【智能调度层】安全处理 → 提示词注入检测PII 脱敏内容过滤↓5. 【智能调度层】路由选择 → 根据策略选择上游链路权重/成本/智能↓6. 【模型接入层】上游请求 → 协议转换调用真实模型供应商↓7. 【智能调度层】结果处理 → 响应内容检测缓存写入↓8. 【分发与管理层】费用记录 → 计算 Token 消耗和费用归属到项目↓9. 【分发与管理层】日志留存 → 记录请求链路、响应状态、耗时等↓10. 返回结果给应用注意步骤 4 的安全处理——这是在请求到达模型供应商之前执行的。也就是说敏感信息在离开企业内网之前就已经被脱敏了。这个位置很重要如果放在模型返回之后再处理数据已经出去了。八、与通用聚合网关的对比最后聊聊大家都关心的问题企业级 AI 网关和开源聚合网关到底差在哪维度通用聚合网关企业级 AI 网关MAI Gateway核心定位渠道接入、模型转发、运营计费企业内部治理组织架构基本不支持同步飞书/钉钉/企微/AD权限模型简单的用户级权限多层级角色 项目隔离成本管理总量统计预算 分账 归因 审计安全防护基本没有PII 脱敏 注入拦截 内容过滤令牌管理简单的 Key 分发全生命周期 轮换 IP 控制高可用基本转发健康检查 故障转移 熔断GPU 管理不支持资产可视 负载监控合规审计基本日志全链路日志 操作审计 等保简单说聚合网关解决的是能不能用的问题企业级网关解决的是用得好不好、管得住管不住、花得清不清楚的问题。如果你的场景是个人开发或小团队内部使用聚合网关够用。如果是企业级场景涉及多部门、多项目、预算管控和安全合规那企业级网关的这些能力就不是锦上添花而是必需品。九、写在最后拆完整个架构我最大的感受是企业级 AI 网关的本质不是技术问题而是治理问题。转发请求不难难的是在转发的过程中把身份、权限、成本、安全、审计这些治理逻辑编织进去而且不能影响性能和可用性。MAI Gateway 的四层架构设计本质上是在回答一个问题当大模型成为企业的基础设施后如何让它的使用像用水用电一样安全、可控、可计量。这个问题不会只有一种答案但理解现有的架构设计思路有助于我们在选型和使用时做出更明智的判断。