2025年12月13日Anthony.Kim
Caret Router: LiteLLMからany-llmへの移行理由
LiteLLMは強力でしたが、Caretにとっては過度に重く複雑なルーターでした。any-llmは、その無駄のないAPIファーストな設計により、Caretが本当に必要とする機能のみを拡張できました。これにより、CaretネイティブのUXと運用構造を構築し、将来のパフォーマンス向上にも備えることができました。

CaretでLLMルーターを設計する際、私たちにとって最も重要なことは**「制御可能なシンプルさ」**でした。 モデルは増え続け、ベンダーは変わり、要件は増大します。そして、ルーターが重すぎると、運用上の複雑さが製品の速度を低下させることを何度も学びました。
しばらくの間、LiteLLMを使用していました。機能的には優れており、非常によく構築されています。 しかし、時間が経つにつれて、その一部がCaretの進むべき方向や、本番環境での運用方法に適合しないことが明らかになりました。 そこで、ルーターをLiteLLM → any-llmに切り替えました。
これは「比較レビュー」ではなく、切り替えた理由と、切り替え後に何が可能になったかの記録です。
1. LiteLLMは複雑すぎ、Caretはその多くの機能を必要としなかった

LiteLLMは、単純なSDKというよりはAIゲートウェイ/プロキシサーバーに近いものです。 マルチテナント、仮想キー、組織管理、予算管理、ロギング、アラート、データベース統合... 「エンタープライズ環境」では、これらは間違いなく強力な利点です。
問題は、Caretのルーターがそのような機能セットを必要としなかったことです。
- ルーターの変更により、DB、ワーカーのセットアップ、および運用パラメータが追加された
- 使用しない機能を含む構造を維持する必要があった
- 結局、「LLMのルーティング」よりも「ルーターの運用」が重要になる
その結果、LiteLLMは機能が不足しているからではなく、機能が多すぎるために、Caretにとって重い選択肢となりました。
2. any-llmは無駄がなく、拡張が容易だった

any-llmを選択した最大の理由は単純です。
「ルーターは薄くあるべきだ」
any-llmは、基本的にクリーンなAPIインターフェースに焦点を当てたライブラリです。
- プロキシサーバーに強制されることはない
- モデル呼び出しの抽象化に焦点を当てている
- 構造が単純なので、コードレベルで理解しやすい
これは単に「軽量」であるということではありません。つまり、 サービスアーキテクチャに自然に組み込むことができます。
ルーターをスタンドアロンサービスとしてではなく、Caretプラットフォームの内部コンポーネントにしたいと考えていた私たちにとって、これは決定的なものでした。
3. any-llmが提供しないものを、Caretに合うように拡張できた

LiteLLMの使用で最も難しかったことの1つは、 「すでに決定された構造に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固有の機能自体を追加するにつれて、1つのことが明らかになりました。
この構造は、私たちだけで保持するには良すぎます。
そこで、現在コードをクリーンアップしており、 準備ができたらオープンソースとしてリリースします。
- any-llmベースのルーティングアーキテクチャ
- Caretで実際に使用する拡張パターン
- 実行からの運用上の学習
私たちは、一緒に考え、構築したい開発者を探しています。 「完成したフレームワーク」ではなく、一緒に成長する基盤になることを願っています。
終わりに
この切り替えは「LiteLLMが悪い」と言っているわけではありません。 LiteLLMは依然として優れたツールであり、多くのチームに適しています。
しかし、Caretにとって、私たちが必要としていたのは:
- より薄いルーター
- 拡張する自由度
- 責任の明確な分離
そして、any-llmはそれらのニーズに一致するオプションでした。
この選択が何につながるかは、継続的な運用とオープンソースプロセスを通じてより明確になります。
すぐにコードで語らせます。
More posts

Type next instructions while AI is streaming, cancel with a single ESC press. Also includes Gemini 3.1 Pro Support, Direct VSIX Download, CLI sub-agent execution, and v0.4.7 infinite loading fix.

Careti v0.4.7でZ.AI GLM-4.7モデル、Claude Code互換コマンドシステム、SmartEditEngine改善、UI改善を追加しました。
