LiteLLM 的 Rust 核心化：当 Python 网关把热路径交给 Rust

研究对象：BerriAI/litellm
抓取日期：2026-10-09 ｜ 当日 stars：+95
语言：Python + Rust ｜ 许可证：MIT
GitHub：https://github.com/BerriAI/litellm

一个 Python 项目的"心脏移植"

2026 年 7 月，LiteLLM 做了一件很多 Python 项目都在做但很少做到底的事：把核心热路径用 Rust 重写，同时保持 Python SDK 的 API 一字不改。

这不是"用 Rust 重写整个项目"。LiteLLM 的迁移策略更精确：只换心脏，不换皮肤。Python SDK 的 import litellm 还是那个 import，completion() 还是那个 completion，但底下跑的代理服务器——处理路由、认证、负载均衡、日志的那一层——正在逐步换成 Rust 实现。

官方在 2026 年 7 月的文档里写道："We are launching an early beta of the LiteLLM AI Gateway in Rust, and we built AIGatewayBench to measure it。" 他们甚至专门造了一个基准测试工具来衡量迁移效果——这本身就是一种工程严肃性的信号。

为什么不是全量重写？

LiteLLM 的迁移路线图透露出一种克制的工程哲学：

• OCR 路由：2026 年 8 月中旬
• /chat/completions 和 /messages：2026 年 9 月
• 完整路由层：之后

不是一次性推倒重来，而是按路由类型逐个迁移。每个阶段都有 Rust 实现接管一部分流量，Python 实现继续兜底。用户可以在两种后端之间切换，对比性能和正确性。

这种"渐进式核心化"的模式，和 Node.js 当年的策略如出一辙：V8 引擎用 C++ 写核心，JS 层保持 API 不变。也像 CPython 本身——Python 语法不变，但解释器循环用 C 实现。用户感知到的 API 是稳定的，但底层的执行效率在悄悄变化。

8ms P95 的含义

LiteLLM 官方给出的性能数据是：8ms P95 延迟，在 1000 RPS（每秒请求）的负载下。

这个数字需要放在上下文里理解。一个 LLM 网关的延迟构成大致是：

1. 网关自身开销：解析请求、路由匹配、认证、日志
2. 上游 LLM 延迟：模型推理时间（通常 200ms-2s）

大多数 LLM 网关的自身开销在 20-50ms 量级。LiteLLM 的 Rust 核心把它压到 8ms，意味着网关开销占整个请求生命周期的比例从 5-10% 降到了 1-2%。对于做大量小请求的场景（比如 Agent 系统的频繁调用），这个差距会累积成显著的成本差异。

但更重要的是长尾稳定性。P95 延迟低意味着 95% 的请求都在 8ms 以内完成，不会出现 Python GIL 导致的尾部延迟尖峰。在 1000 RPS 下保持 P95 稳定，是 Rust 的无 GCU 并发模型相对于 Python asyncio 的核心优势。

100+ LLM 的统一接口

LiteLLM 的核心价值主张从一开始就没变：一个 API 调 100+ 个 LLM 提供商。OpenAI、Anthropic、Gemini、Bedrock、Azure、VertexAI、vLLM、Nvidia NIM——全部用 OpenAI 兼容格式调用。

这个价值主张在 2026 年比以往任何时候都重要。原因：

1. 模型选择爆炸：2026 年每月都有新模型发布，每个模型有不同的 API 格式、认证方式、能力边界
2. Agent 系统的混排需求：一个 Agent 可能需要 Claude 做推理、GPT 做代码、Gemini 做长上下文——这些调用要在一个统一框架下管理
3. 成本优化：不同模型的价格差异巨大，网关层做路由可以实现成本/质量的最优分配

Rust 核心化让这个统一层不仅"能用"而且"快"。在 Agent 系统里，一次任务可能触发 10-50 次 LLM 调用，网关延迟的每 1ms 都会被放大 10-50 倍。

