複数の LLM を呼び出すには、プロバイダー/モデル固有の構成が必要になります。 I/O を統合したとしても、モデル/プロバイダー固有のエッジケースを処理する方法が必要です。
先週、Anthropic がコンテンツ ポリシーに違反したと告げたとき、私たちはこの問題に直面しました。それ以来、私たちはオープンソースプロキシ サーバーを通じて、Claude-2 などの LLM へのコミュニティ アクセスを提供しています。
OpenAI モデレーション エンドポイントを通じてクエリをチェックするとクエリの速度が低下するため、これを Anthropic のモデルでのみ実行したいと考えました。
if model in ["claude-instant-1", "claude-2"]: # run moderations check return litellm.completion(model, messages)
しかし、このような条件付きロジックはバグを引き起こします。私たちは以前にもまさにこの問題に直面しており、この問題を解決するために LiteLLM を構築していました (LLM API 呼び出しを簡素化する抽象ライブラリ)。
tldr;
私たちの解決策は、LiteLLM にこれを処理させ、構成ファイルを通じてそのロジックを制御させることでした。これにより、サーバー コードから条件付きロジックが削除されましたが、それでもプロバイダー/モデル固有の詳細を制御できるようになりました。
これにより、コンテキスト ウィンドウ エラー、最大トークンなどの他のシナリオも処理できるようになりました。
完全なコードは次のとおりです。
import litellm import os config = { "default_fallback_models": ["gpt-3.5-turbo", "claude-instant-1", "j2-ultra"], "model": { "claude-instant-1": { "needs_moderation": True }, "gpt-3.5-turbo": { "error_handling": { "ContextWindowExceededError": {"fallback_model": "gpt-3.5-turbo-16k"} } } } } # set env var os.environ["OPENAI_API_KEY"] = "sk-litellm-5b46387675a944d2" # [OPTIONAL] replace with your openai key os.environ["ANTHROPIC_API_KEY"] = "sk-litellm-5b46387675a944d2" # [OPTIONAL] replace with your anthropic key sample_text = "how does a court case get to the Supreme Court?" * 1000 messages = [{"content": sample_text, "role": "user"}] response = completion_with_config(model="gpt-3.5-turbo", messages=messages, config=config) print(response) # should be gpt-3.5-turbo-16k
設定ファイルは現在以下を管理しています:
時間の経過とともに、最大トークンの設定、プロンプトの書式設定など、他のモデル固有のパラメーターも処理されるようになります。アイデア/提案は大歓迎です。
LiteLLM は、OpenAI ChatCompletion のエンドポイントをドロップインで置き換えることにより、LLM プロバイダーの呼び出しをすでに簡素化しています。
構成ファイルを使用すると、サーバー側のコードを変更せずに、運用環境に新しいモデルを追加できるようになります。
全体として、LiteLLM は、本番環境に非 OpenAI モデルを迅速かつ簡単に追加したい人にとって優れた選択肢です。
私たちはこのプロジェクトの成長に積極的に取り組んでいますので、スキル レベルに関係なく、貢献を歓迎します。不足している機能やバグを見つけた場合、または既存の問題に関与している場合は、問題を報告してください。新しいアップデートが来るたびに私たちの進捗状況を追跡したい場合は、GitHub でスターを付けてください。