最近折腾 AI 编程工具，一个很现实的问题是：API 和套餐越买越多，管理起来越来越烦。
一开始可能只是充了一个模型 API。
后来为了写代码，又买了几个 Coding Plan；为了跑批量任务，又开了几个 Token Plan；看到某个平台便宜、某个模型效果好，还会顺手再接一个。
结果手里慢慢攒了一堆东西：
- 一堆 base URL；
- 一堆 API Key；
- 一堆模型名；
- 一堆套餐额度；
- 一堆客户端配置。
Cursor 要配一次，脚本要配一次，内部工具也要配一次。某个 Key 快用完了，得去对应平台查；想把某个客户端切到另一个模型，还要重新改 base URL、API Key 和模型名。
这时候真正麻烦的，不是没有模型可用，而是入口太散。
我想要的是一个统一的地方：
把这些模型 API、Coding Plan、Token Plan 都接进去，对外只给我一套 base URL 和 API Key。
最近看到一个开源项目 OctaFuse Gateway，就很适合这个需求。
它不是单纯做一个模型代理，而是把 Provider、模型路由、API Key、用户、预算、用量审计、财务记账和管理后台都放在一起。
个人用，它可以把一堆模型和套餐统一成一套入口。
做 SaaS，它又可以变成产品里的 LLM 服务底座：业务系统只管业务，模型接入、Key 管理、调用审计和计费都交给 Gateway。
一句话概括：
OctaFuse Gateway 想做的不是“多转发几个模型”，而是把 LLM 接入做成一套可管理、可审计、可计费的基础设施。
先说个人场景：一套 base URL 和 API Key 管全部
现在很多 AI 客户端都支持自定义 OpenAI-compatible 接口。
比如你可以填：
Base URL: https://your-gateway.example.com
API Key: sk-xxxx
然后客户端就能像调用 OpenAI 一样调用你自己的网关。
问题是，如果你背后接了很多 Provider，通常要在每个客户端里反复配置：
| 场景 | 常见麻烦 |
|---|---|
| 多个模型供应商 | 每个都要记 base URL、Key、模型名 |
| 多个 Coding Plan | 哪个工具该走哪个额度容易混乱 |
| 多个 Token Plan | 用量分散，不好判断哪里快用完 |
| 多个客户端 | Cursor、Claude Code、脚本、内部工具都要重复配置 |
| 临时换模型 | 客户端配置和业务代码可能都要改 |
OctaFuse Gateway 的体验更像是在中间加一个“总控台”。
你把不同 Provider、不同模型、不同上游 Key 配到 OctaFuse 里，然后对外只暴露统一入口。
之后客户端侧可以尽量保持简单：
统一 Base URL -> OctaFuse Gateway
统一 API Key -> OctaFuse 里的用户 Key
模型名 -> Gateway 里的 route
这样就不用每个客户端都塞一堆供应商 Key。
如果将来想把某个模型 route 从 A Provider 换到 B Provider，也可以优先在 Gateway 后台改路由，而不是到处改客户端配置。
对个人重度 AI 用户来说，这已经很实用了。
买了很多 Coding Plan 和 Token Plan 之后，最烦的不是没有模型可用，而是模型太多、入口太散、账单太碎。
有一个统一网关，至少能把这些东西收回来。
OctaFuse Gateway 是什么？
OctaFuse Gateway 是一个开源 AI 网关项目。
它采用 Proxy + Admin + Core 的结构：
| 模块 | 作用 |
|---|---|
| Proxy | 对外提供 OpenAI / Anthropic / Gemini 兼容推理入口 |
| Admin | 管理后台，以及 /api/admin/* 自动化管理接口 |
| Core | 共享类型、数据库迁移、存储层和跨数据库实现 |
它支持两类部署：
| 部署方式 | 适合场景 |
|---|---|
| Cloudflare Worker + Pages + D1 | 想低运维，喜欢边缘部署 |
| Docker / Node + Postgres 或 MySQL | 想自托管，已有服务器和数据库 |
它当前已经支持的能力包括：
- OpenAI / Anthropic / Gemini 多协议入口；
- Provider、Model、Route、Route Group 管理；
- 用户和 API Key 管理；
- 预算上限和周期重置；
- 请求日志和用户审计；
- 模型用量、供应商用量、用户用量分析；
- Playground 和 Simulator；
- 飞书 / 企业微信错误告警；
- Cloudflare D1、Postgres、MySQL 多种存储。
也就是说，它不是只有一个转发接口，而是带了一套完整的管理面。
这也是我觉得它有意思的地方。
路由：把“模型选择”从客户端里拿出来
如果所有模型配置都写在客户端里，后面会很累。
比如你现在有一个客户端模型名叫：
fast-coder
今天它背后走某个 Coding Plan。
过一段时间，你发现另一个 Provider 的编码模型更便宜，或者某个 Token Plan 额度没用完，就想把 fast-coder 切过去。
如果没有网关，你可能要改客户端、改脚本、改环境变量，甚至改业务代码。
如果用 OctaFuse Gateway，可以把 fast-coder 做成一条 route。
客户端只认这个 route，背后具体走哪个 Provider、哪个上游模型、哪个 API Key，由 Gateway 决定。
这就把“模型选择”从客户端配置里抽了出来。
后续你可以在 Gateway 里做这些事：
- 给不同场景配置不同 route；
- 把便宜模型用于普通任务；
- 把强模型留给复杂任务；
- 按 route group 区分免费、默认、付费或内部使用；
- 上游不可用时做 failover；
- 某个 Provider 价格或质量变化时，调整路由而不是改业务。
对个人用户，这是一个多模型控制台。
对团队或 SaaS 产品，这是一个模型路由层。
Provider Key 池：多套额度终于能统一调度
OctaFuse Gateway v1.4.0 里有一个很关键的能力：Provider API Key 池。
以前一个 Provider 通常只配一条上游 Key。
但真实使用里，很多人手里并不是只有一条 Key：
- 一个 Provider 有多个账号；
- 一个模型平台有多个套餐；
- 某些 Key 对应 Coding Plan；
- 某些 Key 对应 Token Plan；
- 某些 Key 专门给测试环境；
- 某些 Key 只给生产高优先级业务。
如果这些 Key 都散落在不同客户端和脚本里，管理起来会非常痛苦。
OctaFuse 现在可以给同一个 Provider 配多条上游 Key，并给每条 Key 设置：
- label；
- status；
- weight；
- priority。
Proxy 层会按 priority 分批 failover，同一批里按 weighted-random 选择；近期失败的 Key 会进入内存 cooldown，默认 60 秒内跳过。
这就很接近实际运维需求了。
比如你可以把稳定、重要、余额充足的 Key 放高优先级；把备用 Key 放低优先级；把不同套餐通过 weight 做分流；某个 Key 出错后，短时间内先避开。
这比“我在不同工具里手动换 Key”舒服太多。
尤其是当你买了多套 Coding Plan 和 Token Plan 后，最需要的就是这种统一调度能力。
多协议入口：不只服务 OpenAI-compatible 客户端
很多网关只做 OpenAI-compatible。
这很实用，但还不够。
现在不同工具和 SDK 的调用形态并不完全一样。有的按 OpenAI Chat Completions 写，有的按 Anthropic Messages 写，有的要接 Gemini 的 /v1beta/*。
OctaFuse Gateway 当前提供了几类入口：
| 接口 | 对应协议 |
|---|---|
/v1/chat/completions | OpenAI 兼容 |
/v1/messages | Anthropic 兼容 |
/v1beta/* | Gemini 兼容 |
这意味着它不只是后端能接多个 Provider，对前端客户端也尽量提供多种协议入口。
对个人来说，这可以接更多工具。
对 SaaS 产品来说，这可以让不同业务模块按自己熟悉的协议接入，而底层还是统一走 Gateway。
更大的价值：给 SaaS 产品提供 LLM 服务底座
个人统一管理模型，只是第一层价值。
我更看重的是第二层：把它接到 SaaS 产品里。
现在很多 SaaS 都想加 AI 功能：
- AI 写作；
- AI 总结；
- AI 客服；
- AI 报表分析；
- AI 数据查询；
- AI 代码生成；
- AI 文档助手；
- AI 自动化工作流。
一开始，你可能会直接在业务服务里调用模型 API。
但很快就会遇到一堆和业务无关、但又绕不开的问题：
| 问题 | 业务系统自己做会怎样 |
|---|---|
| Gateway Key | 要自己设计创建、吊销、权限和归属 |
| 用量统计 | 要自己记录 token、模型、成本、用户 |
| 预算限制 | 要自己做额度、周期重置和超额拦截 |
| 审计追踪 | 要自己查每次调用是谁发起、走了哪里 |
| 财务记账 | 要自己区分成本价、目录价、用户收费价 |
| 模型切换 | 要自己改配置、迁移、灰度 |
| 上游故障 | 要自己做 fallback、告警和排查 |
这些东西都不是你的 SaaS 核心业务。
但如果不做，AI 功能很难真正商业化。
OctaFuse Gateway 的思路就是把这些能力沉到 Gateway。
业务系统只需要关注：
用户在产品里要完成什么任务？
该调用哪个业务能力？
结果如何展示给用户？
至于：
走哪个模型？
用哪个 Provider？
谁的 API Key？
有没有超预算？
这次调用花了多少钱？
日志怎么审计？
账单怎么归集？
这些交给 Gateway。
这才是它和普通模型代理最大的区别。
普通代理解决的是“怎么把请求转出去”。
OctaFuse 更像是在解决“怎么把 LLM 能力作为 SaaS 产品的一部分经营起来”。
用户、Key、审计和记账：SaaS 最需要的四件事
如果你做的是 SaaS 产品，光有一个模型转发接口不够。
你迟早需要四件事。
第一，用户管理。
不同用户、团队、租户要能区分。谁创建了 Key，谁在调用，谁消耗了额度，都要能对上。
第二，Key 管理。
业务侧调用不能直接暴露上游 Provider Key。更合理的方式，是给租户、服务端模块或内部业务发自己的 Gateway Key，然后由 Gateway 负责转发、记录和控制权限。
第三，审计。
出了问题要能追踪：哪位用户、哪个 Key、哪个 route、哪个 Provider、哪个上游 Key、什么时间、调用了什么模型、结果是否成功。
第四，财务记账。
SaaS 最后一定要算账。
上游模型成本是多少，平台给用户展示的标准成本是多少，最终向用户收取的费用是多少，这三件事可能不是同一个数字。
OctaFuse Gateway 里把成本拆成三层：
| 成本口径 | 含义 |
|---|---|
| metered_cost | 实际计量成本 |
| standard_cost | 标准目录成本 |
| charged_cost | 对用户或业务侧收取的成本 |
这个设计对 SaaS 很有用。
因为你可以把“上游采购成本”和“产品商业定价”分开处理。
比如某个模型实际很便宜，但你在产品里把它打包成高级能力；或者某些内部用户按成本价走，外部客户按目录价走；再或者给某些套餐赠送额度，超过后再按 charged_cost 计费。
如果这些逻辑都散在业务系统里，后面会越来越乱。
把它们集中在 Gateway 层，业务系统会轻很多。
Admin 后台：不只是工程师能用
OctaFuse Gateway 自带 Admin 应用。
这点对 SaaS 场景很重要。
因为 LLM 服务上线以后，盯着它的不只有工程师。
产品经理想看某个功能用量；运营想看用户消耗；财务想看成本；平台管理员想看 Key 和路由；工程师想查失败日志。
如果所有东西都藏在数据库和日志文件里，协作会很痛苦。
根据项目 README 和 changelog，目前 Admin 里已经有：
- Provider 管理；
- Model 管理；
- Route 管理；
- 用户和 API Key 管理；
- 请求日志；
- 用量分析；
- 可靠性摘要；
- Playground；
- Simulator；
- 飞书 / 企业微信错误告警配置。
Playground 可以测试某条模型路由是否连通。
Simulator 可以带着真实用户 API Key，从浏览器模拟 OpenAI / Anthropic / Gemini 形态的调用，检查鉴权、路由、计费和日志是否正常。
这类功能看起来很“后台”，但做 SaaS 的人应该懂：真正上线后，最耗时间的往往不是写第一版 AI 功能，而是排查“为什么这个客户调用失败了”“为什么这笔账对不上”“为什么某个 Key 突然消耗很高”。
有一个可视化管理台，会省很多沟通成本。
一个理想的 SaaS 接入方式
如果把 OctaFuse Gateway 放进 SaaS 架构里，我会倾向于这样分工：
SaaS 业务系统
负责用户体验、业务权限、业务数据、AI 功能流程
OctaFuse Gateway
负责模型 Provider、route、用户 Key、用量、审计、计费口径
上游模型 / Coding Plan / Token Plan
负责真正的模型推理能力
这样业务系统不需要直接感知所有模型供应商。
它只需要通过 Admin API 或内部集成，把用户、租户、Key、套餐、额度等信息和 Gateway 对齐。
用户在 SaaS 里购买一个 AI 套餐，业务系统可以调用 Gateway 的管理 API 创建用户或租户记录、分配 Gateway Key、设置预算。用户使用 AI 功能时，业务服务端再带着对应 Key 调用 Gateway，由 Gateway 记录用量、扣减额度、留下审计日志。
后续要调整模型、切换 Provider、增加备用 Key、修改计费口径，都优先在 Gateway 处理。
这套分工的好处是：
SaaS 业务继续专注产品，LLM 的接入、路由、成本和审计交给专门的基础设施。
这比在每个业务服务里重复写一套 LLM 管理逻辑要舒服很多。
怎么快速跑起来？
如果只是本地体验，项目提供了 Docker quickstart。
前提是 Docker Compose 版本支持 service_completed_successfully。
docker compose -f docker/compose/quickstart.yml up --build
curl -sS http://localhost:8787/health
健康后，默认地址是：
| 服务 | 地址 |
|---|---|
| Proxy | http://localhost:8787 |
| Admin | http://localhost:8789 |
Admin 默认登录是：
admin / changeme
进入 Admin 后，大致流程是：
配置 Provider -> 配置 Model Route -> 创建用户 API Key -> 调用推理接口
配置好 route 和用户 Key 后，就可以像调用 OpenAI 一样请求：
curl -sS http://localhost:8787/v1/chat/completions \
-H "Authorization: Bearer sk-..." \
-H "Content-Type: application/json" \
-d '{"model":"your-route-model","messages":[{"role":"user","content":"Hello"}]}'
如果走 Cloudflare 本地 D1，则是：
npm install
npm run db:migrate
npm run dev:proxy
另开终端：
npm run dev:admin
Proxy 默认在 127.0.0.1:8787，Admin 默认在 127.0.0.1:8789。
使用前要注意什么？
我觉得 OctaFuse Gateway 很值得关注，但有几件事要提前知道。
第一，它是基础设施，不是免配置工具。
你需要理解 Provider、Model、Route、Key、预算、数据库迁移这些概念。个人折腾没问题，生产环境要认真规划。
第二，默认账号和密钥一定要改。
本地 quickstart 里的默认 Admin 登录是 admin / changeme，开发种子里也会有默认 MASTER_KEY。任何共享环境和生产环境都必须轮换。
适合谁？
我觉得它特别适合这几类人：
| 场景 | 为什么适合 |
|---|---|
| 买了很多 Coding Plan / Token Plan 的个人用户 | 可以统一 base URL、Key、route 和用量入口 |
| 经常切换模型的开发者 | 可以在 Gateway 里调整 route，减少客户端重复配置 |
| 内部 AI 平台 | 可以统一管理 Provider、Key、预算、审计和告警 |
| 正在做 AI SaaS 的团队 | 可以把 LLM 接入、计费、审计从业务系统里拆出来 |
| 多租户产品 | 用户、Key、预算和调用日志天然需要集中管理 |
| 只调用一个模型的小脚本 | 可能没必要，上来就部署网关会显得重 |
如果你只是偶尔调一下 API，直接写在脚本里就够了。
但如果你已经有一堆模型、一堆 Key、一堆客户端，或者准备把 AI 能力做进产品里，OctaFuse Gateway 这种东西就会变得很香。
总结
过去我看 AI 网关，更多会关注它支持多少模型、能不能 OpenAI-compatible。
但现在看，真正重要的是另一件事：
LLM 能力越来越像一项基础设施，而不是某个业务函数里的几行 HTTP 请求。
个人用户买了多套 Coding Plan、Token Plan，需要统一入口和统一调度。
SaaS 产品接入 AI，需要用户管理、Key 管理、预算控制、调用审计和财务记账。
这些能力如果都塞进业务系统，后面一定会变重。
OctaFuse Gateway 的价值就在于，它把这些东西放到 Gateway 层：业务系统只需要关注自己的产品逻辑，LLM 的接入、路由、计费和审计交给它处理。
它不是简单的“模型代理工具”，更像是一个开源的 LLM 服务管理台。
如果你已经开始被各种模型套餐、API Key、客户端配置和用量账单折磨，这个项目值得试一下。