litellm-core：一个有趣的架构选择

LiteLLM 最近还做了一个架构拆分：发布了一个独立的 litellm-core 发行版。这个版本只包含 Python SDK，没有 CLI、没有代理服务器、没有可选依赖。

为什么这很重要？因为很多用户只需要 SDK 做库级别的集成，不需要部署整个代理服务器。过去他们 pip install litellm 会拉下一堆依赖（FastAPI、Pydantic、各种数据库驱动）。现在 litellm-core 提供了一个极简选择：只有 import litellm 和运行时依赖。

这背后是一个更深的趋势：Python 包的"分层发行"。同一个项目提供"完整版"和"核心版"两个 wheel，让用户按需选择。类似 Rust 生态里 serde 的 feature flags，但更彻底——直接分成两个包。

Netflix 在用，但不是因为 Rust

LiteLLM 的采用者列表里有 Netflix。但值得注意的是，Netflix 采用 LiteLLM 的时候，Rust 核心还没上线。他们用的是 Python 版本。

这说明什么？用户选择 LiteLLM 是因为 API 统一和功能完整，不是因为底层语言。Rust 核心化是锦上添花——让已经在用的用户获得性能提升，让还在犹豫的用户打消延迟顾虑。但它不是 LiteLLM 的核心卖点。

核心卖点是：100+ LLM 提供商，一个 API，OpenAI 格式。Rust 只是让这个承诺跑得更快。

"热路径迁移"模式

LiteLLM 的 Rust 核心化代表了一个在 2026 年越来越常见的模式：Python 项目不重写，只迁移热路径。

这个模式的逻辑是：

1. Python 的优势在 API 设计和生态：用户习惯、文档、示例都是 Python
2. Python 的劣势在 CPU 密集型任务：GIL、解释器开销、内存管理
3. Rust 的优势在性能和安全性：零成本抽象、无 GIL、内存安全
4. 解法：保持 Python API 不变，把 CPU 密集的路由/解析/序列化层用 Rust 重写

这不是新概念——NumPy 早在 2006 年就这么做了（C 核心 + Python 接口）。但 2026 年的区别是：PyO3 和 maturin 让 Rust-Python 互操作变得极其简单。以前写 C 扩展需要处理引用计数、GIL、类型对象，现在用 PyO3 写 Rust 扩展几乎是声明式的。

LiteLLM 不是第一个这么做的，也不会是最后一个。但它的迁移路线图——按路由类型逐步切换、用基准测试验证、保持 API 不变——为其他 Python 项目提供了一个可参考的模板。

对 Agent 系统的意义

Agent 系统是 LLM 网关的重度用户。一个 Agent 任务可能涉及：

• 规划：调用 LLM 生成步骤
• 执行：每步调用工具，工具可能再调 LLM
• 反思：调用 LLM 评估结果
• 记忆：调用 embedding 模型

这些调用可能指向不同的模型提供商，需要不同的认证和路由策略。网关层的性能和可靠性直接影响 Agent 的端到端延迟。

LiteLLM 的 Rust 核心化对 Agent 系统的意义在于：网关不再是瓶颈。当 Agent 的 LLM 调用频率从每分钟几次提升到每秒几十次时，网关的 P95 延迟从 30ms 降到 8ms 意味着 Agent 的响应时间可以缩短 200-500ms——这在交互式场景里是用户可感知的差异。

结语

LiteLLM 的 Rust 核心化不是"Python vs Rust"的叙事。它是一个关于在正确的地方使用正确的工具的实践：Python 做 API 层，Rust 做执行层，用户什么都不用改。

2026 年的趋势已经很清楚：不是"用 Rust 重写一切"，而是"用 Rust 重写热路径"。LiteLLM 给出了一个可操作的模板——渐进式迁移、基准测试驱动、API 零破坏。这个模板比任何"Rust vs Python"的口水战都有价值。

GitHub：https://github.com/BerriAI/litellm
文档：https://docs.litellm.ai