# 企业内部统一Token运营分发平台技术选型方案

## 一、选型背景与目标

### 1.1 业务痛点

集团各事业部独立持有文心、通义、OpenAI、Claude等多厂商大模型API密钥，存在以下治理问题：

| 序号 | 痛点 | 影响程度 |
|------|------|----------|
| 1 | 密钥分散存储，无统一托管与回收机制 | 严重 |
| 2 | 无标准化内部子Token分发，权限/额度无法按部门隔离 | 严重 |
| 3 | 单机工具无法承载万级QPS并发 | 高危 |
| 4 | 无调用日志、用量统计、审计溯源 | 高危 |
| 5 | 开源工具存在停更、适配滞后风险 | 中等 |

### 1.2 硬性约束条件

| 编号 | 约束项 | 说明 |
|------|--------|------|
| H1 | 源码完全开放 | 支持企业私有化深度二次开发 |
| H2 | 核心定位 | Token集中管理、内部子Token分发运营 |
| H3 | 分布式集群扩展 | 具备支撑集团大规模业务的扩展潜力 |
| H4 | 社区可持续维护 | 规避长期无人迭代风险 |

### 1.3 建设目标

1. **统一密钥托管**：全厂商API Key集中收纳、加密存储、分级权限管控
2. **标准化Token分发**：子Token支持配额、时效、IP、模型权限精细化管控
3. **分布式高可用底座**：多实例水平扩容，支撑集团全业务并发调用
4. **全链路流量治理**：负载均衡、故障切换、限流熔断、重试降级
5. **合规可观测体系**：调用日志、操作审计、用量报表、异常告警
6. **可定制扩展**：对接LDAP/SSO、成本核算、审批流等
7. **长期可持续迭代**：依托活跃开源社区，减少重复造轮子

## 二、候选方案横向对比总览

### 2.1 五方案综合能力评分矩阵

| 评估维度（权重） | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|------------------|--------|---------|---------|----------------|------|
| **技术架构合理性(15%)** | ★★★ | ★★★★★ | ★★ | ★★★★ | ★★★★★ |
| **源码与二次开发(15%)** | ★★★★ | ★★★★★ | ★★★ | ★★★ | ★★★★★ |
| **Token运营能力(15%)** | ★★★★★ | ★★★ | ★★★★ | ★★★★ | ★★★★★ |
| **分布式集群能力(15%)** | ★★ | ★★★★★ | ★ | ★★★ | ★★★★★ |
| **社区活跃度(10%)** | ★★★★★ | ★★★★★ | ★★ | ★★ | — |
| **大模型适配(10%)** | ★★★★★ | ★★★★ | ★★★ | ★★★ | ★★★★★ |
| **流量治理(10%)** | ★★★ | ★★★★★ | ★★ | ★★★ | ★★★★★ |
| **可观测与审计(10%)** | ★★★ | ★★★★★ | ★★ | ★★★ | ★★★★★ |
| **综合得分** | **3.8** | **4.7** | **2.4** | **3.1** | **4.9** |

> ⭐ 评分说明：1=严重缺陷，2=不足，3=达标，4=良好，5=优秀

---

## 三、分维度逐项对比详情

### 3.1 技术架构

| 对比项 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|--------|--------|---------|---------|----------------|------|
| **架构模式** | 单体一体化 | 分层解耦云原生 | 单体一体化 | 分层分离架构 | 完全自定义 |
| **网关与后台耦合度** | 高耦合 | 完全解耦 | 高耦合 | 完全解耦 | 按需设计 |
| **状态设计** | 有状态（需改造） | 完全无状态 | 有状态 | 网关无状态 | 按需设计 |
| **配置同步机制** | 依赖Redis改造 | Redis原生支持 | 无 | Redis基础支持 | 按需设计 |
| **K8s原生适配** | 需改造 | 天然适配 | 不支持 | 缺少官方模板 | 按需设计 |
| **架构评分** | ★★★ | ★★★★★ | ★★ | ★★★★ | ★★★★★ |

**分析**：
- **LiteLLM**采用云原生分层解耦架构，网关完全无状态，配置/配额统一托管Redis，天然适配K8s弹性伸缩，架构最成熟。
- **NewAPI**为单体一体化架构，虽可改造为集群部署，但网关与后台共用资源，高并发下管理操作挤占转发资源。
- **LLMProxy-Admin**架构设计合理（网关与后台分离），但工程实现缺少成熟集群方案。

