New API vs LiteLLM：大模型 API 网关终极对决，6 维对比一篇说透
核心定位 × 技术栈 × 配置扩展 × 预算管理 × 可观测性 × 路由容灾，6 维对比一次讲清，帮你选对 AI Gateway。
一句话总结
- New API = 开箱即用的 AI API 网关 + 用量管理平台，更偏平台化，强调多模型聚合、多租户、用户/额度、渠道管理和 Web 后台。
- LiteLLM = 面向 AI 工程化的 AI Gateway + Router + SDK，更偏基础设施，强调统一模型接入、路由、预算治理、可观测性和开发者集成。
- 一句话选型：需要用户、额度、计费、渠道、Web 管理后台，优先考虑 New API；需要复杂路由、工程化治理、SDK、可观测性和 AI 基础设施能力，优先考虑 LiteLLM。
- 它们不是简单的替代关系：两者都能做 AI Gateway，真正的区别是产品化平台能力和工程化基础设施能力的侧重点不同。
一、为什么要做这个对比？
OpenAI、Claude、Gemini、DeepSeek、智谱等模型厂商越来越多，不同厂商的 API 协议、模型名称、计费方式、限流策略和错误格式也各不相同。
当一个企业或团队同时接入多个模型时，直接让业务系统分别对接每一家厂商，很快就会遇到一堆问题：
- 每接一家模型，就要维护一套 API 适配逻辑。
- 模型切换时，业务代码需要跟着修改。
- 某个模型故障后，没有统一的备用路由。
- 不同团队、项目的模型成本很难统计。
- API Key、权限、预算和调用日志越来越难管理。
于是，AI API Gateway 就成为了一个越来越重要的基础设施。
New API 和 LiteLLM 经常被放在一起比较，因为它们都能够把不同模型服务统一到一个入口，并提供 OpenAI 兼容的调用方式。
但两者的设计思路并不完全一样：
New API 更偏“平台化的 AI Gateway”，LiteLLM 更偏“工程化的 AI Gateway”。
下面从 6 个维度详细对比。
二、核心定位：都是 AI Gateway，但产品侧重点不同
| 维度 | New API | LiteLLM |
|---|---|---|
| 核心定位 | AI API 网关 + 用量管理平台 | AI Gateway + Router + SDK |
| 产品侧重 | 平台化、多租户、用户/额度、渠道和运营管理 | 工程化、路由、预算、治理、可观测性 |
| 典型用户 | 个人开发者、团队、企业平台团队 | AI 工程师、平台团队、Agent 开发者、企业 IT |
| Web 管理 | 较强 | ✅ |
| 多模型统一接入 | ✅ | ✅ |
| 多租户 | ✅ | ✅ |
| 用户 / Token / 额度 | 强 | ✅，偏 Virtual Key / Team / Project |
| 路由与故障切换 | ✅ | 能力更丰富 |
| Python SDK | ❌ | ✅ |
| REST API | ✅ | ✅ |
| 可观测性生态 | 基础到中等 | 更丰富 |
New API 更像什么？
New API 更像一个已经做好的“AI API 平台”。
你把 OpenAI、Claude、Gemini、DeepSeek 等合法授权的上游渠道接进去，然后在 Web 后台统一管理：
- 用户
- Token
- 模型
- 渠道
- 分组
- 用量
- 成本
- 权限
- 日志
它特别适合希望少写管理系统代码，直接搭起一个完整 AI Gateway 平台的团队。
LiteLLM 更像什么？
LiteLLM 更像一个可以嵌进企业技术架构里的“AI 基础设施层”。
它既可以作为独立的 Proxy Gateway，也可以作为 Python SDK 直接集成到应用代码里。
因此它更适合：
- AI Platform
- Agent 平台
- 企业内部统一模型入口
- 多模型路由
- 成本治理
- 可观测性
- 自定义工程化集成
结论
不是：
New API 做分发，LiteLLM 做网关。
更准确的说法是：
两者都能做 AI Gateway，只是 New API 更偏平台化，LiteLLM 更偏工程化。
三、技术栈：Go 平台 vs Python AI 生态
| 维度 | New API | LiteLLM |
|---|---|---|
| 主要语言 | Go | Python |
| 服务形态 | 独立 Web / API 服务 | Proxy Gateway + Python SDK |
| API 协议 | OpenAI 兼容 API | OpenAI 兼容 API |
| SDK | 主要通过 HTTP/API 接入 | Python SDK 原生支持 |
| 部署方式 | Docker / 独立服务 | Docker / CLI / Python 环境 |
| 适合 | 独立运行的平台型网关 | AI 工程和平台基础设施 |
怎么理解这个差异？
New API 的优势之一，是它本身就是一个相对完整的独立平台。
你不需要把它嵌进自己的 Python 项目里，部署完成之后，业务系统通过标准 API 调用即可。
因此它特别适合：
“我想先把一个完整的 AI Gateway 跑起来。”
而 LiteLLM 的特点是同时提供两种使用方式：
方式一：LiteLLM Proxy
把它当成一个中央 AI Gateway：
业务系统
↓
LiteLLM Proxy
↓
OpenAI / Claude / Gemini / DeepSeek / Azure / Ollama ...
这种模式下，你的业务系统甚至不需要使用 Python。
Java、Go、Node.js 等后端只需要调用 OpenAI 兼容接口即可。
方式二：LiteLLM Python SDK
如果你本身就在开发 Python AI 应用，也可以直接：
from litellm import completion
response = completion(
model="gpt-5",
messages=[
{"role": "user", "content": "Hello"}
]
)
这样就可以在应用层直接获得统一的模型调用接口、重试、Fallback、成本统计和其他能力。
所以不要简单理解成“LiteLLM = Python 项目”。
更准确地说：LiteLLM 对 Python / AI 工程生态特别友好，但 LiteLLM Proxy 本身并不要求你的业务系统使用 Python。
一个需要特别说明的问题
网上经常有人喜欢直接说：
Go 一定比 Python 并发高。
这个说法并不严谨。
Gateway 的实际吞吐还会受到：
- Streaming
- 上游模型响应时间
- 数据库
- Redis
- 日志
- Callback
- 网络
- 路由策略
- 部署副本
等因素影响。
因此，除非使用相同配置和真实流量进行 Benchmark，否则不建议简单下结论：
“New API 单实例一定比 LiteLLM 并发高”。
更稳妥的结论是：
New API 的 Go 架构更适合把网关作为独立平台运行；LiteLLM 则更强调 AI 工程生态和 Gateway 能力的组合。
四、系统配置和扩展方式：平台化管理 vs 工程化定制
这是两个项目差异非常明显的一点。
New API：Web 管理后台驱动
New API 的一个明显优势，就是很多功能已经做成了现成的平台能力。
例如：
- 用户管理
- Token 管理
- 渠道管理
- 模型管理
- 分组管理
- 兑换码
- 日志
- 用量统计
- 成本管理
- 权限设置
- 系统设置
管理员可以直接通过 Web 后台操作。
例如添加一个模型渠道，通常就是：
添加渠道
↓
选择模型供应商
↓
填写 API Key
↓
配置模型
↓
配置优先级 / 权重
↓
完成
对于希望快速搭建一个完整 AI API 平台的人来说，这种方式非常省事。
而且 New API 并不是“只能点网页”。
当前也提供完整 RESTful API，可以用于 AI 调用和系统管理，因此也可以进行自动化运维和二次开发。
适合谁？
希望少写代码，直接得到一个完整 AI API 管理平台的人。
LiteLLM：配置 + API + SDK
LiteLLM 的思路更加工程化。
例如 Proxy 常见配置可以放到 YAML：
model_list:
- model_name: gpt-5
litellm_params:
model: openai/gpt-5
api_key: os.environ/OPENAI_API_KEY
- model_name: claude
litellm_params:
model: anthropic/claude-sonnet
api_key: os.environ/ANTHROPIC_API_KEY
然后通过统一的 Gateway 暴露给业务系统。
这种方式特别适合：
- Git 管理
- CI/CD
- Docker
- Kubernetes
- GitOps
- 自动化部署
- 环境隔离
同时 LiteLLM 还提供 API、SDK、Proxy、插件和 Callback 等能力，因此比较容易和企业现有系统打通。
例如：
企业 SSO
↓
业务系统
↓
LiteLLM Gateway
├── 鉴权
├── Budget
├── Rate Limit
├── Router
├── Logging
└── Observability
↓
多家模型厂商
适合谁？
希望把 AI Gateway 当成企业基础设施，而不是单独的一套管理网站。
一句话总结
New API 是“拿来就能跑的平台”。
LiteLLM 是“方便纳入企业技术栈的基础设施”。
五、用户、计费与预算：解决的是两类不同的管理问题
这一块非常容易把两个项目简单理解成：
一个负责收费，一个负责预算。
但实际上，现在两者的能力已经有不少重叠。
真正的区别应该看：
它们把“用量管理”放在产品里的哪个位置。
New API：更强调用户、额度、渠道和账务
New API 的平台能力包括：
- Token / API Key 管理
- 用户管理
- 用户分组
- 用量统计
- 余额 / 额度
- 模型倍率
- 渠道管理
- 企业客户账务
- 成本分摊
- 充值和订阅等平台能力
因此它非常适合：
把模型服务包装成一个完整的 API 服务平台。
比如：
用户 A
↓
Token
↓
New API
↓
模型渠道
↓
OpenAI / Claude / Gemini
同时记录：
- 调用次数
- Token
- 消耗
- 模型
- 用户
- 渠道
这种模式特别适合需要用户体系 + 用量体系 + 管理后台的场景。
LiteLLM：更强调 Team / Project / Key / Budget
LiteLLM 的成本治理更偏企业工程体系。
例如：
Organization
│
├── Team A
│ ├── Project 1
│ └── Project 2
│
└── Team B
├── Project 3
└── Project 4
每个团队或项目可以进一步关联：
- Virtual Key
- Budget
- Spend
- Model Access
- Rate Limit
- Usage Tracking
于是你可以回答：
“研发团队这个月用了多少钱？”
“Agent 项目用了多少钱？”
“这个 API Key 到预算上限了吗？”
“这个项目能不能调用 Claude？”
这就是 LiteLLM 的工程治理思路。
最容易记住的一句话
New API 更像“把模型服务平台化”。
LiteLLM 更像“把模型调用治理化”。
这比单纯说：
“New API 管收费，LiteLLM 管预算”
更加准确。
六、可观测性：内置管理能力 vs LLMOps 生态
到了生产环境，真正让人头疼的问题往往不是：
“模型能不能调用？”
而是：
“为什么这个请求慢了？”
“哪个项目花的钱最多？”
“哪个模型错误率最高？”
“这次 Agent 调用了哪些模型？”
“到底是哪一次调用导致成本飙升？”
这时候，可观测性就非常重要。
New API：内置数据看板和调用管理
New API 本身已经提供比较完整的管理能力，包括：
- 调用日志
- 用量统计
- 成本分析
- 数据看板
- 性能监控
- 渠道状态
- Token 使用情况
对于大多数内部团队来说，这些功能已经可以覆盖日常运营需求。
而且它的优势在于：
这些能力直接集成在自己的管理后台里。
不需要额外拼一套复杂的系统。
LiteLLM：更容易接入完整 LLMOps 链路
LiteLLM 的优势则在于生态。
它可以把模型调用数据进一步发送给：
- OpenTelemetry
- Prometheus
- Datadog
- Langfuse
- LangSmith
- MLflow
- Lunary
等系统。
于是整个链路可以变成：
用户
↓
Agent
↓
LiteLLM
↓
Router
↓
Claude / GPT / Gemini / DeepSeek
↓
Observability
├── Logs
├── Metrics
├── Traces
├── Cost
└── Prompts
当你的 AI 系统开始进入生产环境以后，这种能力的价值会越来越明显。
怎么选？
如果你的需求是：
“我需要一个后台看调用量、用户、余额和渠道状态。”
New API 已经很好用。
如果你的需求是：
“我要把模型调用接入现有的 Prometheus / OpenTelemetry / Langfuse / Datadog 体系。”
LiteLLM 的优势会更加明显。
七、路由和容灾：平台型路由 vs 工程化 Router
模型数量一多，真正重要的就不只是“能调用”。
还要考虑：
- 一个模型挂了怎么办？
- 同一个模型有多个渠道怎么办？
- 哪个渠道延迟最低？
- 哪个渠道成本最低？
- 请求失败需要不要重试？
- 是否需要备用模型？
- 某个渠道连续失败要不要暂时摘除？
这也是 AI Gateway 的核心价值之一。
New API：多渠道负载均衡 + 故障切换
New API 当前已经支持比较完整的渠道路由能力，例如：
- 多渠道负载均衡
- 优先级
- 权重
- 加权随机
- 自动禁用异常渠道
- 故障自动切换
- 模型映射
例如你有：
GPT-5
├── OpenAI Channel A
├── OpenAI Channel B
└── Azure Channel C
可以通过优先级和权重决定流量怎么分配。
某个渠道连续失败后，还可以自动禁用，让请求转向其他渠道。
对于绝大多数：
多渠道 + 高可用 + 基础负载均衡
场景来说，已经足够实用。
LiteLLM：更强的 Router 体系
LiteLLM 的 Router 则更加偏工程化。
可以根据不同策略进行模型部署选择，例如：
- Weighted Routing
- Latency-based Routing
- Least-busy
- Usage-based
- Cost-based
- Retry
- Fallback
- Cooldown
- Load Balancing
例如：
用户请求
↓
LiteLLM Router
│
├── GPT Deployment A
├── GPT Deployment B
├── Azure Deployment
└── Backup Deployment
如果某个 deployment 出现错误或者进入 cooldown 状态，可以自动把请求转移到其他 deployment。
同时还可以把 Router 和：
- Budget
- Rate Limit
- Cache
- Observability
- Guardrails
组合起来。
一个容易被误解的点
不要简单把 LiteLLM 写成：
“拥有无限智能的 AI 路由器”。
它本质上依然是基于配置、指标和策略进行请求调度的 Router。
例如：
Lowest Latency
就是根据实际延迟数据选择更快的 deployment。
而：
Context Window Check
更多是调用前进行上下文能力检查，避免请求超出模型能力边界。
因此，更准确的说法是：
LiteLLM 的优势不是“会替你思考”，而是提供了更丰富的、可以工程化配置的路由和容灾机制。
八、选型总结：四类场景，一张表搞定
8.1 更适合 New API 的场景
场景一：需要完整 Web 管理后台
例如：
用户
Token
模型
渠道
额度
日志
成本
权限
都希望在一个后台完成。
→ New API
场景二：多用户、多租户、用量管理
如果你的系统需要：
- 用户管理
- Token
- 分组
- 额度
- 用量
- 成本统计
→ New API 非常适合
场景三：想快速搭建统一 AI API 平台
希望：
Docker 拉起来 → 配渠道 → 配模型 → 发 API
而不是自己开发一整套管理后台。
→ New API
8.2 更适合 LiteLLM 的场景
场景一：企业内部 AI Gateway
业务系统
↓
LiteLLM
↓
统一模型池
多个业务系统都通过一个统一入口访问模型。
→ LiteLLM
场景二：Agent / AI Platform
你的系统本身就大量使用：
- Python
- Agent
- LangChain
- LlamaIndex
- Langfuse
- OpenTelemetry
并且希望 Gateway 和这些生态深度结合。
→ LiteLLM
场景三：复杂模型路由
如果你需要：
- 多 deployment
- Fallback
- Retry
- Latency Routing
- Load Balancing
- Budget
- Rate Limit
→ LiteLLM 更值得优先考虑
场景四：企业级成本治理
例如：
公司
├── AI Team
│ ├── Agent Project
│ └── RAG Project
│
├── Marketing
│ └── Content Project
│
└── Customer Service
└── AI Assistant
每个团队和项目都有自己的：
- API Key
- Budget
- Spend
- Model Access
→ LiteLLM 更适合做这种工程化治理。
九、一句话对比
| 项目 | 一句话定义 | 核心关键词 |
|---|---|---|
| New API | 开箱即用的 AI API 网关 + 用量管理平台 | 多模型、渠道、用户、Token、额度、成本、Web 后台 |
| LiteLLM | 面向 AI 工程化的 AI Gateway + Router + SDK | Python SDK、Proxy、路由、Budget、Fallback、可观测性、治理 |
十、真正的选型决策树
你要解决什么问题？
│
├── 想快速搭一个完整 AI API 管理平台
│ ├── 用户
│ ├── Token
│ ├── 模型
│ ├── 渠道
│ ├── 额度
│ └── Web 后台
│
│ └── 👉 New API
│
├── 企业内部多个业务系统统一接入模型
│ │
│ └── 👉 New API / LiteLLM 都可以
│
├── 需要复杂模型路由、Fallback、Retry、Load Balancing
│ │
│ └── 👉 LiteLLM 更有优势
│
├── AI 应用 / Agent 深度使用 Python
│ │
│ └── 👉 LiteLLM
│
├── 需要 Team / Project / Virtual Key / Budget
│ │
│ └── 👉 LiteLLM 更值得优先考虑
│
├── 更看重用户、额度、渠道和 Web 管理体验
│ │
│ └── 👉 New API
│
├── 希望接入 OpenTelemetry / Prometheus /
│ └── Langfuse / Datadog 等现有 LLMOps 体系
│
│ └── 👉 LiteLLM
│
└── 只是想统一多个模型 API
│
└── 👉 两个都可以
十一、那到底应该怎么选？
到了这里，其实答案已经很清楚了。
如果你更看重“平台”
选择 New API。
你会得到：
Web 管理后台
+
用户体系
+
Token / 额度
+
渠道管理
+
模型管理
+
用量统计
+
成本管理
+
统一 API
它更像：
一个开箱即用的 AI API 平台。
如果你更看重“基础设施”
选择 LiteLLM。
你得到的是：
统一模型接口
+
Router
+
Fallback
+
Retry
+
Budget
+
Rate Limit
+
Virtual Key
+
Observability
+
Python SDK
+
企业工程生态
它更像：
AI 应用背后的一层基础设施。
十二、两者其实也可以一起用
很多人看到这篇文章之后，第一反应是：
“既然两个定位不同，那是不是只能二选一？”
其实不一定。
如果企业规模足够大，完全可以采用类似这样的架构：
┌── Agent System
│
├── RAG Platform
业务系统 ────────────┤
└── Internal AI Apps
│
▼
┌──────────────┐
│ LiteLLM │
│ AI Gateway │
└──────────────┘
│
┌──────────┼──────────┐
▼ ▼ ▼
OpenAI Claude DeepSeek
对外 / 平台侧
│
▼
┌──────────────┐
│ New API │
│ AI API 平台 │
└──────────────┘
│
多模型 / 多渠道
当然，这不是说企业一定要同时部署两个 Gateway。
而是：
当组织同时存在“内部 AI 基础设施”和“平台化 API 服务”两类需求时，两者可以承担不同的职责。
对于大多数团队来说，没必要为了“架构看起来高级”而强行同时部署。
十三、最终结论
New API 和 LiteLLM，真正的区别并不是：
谁能做 Gateway，谁不能做。
而是：
两者都能做 AI Gateway，但产品哲学不同。
New API
更偏：
平台化
关键词：
用户、Token、额度、渠道、模型、成本、Web 后台、多租户、用量管理
适合：
想快速搭建一个完整 AI API 平台的人。
LiteLLM
更偏：
工程化
关键词：
Gateway、Router、Fallback、Budget、Virtual Key、SDK、OpenTelemetry、Prometheus、LLMOps
适合：
想把 AI Gateway 作为企业基础设施的人。
最简单的一句话
New API：把“模型调用”做成一个平台。
LiteLLM：把“模型调用”做成一层基础设施。
所以：
重平台管理 → New API
重工程治理 → LiteLLM
两者能力重叠的地方，就根据团队技术栈、管理习惯和已有基础设施来选。
这才是比“谁更强”更有价值的答案。