0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@locallab

LLMゲートウェイを自作する前に知っておきたい5つのアーキテクチャパターン

0
Posted at

TL;DR

  • LLMゲートウェイは「ルーティング」「レート制限」「フォールバック」「コスト管理」「評価ベース切り替え」の5層で設計するのが定石
  • OSS 実装（LiteLLM / Relay / Concentrate）は目的別に使い分けると低コストで本番運用できる
  • eval-gated routing を導入すると品質劣化を自動検知してモデルを切り替えられる

背景

2026 年現在、LLM を本番運用するチームの共通課題は「どのモデルをいつ使うか」の意思決定をコードから分離することだ。

  • OpenAI / Anthropic / Mistral / ローカル Ollama を混在させたい
  • 特定モデルが落ちたときに自動フォールバックさせたい
  • チームごとに月額の利用上限を設けたい
  • 出力品質が閾値を下回ったら別モデルへ自動切り替えしたい

これらをアプリ層に直書きすると、変更のたびにデプロイが必要になり、コードが汚染される。LLM ゲートウェイを間に挟むと、これらの関心事をインフラ層に切り出せる。

本記事では、OSS ゲートウェイの実装を参考に「よく使われる 5 つのアーキテクチャパターン」を整理する。

パターン 1 — シンプルなプロキシ + ラウンドロビン

最もシンプルな構成。/v1/chat/completions を受け取り、バックエンドの複数モデルへ分散するだけ。

Client
  │
  ▼
LLM Gateway (:8080)
  ├── OpenAI gpt-4o
  ├── Anthropic claude-sonnet
  └── Ollama (ローカル)

LiteLLM Proxy で実現するなら config.yaml はこれだけ：

# litellm config.yaml
model_list:
  - model_name: my-gpt
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
  - model_name: my-gpt
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: my-gpt
    litellm_params:
      model: ollama/llama3.2
      api_base: http://localhost:11434

router_settings:
  routing_strategy: simple-shuffle  # ラウンドロビンに近い

アプリ側は base_url をゲートウェイに変えるだけで既存コードがそのまま動く。

向いているユース: 負荷分散・コスト分散・プロバイダ冗長化

パターン 2 — コストベースルーティング

リクエストの「重さ」（タスク種別・プロンプト長）に応じてモデルを切り替える。

短い分類タスク  →  安価なモデル (gemini-flash / gpt-4o-mini)
長文要約タスク  →  高性能モデル (claude-sonnet / gpt-4o)

実装イメージ（Python 疑似コード）：

def route(prompt: str, task_type: str) -> str:
    """モデル名を返す"""
    if task_type == "classify" or len(prompt) < 200:
        return "gpt-4o-mini"
    if task_type == "summarize":
        return "claude-sonnet-4-5"
    return "gpt-4o"  # デフォルト

Ramp 社が 2026 年に公開したルーターは、このアプローチで内部 LLM コストを 30% 削減したと報告している。タスク種別をメタデータとしてリクエストヘッダに乗せるのが最もシンプルな実装パターンだ。

POST /v1/chat/completions
X-Task-Type: classify

向いているユース: コスト最適化・レスポンスタイム要件が異なる複数タスクの同居

パターン 3 — フォールバックチェーン

プライマリモデルが 5xx / タイムアウトを返したら、次のモデルへ自動的に再試行する。

gpt-4o  →  (失敗)  →  claude-sonnet  →  (失敗)  →  ollama/llama3.2

LiteLLM では fallbacks キーで宣言的に設定できる：

router_settings:
  fallbacks:
    - {"my-gpt": ["backup-claude", "local-llama"]}
  context_window_fallbacks:
    - {"my-gpt": ["my-gpt-16k"]}  # コンテキスト超過時に自動昇格
  num_retries: 2
  retry_after: 5  # 秒

context_window_fallbacks が地味に便利で、入力トークンがモデルの上限を超えたとき、より大きなコンテキストウィンドウを持つモデルへ自動で退避させられる。

向いているユース: 本番 SLA 要件・マルチクラウド冗長化

パターン 4 — eval-gated ルーティング (評価ベース切り替え)

出力品質を自動評価し、スコアが閾値を下回ったら別モデルへ切り替えるパターン。GitHub 上の OSS「Relay」が実装している。

Request
  │
  ▼
モデル A で推論
  │
  ▼
Evaluator (LLM or ルールベース)
  ├── スコア >= 0.8 → そのままレスポンス返却
  └── スコア < 0.8  → モデル B で再推論 → 返却