---

### 3.2 开发语言与技术栈

| 对比项 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|--------|--------|---------|---------|----------------|------|
| **后端语言** | Go | Python（异步IO） | Go | Go | Go/Java自由选 |
| **前端框架** | Vue | 无（API Only） | Vue | Vue | Vue/React自由选 |
| **部署方式** | 单文件二进制 | 容器化优先 | 单文件二进制 | 单文件二进制 | 按需选型 |
| **性能特点** | 内存占用低 | 异步高性能 | 内存占用低 | 轻量高效 | 按需设计 |
| **技术评分** | ★★★★ | ★★★ | ★★★★ | ★★★★ | ★★★★★ |

**分析**：
- NewAPI/Sub2API/LLMProxy-Admin均采用Go+Vue组合，编译型语言性能稳定，部署简单。
- LiteLLM采用Python异步IO架构，生态丰富、插件化扩展能力强，但运行环境依赖容器化。
- 自研方案技术栈自由，但需企业自行承担技术选型与基建成本。

---

### 3.3 源码开放性与二次开发

| 对比项 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|--------|--------|---------|---------|----------------|------|
| **开源协议** | MIT | MIT | MIT | MIT | 100%自有 |
| **源码完整度** | 完整开放 | 完整开放 | 完整开放 | 完整开放 | — |
| **代码分层设计** | 中等（耦合较重） | 优秀（插件化） | 较差（高耦合） | 中等（文档少） | 完全可控 |
| **扩展改造成本** | 中等 | 低（插件机制） | 高 | 较高 | 自主可控 |
| **企业定制扩展点** | 渠道/配额/前端 | 全插件接口 | 计费/账单模块 | 需深度读源码 | 无限 |
| **二次开发评分** | ★★★★ | ★★★★★ | ★★★ | ★★★ | ★★★★★ |

**分析**：
- **LiteLLM**插件化架构为最大优势，鉴权、路由、计量、缓存全部标准化接口，自定义逻辑不修改底层核心，上游版本升级冲突风险最低。
- **NewAPI**代码结构清晰、国内开发者熟悉度高，但单体耦合严重，拆分网关需大规模重构。
- **Sub2API**大量代码围绕付费计费逻辑，内部免费场景下冗余模块删减困难。

---

### 3.4 核心Token运营能力（硬性约束H2）

| 功能项 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|--------|--------|---------|---------|----------------|------|
| **原始密钥批量导入/托管** | ✅ 完善 | ✅ API方式 | ✅ 基础 | ✅ 基础 | ✅ 自定义 |
| **子Token创建与配额管理** | ✅ 日/月额度 | ✅ 多维度限制 | ✅ 基础 | ✅ 基础 | ✅ 自定义 |
| **模型黑白名单控制** | ✅ | ✅ | 部分 | 部分 | ✅ |
| **IP白名单/时效管控** | ✅ | ✅ | ✅ | ✅ | ✅ |
| **可视化运营后台** | ✅ 开箱即用 | ❌ 无（需自建） | ✅ 内置 | ✅ 内置 | ✅ 自定义 |
| **租户/部门资源隔离** | ✅ 分组管理 | ✅ 租户隔离 | 粒度粗 | 功能缺失 | ✅ 自定义 |
| **国产多模型分组管理** | ✅ 最完善 | 部分滞后 | 弱 | 基础 | ✅ 自定义 |
| **内置成本分摊/账单** | 基础用量 | ❌ | ✅ 完善 | ❌ | ✅ 自定义 |
| **运营能力评分** | ★★★★★ | ★★★ | ★★★★ | ★★★★ | ★★★★★ |

**关键差异**：
- **NewAPI**开箱即用完整运营后台，是唯一无需前端开发即可完成日常密钥运维的方案。
- **LiteLLM**底层能力完备，但所有操作需通过API调用，可视化运营需全栈二次开发，人力投入最大。
- **Sub2API**内置账单模块适合付费场景，但对内部免费分发场景冗余功能过多。

---

### 3.5 分布式集群扩展能力（硬性约束H3）

