xx.md 21 KB
企业内部统一Token运营分发平台技术选型方案
一、选型背景与目标
1.1 业务痛点
集团各事业部独立持有文心、通义、OpenAI、Claude等多厂商大模型API密钥，存在以下治理问题：
| 序号 | 痛点 | 影响程度 |
|---|---|---|
| 1 | 密钥分散存储，无统一托管与回收机制 | 严重 |
| 2 | 无标准化内部子Token分发，权限/额度无法按部门隔离 | 严重 |
| 3 | 单机工具无法承载万级QPS并发 | 高危 |
| 4 | 无调用日志、用量统计、审计溯源 | 高危 |
| 5 | 开源工具存在停更、适配滞后风险 | 中等 |
1.2 硬性约束条件
| 编号 | 约束项 | 说明 |
|---|---|---|
| H1 | 源码完全开放 | 支持企业私有化深度二次开发 |
| H2 | 核心定位 | Token集中管理、内部子Token分发运营 |
| H3 | 分布式集群扩展 | 具备支撑集团大规模业务的扩展潜力 |
| H4 | 社区可持续维护 | 规避长期无人迭代风险 |
1.3 建设目标
- 统一密钥托管：全厂商API Key集中收纳、加密存储、分级权限管控
- 标准化Token分发：子Token支持配额、时效、IP、模型权限精细化管控
- 分布式高可用底座：多实例水平扩容，支撑集团全业务并发调用
- 全链路流量治理：负载均衡、故障切换、限流熔断、重试降级
- 合规可观测体系：调用日志、操作审计、用量报表、异常告警
- 可定制扩展：对接LDAP/SSO、成本核算、审批流等
- 长期可持续迭代：依托活跃开源社区，减少重复造轮子
二、候选方案横向对比总览
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，为集团全面推广奠定基础。