LiteLLM完全ガイド｜100モデル統合・LLMルーティング・コスト最適化

2026.05.05 公開 26分で読める

この記事の結論

LiteLLMはOpenAI/Anthropic/Bedrock等100モデルを統合するOSSゲートウェイ。ルーティング・Fallback・コスト追跡・Proxy構築まで実装コード付きで解説。

「モデルを切り替えるたびに、APIクライアントのコードを書き直している…」

マルチプロバイダー構成のLLMシステムを運用していると、こんな状況は日常茶飯事です。OpenAIで動いていたコードをAnthropicに切り替えようとしたら、メソッド名もレスポンス構造も全然違う。AWSのBedrockを使うにはSDKがまた別物で、Azure OpenAIには独自のAPIバージョン指定が必要——。

実際に10社以上のAIエージェント導入を支援する中で気づいたのは、「モデルの切り替えコストが高すぎて、最適なモデルを試せていない」という問題でした。そこで解決策として毎回紹介するのが LiteLLM です。100以上のLLMプロバイダーを統一インターフェースで扱えるOSSのAIゲートウェイで、GitHub Stars 45.7k（2026年5月時点）という実績が示すとおり、事実上の業界標準ツールです。

この記事では、LiteLLMの基本から本番環境でのProxy Server構築、ルーティング戦略の実装まで、コピペ可能なコード・設定例つきで全公開します。

LiteLLMとは｜アーキテクチャ概要

LiteLLMはBerriAIが開発するOSSのLLMゲートウェイです。2つの使い方があります。

Python SDK：コード内でimportして使う軽量ライブラリ
Proxy Server（AI Gateway）：OpenAI互換のHTTPエンドポイントを自ホスト

どちらも「litellm.completion()を一度書けば、モデル名だけ変えれば他プロバイダーに切り替えられる」というコンセプトを共有しています。

対応プロバイダー（抜粋）

プロバイダー	モデル例	prefix
OpenAI	gpt-4o, o3-mini	`openai/`
Anthropic	claude-3-7-sonnet, claude-3-5-haiku	`anthropic/`
Google Vertex AI	gemini-2.0-flash, gemini-2.5-pro	`vertex_ai/`
AWS Bedrock	claude, llama3, titan	`bedrock/`
Azure OpenAI	GPT-4o（デプロイ名指定）	`azure/`
Groq	llama3-70b, mixtral	`groq/`
HuggingFace	各種OSS LLM	`huggingface/`
vLLM（ローカル）	任意のモデル	`openai/`（base_url指定）

公式ドキュメントによれば100以上のプロバイダーに対応しており、Chat Completions、Embeddings、Image Generation、Audio処理、Batch APIまでカバーしています。

インストール｜pip vs Docker

pip（SDK単体）

最も手軽な方法はpipでのインストールです。動作環境：Python 3.8+

# SDK のみ
pip install litellm

# Proxy Server 機能を含む場合
pip install 'litellm[proxy]'

# または uv を使う場合（推奨・高速）
uv add litellm
uv tool install 'litellm[proxy]'

Docker（Proxy Server）

本番環境では公式Dockerイメージを使うのが安全です。

# config.yaml を用意した上で起動
docker run -d 
  -p 4000:4000 
  -v $(pwd)/config.yaml:/app/config.yaml 
  -e OPENAI_API_KEY=$OPENAI_API_KEY 
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY 
  ghcr.io/berriai/litellm:main-latest 
  --config /app/config.yaml

これだけで http://localhost:4000 にOpenAI互換のエンドポイントが立ち上がります。

Proxy Server起動 vs SDK直接利用の使い分け

どちらを選ぶかは、チームの規模と運用要件で決まります。

