聚合网关选型横评：OneAPI / NewAPI / OpenRouter / LiteLLM
市面上的大模型聚合网关方案可大致分为两类：开源自建（OneAPI、NewAPI、LiteLLM）和托管服务（OpenRouter、力达云聚合 API）。两类各有权衡，本文用横向对比表帮你快速定位适合自己的方案。
价格与模型支持数据截至 2026 年 6 月，以各方官方文档为准，请以实际页面为准。
核心维度横向对比
| 维度 | OneAPI | NewAPI | LiteLLM | OpenRouter | 力达云聚合 API |
|---|---|---|---|---|---|
| 类型 | 开源自建 | 开源自建 | 开源自建 | 托管服务 | 托管服务 |
| 协议兼容 | OpenAI 兼容 | OpenAI 兼容 | OpenAI 兼容 | OpenAI 兼容 | OpenAI 兼容 |
| 上游模型数 | 取决于自行配置 | 取决于自行配置 | 100+ 上游 | 200+ 模型 | 国内外主流模型 |
| 国内模型支持 | 需手动配置 | 有社区渠道配置 | 部分支持 | 较少 | 重点支持 |
| 路由策略 | 优先级、权重轮询 | 优先级、负载均衡 | 策略丰富（成本/延迟/备用） | 自动路由 | 自动路由+定制 |
| 计费管理 | 用户额度、充值 | 用户额度、API Key 管理 | 基础用量统计 | 统一计费 | 统一计费+明细 |
| 运维成本 | 高（自行部署维护） | 高（自行部署维护） | 中（Python 服务，较重） | 零 | 零 |
| 数据自持 | 完全自控 | 完全自控 | 完全自控 | 经第三方 | 经第三方 |
| 部署复杂度 | 中（Docker 单容器） | 中（Docker 单容器） | 中高（Python 依赖较多） | 无需部署 | 无需部署 |
| 社区活跃度 | 高（GitHub 星标多） | 活跃（国内社区为主） | 高（英文社区为主） | 高 | —— |
| 适用规模 | 小中团队 | 小中团队/代理商 | 中大团队/企业 | 个人到中型 | 个人到企业 |
各方案详解
OneAPI
OneAPI 是国内最早流行的开源聚合代理，Go 语言编写，单二进制部署简单，Docker 一键启动。支持用户系统、额度管理、渠道负载均衡，社区有大量国内服务商的渠道配置模板。
优点：部署简单、中文文档齐全、国内社区活跃。
缺点：功能相对基础，插件生态不如 LiteLLM 丰富；需自行维护上游兼容性更新。
真实踩坑：部署完 OneAPI 之后第一件容易翻车的事是”渠道类型”选错。国内大部分中转商挂的是 OpenAI 兼容接口，但渠道类型下拉框里其实分得很细（OpenAI、Azure、文心一言、讯飞星火……），选错了的直接后果是请求发出去之后返回一个 {"error":{"message":"invalid_api_key","type":"invalid_request_error"}}，但你的 Key 其实是对的——因为 OneAPI 把请求路由到了错误的上游端点格式。排查思路很简单：先在渠道测试按钮里单独测一次这条渠道，如果测试通过但业务代码报错，问题基本出在你客户端调用的 base_url 没有指向 OneAPI 自己的 /v1 而是绕过去直连了上游。第二个高频坑是额度耗尽后的报错文案是 "当前分组下没有可用渠道"，这条提示信息容易让人以为是渠道挂了，其实往上翻日志能看到是余额或额度为 0，先查用户额度和渠道余额，再查渠道健康度，顺序不能反。
NewAPI
NewAPI 是 OneAPI 的 fork，在 OneAPI 基础上增加了更多计费模式、渠道管理功能，深受国内 API 代理商使用。界面更现代，权限控制更细。
优点：继承 OneAPI 优点并有功能扩展；适合做多用户/多团队 API 分发。
缺点：社区规模小于 OneAPI；部分功能依赖维护者更新节奏。
如果你是做 API 代理商或者要给团队内多个项目分账，NewAPI 比 OneAPI 更值得选的地方在于计费颗粒度：它支持按模型、按渠道单独设置倍率（比如某个国产模型走特惠渠道价格打七折），OneAPI 的倍率体系相对粗放，只能按分组统一设置。但要提醒一句，NewAPI 是社区 fork，跟 OneAPI 主线的代码差异会随时间拉大，升级时不能直接照搬 OneAPI 的升级脚本，得看 NewAPI 自己的 release note，否则数据库迁移脚本对不上版本号，启动时会直接报 panic: table users has no column named xxx。
LiteLLM
LiteLLM 是 Python 生态下功能最丰富的聚合库，既可作为 SDK 嵌入代码，也可独立部署为代理服务。支持 100+ 上游，路由策略最灵活（成本优先、延迟感知、fallback 链）。
优点：路由策略最丰富；Python 生态集成最深；支持 LangChain/LlamaIndex。
缺点：Python 服务依赖链较重，冷启动慢；国内模型支持依赖社区贡献，有滞后。
LiteLLM 最值钱的地方是 fallbacks 和 retry 这两个配置项，很多团队用了大半年都没吃透。举个真实场景：你的主力模型是 GPT-4o，但偶尔会遇到上游限流，直接报错终止会让用户体验很差。用 router_config.yaml 配一条 fallback 链，遇到限流自动切到备用模型，业务代码完全无感知：
model_list:
- model_name: gpt-4o
litellm_params:
model: openai/gpt-4o
api_key: os.environ/OPENAI_API_KEY
- model_name: gpt-4o
litellm_params:
model: anthropic/claude-3-5-sonnet-20241022
api_key: os.environ/ANTHROPIC_API_KEY
router_settings:
fallbacks: [{"gpt-4o": ["gpt-4o"]}]
num_retries: 2
timeout: 30
这里有个容易踩的坑：num_retries 是针对同一个 model_name 下所有条目轮询重试，如果你把主备模型都取了同名的 model_name（如上面都叫 gpt-4o），LiteLLM 会在第一个失败后自动尝试第二条——这也是为什么很多人看教程配了 fallback 却发现”没生效”，其实是因为两条配置写了不同的 model_name，路由器根本不知道它们是备份关系。
并发场景下另一个高频报错是 RateLimitError: You exceeded your current quota，这在你用 asyncio.gather 批量并发调用时特别常见，因为 LiteLLM 默认不会自动限速，并发数完全由你的代码决定。稳妥的做法是自己包一层信号量控制并发上限（比如 asyncio.Semaphore(5)），再配合 LiteLLM 的 num_retries 加指数退避，而不是指望网关层帮你兜底限流——这是 LiteLLM 和托管网关（如 OpenRouter、力达云）的本质区别：托管服务通常在网关侧就做好了限流保护，自建方案这部分责任在你自己。
OpenRouter
OpenRouter 是目前全球用户最多的托管聚合服务，覆盖 200+ 模型，按实际 token 消耗计费，无月费。页面有实时价格对比，支持”自动路由”（在满足上下文长度的模型中选最便宜的）。
优点：模型数量最多；价格透明；无需运维；API 文档完善。
缺点：服务器在境外，中国大陆直连有时不稳定；国内模型覆盖有限；数据经第三方。
这个”直连不稳定”具体是什么体感？国内不少开发者反馈的现象是请求偶发性卡在 TLS 握手阶段，客户端表现为长时间无响应最后超时，而不是明确的报错码——这种”卡住而不是报错”的故障最难排查，因为你没法从状态码上直接定位问题出在网络链路还是上游服务。常见的缓解办法是给 HTTP 客户端设置合理的连接超时（而不是只设总超时），比如 httpx.Timeout(connect=5.0, read=60.0)，连接阶段 5 秒内建不上就快速失败转入重试或降级，而不是傻等全局超时（往往设的是 60s 甚至更长）耗光整个请求预算。如果你的业务对延迟敏感，境外直连的网络抖动会比国内托管服务明显得多，这也是很多团队即便认可 OpenRouter 的模型覆盖，最终还是选择境内托管方案兜底关键路径的原因。
力达云聚合 API
力达云聚合 API 是面向中国大陆开发者的托管聚合服务，重点解决 OpenRouter 痛点：国内网络直连、国内模型优先覆盖（文心、通义、智谱、Kimi 等）、统一人民币计费。对需要同时调用境内外模型的团队有明显优势。目前处于内测阶段，可申请力达云聚合 API 内测。
按场景的选型建议
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 个人开发者快速试验 | OpenRouter 或力达云内测 | 零运维，按量付费 |
| 初创团队，专注产品 | 托管方案（OpenRouter/力达云） | 节省运维精力 |
| 需要数据完全自持 | OneAPI 或 LiteLLM 自建 | 流量不经第三方 |
| 国内模型为主 | NewAPI 自建 或 力达云 | 国内渠道支持好 |
| Python 栈 LangChain 项目 | LiteLLM | 原生集成最顺畅 |
| 多用户/做 API 分发 | NewAPI | 用户管理和计费功能完善 |
| 大型企业，有 DevOps 团队 | LiteLLM 企业版 或 自建 | 路由策略灵活，可定制 |
| 境内外模型混用 | 力达云聚合 API | 专线优化，一站覆盖 |
常见问题
开源方案的上游兼容性谁来维护？ 开源方案由社区和你自己维护。当模型服务商更新 API（如 Anthropic 推新版本、Google 改接口），需要你关注上游仓库的更新并自行升级。托管方案由服务商维护，对用户透明。
自建方案的总成本（TCO）怎么算？ 需要加上：服务器月费（轻量 ECS 约 ¥30–100/月）+ 运维人力（日常维护、故障排查、版本升级）+ 潜在的故障损失。对于小团队，这个隐性成本往往超过托管服务的差价，详见自建聚合 vs 用托管服务怎么选。
举个假设场景帮你把这笔账算得更具体一点：一个两人小团队自建 OneAPI，服务器每月 ¥60，看起来比托管服务省钱。但真实运维投入往往被低估——上游服务商更新鉴权方式、渠道偶发故障需要手动切换、数据库偶尔需要清理日志表防止磁盘写满，这些琐事平摊下来每月至少占用一名工程师半天到一天的时间。按外包或兼职行情随便估一个每小时 ¥100 的机会成本，一天就是 ¥800，一个月哪怕只发生一次故障排查，隐性成本就已经远超托管服务几十块的差价。这笔账不是说自建不划算，而是提醒你：自建的真实优势是”数据自持”和”路由策略深度定制”，如果你的团队没有这两个硬需求，单纯为了省服务费去自建，多半是在拿工程师的时间换一笔小钱。
OpenRouter 和力达云能同时用吗？ 完全可以。你甚至可以在自建的 OneAPI/LiteLLM 里把 OpenRouter 或力达云作为上游渠道之一，实现”嵌套聚合”，做更精细的路由控制。
网关本身挂了怎么办，有没有必要做高可用？ 个人项目和小团队没必要过度设计，但如果你的产品已经有真实付费用户，建议至少做到”网关单点故障不影响核心链路”这一档——具体做法是在客户端代码里保留一个直连上游的兜底分支，网关连续失败 N 次（比如 3 次）自动降级为直连主力模型，哪怕失去了聚合网关的路由能力，至少保证服务不整体宕机。这个降级开关平时不启用，只在网关侧真出故障时临时切换，比在网关层面自己做多活集群的投入产出比高得多，尤其是对自建 OneAPI/NewAPI 这种单实例部署来说更实用。
流式响应（stream）在聚合网关这一层会不会被卡住？
会，而且这是排查”响应慢”问题时最容易被忽略的一环。无论是 OneAPI、NewAPI 还是 LiteLLM，网关本质上是在做一次反向代理转发，如果反向代理或者中间的 Nginx/Caddy 配置了响应缓冲（buffering），流式的 SSE 数据会被攒够一定大小或等超时才转发给客户端，表现为”打字机效果”消失、内容一次性蹦出来。自建 OneAPI 时如果前面套了 Nginx，一定要显式关闭 proxy_buffering off，否则流式体验会比直连上游明显卡顿，这个坑在国内自建方案的论坛里被反复提起，但官方文档里容易被忽略。
延伸阅读：
- 多模型聚合 API 完整指南
- 自建聚合 vs 用托管服务怎么选
- 更多聚合 API 内容见 聚合API 专题
想省去选型烦恼？申请力达云聚合 API 内测，一个 Key 接通国内外主流大模型，开箱即用。