最近两年，开发者可以使用的 AI 模型越来越多。

OpenAI、Claude、Gemini，以及国内外不同平台提供的模型，各有擅长的领域。与此同时，我们手里的模型账号、API Key 和接口地址也越来越多。

刚开始时，这似乎不是一个大问题：在项目里增加一个环境变量，再封装一层调用代码就可以了。

但随着项目、模型和使用者不断增加，问题很快就会出现：

– 不同应用配置着不同的 API 地址和 Key；

– 更换模型供应商时，需要逐个修改客户端；

– 团队成员共用 Key，很难区分各自的用量；

– 不同平台的价格和账单口径不一致；

– 接口出现故障时，需要到多个控制台分别排查；

– 某个供应商不可用时，业务无法快速切换到备用通道。

于是我开始思考：能不能在应用和模型供应商之间增加一个统一入口，把这些重复工作聚焦起来处理？

基于这个想法，我开发并开源了 Octafuse Gateway。

Octafuse Gateway 是什么？

Octafuse Gateway 是一个可以自托管的开源 AI Gateway。

它位于客户端与模型供应商之间，把分散在不同平台、账号和 API Key 后面的模型能力，统一成：

– 一个 Base URL；

– 一个 API Key；

– 一套模型路由；

– 一套用量、成本和日志管理后台。

接入 Gateway 后，应用不再需要直接保存每一家模型供应商的配置。

无论后面连接的是 OpenAI、Anthropic、Gemini、本地模型还是其他兼容服务，客户端面对的始终是同一个入口。

后来增加、替换或临时切换供应商时，只需要调整网关中的配置，不必逐个修改已经上线的应用。

把模型选择从业务代码里移出来

在不少 AI 项目中，模型名称、接口地址和供应商选择直接写在业务代码里。

这种方式在项目早期比较简单，但模型一多，维护成本就会迅速上升。

Octafuse Gateway 将 Provider、Model 和 Route 独立出来，通过管理后台统一配置。同一个模型 ID 可以根据路由组、优先级、权重和可用性，被转发到不同的上游服务。

例如，业务系统始终请求同一个模型名称，网关背后可以配置：

– 默认使用主要供应商；

– 主要供应商不可用时切换到备用通道；

– 按照权重向多个供应商分配流量；

– 小范围测试新的模型或接口；

– 在价格或额度发生变化时快速调整路由。

这样一来，模型供应商发生变化时，业务代码不需要跟着频繁修改。

为不同用户和项目分配独立 API Key

如果只是个人使用，共享一个 API Key 或许还能接受。

但当模型能力需要提供给团队成员、不同项目或者外部客户时，共用 Key 很快就会带来权限和成本管理问题。

Octafuse Gateway 可以为每个用户、项目或客户创建独立 API Key，并分别设置：

– 使用预算；

– 启用或停用状态；

– 额度重置周期；

– 独立的调用记录。

客户端还可以通过接口查询自己的身份和剩余额度。

这样既可以复用团队已有的模型资源，也能够清楚地知道谁在使用、使用了多少，以及成本最终产生在哪里。

统一记录用量、成本和运行状态

接入多个模型平台之后，另一个明显的问题是观测数据分散。

某次请求为什么失败？

哪个模型延迟比较高？

某个成员用了多少 Token？

这个月哪个 Provider 的成本最高？

如果每次都要登录不同平台的控制台查询，排查效率会超级低。

Octafuse Gateway 会聚焦记录请求日志、错误、延迟、Token 用量、模型用量、Provider 用量、用户用量和可靠性指标，并通过管理后台统一展示。

在成本方面，它会分别记录：

– 上游实际产生的成本；

– 根据统一价格计算的标准成本；

– 最终向用户扣除的金额。

这三套数据可以协助团队区分采购成本、内部核算价格和最终计费金额，也方便后续接入自己的 Billing、对账或风控系统。

不只是一个反向代理

AI Gateway 最基础的能力是转发请求，但 Octafuse Gateway 想解决的不只是“把请求代理到另一个地址”。

目前项目还提供了：

– Provider 与模型管理；

– 模型路由和故障切换；

– 用户与 API Key 管理；

– 预算及周期重置；

– 请求日志与成本统计；

– 管理后台；

– Admin API；

– Playground 路由测试；

– 浏览器端调用模拟器。

其中，Admin UI 适合日常人工配置；Admin API 则可以接入现有的 SaaS 后台、企业门户或自动化脚本，用于创建用户、发放 Key、同步预算和读取配置。

哪些人可能需要它？

Octafuse Gateway 主要面向以下几类使用场景。

1. 个人开发者

如果你同时使用多个 AI 或 Coding 服务，可以通过一个 Gateway 地址接入 IDE 插件、命令行工具和其他 AI 应用。

后来更换上游时，不必重新修改所有工具的配置。

2.独立开发者和小团队

可以为不同项目或成员分配独立 Key，通过预算和日志区分使用情况，统一管理团队的 Token 成本。

3. AI 应用和 SaaS 产品

可以把 Gateway 接入自己的用户系统，为客户自动开通 API Key、分配额度，并利用统一的成本数据完成计费和对账。

4. 有多供应商容灾需求的团队

可以为同一个模型入口配置多个上游。当某个供应商不可用、额度不足或者价格发生变化时，通过调整路由快速切换。

支持自托管和多种部署方式

Octafuse Gateway 是一个自托管项目，模型请求、API Key、日志和成本数据都可以保存在自己的环境中。

目前支持的主要部署方式包括：

– Docker Compose；

– Cloudflare Workers 与 D1；

– PostgreSQL；

– MySQL。

如果只是想在本地体验，推荐使用 Docker Compose 快速启动；如果希望运行在边缘环境中，可以选择 Cloudflare Workers；需要传统服务器部署时，则可以使用 Node.js 配合 PostgreSQL 或 MySQL。

为什么选择开源？

AI 基础设施往往处在应用和模型供应商之间，会接触 API Key、请求日志和成本数据。

对于这类组件，我认为可审计、可修改和可自托管超级重大。因此，Octafuse Gateway 已经在 GitHub 开源。你可以查看源码、自行部署，也可以根据自己的业务需求进行扩展。

目前项目仍在持续迭代。如果你正在开发 AI 应用，或者也遇到了多模型接入、Key 管理、成本统计和供应商切换的问题，欢迎体验并提出提议。

项目名称：Octafuse Gateway

GitHub：https://github.com/OctaFuse/octafuse-gateway

官网：https://octafuse.dev/zh/

如果这个项目对你有协助，也欢迎在 GitHub 点一个 Star，或者通过 Issue 告知我你希望它接下来支持哪些能力。