Caret 路由：我们为什么从 LiteLLM 迁移到 any-llm

在 Caret 设计 LLM 路由时，对我们来说最重要的是**“我们可以控制的简单性”。** 模型不断增加，供应商不断变化，需求不断增长——而且我们已经不止一次地了解到，如果路由器也变得过于繁重，运营复杂性最终会吞噬产品速度。

我们使用 LiteLLM 一段时间了。从功能上讲，它非常出色并且构建得很好。 但随着时间的推移，很明显，它的某些部分并不适合 Caret 的发展方向或我们在生产中的运营方式。 所以我们将路由器从 LiteLLM → any-llm 切换了。

这不是“比较评论”，而是我们为什么要切换——以及切换后会发生什么的记录。

---

1. LiteLLM 太复杂，Caret 不需要它的许多功能

LiteLLM 更接近于 AI 网关 / 代理服务器，而不是简单的 SDK。 多租户、虚拟密钥、组织管理、预算控制、日志记录、警报、数据库集成…… 在“企业环境”中，这些无疑是强大的优势。

问题是 Caret 的路由器不需要那种功能集。

• 更改路由器会引入 DB、worker 设置和运营参数
• 我们必须维护一个包含我们不使用的功能的结构
• 最终，“运营路由器”变得比“路由 LLM”更重要

因此，LiteLLM 对于 Caret 来说是一个沉重的选择，不是因为它缺少功能，而是因为它有太多的功能。

---

2. any-llm 精简且易于扩展

我们选择 any-llm 的最大原因很简单。

“路由器应该很薄。”

any-llm 从根本上说是一个专注于干净的 API 接口的库。

• 它不会强迫你进入代理服务器
• 它专注于抽象模型调用
• 结构简单，因此很容易在代码级别理解

这不仅仅是“轻量级”——这意味着 我们可以自然地将其嵌入到我们的服务架构中。

对于我们来说，希望路由器成为 Caret 平台的内部组件 而不是独立的服务器，这是决定性的。

---

3. 我们可以以适合 Caret 的方式扩展 any-llm 没有提供的功能

使用 LiteLLM 最困难的部分之一是 “将 Caret 放入已经决定的结构中”。

在迁移到 any-llm 之后，我们的方法完全改变了。

路由器进行路由——我们构建其他一切。

因此，我们可以添加 any-llm 中没有但对 Caret 至关重要的功能——以我们自己的方式。

• 配置文件管理
• 账单/付款
• API 密钥管理
• 信用管理
• 社交登录和身份验证

这些功能不应在路由器级别强制执行； 它们需要与 Caret 的业务逻辑自然集成。

感谢 any-llm 简单的 API 结构， 这种扩展变得容易得多。

---

4. 因为 any-llm 仅提供 API，所以我们可以完全自由地构建 UI

LiteLLM 更接近于“包含管理 UI 的平台”。 但 Caret 已经有自己的 UX 和设计理念。

any-llm 根本不强加任何 UI。

• 仅提供 API
• 服务完全决定 UI/UX

这让我们设计了：

• 与 Caret 用户流程对齐的 UI
• 信用、付款和密钥管理自然连接的屏幕
• LLM 功能感觉像“工具”的体验

——没有约束。

不是路由器定义 UX， 而是产品包装路由器。

---

5. any-llm 还使以后使用 Go 提高性能变得更容易

从长远来看，Caret 关心性能和成本效益。 特别是路由器层是流量集中的地方。

因为 any-llm 的结构很简单：

• 它没有锁定到特定的语言/运行时
• 稍后用 Go 重建它——或用 Go 组件替换部分——是一个现实的选择

如果我们与假设重型代理服务器的设计相关联，那么这将是一个更难的决定。 使用基于 any-llm 的结构，我们可以保持性能策略的灵活性。

---

6. 我们将在清理干净后开源它

当我们从 LiteLLM 迁移到 any-llm 并自己添加 Caret 特定的功能时，一件事变得很清楚。

这种结构太好了，不能只留给我们自己。

所以我们目前正在清理代码， 一旦准备好，我们将将其作为开源发布。

• 基于 any-llm 的路由架构
• 我们在 Caret 中实际使用的扩展模式
• 运行它的运营经验

我们正在寻找想要一起思考和构建的开发人员。 我们希望它成为一个我们一起成长的基础，而不是一个“完成的框架”。

---

总结

这种切换并不是说“LiteLLM 不好”。 LiteLLM 仍然是一个很棒的工具，并且非常适合许多团队。

但对于 Caret，我们需要：

• 更薄的路由器
• 更多的扩展自由
• 更清晰的责任分离

而 any-llm 是满足这些需求的选项。

这种选择会导致什么，将通过持续的运营和开源过程变得更加清晰。

我们很快就会让代码说话。