Let's Make AGI Real

I, Robot

LiteLLM：AI世界的总配电室

Banner with the text 'CREATIVE MINDS' over a colorful abstract artistic background.

——一个"if/else地狱"里诞生的开源项目，如何长成了全球AI基础设施的隐形枢纽

一百行if/else的噩梦

2023年初，旧金山。两个年轻人正在对着屏幕发愁。

Krrish Dholakia，佐治亚理工毕业，做过大厂产品经理；Ishaan Jaffer，卡内基梅隆毕业，写过Coinbase的后端代码。两人刚拿到Y Combinator W23批次的入场券，正在做一个叫BerriAI的项目——简单说，就是"让企业能用自己的数据和大模型聊天"。

产品本身不复杂。复杂的是底下那一层。

他们需要同时接入OpenAI、Azure OpenAI和Cohere三个模型提供商。每家的API格式不一样，参数命名不一样，错误码不一样，计费方式不一样。于是代码里出现了大量的if/else语句——每加一个提供商，就多一百行判断逻辑。当Azure的调用开始频繁失败时，他们又得写模型回退（fallback）机制。但回退逻辑和每个提供商的特殊处理纠缠在一起，代码变成了一团意大利面。

Dholakia后来说，那段日子"调试一个bug要翻三层if/else，每层都是不同提供商的特殊逻辑"。

于是两人做了一个决定：把这团意大利面抽出来，做成一个独立的包。

2023年8月9日，LiteLLM的第一个版本被推到了PyPI上。

他们大概没有想到，这个为了解决自家代码噩梦而诞生的小工具，三年后会成为全球AI基础设施中最关键——也最危险——的隐形枢纽之一。

"万能转接头"

LiteLLM的核心思想极其简单：用一种格式调用所有大模型。

不管你要调的是OpenAI的GPT、Anthropic的Claude、Google的Gemini、AWS Bedrock上的模型、还是自己部署的vLLM，LiteLLM都把它们统一成OpenAI的API格式。你的代码只需要写一次，切换模型只需要改一个字符串。

这就像一个万能转接头——你带着一个美标插头出国，不管到了英国、日本还是澳大利亚，插上转接头就能用。

但LiteLLM的野心远不止于此。

它迅速从一个Python SDK进化成了一个完整的Proxy Server（代理网关）。你可以把它部署成一个独立服务，所有AI调用都经过它：认证、授权、负载均衡、模型回退、成本追踪、速率限制、日志记录、团队管理、预算控制——一站式解决。

用技术语言说，它的架构是这样的：前面是一个OpenAI兼容的REST端点，后面接PostgreSQL（存配置、密钥、预算、团队信息）和Redis（分布式速率控制），中间是一个路由引擎，根据你的配置把请求分发到不同的模型提供商。你可以把它跑在Docker里、Kubernetes上、AWS ECS里，前面再加一层负载均衡器。

任何能调用OpenAI API的客户端，几乎不改代码就能接到LiteLLM上。

这句话是LiteLLM最强大的武器，也是它最深的隐患。我们后面会回到这一点。

每天340万次下载

LiteLLM的增长速度，用"安静的爆发"来形容最为恰当。

没有铺天盖地的PR稿，没有病毒式传播的推文，没有大佬站台。它的增长完全靠一件事：开发者发现它真的好用。

2023年8月发布，到2025年1月GitHub星标突破1.5万。到2026年初，星标超过2万，PyPI上的下载量达到了一个惊人的数字——每天340万次，每月近1亿次。

根据多家安全厂商的监测，LiteLLM已经出现在约36%的被监控云环境中。

Netflix的AI平台团队公开表示，LiteLLM"为我们节省了数月的工作量"，让他们能在新模型发布后"一天之内"提供给内部用户。保险科技公司Lemonade的GenAI平台首席架构师称赞它"简化了管理多个LLM模型的复杂性"。个人理财应用Rocket Money的团队也在用它统一管理多模型调用。

而这一切，来自一个只融了210万美元的公司。

是的，你没看错。LiteLLM的母公司BerriAI总共只拿到了210万美元——其中160万来自Y Combinator的种子轮，投资方包括Gravity Fund和Pioneer Fund。相比之下，Dify拿了3000万美元Pre-A轮，Manus的融资规模更是天文数字。

210万美元，撬动了一个每天340万次下载、覆盖全球36%云环境的基础设施项目。

这不是资本效率，这简直是资本魔术。

从转接头到总配电室

如果LiteLLM只是一个"万能转接头"，这篇文章就不需要写了。

问题在于，它正在悄悄变成别的东西。

2025年以来，LiteLLM开始大力推进MCP Gateway功能。MCP（Model Context Protocol，模型上下文协议）是Anthropic提出的一套标准，让大模型不仅能"回答问题"，还能"调用工具"——读文件、查数据库、发邮件、操作API。

