技术知识库 · 工具评测 · · 国科智飞 Gavin
TokenHub：企业私有 AI 网关该管什么
astaxie/TokenHub 把模型接入、路由、鉴权、配额、审计与成本归因收进一个可私有部署的网关，按企业三层治理角色设计，Apache-2.0。
TokenHub 是谢孟军（astaxie，Go 社区 beego 框架作者）开源的私有 AI 网关，Apache-2.0 许可，后端用 Go 编写。定位一句话：统一各家模型 API 的接入、路由、鉴权、配额、审计与成本归因，让每一个模型请求可控、可追踪、可归因。项目 2026 年 6 月创建，8 月已积累约 850 star / 105 fork，提交活跃。
企业模型变多之后，"统一入口 + 管控 + 账单归因"会从可选项变成刚需——这正是 TokenHub 瞄准的位置。它和"在代码里包一层 SDK"的区别在于：网关是独立部署的基础设施，Key、配额、路由规则和日志都在服务端，换模型、加供应商、调限额不用改业务代码，也不会因为某个客户端的实现方式而绕开管控。
能力与亮点
双协议兼容。 OpenAI 兼容侧有 /v1/chat/completions、/v1/responses、/v1/embeddings；Anthropic 侧有 /v1/messages 与 /v1/messages/count_tokens；还有图像生成 /v1/images/generations 和参考图编辑 /v1/images/edits（异步任务）。下游 Agent 框架接进来基本不用改代码。
150+ Provider 模板。 覆盖 OpenAI、Azure OpenAI、Anthropic、Gemini、DeepSeek、Qwen、Moonshot、Z.AI、MiniMax、豆包、硅基流动、ModelScope、OpenRouter、Groq、Together、Fireworks、Mistral、Cohere、Perplexity、HuggingFace、NVIDIA NIM、vLLM、Ollama、LM Studio、Bedrock、Vertex、Grok 等，原生适配器加 OpenAI 兼容兜底。对国产模型生态的适配是它与海外网关的差异点之一。
路由与模型目录。 支持优先级、权重、故障转移顺序，以及路由健康诊断——某家 API 挂了能自动切走，而不是等业务方报障。
三角色治理模型。 User 负责找模型、建 Key、调 API、看个人用量；Team Leader 负责项目空间、成员、Key、团队报表与成本归因；Administrator 负责 Provider、模型目录、路由、身份源、RBAC、审计与成本控制。这不是给开发者自嗨的网关，而是按企业三层决策链设计的。
项目级 Key 与配额。 Key 有团队归属、成员权限、配额和并发控制，而不是一人一个万能 Key。
用量与成本归因。 请求日志按用户、项目、团队、模型、成本中心多维度归因，能回答"钱花在哪、哪个团队在烧模型"。技术团队看路由和配额，管理层看账单和审计——把这两套语言放进同一个控制台，是它比纯技术网关更容易在企业里通过预算审批的原因。
部署和运维路径清晰。 SQLite-first：默认单机 SQLite，systemd 安装脚本 + Docker Compose 一键起；数据规模上来后切 PostgreSQL 多实例，前后端副本横向扩展。安装器校验 Release 校验和，版本面板支持一键更新、回滚、重启。控制台有中英日三语。
订阅容量也能接。 可以把订阅型编程账号接入网关，作为可路由的模型资源使用；官方给了具体接法，比如让订阅容量承接图像生成请求，或让 Gemini CLI 通过网关调用其他家的模型。本质是把固定订阅成本变成网关内可路由的额度，在 2026 年的"订阅经济学"下很实用，但合规风险见下一节。
审计与身份。 OAuth/OIDC 身份源、RBAC 和审计追踪是内建能力，不是插件。对受监管行业来说，"谁在什么时候调了哪个模型、花了多少额度"能出报告，比省下几个 API Key 更有价值。
局限与坑
订阅账号共享的条款风险。 把订阅容量接进网关当 API 用，是否违反上游服务条款，需要自己逐家确认。个人玩可以自担风险，企业采购不要默认"可以"。
SQLite 单机不等于高可用。 单机起步对中小团队极友好，但关键业务要切到 PostgreSQL 多实例模式，并在真实流量下验证故障转移，别把"能跑"当"生产级"。
配置面大，运维有成本。 Provider、路由策略、RBAC、配额、预算这些都要人维护。功能广度的代价就是上手门槛——想要"开箱即用"的小团队需要投入学习时间。
竞品已很成熟。 LiteLLM、One API / new-api、Higress AI Gateway 在社区与文档上都有积累。粗略分工是：LiteLLM 在 Python 生态与海外模型接入上更顺；One API / new-api 轻量、适合个人与小团队；Higress 偏云原生、绑 K8s 生态。TokenHub 的差异化在国产生态适配与企业治理完整度，选型时应针对这两点做验证，而不是只看 Provider 数量。
绕过网关的调用统计不到。 成本归因依赖请求走网关。如果有人直连模型供应商，报表就会失真，这需要管理制度配合，不是技术能单独解决的。
适用场景
- 中大型企业需要统一的模型入口：多团队、多供应商、要配额、要审计；
- Key 与数据不能分散在各人手里的私有化部署环境；
- 需要按部门、项目或成本中心分摊模型账单的组织；
- 以国产模型（DeepSeek、Qwen、豆包、硅基流动等）为主的团队；
- 已有多个 Agent 框架或工具，希望统一模型层、避免每家单独配置。
选型建议
先回答一个问题：你是否真的需要"模型访问治理"这一层。一个人用几个模型，直连或轻量代理就够；多人多团队共享预算与 Key，才值得上网关。
部署建议从 SQLite 单机开始，用一个月真实流量验证路由策略与统计口径，再决定是否升级 PostgreSQL 多实例。上线前把三件事定成规则：订阅账号能否共享、数据合规边界、绕过网关直连的处理办法。仅看协议，Apache-2.0 可商用，私有化交付没有 AGPL 之类的传染性顾虑；但"开源获客 + 企业版/定制/运维"是它明确的商业路径，长期使用要关注企业版的边界划分。
迁移路径也要提前设计：现有系统如果是直连各家的 Key，建议先按团队聚合 Key、给每个项目建独立凭证，再逐步把调用切到网关；统计口径要新旧并行一段时间，避免切换当天报表直接断档。网关这类基础设施的价值随使用规模增长——用的人越多，路由、配额和归因越有意义。