大模型网关与接口分发工具怎么选？7 款开源项目的真实场景对比

月诸清酒
0 阅读6分钟

大模型网关与接口分发工具怎么选？7 款开源项目的真实场景对比

不仅模型百花齐放，模型网关也百花齐放，比如：LiteLLM、One API、New API、Portkey、Helicone、sub2api、CLIProxyAPI……

它们在 GitHub 上的简介看起来都差不多——大家都说自己是“统一接入”、“模型路由”、“支持百种模型”。但真正在业务里跑起来以后，你会发现它们基本都有点自己的侧重点。

有的是企业级的重量级网关，有的是纯粹为了分发额度，还有的只是为了让你的终端工具（比如 Claude Code）用得更爽。

这篇文章不罗列干巴巴的功能表，我们直接从实际的工程痛点和使用场景出发，来看看这 7 款工具的真实场景。

场景一：单纯想把 Key 分发给团队和朋友

很多时候我们的诉求极其简单：手里有几个高额度的 API Key，想分给团队里的几个人或者几个不同的内部项目用，最好能限制一下每个人的调用额度，免得某天睡醒发现被刷爆了。

在这个场景下，老牌的 One API 和它的衍生版本 New API 是最稳妥的选择。

  • One API (28k+ stars)：简单粗暴，单文件部署或者 Docker 跑起来就能用。它最大的杀手锏是对国内中文大模型支持得极好（DeepSeek、文心一言、通义千问、豆包、智谱、腾讯混元等几乎闭眼秒接入）。它在 OpenAI 协议兼容和发卡中转这块摸爬滚打了很久，非常适合快速拉起一个稳定的 relay。

  • New API (14k+ stars)：如果你觉得 One API 的界面和多格式兼容还能再提升一点，New API 是一套更现代的统一管理系统，它把模型接入、多账号分发和 UI 收拾得更干净些。

如果你不光想分发给团队，还想搞一套完善的计费和配额运营系统，那可以看看 sub2api。它重点关注订阅、限流、并发控制，甚至自带支付和管理后台。做共享平台或分摊成本，它是对口的；但如果是个人小团队内部用，它的系统组件会显得太重了。

场景二：自己手搓 Agent，光是适配不同 Provider 就把代码写成了一锅粥

写过 Agent 架构的人都知道，稍微复杂点的工作流通常要混用好几个模型：比如用便宜又快的模型做意图识别，用算力拉满的 Claude 处理核心逻辑，再去调不同的 API 做特殊任务。如果各种厂家的 SDK 混在一起写，你的 Agent 核心逻辑很快就会被满屏的 API 适配、出错重试给淹没。这时候，纯粹的发卡代理对你毫无帮助，你需要的是一个懂“模型路由策略”的网关。

  • LiteLLM (32k+ stars)：Python Agent 的“瑞士军刀”。它最大的本事就是把外面奇奇怪怪的模型厂家全部抹平，对外统一暴露成标准的 OpenAI 接口规范。你的 Agent 代码里从此只用写一套核心逻辑，剩下的超时重试、并发负载、包括某个 Provider 挂了自动切到备用模型（Fallback），全扔给它管。 当然，代价是规则配置有点繁琐。如果你只是写个单模型的对话脚本，用 LiteLLM 就像开着重卡去买菜。但如果是搭多模型的 Agent 架构，它是打底的首选。

  • Portkey Gateway (10k+ stars)：如果是上生产线，它比 LiteLLM 更像是“正规军”。Agent 最大的黑洞就是“不可控的幻觉和输出”，极其需要护栏（Guardrails）。如果你一定要个控制台来拦截违规词、或者追求极端的路由稳定性，选 Portkey 就对了。相反，如果是个人开发者刚开始起步写 Agent，这套厚重的架构可能会成为累赘。

场景三：不需要花里胡哨的路由，我只想把大模型请求彻底监控起来

有很多时候，你的架构其实早就稳定了。你不需要它帮你切账号，也不需要它帮你轮询重试。你唯一的诉求就是监控：怎么把业务里的大模型请求看个清清楚楚，比如查出到底是哪段 prompt 耗时 10 秒钟、每次对话的 Token 消耗、以及追踪用户的完整聊天链路（Trace）。

  • Helicone (4k+ stars)：把它归到代理网关里其实有点委屈它，它更像是一个无侵入式的“听诊器”。你只需要在代码的 base_url 里换一套它的地址，它就能顺手拦截并记录所有的请求日志。成本、延迟、各个版本的 prompt 质量，全给你掰碎了揉在一个可视化的分析看板上。它不抢网关的活儿，就是单纯帮你把大模型的“可观测性（Observability）”这件事做到极致。

场景四：只想把端侧的 Codex/Gemini 代理成标准 API

其实我们大多数人根本用不上 LiteLLM 那么沉重的网关。最大的需求其实就是把Codex、Antigravity、Claude Code这些官方工具代理成标准API，然后把这些API本地代理接入到自己的Agent中。

  • CLIProxyAPI (26.9k+ stars)：这工具专门帮你代理转换这批端侧模型。如果你只是想把本地跑的 Codex、Gemini、Copilot 或者 Antigravity，套个壳变成兼容 OpenAI 格式的 API 接口，用它最直接。 它的好处是不用去买或者填 API Key，直接走原生的 OAuth 授权登录就行。如果你有几个账号轮着用，或者偶尔触发限流了，填进配置表里，它会在后台自动帮你做账号切换和轮询。因为这套代理方案太省事，现在 GitHub 上一堆用来管面板和多开账号的周边生态（像 vibeproxy、CodMate、quotio），底层全都是直接调的它。

总结：你的需求是什么？

不要看着 GitHub 上的 Star 数盲目选型，这几类工具其实对应架构里的三层不同需求：

  1. 接入层（网关与路由）：需要兜底和统一接口，选 LiteLLM ；需要稳定分发和管控，选 One API / New API；需要企业级护栏，选 Portkey。
  2. 观测层（日志与成本）：需要看破请求黑盒，选 Helicone。
  3. 工作流层（终端与运营）：CLI 命令行深度受众选 CLIProxyAPI；想做计费运营平台选 sub2api。

提及工具链接一览

avatar
文章
阅读
粉丝