観点	SDK直接利用	Proxy Server
セットアップ	即座（pip install のみ）	Docker/サーバー管理が必要
対象	個人・小チーム・プロトタイプ	複数チーム・本番環境
APIキー管理	アプリ側で各自管理	Proxy側で一元管理（Virtual Keys）
コスト追跡	コールバック経由で可能	Admin UIで全チームのコストを可視化
ルーティング	Router クラスで実装	config.yaml で宣言的に設定
既存コードの移行	コード変更が必要	base_url を変えるだけで移行ゼロ

ポイント：個人や小規模プロジェクトではSDKで十分ですが、複数チームがLLMを使う組織ではProxy Serverを中央集権的に置くことで、APIキー漏洩リスクを下げながらコスト管理が劇的に楽になります。

SDK の基本的な使い方

# 動作環境: Python 3.8+, litellm>=1.30.0
import litellm
import os

# 環境変数に各プロバイダーのAPIキーを設定
# OPENAI_API_KEY, ANTHROPIC_API_KEY など

# OpenAI
response = litellm.completion(
    model="gpt-4o",
    messages=[{"role": "user", "content": "AIエージェントの設計パターンを教えて"}],
)
print(response.choices[0].message.content)

# モデル名を変えるだけで Anthropic に切り替え
response = litellm.completion(
    model="anthropic/claude-3-7-sonnet-20250219",
    messages=[{"role": "user", "content": "AIエージェントの設計パターンを教えて"}],
)
print(response.choices[0].message.content)

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

モデル統合｜YAML設定とProxy起動

Proxy Serverの設定はすべて config.yaml に集約します。以下はOpenAI/Anthropic/Bedrock/Azureの4プロバイダーを統合する実践的な例です。

# config.yaml
model_list:
  # OpenAI
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  # Anthropic
  - model_name: claude-3-7-sonnet
    litellm_params:
      model: anthropic/claude-3-7-sonnet-20250219
      api_key: os.environ/ANTHROPIC_API_KEY

  # AWS Bedrock（クロスリージョン推論）
  - model_name: bedrock-claude-3-5-sonnet
    litellm_params:
      model: bedrock/us.anthropic.claude-3-5-sonnet-20241022-v2:0
      aws_access_key_id: os.environ/AWS_ACCESS_KEY_ID
      aws_secret_access_key: os.environ/AWS_SECRET_ACCESS_KEY
      aws_region_name: us-east-1

  # Azure OpenAI
  - model_name: azure-gpt-4o
    litellm_params:
      model: azure/gpt-4o-deployment
      api_base: https://your-resource.openai.azure.com/
      api_version: "2024-08-01-preview"
      api_key: os.environ/AZURE_API_KEY

  # ローカルvLLM（OpenAI互換エンドポイント）
  - model_name: local-llama
    litellm_params:
      model: openai/meta/llama-3-70b-instruct
      api_base: http://localhost:8000/v1
      api_key: dummy

litellm_settings:
  num_retries: 3
  request_timeout: 60

general_settings:
  master_key: sk-my-secret-key  # Proxy認証用

# Proxy 起動
litellm --config config.yaml --port 4000

# クライアントからの呼び出し（既存の OpenAI コードをそのまま流用可能）

# 動作環境: openai>=1.0.0
import openai

client = openai.OpenAI(
    api_key="sk-my-secret-key",
    base_url="http://localhost:4000"
)

# base_url を変えるだけ。コードの変更は一切不要
response = client.chat.completions.create(
    model="claude-3-7-sonnet",  # config.yaml の model_name を指定
    messages=[{"role": "user", "content": "Hello from LiteLLM Proxy!"}]
)
print(response.choices[0].message.content)

Routing戦略｜least-busy / cost-aware / latency-based

LiteLLMの最も強力な機能の一つが、Router クラスによるインテリジェントなルーティングです。同一 model_name に複数のデプロイメントを登録することで、様々な戦略でリクエストを分散できます。

利用可能なルーティング戦略

