AI API Hub

API Gateway · Billing · Payments · Admin

Self-Hosted AI Gateway

把模型接入、计费、支付、运营后台放进一条可落地的主线。

AI API Hub 面向想自建 OpenAI API 中转与计费平台的团队。它不是一个只会展示设计稿的落地页，而是一套已经整理出主线的 Python 微服务方案，适合快速上线 API 服务、充值通道和运营后台。

查看部署方式查看模型入口

公开域名应只承载官网或开发者入口。后台控制台建议使用 `console.xxx.com`、Zero Trust 或内网访问。

4 主线 API 服务：Gateway / Billing / Payments / Admin

3 常驻 Worker：健康检查、余额预警、欢迎邮件

/v1 兼容主模型调用入口，支持计费和 GET 熔断保护

Cloudflare 前台可托管到 Pages，后端继续部署在自有服务器

核心能力

这套仓库当前强调“能部署、能计费、能巡检、能运营”，而不是只停留在单接口转发。

Gateway

统一模型代理入口

统一承接 `/v1/*`，代理到上游 New-API，同时提供限流、API Key 规则、GET 自动重试和 Redis 持久化熔断。

Billing

计费与余额视图

统一管理余额、用量、充值流水和用户汇总接口，适合开发者中心或 SaaS 控制台直接消费。

Payments

支付通道拆分

支付聚合入口和 Webhook 解耦，Stripe / USDT 能独立演进，部署和测试都更清晰。

Admin

运营后台 API

提供用户管理、余额调整、注册码、财务概览和 `/admin/dashboard` 聚合视图，但建议仅在受控域名或内网开放。

Runtime

统一运行时目录

`runtime/` 承接支付记录、状态页和 worker 状态，减少各服务把状态文件散落在源码目录里的问题。

Ops

就绪与巡检

主线服务都有 `/ready`，并补了 `metrics`、熔断状态、部署巡检和 native 部署兜底脚本，适合小团队快速接管。

部署落点

现在仓库里的静态前端已经拆成两类：公开落地页和后台控制台，不应再混用。

Cloudflare Pages

适合承载公开官网或开发者入口。推荐把 `apps/marketing-site` 作为输出目录。

Framework preset: `None`
Build command: 留空
Build output directory: `apps/marketing-site`
域名建议：`www.xxx.com` 或 `app.xxx.com`

apps/marketing-site ├─ index.html ├─ _headers └─ _redirects

控制台与 API

控制台不是公开前台。它应该挂在独立域名或内网，并且与 API 域名配合使用。

控制台静态页目录：`apps/console-site`
后端控制台入口：`/console`
API 域名建议：`api.xxx.com`
控制台域名建议：`console.xxx.com`

Public: https://www.xxx.com Private or Restricted: https://console.xxx.com API: https://api.xxx.com

FAQ

几个最容易部署错位的点，这里直接说明白。

为什么后台不能直接部署成公开首页？

因为它包含用户管理、财务概览、注册码操作、充值巡检和运维诊断能力。即使接口本身有鉴权，把这类页面直接暴露在公开前台域名也会放大扫描和误配风险。

Cloudflare Pages 应该放哪个目录？

公开前台放 `apps/marketing-site`。如果你要公开访问控制台，也应使用单独的 `apps/console-site` 和单独域名，而不是继续复用营销站目录。

控制台还能继续用原来的单文件页吗？

可以。现有控制台已经被保留到 `apps/console-site`，并继续由后端 `/console` 提供。只是它不再承担公开前台的职责。

仓库目录

apps/
├─ gateway-api
├─ billing-api
├─ payments-api
├─ admin-api
├─ marketing-site
└─ console-site

控制台目录已和公开前台分离，后续 Pages 项目请明确选对输出目录。