| 对比项 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|--------|--------|---------|---------|----------------|------|
| **原生分布式支持** | ❌ 需改造 | ✅ 原生设计 | ❌ 无 | 架构支持但工程弱 | ✅ 自主设计 |
| **多实例数据一致性** | 需Redis改造 | Redis统一托管 | 无机制 | Redis基础实现 | 自主实现 |
| **网关独立弹性伸缩** | 不支持 | ✅ 无状态独立扩缩 | 不支持 | 理论可行 | ✅ |
| **K8s HPA自动扩缩** | 需改造 | ✅ 原生支持 | 不支持 | 无官方模板 | 自主实现 |
| **跨机房多集群部署** | 困难 | ✅ 原生支持 | 不支持 | 未验证 | 自主实现 |
| **日均调用支撑上限** | 数万级 | 百万级以上 | 单机万级 | 数万级 | 不限 |
| **分布式评分** | ★★ | ★★★★★ | ★ | ★★★ | ★★★★★ |

**分析**：
- **LiteLLM**分布式能力最优，转发服务无状态、Redis全局统一配额，支持K8s HPA自动弹性，百万级日调用无瓶颈。
- **NewAPI**单体架构先天限制，多实例需依赖Redis改造共享配置，且网关与后台耦合，无法独立弹性伸缩。
- **Sub2API**完全不适合分布式集群场景，多节点并发会出现额度重复扣减、路由不一致。
- **LLMProxy-Admin**架构合理但实现不成熟，高并发下存在同步延迟问题，生产级大规模案例极少。

---

### 3.6 社区活跃度与可持续维护（硬性约束H4）

| 对比项 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|--------|--------|---------|---------|----------------|------|
| **项目维护模式** | 数十位贡献者 | 商业公司+全球社区 | 单人维护 | 单人独立维护 | 内部团队 |
| **代码提交频率** | 每周稳定提交 | 每日提交 | 间歇性 | 数月无更新 | 自主掌控 |
| **版本发布节奏** | 月度固定Release | 规划清晰Roadmap | 无固定节奏 | 无固定节奏 | 自主规划 |
| **Issue响应速度** | 快 | 极快 | 长期积压 | 慢 | 自主处理 |
| **国产模型适配速度** | 国内最快 | 海外优先，国内滞后 | 缓慢 | 缓慢 | 自主可控 |
| **企业落地案例** | 大量国内企业 | 全球大厂 | 少量创业团队 | 极少 | — |
| **社区评分** | ★★★★★ | ★★★★★ | ★★ | ★★ | — |

**风险结论**：
- **NewAPI**与**LiteLLM**均为高活跃项目，不存在单人维护风险，长期可持续迭代有保障。
- **Sub2API**与**LLMProxy-Admin**为单人维护，Issue长期积压，Bug修复周期长，集团级生产环境落地风险极高。
- **自研**无外部依赖，但迭代节奏完全依赖内部研发资源投入。

---

### 3.7 大模型厂商适配

| 厂商/模型 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|-----------|--------|---------|---------|----------------|------|
| OpenAI | ✅ 完整 | ✅ 最完善 | ✅ 优先适配 | ✅ 基础 | ✅ |
| Claude/Anthropic | ✅ | ✅ 最完善 | 部分 | 部分 | ✅ |
| Gemini/Google | ✅ | ✅ 完整 | 部分 | 部分 | ✅ |
| Azure OpenAI | ✅ | ✅ 完整 | 部分 | 部分 | ✅ |
| 文心一言 | ✅ 第一梯队 | 适配滞后 | 覆盖不全 | 基础 | ✅ |
| 通义千问 | ✅ 第一梯队 | 适配滞后 | 覆盖不全 | 基础 | ✅ |
| 讯飞星火 | ✅ 第一梯队 | 适配滞后 | 覆盖不全 | 基础 | ✅ |
| 智谱/ChatGLM | ✅ 第一梯队 | 适配滞后 | 覆盖不全 | 基础 | ✅ |
| DeepSeek | ✅ | 适配滞后 | — | — | ✅ |
| MiniMax | ✅ | 适配滞后 | — | — | ✅ |
| 本地私有化模型 | 需二开 | 需插件开发 | 不支持 | 不支持 | ✅ |
| **适配评分** | ★★★★★ | ★★★★ | ★★★ | ★★★ | ★★★★★ |

