設計目標
社内アプリは OpenAI 互換 API のみを叩き、裏側で複数のモデル（中国系 + 米系 + セルフホスト）が透過的に切り替わる構成を作る。要件は (1) コスト最小化、(2) レイテンシ p95 < 4 秒、(3) 何らかの理由で 1 系統が落ちても自動でフォールバック、の 3 つ。
構成図
``` 社内アプリ → LiteLLM Proxy (Tokyo VPC) → ルータ ├ DeepSeek 公式 API ├ Qwen3 セルフホスト (vLLM) ├ Bedrock Tokyo (Claude) └ OpenRouter (バックアップ) ```
ルーティングルール
```yaml # litellm.yaml model_list: - model_name: smart-jp litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY model_info: { tier: "low" } - model_name: smart-jp-fallback litellm_params: model: openai/qwen3-72b api_base: https://qwen.internal/v1 model_info: { tier: "low" } - model_name: smart-jp-secure litellm_params: model: bedrock/anthropic.claude-3-5-sonnet-20241022-v2:0 aws_region_name: ap-northeast-1 model_info: { tier: "high" }
router_settings: fallbacks: - smart-jp: ["smart-jp-fallback", "smart-jp-secure"] routing_strategy: latency-based-routing cooldown_time: 30 ```
レート制御とコスト追跡
LiteLLM Proxy は Redis 連携で per-team / per-user の TPM/RPM 制御を提供する。各部署に予算（仮想枠）を割り、月次でダッシュボード化。Komoju 系決済データを扱うチームには `smart-jp-secure` のみ許可するなど、ACL も同 proxy で実装可能。
観測
- request_id ベースの分散トレース（OpenTelemetry）
- フォールバック発火率: 平常 < 0.5%、異常時はアラート
- 1 リクエストあたりの平均トークン使用と平均コスト
- モデル別エラー率
まとめ
LiteLLM Proxy はマルチモデル運用の必須コンポーネントとして急速に成熟しており、中国系 LLM のコスト性能と米系 LLM の信頼性をうまく両立させるための要となる。社内 R&D の構成では、Proxy 導入だけで月額 LLM コストが 30-40% 圧縮された。