LiteLLM的MCP Gateway意味着：它不再只是"把你的问题转发给模型"，而是"替你管理模型能发现哪些工具、能调用哪些工具、以谁的身份调用"。

它还支持了Agent（A2A）Gateway，让AI智能体之间的通信也经过它，并追踪每次智能体查询的成本。

加上它原有的功能——虚拟密钥管理、多租户RBAC（基于角色的访问控制）、组织/团队/用户三级权限体系、预算控制、日志审计、流量镜像、Guardrails（安全护栏）——LiteLLM已经不是一个"转发器"了。

它是AI基础设施的控制平面。

用一个比喻来说：如果你的AI系统是一栋楼，LiteLLM正在同时变成这栋楼的总配电室、总门禁和总监控室。电从哪里来（模型提供商）、谁能进哪个房间（权限控制）、每间房用了多少电（成本追踪）、谁在什么时候做了什么（日志审计）——全部经过这一个地方。

这样做当然高效。但一旦这里出事，影响就不是"某个房间灯坏了"。

是整栋楼一起停电。

三月惊雷：一场教科书级的供应链攻击

2026年3月24日，上午10:39 UTC。

一个名为TeamPCP的黑客组织向PyPI推送了LiteLLM v1.82.7。13分钟后，v1.82.8紧随其后。

这两个版本里藏着一个三阶段恶意载荷。

第一阶段：收割。 恶意代码会扫描运行环境中的一切有价值的秘密——SSH密钥、云服务商凭证、Kubernetes令牌、加密货币钱包、.env环境变量文件、数据库密码。然后，把这些数据加密后通过POST请求发送到攻击者控制的域名。

第二阶段：横向扩散。 如果检测到Kubernetes环境，恶意代码会尝试在集群中的每个节点上部署特权Pod，进行横向移动。

第三阶段：持久化。 在受感染的机器上安装一个systemd后门服务，定期轮询攻击者的服务器获取新的指令。更阴险的是，v1.82.8还会在Python环境中植入一个.pth文件——由于Python解释器在启动时会自动加载所有.pth文件，这意味着即使你从未import过litellm，只要Python启动，恶意代码就会执行。

这些恶意版本在PyPI上存活了大约三个小时，然后被紧急隔离。

三个小时。对于一个每天被下载340万次的包来说，这意味着什么？

攻击者是怎么进来的

这起事件最令人不寒而栗的部分，不是恶意载荷本身，而是攻击路径。

TeamPCP没有去破解LiteLLM的密码，没有利用GitHub的漏洞，也没有钓鱼LiteLLM的维护者。他们走了一条更精巧的路：先攻破LiteLLM的安全工具，再用安全工具的权限攻破LiteLLM。

具体来说：LiteLLM的CI/CD流水线（持续集成/持续部署）中使用了Trivy——一个广受欢迎的开源安全扫描器——来做容器镜像的漏洞扫描。然而，LiteLLM在配置中没有固定Trivy的版本号。

TeamPCP先是攻破了Trivy的GitHub Actions工作流，在其中注入了恶意代码。当LiteLLM的CI/CD流水线自动拉取最新版Trivy运行时，被篡改的Trivy从GitHub Actions运行器的环境变量中偷走了PYPI_PUBLISH令牌。

拿到这个令牌后，攻击者就能以LiteLLM官方维护者的身份，直接向PyPI发布任意版本的包。

一个安全扫描器，变成了攻击的入口。守卫变成了内鬼。

Snyk的安全研究员后来用一个精辟的标题总结了这件事："一个被下毒的安全扫描器，如何成为了后门LiteLLM的钥匙。"

这不是一个孤立事件。TeamPCP的攻击链条从Trivy延伸到了Checkmarx的KICS项目，再到LiteLLM——每一次攻击窃取的凭证，都成了打开下一个目标的钥匙。这是一场精心设计的多级供应链攻击，而LiteLLM恰恰因为它在AI生态系统中的枢纽位置，成为了这条链条上最有价值的猎物。

护城河的悖论

LiteLLM面临一个有趣的悖论：它最大的优势，恰恰是它最大的风险来源。

"任何能调用OpenAI API的客户端，几乎不改代码就能接到LiteLLM上"——这种极低的接入摩擦，让它像水一样渗透进了全球的AI基础设施。但也正因为如此，一旦它出问题，波及面几乎无法估量。

而且，LiteLLM面临着真实的技术天花板。

由于底层是Python，受限于GIL（全局解释器锁），在高并发场景下性能会显著下降。有测试显示，当请求量达到每秒2000次时，LiteLLM开始出现超时，内存使用飙升至8GB以上，级联故障随之而来。当数据库日志积累超过100万条后，API请求的响应速度也会明显变慢。

竞争对手正在从这些缝隙中涌入。