**分析**：
- **NewAPI**国产模型适配能力最强，国内厂商新接口第一时间跟进，社区插件丰富。
- **LiteLLM**海外模型生态最完善，但国内小众模型适配滞后，中文本地化能力弱，需自行编写适配插件。
- **自研**可快速对接企业私有化本地大模型集群，响应速度完全可控。

---

### 3.8 流量治理能力

| 治理能力 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|----------|--------|---------|---------|----------------|------|
| 多密钥轮询/权重负载 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 渠道故障自动剔除 | ✅ | ✅ | 基础 | 基础 | ✅ |
| 单次失败重试 | ✅ | ✅ | ✅ | ✅ | ✅ |
| **分布式全局限流** | ❌ | ✅ 原生支持 | ❌ | 基础实现 | ✅ |
| **多级熔断降级** | ❌ | ✅ 完善 | ❌ | ❌ | ✅ |
| **灰度路由/流量染色** | ❌ | ✅ | ❌ | ❌ | ✅ |
| **KV缓存加速** | ❌ | ✅ | ❌ | ❌ | ✅ |
| **超时自适应降级** | ❌ | ✅ | ❌ | ❌ | ✅ |
| **治理评分** | ★★★ | ★★★★★ | ★★ | ★★★ | ★★★★★ |

**分析**：
- **LiteLLM**提供企业级完整流量治理体系，分布式限流基于Redis计数器，多节点额度不超额，灰度路由、流量染色等能力完备。
- **NewAPI**仅内置单机级基础治理能力，无分布式全局限流、多级熔断等高阶能力。
- 自研方案全部能力需自主开发，但可按需叠加任意治理策略。

---

### 3.9 可观测与审计合规

| 对比项 | NewAPI | LiteLLM | Sub2API | LLMProxy-Admin | 自研 |
|--------|--------|---------|---------|----------------|------|
| 调用日志 | 基础日志 | 全链路结构化 | 简陋 | 简单日志 | 自定义 |
| 用量统计 | 基础统计 | 多维度计量 | 账单为主 | 基础报表 | 自定义 |
| **OTel链路追踪** | ❌ | ✅ 原生支持 | ❌ | ❌ | ✅ 可集成 |
| **Prometheus监控** | ❌ 需二开 | ✅ 原生暴露 | ❌ | ❌ | ✅ 可集成 |
| **操作审计留痕** | 简单记录 | 完整审计字段 | 缺失 | 不足 | 自定义 |
| **ELK对接能力** | 需二开 | ✅ 结构化输出 | 困难 | 困难 | 自定义 |
| **告警推送** | 无原生 | ✅ 自定义钩子 | 无 | 无 | 自定义 |
| **等保合规** | 需补充开发 | 少量补充 | 不满足 | 不满足 | 完全贴合 |
| **观测评分** | ★★★ | ★★★★★ | ★★ | ★★★ | ★★★★★ |

**分析**：
- **LiteLLM**原生支持OTel、Prometheus标准接口，全链路日志结构化输出，可直接对接ELK，审计字段完整。
- **NewAPI**基础功能具备，但需二次开发对接企业监控体系，无标准化指标暴露接口。
- Sub2API/LLMProxy-Admin合规能力严重不足，无法满足集团等保审计要求。

---

## 四、各方案业务场景适配结论

| 方案 | 最佳适配场景 | 企业规模 | 推荐度 |
|------|-------------|----------|--------|
| **NewAPI** | 国内中小企业、内网小规模调用、快速上线可视化运营 | 中小规模（日调用数万级） | ⭐⭐⭐⭐ |
| **LiteLLM** | 云原生K8s架构、超大并发、海外模型为主、有前端自研能力 | 中大型集团（百万级日调用） | ⭐⭐⭐⭐ |
| **Sub2API** | 小型创业团队、对外付费AI服务运营 | 极小型（单机） | ⭐ |
| **LLMProxy-Admin** | 小业务线临时中转、测试环境 | 测试/临时场景 | ⭐⭐ |
| **自研** | 涉密内网、特殊合规、充足研发人力 | 超大型集团 | ⭐⭐⭐⭐ |
| **LiteLLM+NewAPI组合** | 国内大型集团、兼顾国产适配+超大并发+开箱即用 | 集团级（全规模） | ⭐⭐⭐⭐⭐ |