戦略名	説明	推奨用途
`simple-shuffle`	ランダム分散（デフォルト）	本番環境の基本（最低オーバーヘッド）
`least-busy`	同時処理数が最小のデプロイへ	バースト負荷の均等化
`latency-based-routing`	過去の応答時間が最短のデプロイへ	レイテンシ最重視のユーザー向け機能
`cost-based-routing`	LiteLLM内蔵の料金DBで最安値を選択	コスト最適化・非リアルタイム処理
`usage-based-routing-v2`	TPM/RPM上限未満のデプロイへ（Redis必須）	レート制限の分散

least-busy（最小同時接続数）

# 動作環境: Python 3.8+, litellm>=1.30.0
import asyncio
import os
from litellm import Router

model_list = [
    {
        "model_name": "gpt-4o",
        "litellm_params": {
            "model": "openai/gpt-4o",
            "api_key": os.getenv("OPENAI_API_KEY"),
        },
    },
    {
        "model_name": "gpt-4o",
        "litellm_params": {
            "model": "azure/gpt-4o-deployment",
            "api_base": os.getenv("AZURE_API_BASE"),
            "api_key": os.getenv("AZURE_API_KEY"),
            "api_version": "2024-08-01-preview",
        },
    },
]

router = Router(model_list=model_list, routing_strategy="least-busy")

async def main():
    response = await router.acompletion(
        model="gpt-4o",
        messages=[{"role": "user", "content": "処理中のリクエストが少ない方に回してください"}],
    )
    # どちらのデプロイが選ばれたか確認
    print(response._hidden_params.get("model_id"))

asyncio.run(main())

latency-based-routing（レイテンシ最小化）

# routing_strategy_args でキャッシュ期間と許容バッファを設定
router = Router(
    model_list=model_list,
    routing_strategy="latency-based-routing",
    routing_strategy_args={
        "ttl": 10,                  # 10秒間の応答時間キャッシュ
        "lowest_latency_buffer": 0.3  # 最速の 1.3倍以内を候補に含める
    }
)

cost-based-routing（コスト最安値）

# LiteLLM の料金DBに基づいて最安値デプロイを自動選択
model_list_with_cost = [
    {
        "model_name": "my-model",
        "litellm_params": {"model": "gpt-4o"},
        "model_info": {"id": "openai-gpt-4o"},  # IDを明示
    },
    {
        "model_name": "my-model",
        "litellm_params": {"model": "groq/llama3-70b-8192"},
        "model_info": {"id": "groq-llama3-70b"},
    },
]

router = Router(
    model_list=model_list_with_cost,
    routing_strategy="cost-based-routing"
)

# → groq-llama3-70b が選ばれることが多い（gpt-4o より大幅に安価）
async def cost_aware():
    resp = await router.acompletion(
        model="my-model",
        messages=[{"role": "user", "content": "バッチ処理用のリクエストです"}],
    )
    print(resp._hidden_params.get("model_id"))  # groq-llama3-70b

asyncio.run(cost_aware())

モデルごとに異なる戦略を使うRouting Groups

# リアルタイム応答が必要な gpt-4o はレイテンシ重視
# バッチ処理の my-model はコスト重視
router = Router(
    model_list=[...],
    routing_strategy="simple-shuffle",  # デフォルト
    routing_groups=[
        {
            "group_name": "latency-sensitive",
            "models": ["gpt-4o"],
            "routing_strategy": "latency-based-routing",
            "routing_strategy_args": {"ttl": 3600},
        },
        {
            "group_name": "cost-sensitive",
            "models": ["my-model"],
            "routing_strategy": "cost-based-routing",
        },
    ],
)

Fallback / Retry設定

本番環境では「プロバイダーが一時的に落ちる」「レート制限に引っかかる」という事態が必ず発生します。LiteLLMはフォールバックと指数バックオフリトライを標準でサポートしています。

config.yaml でのFallback設定