Evaluator は次のいずれかで実装することが多い：

評価手法 コスト 精度 向いている用途
ルールベース (正規表現・JSON schema) 低 中 フォーマット検証
小型 LLM (gpt-4o-mini で自己評価) 中 高 文章品質・一貫性
外部評価 API (Braintrust / Langfuse) 中〜高 最高 複雑な事実確認

実装上の注意点:

  • 評価にも LLM を使うと評価コスト ≒ 推論コストの 50〜100% が追加でかかる
  • 再推論の max_retries は必ず設定し、無限ループを防ぐ
  • ユーザー向け P99 レイテンシへの影響を事前に試算すること

向いているユース: 出力品質保証が必要な B2B プロダクト・医療・法務・金融

パターン 5 — マルチテナント予算管理 + 監査ログ

チームや顧客ごとにトークン消費量を追跡し、上限を超えたらエラーを返す。

Team A: 月 1M tokens
Team B: 月 500K tokens (残: 200K)
Team C: 月 2M tokens

LiteLLM の Virtual Key 機能を使うか、自前のミドルウェアで実装する：

# FastAPI ミドルウェア例（簡略版）
@app.middleware("http")
async def budget_guard(request: Request, call_next):
    team_id = request.headers.get("X-Team-ID")
    used = await redis.get(f"tokens:{team_id}:{current_month()}")
    limit = await db.get_budget(team_id)

    if int(used or 0) >= limit:
        return JSONResponse(
            {"error": "monthly token budget exceeded"},
            status_code=429
        )

    response = await call_next(request)
    # レスポンスヘッダからトークン数を取得して加算
    tokens_used = int(response.headers.get("x-tokens-used", 0))
    await redis.incrby(f"tokens:{team_id}:{current_month()}", tokens_used)
    return response

監査ログは OpenTelemetry トレースとして出力すると、Grafana / Datadog などの既存可観測性スタックと統合しやすい。

向いているユース: 社内 AI プラットフォーム・マルチテナント SaaS

OSS ゲートウェイの比較 (2026 年時点)

プロジェクト ライセンス 主な特徴 向いている規模
LiteLLM Proxy MIT 100+ モデル対応・バジェット管理・OpenTelemetry スタートアップ〜中規模
Relay MIT eval-gated routing・セルフホスト 品質保証が必要なチーム
Concentrate SaaS (無料枠あり) GUI 管理画面・マネージドホスティング 小規模・インフラ省力化
OpenRouter SaaS 無料モデル多数・API 互換 プロトタイプ・個人開発

Note: 各 OSS のライセンスは MIT。商用利用可。Concentrate は SaaS のため利用規約を個別に確認のこと。

どのパターンを選ぶか — 意思決定フロー

本番運用か?
├── No → OpenRouter の :free モデルで十分
└── Yes
      ├── マルチテナントか?
      │     └── Yes → パターン 5 + LiteLLM
      ├── 品質 SLA が厳しいか?
      │     └── Yes → パターン 4 (eval-gated)
      ├── コスト最適化が最優先か?
      │     └── Yes → パターン 2 + パターン 3
      └── まず冗長化したいだけ
            └── → パターン 1 + パターン 3 の組み合わせ

実際のプロダクションでは、これらは排他ではなく重ねて使うものだ。例えば「コストベースルーティング（パターン 2）+ フォールバックチェーン（パターン 3）+ 予算管理（パターン 5）」を同時に適用するのが典型的な構成になる。

まとめ

パターン 主な効果
1. シンプルプロキシ プロバイダ依存排除・負荷分散
2. コストベースルーティング LLM コスト 20〜30% 削減
3. フォールバックチェーン 可用性向上・SLA 担保
4. eval-gated ルーティング 出力品質の自動保証
5. 予算管理 + 監査ログ ガバナンス・マルチテナント対応

LLM ゲートウェイは「1 日で動くプロトタイプ」から始めて、本番需要に合わせてパターンを積み重ねていくのが現実的なアプローチだ。LiteLLM のような OSS は最初から複数パターンを内包しているので、自作する前に一度触れてみることを強くすすめる。

参考リンク

✍️ 本記事の著者: 合同会社ジモラボ

ジモラボは、八王子を拠点に AI を活用した SaaS を多数開発しています。本記事の技術検証もそうした開発過程の副産物です。

興味を持っていただけたら、ぜひ各 SNS のフォローもお願いします!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?