---

## 五、最终推荐方案

### 方案A：最优组合（推荐集团正式落地）⭐

**LiteLLM分布式转发网关集群 + NewAPI Token可视化运营后台**

| 硬性约束 | 满足情况 |
|----------|----------|
| H1 源码开放可二开 | ✅ 两套均为MIT协议，完整Fork至企业私有仓库 |
| H2 Token运营分发 | ✅ NewAPI完整运营后台 + LiteLLM底层完备能力 |
| H3 分布式集群扩展 | ✅ LiteLLM原生无状态，K8s HPA弹性伸缩，百万级QPS |
| H4 社区可持续维护 | ✅ 两套均为高活跃主流项目，单一停更可单独替换 |

**组合优势**：
- 架构互补：LiteLLM解决集群扩容+流量治理，NewAPI补齐可视化运营+国产模型适配
- 风险对冲：分层解耦，任一项目迭代放缓可单独替换对应层级
- 落地路径清晰：短期NewAPI快速上线，长期LiteLLM支撑业务爆发式扩容

### 方案B：仅国内中小规模业务

单独选用**NewAPI**，部署简单、运维成本低、国产模型适配友好；业务增长至瓶颈后接入LiteLLM做转发层拆分改造。

### 方案C：涉密/强合规/充足人力

选用**自研方案**，彻底消除外部开源依赖，架构、安全、流程完全贴合内部管控标准。

### 方案D：直接淘汰

**Sub2API**、**LLMProxy-Admin**：社区活跃度低、长期维护风险不可控，分布式能力先天缺陷，不适合集团级平台。

---

## 六、组合方案落地架构概览

```
┌─────────────────────────────────────────────────────────────────┐
│                      接入负载均衡层                              │
│               K8s Ingress / Nginx（HTTPS + IP白名单）           │
└───────────────────────────┬─────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────────────┐
│                分布式转发集群层（LiteLLM Proxy）                  │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │ Pod 1    │  │ Pod 2    │  │ Pod 3    │  │ Pod N    │       │
│  │无状态网关 │  │无状态网关 │  │无状态网关 │  │无状态网关 │       │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘       │
│  子Token鉴权 | 模型路由 | 分布式限流熔断 | 负载均衡 | 计量      │
└───────────────────────────┬─────────────────────────────────────┘
                            │ Redis Pub/Sub 配置实时同步
┌───────────────────────────▼─────────────────────────────────────┐
│                 Token运营后台层（NewAPI）                        │
│  ┌──────────┐  ┌──────────┐                                    │
│  │ Admin 1  │  │ Admin 2  │（多副本，不承载转发流量）           │
│  └──────────┘  └──────────┘                                    │
│  密钥加密入库 | 子Token创建 | 配额配置 | 用量报表 | 操作审计     │
└───────────────────────────┬─────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────────────┐
│           分布式缓存层（Redis哨兵集群）                           │
│   实时额度计数器 | 路由配置缓存 | 分布式限流规则 | 会话数据       │
└───────────────────────────┬─────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────────────┐
│           持久化与可观测存储层                                   │
│  ┌──────────┐  ┌──────────┐  ┌───────────────┐                │
│  │ MySQL    │  │  ELK     │  │ Prometheus+    │                │
│  │ 主从集群  │  │ 日志集群  │  │ Grafana监控   │                │
│  └──────────┘  └──────────┘  └───────────────┘                │
└─────────────────────────────────────────────────────────────────┘
```

---

## 七、选型结论

| 维度 | 结论 |
|------|------|
| **最优方案** | LiteLLM + NewAPI 组合架构 |
| **核心优势** | 同时满足源码开放、Token运营、分布式扩容、社区可持续四项硬性约束 |
| **风险可控性** | 双开源分层解耦，单一项目停更可单独替换，风险对冲 |
| **落地性价比** | 短期依托NewAPI快速上线，长期依托LiteLLM支撑扩容，兼顾速度与架构 |
| **对比淘汰项** | Sub2API/LLMProxy-Admin社区与架构缺陷明显，不满足集团级要求；自研成本过高 |

**建议立即启动阶段一试点验证，3天内完成单机POC，为集团全面推广奠定基础。**