Bifrost，用Go语言编写，号称吞吐量比LiteLLM高9.4倍，网关层额外开销仅11微秒——而LiteLLM在1000 RPS下的网关延迟约8毫秒，相差近700倍。

Portkey Gateway，TypeScript编写，GitHub星标1.1万，定位更偏"企业级AI控制平面"，在路由、Guardrails、成本归因方面做得更深，官方宣称已服务200多家企业、每天处理4000亿token的成本归因。

BricksLLM，同样Go语言，走"成本控制+权限治理"路线，更像是"先管好组织边界再说"的思路。

Helicone，Rust编写，核心是一个可观测性平台，网关只是它长出来的一条触手。

这些竞争者代表了三条不同的分化路线：Bifrost/BricksLLM走性能与治理，Portkey走企业级控制平面，Helicone走观测优先。而LiteLLM的路线，至今仍然是统一调用、什么都做。

什么都做的好处是覆盖面广。什么都做的坏处是，你变成了总配电室——所有风险都汇聚到你这里。

210万美元的孤注一掷

让我们回到钱的问题。

210万美元。在2026年的AI创业圈里，这个数字几乎可以忽略不计。一个大模型公司一次训练的电费可能就不止这个数。

但LiteLLM用这210万美元做到了什么？

每天340万次下载。每月近1亿次。出现在36%的被监控云环境中。Netflix、Lemonade、Rocket Money都在用。GitHub 2万多颗星。 覆盖100多个模型提供商的API适配。企业级的RBAC、SSO、审计日志。MCP Gateway。Agent Gateway。Guardrails。

两个创始人，一小撮工程师，210万美元。

这要么说明开源的杠杆效应大得惊人，要么说明全球AI基础设施的一个关键节点，正被一支极度资源有限的团队支撑着。

或者两者皆是。

三月的供应链攻击事件，恰恰暴露了这种结构的脆弱性。LiteLLM的CI/CD流水线里，Trivy没有固定版本号——这不是一个高深的安全失误，而是一个资源有限的小团队在快速迭代中可能犯的最常见的疏忽。当你的todo列表上有一百件事要做、只有几个人在做的时候，"给安全扫描器固定版本号"很容易被排到第一百零一位。

但这个第一百零一位的疏忽，差点把全球36%的云环境变成了攻击者的提款机。

下一个十字路口

LiteLLM正站在一个关键的十字路口。

往左走，是继续当"万能转接头"——保持轻量、保持简单、专注于做好统一调用这一件事。这条路上，Bifrost们的性能优势会持续侵蚀它的领地。

往右走，是全面拥抱"AI控制平面"——把密钥管理、权限控制、MCP Gateway、Agent编排、可观测性、Guardrails全部做深做透。这条路上，它需要更多的资金、更大的团队、更严格的安全实践——而这些恰恰是它目前最缺的。

还有一个更深层的问题：当一个开源项目成为了事实标准的基础设施，但背后的公司只有210万美元的弹药时，谁来为它的安全性买单？

开源软件的悖论在LiteLLM身上体现得淋漓尽致：全世界都在用它，但全世界都没有为它的安全性负责。Netflix用它"节省了数月的工作量"，但Netflix并没有派一支安全团队去审计LiteLLM的CI/CD流水线。Lemonade夸它"简化了复杂性"，但Lemonade并没有帮它固定Trivy的版本号。

每天340万次下载。210万美元融资。一个被攻破的安全扫描器就能让它变成全球AI系统的后门。

这三个数字放在一起，就是2026年AI基础设施最真实的画像。

总配电室的隐喻

让我们回到开头的比喻。

LiteLLM像一座总配电室。它高效、集中、统一。所有的电力（模型调用）、门禁（权限控制）、电表（成本追踪）都从这里经过。管理得好，整栋楼井井有条；管理得差，一次断电就是全面瘫痪。

但真正的问题不在于"该不该建总配电室"——在一个有100多个模型提供商、成千上万个AI应用的世界里，某种形式的统一层几乎是必然的。

真正的问题在于：这座总配电室的钥匙，掌握在一支只有210万美元预算的小团队手里。而这座楼里住着Netflix、Lemonade、Rocket Money，以及全球36%的云环境。

2023年8月，两个年轻人为了摆脱一百行if/else的噩梦，写了一个小工具。

2026年3月，一个黑客组织用一把从安全扫描器偷来的钥匙，差点把这个小工具变成了全球AI系统的特洛伊木马。

这中间只隔了三年。

在AI的世界里，三年足以让一个解决代码洁癖的小工具，长成一个牵动全球基础设施安全的庞然大物。而它的创造者们，可能至今还没有完全意识到，自己手中握着的到底是什么。

或者他们已经意识到了。只是210万美元，能做的实在有限。

参考资料与延伸阅读：

keven 的头像

Posted by:

keven

A wonderer in the forest of knowledge.

留下评论