# config.yaml（Proxy Server用）
router_settings:
  num_retries: 3
  timeout: 60
  allowed_fails: 3        # 1分あたり3回失敗でクールダウン
  cooldown_time: 60        # クールダウン期間（秒）

  # モデルレベルのフォールバック
  fallbacks:
    - {"gpt-4o": ["claude-3-7-sonnet", "bedrock-claude-3-5-sonnet"]}
    - {"claude-3-7-sonnet": ["gpt-4o"]}

  # コンテキスト長超過時のフォールバック（自動）
  context_window_fallbacks:
    - {"gpt-4o": ["gpt-4o-mini"]}

  # 例外種別ごとのリトライ設定
  retry_policy:
    AuthenticationErrorRetries: 0    # 認証エラーはリトライしない
    TimeoutErrorRetries: 3
    RateLimitErrorRetries: 3
    ContentPolicyViolationErrorRetries: 0
    InternalServerErrorRetries: 2

Python SDK でのFallback設定

import litellm

# 単発のリクエストにフォールバックを追加
response = litellm.completion(
    model="gpt-4o",
    messages=[{"role": "user", "content": "テスト"}],
    fallbacks=["anthropic/claude-3-7-sonnet-20250219", "groq/llama3-70b-8192"],
    num_retries=2,
    timeout=30,
)

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

Prompt Caching統合

Prompt Cachingを使うと、同じプレフィックスのトークンをキャッシュして再利用できます。公式ドキュメントによれば、適切に設定すればキャッシュヒット時のコストを最大90%削減できます。

注意点として、Anthropicのモデルはキャッシュ書き込み時にコストが発生します。同一プレフィックスを繰り返し使うバッチ処理や長いシステムプロンプトを持つ会話システムで特に効果的です。

# Anthropic でのPrompt Caching（cache_control を付与）
import litellm

response = litellm.completion(
    model="anthropic/claude-3-7-sonnet-20250219",
    messages=[
        {
            "role": "system",
            "content": [
                {
                    "type": "text",
                    "text": "あなたは優秀なコードレビュアーです。...(長いシステムプロンプト)...",
                    "cache_control": {"type": "ephemeral"},  # キャッシュ対象をマーク
                }
            ],
        },
        {"role": "user", "content": "このコードをレビューしてください: ..."},
    ],
)

# キャッシュ使用状況を確認
usage = response.usage
print(f"キャッシュ書き込みトークン数: {usage.get('cache_creation_input_tokens', 0)}")
print(f"キャッシュヒットトークン数: {usage.get('cached_tokens', 0)}")

# モデルがPrompt Cachingに対応しているか事前確認
print(litellm.supports_prompt_caching(model="anthropic/claude-3-7-sonnet-20250219"))

対応プロバイダー：OpenAI（1,024トークン以上で自動適用）、Anthropic、Google Gemini / Vertex AI、AWS Bedrock、Deepseek、xAI

Spending tracking / コスト試算

LiteLLMはリクエストごとのコストを自動計算し、チーム・ユーザー・APIキー単位で集計できます。Proxy Server経由のリクエストには x-litellm-response-cost ヘッダーでコストが返ります。

Python SDKでのコスト追跡

import litellm

response = litellm.completion(
    model="gpt-4o",
    messages=[{"role": "user", "content": "コスト追跡のテスト"}],
)

# レスポンスからコストを取得
cost = litellm.completion_cost(completion_response=response)
print(f"このリクエストのコスト: ${cost:.6f}")

Proxy Serverでのユーザー別コスト追跡

# user パラメータでエンドユーザーを識別してコストを集計
import openai

client = openai.OpenAI(api_key="sk-my-key", base_url="http://localhost:4000")

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "ユーザー別コスト追跡"}],
    extra_body={
        "user": "user-12345",  # エンドユーザーID
        "metadata": {
            "tags": ["project:ai-agent", "env:production"],
        }
    }
)

予算上限の設定（config.yaml）

# チームや仮想キーに予算上限を設定
# 管理者API経由でもプログラム的に設定可能
litellm_settings:
  # グローバルの月次予算（USD）
  max_budget: 100.0
  budget_duration: "monthly"

コスト集計API

# チーム別コストレポートの取得
curl -X GET "http://localhost:4000/global/spend/report" 
  -H "Authorization: Bearer sk-my-key"

# ユーザー別の日次コスト
curl -X GET "http://localhost:4000/user/daily/activity?user_id=user-12345" 
  -H "Authorization: Bearer sk-my-key"

LangChain / Mastraとの連携

LangChain（ChatLiteLLM）

LangChainからはChatLiteLLMクラスを通じてLiteLLMが使えます。既存のLangChainアプリを変更せず、バックエンドのLLMプロバイダーだけを切り替えたい場合に便利です。

# 動作環境: langchain-community>=0.2.0, litellm>=1.30.0
from langchain_community.chat_models import ChatLiteLLM
from langchain_core.messages import HumanMessage
import os

# OpenAI
chat = ChatLiteLLM(model="gpt-4o", api_key=os.getenv("OPENAI_API_KEY"))

# Anthropic に切り替えるだけ（LangChainのコードは変更不要）
chat_anthropic = ChatLiteLLM(
    model="anthropic/claude-3-7-sonnet-20250219",
    api_key=os.getenv("ANTHROPIC_API_KEY"),
    temperature=0.3
)

messages = [HumanMessage(content="AIエージェントの設計パターンを教えてください")]
response = chat_anthropic.invoke(messages)
print(response.content)

LiteLLM Proxy経由でのMastra連携

MastraはTypeScript製のAIエージェントフレームワークです。LiteLLM ProxyをOpenAI互換エンドポイントとして設定することで、Mastraから100以上のプロバイダーを透過的に利用できます。

// 動作環境: mastra>=0.1.0, Node.js 20+
import { Mastra } from "@mastra/core";
import { openai } from "@ai-sdk/openai";

// LiteLLM Proxyを OpenAI 互換エンドポイントとして指定
const litellmModel = openai.chat("claude-3-7-sonnet", {
  baseURL: "http://localhost:4000",
  apiKey: "sk-my-key",
});

const mastra = new Mastra({
  agents: {
    myAgent: {
      model: litellmModel,
      instructions: "あなたはAIエージェント専門のアシスタントです。",
    },
  },
});

【要注意】よくある失敗パターン4選

失敗1：モデル名のprefixを省略してプロバイダー混乱を起こす

# ❌ NGパターン
litellm.completion(model="claude-3-7-sonnet", messages=[...])
# → LiteLLMがプロバイダーを判定できず、OpenAIとして解釈するケースがある

# ⭕ 正解：プロバイダー prefix を明示
litellm.completion(model="anthropic/claude-3-7-sonnet-20250219", messages=[...])

失敗2：コスト追跡のためにDBを設定せずVirtual Keysを使う

# ❌ NGパターン（Virtual Keysにはデータベース必須）
general_settings:
  master_key: sk-my-key
# DB設定なしでは /key/generate が 500 エラーを返す

# ⭕ 正解：PostgreSQL or SQLiteを設定
general_settings:
  master_key: sk-my-key
database_url: "postgresql://user:pass@localhost:5432/litellm_db"

失敗3：usage-based-routingでRedisを設定しないまま使う

usage-based-routing-v2 はTPM/RPMをリアルタイム集計するためにRedisが必須です。Redisなしで使うとシングルプロセス内の集計しかできず、複数インスタンス構成で正しく機能しません。

# ⭕ 正解：Redisを設定する
router = Router(
    model_list=model_list,
    redis_host=os.environ["REDIS_HOST"],
    redis_port=int(os.environ["REDIS_PORT"]),
    redis_password=os.environ["REDIS_PASSWORD"],
    routing_strategy="usage-based-routing-v2",
)

失敗4：フォールバック先のモデルをconfig.yamlに登録し忘れる

# ❌ NGパターン：フォールバック先が model_list に存在しない
router_settings:
  fallbacks:
    - {"gpt-4o": ["claude-3-7-sonnet"]}  # ← この model_name が model_list にないとエラー

