LiteLLMことはじめ01:

Transcript

1. LiteLLMことはじめ01: SDKとProxyの違いを理解し、実装コストを削減する
2. 導入: LLM APIの乱立問題 (SDK Hell) 1 現状の課題 → "SDK Hell"（SDK地獄）により開発速度が低下 ▪ SDKの断片化: OpenAI, Anthropic, Vertex AIなど、プロバ イダーごとにインターフェースが異なる。 ▪ スイッチングコスト: モデルを切り替える度にコードの書 き換えが発生。 ▪ 管理の複雑化: 複数のAPIキー、エラーハンドリングの実 装が分散。
3. LiteLLMとは？ (解決策) 2 ユニバーサルアダプター 一言で表すと： 「100以上のLLMをOpenAIフォーマットで統一して呼べるI/F」 ▪ 統一規格: 入出力はすべてOpenAI互換。 ▪ 多対応: Azure, Bedrock, Vertex AI, HuggingFaceなど主要 プロバイダーを網羅。 ▪ 軽量: 依存関係が少なく、既存プロジェクトに導入しやす い。 https://www.litellm.ai/ より
4. 主要機能 1: 統一インターフェース (SDK) 3 コードの標準化 completion()関数一つで完結。モデル名の変更だけでプロバイ ダーを切り替え可能。 ▪ OpenAI形式の引数 (messages, model) ▪ OpenAI形式のレスポンスオブジェクト ▪ 環境変数でAPIキーを管理
5. 主要機能 2: 信頼性の向上 (Reliability) 本番運用に不可欠な「落ちない仕組み」をSDKレベルで提供。 4 Fallbacks メインモデル（例: GPT-4）がダ ウンまたはレート制限にかかった 際、自動的にバックアップ（例: GPT-3.5, Claude）へ切り替え。 Retries 一時的なネットワークエラーや APIタイムアウト時に、設定した 回数だけ自動再試行を実施。 Load Balancing 複数のAPIキーやデプロイメント 間でリクエストを分散させ、ス ループットを最大化。
6. 主要機能 3: LiteLLM Proxy Server 5 SDKから「Gateway」へ コードへの埋め込みではなく、独立したサーバーとして立ち上 げ、全てのLLMリクエストを一元管理。 ▪ 一元管理: チーム全体のLLMアクセス窓口を統一。 ▪ 認証機能: 独自のVirtual Keysを発行・管理。 ▪ 予算管理: プロジェクト/ユーザー毎の予算上限設定。
7. 可観測性 (Observability) 6 ブラックボックス化を防ぐ LLMアプリの入出力を可視化し、コストと品質をモニタリン グ。 ▪ 簡単連携: config.yamlに追記するだけで、Langfuse, Datadog, Slackなどへログ送信。 ▪ コスト分析: 誰が、どのモデルを、どれくらい使ったかを 追跡。 ▪ デバッグ: 失敗したリクエストの詳細ログを確認可能。
8. Q & A ご清聴ありがとうございました。