Posted inAI

LiteLLMでローカルAIゲートウェイを構築：OpenAI、Anthropic、Ollamaを集約する

AI tutorial - IT technology blog
AI tutorial - IT technology blog

直接連携 vs AIゲートウェイ：どちらを選択すべきか？

AIアプリの開発は、通常1つのOpenAI APIキーから始まります環境変数に設定するだけで、すべてが機能します。しかし、より高度な推論のためにClaudeを追加したり、プライバシーのためにローカルのLlama 3インスタンスを追加しようとした瞬間、コードベースは競合するSDKや重複したエラーハンドリングの山と化してしまいます。

直接連携の構成では、アプリは各プロバイダーと個別に通信します。もし午前2時にOpenAIがレート制限に達した場合、サービスは停止してしまいます。そのため、AnthropicやGeminiへのフォールバックロジックを手動で実装せざるを得なくなります。また、APIキーや利用データが異なるプラットフォームに分散するため、コスト管理も大きな負担となります。

AIゲートウェイはこのアーキテクチャを劇的に変えます。アプリケーションは、標準的なOpenAI形式を使用して、単一の内部エンドポイントと通信します。ゲートウェイはその中間に位置し、ルーティング、リトライ、認証を処理します。これはスマートなトラフィックコントローラーとして機能し、その瞬間に最も高速、あるいは最も安価なプロバイダーへリクエストを振り分けます。

プロキシ優先アーキテクチャの現実的なトレードオフ

技術スタックに新たなレイヤーを追加するのは大きな決断です。本番環境におけるメリットとデメリットを整理しましょう。

メリット

  • 統合API： OpenAI SDKを使用して一度コードを書くだけで済みます。GPT-4oを呼び出す場合でも、Ollama経由でローカルモデルを呼び出す場合でも、構文は変わりません。
  • 仮想キー： マスターのAnthropicキーを共有する必要はありません。代わりに、特定の開発者や機能向けに、有効期限付きの「仮想キー（Virtual Keys）」を発行できます。
  • 自動フェイルオーバー： GPT-4oが500エラーを返した場合、LiteLLMは即座にリクエストをClaude 3.5 Sonnetに転送します。ユーザーはその瞬断に気づくことさえありません。
  • 詳細なトラッキング： トークンの使用状況を明確に把握できます。どの機能がリアルタイムで予算を消費しているかを正確に特定できます。

デメリット

  • 運用オーバーヘッド： ゲートウェイは重要なインフラの一部となります。これがダウンすると、AI機能全体が停止します。そのため、高可用性（HA）構成でのデプロイが不可欠です。
  • わずかなレイテンシ： プロキシを経由することで、約5〜15msのネットワークオーバーヘッドが発生します。LLMの平均的なレスポンスに1,000ms以上かかることを考えれば、この遅延はエンドユーザーにはほとんど体感できません。

本番環境に耐えうるアーキテクチャ

安定したセットアップのために、PostgreSQLデータベースをバックエンドに備えたDockerコンテナとしてLiteLLMを実行します。データベースはこの運用の「頭脳」です。仮想キーの保存、利用制限の追跡、デバッグのための全リクエストのログ記録を行います。これがないと、LiteLLMはステートレスモードで動作することになり、クイックデモには適していますが、スケーリングするビジネスにおいてはリスクとなります。

このセットアップによってチームが大幅なコスト削減を実現した例を何度も見てきました。あるプロジェクトでは、月間のAPIコストを30%削減しました。これは、単純な分類タスクをローカルのLlama 3インスタンスにルーティングし、GPT-4oのような高価なモデルは複雑な推論タスクのみに限定することで実現しました。

ステップバイステップの実装ガイド

OpenAI、Anthropic、そしてローカルのOllamaインスタンスを同時に管理するLiteLLMプロキシを構築しましょう。

1. モデルルーティングの設定

LiteLLMのすべてはconfig.yamlファイルを中心に動きます。ここで、内部モデル名と実際のプロバイダーをマッピングします。litellm_config.yamlという名前でファイルを作成します。

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: "os.environ/OPENAI_API_KEY"

  - model_name: claude-3-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20240620
      api_key: "os.environ/ANTHROPIC_API_KEY"

  - model_name: local-llama
    litellm_params:
      model: ollama/llama3
      api_base: "http://host.docker.internal:11434"

router_settings:
  routing_strategy: simple-shuffle
  set_verbose: True

2. Docker Composeでの起動

Docker Composeを使用することで、ゲートウェイとデータベースの同期を維持できます。サービスを管理するためのdocker-compose.ymlファイルを作成します。

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    environment:
      - OPENAI_API_KEY=sk-your-key
      - ANTHROPIC_API_KEY=sk-ant-key
      - DATABASE_URL=postgresql://user:pass@db:5432/litellm
    command: ["--config", "/app/config.yaml"]
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=litellm
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

docker-compose up -dを実行します。これでゲートウェイがhttp://localhost:4000でリクエストを待ち受けるようになります。

3. スマートなフォールバックの設定

複数のプロバイダーを1つのエイリアスにグループ化して、高可用性を確保できます。1つのプロバイダーが失敗すると、ゲートウェイはリスト内の次のプロバイダーを自動的に試行します。

model_list:
  - model_name: high-reliability-model
    litellm_params:
      model: openai/gpt-4o
  - model_name: high-reliability-model
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20240620

router_settings:
  routing_strategy: latency-based-routing
  enable_fallbacks: True

これで、アプリはhigh-reliability-modelをリクエストするだけでよくなります。LiteLLMが最もレスポンスの良いプロバイダーを選択するという面倒な作業を代行してくれます。

4. アプリケーションの接続

ゲートウェイのテストは簡単です。標準的なcURLコマンドを使用して、正しくルーティングされているか確認できます。

curl --request POST \
  --url http://localhost:4000/chat/completions \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "なぜゲートウェイを使用するのですか？"}]
  }'

Pythonでは、base_urlを更新するだけです。それ以外のOpenAI互換コードはそのまま利用できます。

from openai import OpenAI

client = OpenAI(
    api_key="sk-anything", # ゲートウェイがこれを検証します
    base_url="http://localhost:4000"
)

response = client.chat.completions.create(
    model="claude-3-sonnet",
    messages=[{"role": "user", "content": "プロキシパターンについて説明してください。"}]
)

print(response.choices[0].message.content)

予算の強化とモニタリング

トラフィックがゲートウェイを経由するようになれば、組み込みのUI（通常は/ui）にアクセスして支出を管理できます。開発（Development）、ステージング（Staging）、本番（Production）の各環境に対して、個別の仮想キーを作成することをお勧めします。

予算管理こそが、ゲートウェイの真骨頂です。開発用キーに50ドルのmax_budgetを設定できます。もし開発者が誤ってAPIを連打する再帰ループを発生させてしまっても、ゲートウェイがサーキットブレーカーとして機能します。制限に達するとそれ以降のリクエストをすべてブロックし、次回のクレジットカード明細で1,000ドルの請求に驚くような事態を防ぎます。

この一元管理戦略により、毎朝3つの異なる請求ダッシュボードをチェックする必要がなくなります。代わりに、AIインフラ全体のための1つの中央司令塔を手にすることができます。どこでいくら使われているかを正確に把握できれば、運用のスケーリングもはるかにストレスの少ないものになります。

Share:
Tags: