企业内部 AI 网关怎么选？LiteLLM、New API、OctaFuse 三方横评

企业内部 AI 网关怎么选LiteLLM、New API、OctaFuse 三方横评【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm当一家企业的业务团队开始把模型调用写进代码混乱几乎必然出现有人直连 OpenAI、有人走 Azure、有人偷偷接了一家国产大模型中转协议五花八门、密钥散落在各环境变量、账单无人对得上。于是「AI 网关」这个角色从基础设施里长了出来——它处在业务代码和模型供应商之间统一协议、统一鉴权、统一计量。社区里围绕「LiteLLM、New API、OctaFuse 怎么选」的讨论热度持续走高本文不以口号站队而是从定位、功能矩阵、落地成本三个维度做一次偏工程视角的横评并把 LiteLLM 的仓库源码作为可验证的证据底座。三家定位差异国际开源网关 vs 国产网关 vs 新势力先看三家在生态里的坐标。LiteLLM是典型的国际开源 AI Gateway源自 YC W23 孵化的 BerriAI定位是「一个接口调用 100 LLM」。仓库 README.md 首页就写着三句话Open Source AI Gateway、Self-hosted、Enterprise-ready以及一个非常具体的性能指标——8ms P95 延迟 1000 RPS。它不是单纯的协议转换器而是一整套「网关 路由器 治理层」的组合既能作为 Python SDK 嵌入应用进程也能以 Proxy Server 形态独立部署这在架构上天然适配「先有 SDK 直连、后有集中管控」的企业演进路径。New API是国产开源网关的代表源自 one-api 系衍生在国内开发者社区渗透率极高。它的强项在于「中转运营」语境渠道管理、令牌体系、额度兑换、站点配置都做得非常贴近国内使用习惯很多团队把它当作统一出口来管理 OpenAI、Anthropic 及各家国产模型的多个上游渠道。OctaFuse属于新势力玩家社区里关于它的信息仍以宣传口径为主、可信的技术评测沉淀较少本文在它身上只做框架性观察、不下具体功能结论——这也正是选型方法论的一部分对一个无法被源码验证的新项目先当作「信息差风险」而非「确定性选项」来管理。三家的分野一句话总结LiteLLM 卖的是「工程完整性」New API 卖的是「本土落地效率」OctaFuse 目前更多是「新叙事」。功能矩阵路由、鉴权、预算、可观测性逐项对比网关选型的本质是回答四个问题模型怎么分发、谁有权限调用、钱怎么控、出了事怎么查。以下矩阵以 LiteLLM 源码为锚其余两家按公开资料对位。路由与协议统一。LiteLLM 的核心是 litellm/main.py 中completion、embedding、text_completion、transcription、speech等入口函数以及 litellm/router.py 的Router类——后者提供了completion、image_generation、embedding、acompletion、abatch_completion等一套完整的同步/异步/批量接口。协议层之上是「模型虚拟名」机制在 proxy_server_config.yaml 里model_name是暴露给业务的逻辑名真正的model、api_key、api_base都藏在litellm_params里业务方永远只认逻辑名。路由策略不再是简单轮询——仓库 router_strategy/ 下除了常规策略还有基于反馈闭环的 AdaptiveRouter 和基于语义分类的 Auto Router后者直接用 semantic_router 把请求按意图分发给不同模型。New API 与 OctaFuse 在这一项上同样主打 OpenAI 兼容入口但渠道级权重调度、失败重试等细节的实现深度需要以各自仓库的文档和 issue 活跃度为准。鉴权体系。网关存在的第二个理由是「不再把供应商真密钥发给每个开发机」。LiteLLM 在 litellm/proxy/auth/ 下实现了完整的虚拟密钥鉴权链user_api_key_auth.py 承担请求级认证管理端则通过 litellm/proxy/management_endpoints/ 的 key、team、budget、customer、organization 等一整套端点对密钥、团队、预算做生命周期管理。密钥可以做到「一个应用一个 key、按团队配额、随时吊销」这是直连模型时代完全不具备的治理颗粒度。New API 的令牌/渠道体系在国内场景同样成熟且对「上游多账号复用」这一痛点有原生支持。预算与计量。网关必须把「钱」变成可审计的数据。LiteLLM 的成本引擎在 litellm/cost_calculator.py提供cost_per_token、completion_cost、response_cost_calculator三个层次的计算底座是仓库根目录的 model_prices_and_context_window.json按供应商、模型、输入/输出单价建索引。配合 Redis/S3/Azure Blob/GCS/磁盘等多后端缓存见 litellm/caching/可以对重复请求做语义/精确缓存来直接砍掉账单。预算控制不只在计量层key、team、org 三个维度都能设max_budget超限即拒绝。New API 的额度与兑换体系在国内更「运营化」适合面向终端用户的售卖场景而 LiteLLM 的预算模型更偏向「内部成本中心」语义。可观测性。网关是天然的观测汇聚点。LiteLLM 的 litellm/integrations/ 目录下挂着一长串可插拔的 callbackLangfuse、Langsmith、OpenTelemetry、Prometheus、Datadog、Arize、Lunary 等都能以配置方式接入不需要改业务代码。Proxy 侧还自带 Prometheus 指标端点配合管理面板可以按 key/team/model 维度看用量曲线。安全与护栏。这是容易被低估的第四维度。LiteLLM 的 Guardrails 是一套可插拔钩子体系目录 litellm/proxy/guardrails/guardrail_hooks/ 下已经沉淀了 50 个实现——Presidio 做 PII 脱敏、Bedrock/OpenAI 的官方内容审核、PromptGuard 类提示注入防护、各种 LLM-as-a-judge 的自定义校验器以及面向 Agent 的 MCP 安全钩子。把护栏收敛到网关一层意味着「一次接入、全业务生效」这是自研方案很难快速补齐的资产。落地成本与企业场景适配度选型不能只看功能表要看「接入成本、运维成本、风险成本」三项。接入成本。LiteLLM 对已有代码最友好的一点是 OpenAI 兼容业务代码里的openai客户端把base_url指到网关即可协议翻译由网关完成。部署形态上官方提供了 docker/docker-compose.ymlgateway Postgres Prometheus 一键拉起、helm/litellm/ 的 Kubernetes 编排以及 terraform/ 下的官方 Provider——模型、团队、密钥全部可以声明为基础设施代码做到「网关即代码」。New API 在国内部署同样以 Docker 为主中文文档与社区排障经验是其隐性成本优势。运维成本。网关一旦成为单点就必须回答高可用问题。LiteLLM 的存储设计相对克制配置与用量数据落 Postgres见 schema.prisma缓存层可外置 Redis配合多副本部署即可横向扩展路由决策本身无状态Router的负载均衡与容灾逻辑全部在进程内完成。需要正视的运维负担是它体量不小——仅litellm/proxy/目录就接近千个文件版本演进快升级前要读变更记录。风险成本。这里必须提一件真实发生的事2026 年 3 月 24 日LiteLLM 在 PyPI 上发布了 1.82.7 与 1.82.8 两个被投毒的版本攻击者利用其 CI 中已被入侵的 Trivy 扫描器拿到发布权限恶意代码分别藏在proxy_server.py与.pth配置文件中——后者在解释器启动时即执行无需任何导入动作。随后恶意版本被撤下1.82.6 为最后一个安全版本。这一事件给所有企业敲的警钟是通用的凡是处理密钥的网关类组件都是供应链攻击的高价值目标选型时必须把「版本校验 签名验证 锁版本发布」纳入制度而不是依赖「官方没出事」。仓库自身的 litellm/_version.py 甚至会主动检测同一环境里litellm与litellm-core两个发行版的命名空间冲突并拒绝启动说明该项目对安装态的正确性有意识但这替代不了企业自己的制品校验流程。场景适配速览维度LiteLLMNew APIOctaFuse典型场景内部多团队研发平台、多云容灾、企业级治理国内中转运营、多上游渠道管理、面向终端售卖新场景探索待源码验证协议统一OpenAI 各厂商原生格式OpenAI 兼容宣传为统一接入鉴权预算虚拟 Key Team/Org 三级预算令牌 额度兑换资料有限可观测性20 可插拔 callback 自带指标基础日志/统计面板资料有限部署Docker/K8s/Helm/Terraform 全栈Docker 为主资料有限语言生态Python SDK 任意语言 HTTP 接入网关服务语言无关语言无关选型建议与迁移路径横向比完结论可以收敛成三条。第一先定「语境」再定「产品」。如果你的诉求是公司内部几十个业务团队统一接入、按团队分账、多云容灾、可观测与护栏全都要——LiteLLM 是目前资料最完整、源码最可验证的开源选项它的 Router Guardrails Cost Engine 三层结构恰好对应企业治理的三件事分发、安全、成本。如果你要的是面向外部用户的额度售卖与多上游渠道运营New API 系在国内语境下更顺手。至于 OctaFuse现阶段请先要求它给出可复现的性能测试与安全审计记录再谈对比。第二用「最小闭环」验证。不要一上来就搭全套。最务实的路径是先用 proxy_server_config.yaml 的model_list挂两三个模型起一个网关实例把业务代码的base_url指过来观察三个信号——协议兼容率有没有请求因参数转换失败、延迟增量网关跳转带来的 P95 涨幅、计量准确性网关账单与供应商账单是否对得上。这三个信号达标再逐步把虚拟密钥、预算上限、Guardrails、可观测性 callback 一层层加上。第三把「退出成本」写进方案。网关的粘性主要来自「业务代码里的 base_url 和逻辑模型名」这两者恰恰是低粘性的——因为它们本来就是抽象。因此迁移路径应该设计成模型名是业务契约、密钥是可吊销的、用量数据可导出、配置可转成 IaCLiteLLM 的 Terraform Provider 正是为此存在的。这样即便未来出现更强的替代品你的迁移动作也只是「换一个网关、改一处 base_url」而不是重写业务。最后回到那个朴素的判断标准AI 网关的价值不在于它接了多少家模型而在于它让「换模型、控成本、查问题、防滥用」都变成配置项而不是改造项。哪个产品能让你的团队在这四件事上少写代码、少开会议它就是当下最适合你的网关。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考