# ⭕ 正解：フォールバック先も model_list に登録
model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
  - model_name: claude-3-7-sonnet   # ← 必ず登録
    litellm_params:
      model: anthropic/claude-3-7-sonnet-20250219

まとめ：今日から始める3つのアクション

LiteLLMは「複数のLLMプロバイダーを使い分けるすべてのチーム」にとって不可欠なインフラです。GitHub Stars 45.7k（2026年5月）という実績が示すとおり、すでに業界標準の地位を確立しています。

今日やること：pip install litellm → 既存のOpenAI呼び出しを litellm.completion() に書き換えて動作確認
今週中：Proxy Serverをローカルに立ち上げて、チームの共有LLMエンドポイントとして導入。APIキー管理を一元化する
今月中：ルーティング戦略（least-busy or cost-based）とFallback設定を本番環境に適用。Admin UIでコスト推移を週次でモニタリング開始

あわせて読みたい：

LLMルーティング×プロンプトキャッシュでコスト最適化する方法 — LiteLLMと組み合わせて使えるコスト削減テクニック
Letta完全ガイド2026｜記憶を持つAIエージェントをPythonで実装 — LLMゲートウェイの上に乗るエージェント層の設計

参考・出典

BerriAI/litellm — GitHub（参照日: 2026-05-05）
Getting Started | liteLLM 公式ドキュメント（参照日: 2026-05-05）
Router – Load Balancing | liteLLM（参照日: 2026-05-05）
Fallbacks | liteLLM（参照日: 2026-05-05）
Prompt Caching | liteLLM（参照日: 2026-05-05）
Spend Tracking | liteLLM（参照日: 2026-05-05）
Using ChatLiteLLM() – Langchain | liteLLM（参照日: 2026-05-05）

この記事を読んで導入イメージが固まってきた方へ

UravationではAIエージェント導入の研修・コンサルを行っています。LiteLLMを含むLLMゲートウェイの設計から本番運用まで、実務ベースでサポートします。

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。100社以上の企業向けAI研修・導入支援。著書累計3万部突破。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約支援実績を見る

※ 本記事の情報は2026年5月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

LiteLLM完全ガイド｜100モデル統合・LLMルーティング・コスト最適化

LiteLLMとは｜アーキテクチャ概要

対応プロバイダー（抜粋）

インストール｜pip vs Docker

pip（SDK単体）

Docker（Proxy Server）

Proxy Server起動 vs SDK直接利用の使い分け

SDK の基本的な使い方

モデル統合｜YAML設定とProxy起動

Routing戦略｜least-busy / cost-aware / latency-based

利用可能なルーティング戦略

least-busy（最小同時接続数）

latency-based-routing（レイテンシ最小化）

cost-based-routing（コスト最安値）

モデルごとに異なる戦略を使うRouting Groups

Fallback / Retry設定

config.yaml でのFallback設定

Python SDK でのFallback設定

Prompt Caching統合

Spending tracking / コスト試算

Python SDKでのコスト追跡

Proxy Serverでのユーザー別コスト追跡

予算上限の設定（config.yaml）

コスト集計API

LangChain / Mastraとの連携

LangChain（ChatLiteLLM）

LiteLLM Proxy経由でのMastra連携

【要注意】よくある失敗パターン4選

失敗1：モデル名のprefixを省略してプロバイダー混乱を起こす

失敗2：コスト追跡のためにDBを設定せずVirtual Keysを使う

失敗3：usage-based-routingでRedisを設定しないまま使う

失敗4：フォールバック先のモデルをconfig.yamlに登録し忘れる

まとめ：今日から始める3つのアクション

参考・出典

この記事を読んで導入イメージが固まってきた方へ

関連記事

MCP Registry完全ガイド｜公開手順6ステップ

MCP認可の実装ガイド｜OAuth 2.1対応

AgentIQとは？NVIDIA製AI運用見える化基盤