LibreChat対Open WebUI — カスタムエンドポイントをより少ない手間で利用できるのはどちらか

どちらもセルフホストで実行でき、どちらもOpenAIプロトコルに対応しており、どちらでも目的を果たせます。 この質問で上位に表示される比較記事は、機能表を並べています。ここでは、あなたがたぶん知りたかった、より限定された質問に答えます。つまり、どちらがカスタムOpenAI互換エンドポイントをより少ない手間で利用できるのか、そしてその代わりにそれぞれ何を提供するのかです。

以下で述べる内容はすべて、各プロジェクト自身のREADMEに基づいています。ここにはベンチマークも、どちらが優れているかという結論もありません。どちらも結論を正当化できる規模で実行していないためです。

それぞれの出自

全体として、Open WebUIはデプロイと検索・取得の側に、LibreChatはプロバイダーとエージェントの側に、より多く投資しています。どちらを重視するかは、通常、機能数よりも優れた決め手になります。

Open WebUIをゲートウェイに向ける

環境変数は2つだけで、すぐに動作します。

# Open WebUI — the OpenAI-compatible connection is a base URL and a key.
docker run -d -p 3000:8080 \
  -e OPENAI_API_BASE_URL=https://api.kunavo.com/v1 \
  -e OPENAI_API_KEY=sk-kn-... \
  -v open-webui:/app/backend/data \
  --name open-webui ghcr.io/open-webui/open-webui:main

# The same two values can be set in Settings -> Connections after
# first launch, which is the faster path when you are trying it out.

モデル選択リストは GET /v1/models から作成できるため、複数のモデル系列を提供するエンドポイントなら、すべてが1つのドロップダウンに入ります。ClaudeとGPTのIDが、2つ目の設定なしで一緒に表示されます。

LibreChatをゲートウェイに向ける

LibreChatでは環境変数ではなくYAMLブロックを使います。記述量は増えますが、名前とモデルを制御できます。

# LibreChat — a custom endpoint is a block in librechat.yaml.
version: 1.2.1
endpoints:
  custom:
    - name: "Kunavo"
      apiKey: "${KUNAVO_API_KEY}"
      baseURL: "https://api.kunavo.com/v1"
      models:
        default: ["claude-sonnet-5", "gpt-5-6-terra", "claude-haiku-4-5"]
        fetch: true          # populate the picker from GET /v1/models
      titleConvo: true
      titleModel: "claude-haiku-4-5"
      modelDisplayLabel: "Kunavo"

エンドポイントに関係なくコピーする価値があるのは titleModel の行です。LibreChatはモデル呼び出しで会話タイトルを生成するため、これを一覧中で最も安いモデルに固定すると、普段チャットしているモデルの料金でタイトルまで請求されるのを防げます。

どちらの背後にもゲートウェイを置く理由

どちらのクライアントも複数のプロバイダーを同時に保持できるため、ゲートウェイは必須ではありません。変わるのは、設定するものの数と請求の数です。モデル系列ごとにアカウント、認証情報、請求関係を用意する代わりに、1つのベースURLと1つのキーで済みます。後から系列を追加する場合も、新しい統合ではなく一覧にモデルIDを追加するだけになります。

Kunavoは両クライアントが使うOpenAI互換のインターフェースを提供するため、上記のベースURLだけでどちらも利用できます。クライアントごとの設定詳細は 統合ハブ、エンドポイントのリファレンスは チャット補完、そして「互換」が含むものと含まないものは OpenAI互換APIガイドで説明しています。

よくある質問