公司内部统一模型入口
所有业务应用都接入企业自己的 NeoGate 地址，不再让每个团队分别配置不同供应商。
企业自用场景
当多个团队开始共用大模型能力，先把访问入口和成本边界管起来。
NeoGate 关注的是企业内部落地大模型时最先遇到的运营问题：谁能调用、 用哪个上游、用了多少、成本归到哪个项目，以及上游异常时如何少影响业务。
给项目和团队发独立 Key
按部门、业务项目、内部服务或自动化任务发放 API Key，权限、额度和用量互相隔离。
集中托管上游凭证
上游供应商 Key 不再散落在业务系统里，管理员在后台统一管理 OpenAI、Anthropic 和兼容通道。
按项目看用量和成本
记录用户、项目、API Key、模型、供应商和通道维度的调用，方便排查问题和做内部核算。
先服务内部管理
内部模式下默认不要求用户余额，但仍记录用量和费用，适合成本分析、预算评估和内部归集。
上游异常时自动切换
上游 Key 失败后自动冷却，并尽量切换到可用凭证，减少单个密钥或通道异常对业务的影响。
企业调用路径
业务应用调用项目 Key，NeoGate 负责鉴权、路由和记录。
内部应用使用项目 API Key 调用 NeoGate。网关完成项目鉴权、服务模式策略、 上游通道和凭证选择，再把响应转回应用，同时沉淀用量记录用于排障、成本分析和内部核算。
1内部应用使用项目 API Key 发起请求
2NeoGate 检查项目策略和服务模式
3网关选择供应商通道和上游凭证
4转发响应，并记录项目维度用量
部署路径
先用单节点落地，真正需要多副本时再切集群。
git clone https://github.com/neogate-io/NeoGate.git
cd NeoGate
docker compose up -d --build
大多数团队起步时使用单节点部署就够了：前端 Nginx、后端和 PostgreSQL 一起启动， 配置简单、排障成本低。等明确需要横向扩展时，再切换到共享 PostgreSQL 和 Redis 的集群部署。