跳转到内容

AI GatewayOctaFuse

统一对接上游 AI 供应商,向你的每一条产品线持续输送模型能力。

OctaFuse 是面向团队与企业的 AI Gateway:在上游 AI 供应商与各条产品线之间架起一层统一的接入基础设施。

  • 上游:无论是公有云大模型、第三方推理服务还是自托管模型——在网关层统一接入与管理;
  • 下游:各产品线按 OpenAI / Anthropic / Gemini 等标准协议调用,无需关心背后路由到哪家供应商。密钥与预算、请求路由与容错、成本计量与审计留痕,均在这一层统一承载,而不是分散在各业务代码里。

适合同时对接 多家 AI 供应商、驱动 多条产品线,并希望把稳定性、成本与合规留痕从业务代码中抽离出来的团队与平台组。

创建 OctaFuse 的初衷,是为了构建一套 可自主掌控、可持续演进 的 AI 网关能力,服务内部不同 SaaS 系统。

在调研过多个开源和商业方案后,我们发现几类共性痛点:

  • provider 选择面偏窄,难以同时覆盖公有云、私有部署与内部模型。
  • 不少产品 只提供 OpenAI 形态入口,团队已在用的 Anthropic、Gemini 等协议往往需要额外适配或二次封装。
  • 计费与审计能力偏固定或不足,难以按路由、用户、成本口径等灵活建模与对账。

OctaFuse 希望通过更高自由度解决上述问题:

  • 支持接入更多不同Provider(包括各种Coding/Token/Agent Plan、本地/内部部署模型),并在同一网关上承载多种客户端常用协议。
  • 支持按业务需要定义路由、计费口径与审计 / 追溯方式,便于多产品线或对内对账。
  • 通过标准管理 API 与业务系统对接,减少耦合。

多协议兼容

/v1/chat/completions(OpenAI)、/v1/messages(Anthropic)、/v1beta/*(Gemini)等推理入口形态。

统一密钥与预算体系

用户 / Key 管理,预算上限与周期重置;客户端可用 GET /v1/me 查询预算等状态。

模型路由治理

Provider / Model / Route 管理;支持 route group 与按优先级的 failover

分层计费与对账

metered_cost / standard_cost / charged_cost 三套成本口径,便于供给侧计量、目录价与实际对用户扣费的对齐。

审计与观测

全局与 按 Key请求日志,以及用户级审计轨迹,便于追溯与问题排查。

Proxy 错误告警

管理台可配置 飞书企业微信 机器人 Webhook;Proxy 转发错误时主动推送,便于发现上游异常、额度/限流压力及上游 API Key 欠费、需充值等信号。

Analytics(用量与可靠性)

管理台按时间范围汇总模型、供应商、用户用量及可靠性概况,便于容量观察、成本感知与上游稳定性对比。

Playground(试调用)

针对单条模型路由发起试请求,确认能否连上供应商与配置是否正确;不占用用户额度,也不产生与真实业务调用相同的计费与用量记录,适合排错与上线前自检。

Simulator(客户端模拟)

浏览器内携带真实用户 API Key,按 OpenAI / Anthropic / Gemini 方式调用已部署网关,联调与验收鉴权、选路、计费、日志是否与线上一致。

多运行时部署

Cloudflare(Worker + Pages + D1)或自托管(Docker / Node + Postgres / MySQL)。选型与命令见站内部署文档。

业务系统解耦

通过 Admin API(/api/admin/* 与上层 SaaS 对接,让业务更专注 AI 应用本身。

可按 合规、延迟、运维习惯与数据落点 在下述形态中取舍;逐步命令与排障见 文档首页 部署相关章节。

  • 本地 / 内网 Docker:快速跑通、PoC、内网联调。
  • Cloudflare 托管:边缘就近、托管 D1 元数据与配置。
  • 自有基础设施:数据驻留、网络边界或与现有 Postgres / MySQL 运维体系对齐。

更多选型说明见 文档首页 中的线上部署章节,上手步骤见 快速开始。开源协议为 GNU AGPL v3,许可全文见 LICENSE

  • 多产品线、多租户或平台型产品,希望 统一治理模型调用 的团队。
  • 需要把 成本、稳定性、合规留痕 从业务代码里抽离出来,交给专门一层基础设施的工程与平台组。
  • 希望在 供应商与模型演进 上保持主动权,而不是被分散集成绑死的组织。