LibreChat vs. Open WebUI — welcher Dienst einen benutzerdefinierten Endpunkt reibungsärmer übernimmt

Beide laufen selbst gehostet, beide sprechen das OpenAI-Protokoll, und beide erledigen die Aufgabe. Die für diese Frage rankenden Vergleiche stellen Funktionstabellen gegenüber. Dieser beantwortet die wahrscheinlich engere Frage, mit der Sie hier angekommen sind: Welcher der beiden übernimmt einen benutzerdefinierten OpenAI-kompatiblen Endpunkt mit weniger Aufwand, und was bietet jeder im Gegenzug?

Alles, was unten behauptet wird, stammt aus der jeweiligen README des Projekts. Es gibt hier keinen Benchmark und kein Urteil darüber, welcher besser ist, da wir keinen der beiden in einem Umfang ausgeführt haben, der ein solches Urteil rechtfertigen würde.

Woher die beiden stammen

Das Muster ist, dass Open WebUI am meisten in Bereitstellung und Retrieval investiert hat, LibreChat dagegen in Anbieter und Agenten. Was Ihnen davon wichtig ist, ist meist ein besseres Entscheidungskriterium als die Anzahl der Funktionen.

Open WebUI auf ein Gateway ausrichten

Zwei Umgebungsvariablen, und es läuft:

# 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.

Da die Modellauswahl über GET /v1/models befüllt werden kann, stellt ein Endpunkt, der mehrere Familien bereitstellt, alle in einem Dropdown zusammen — die Claude- und GPT-IDs erscheinen gemeinsam, ohne zweite Konfiguration.

LibreChat auf ein Gateway ausrichten

LibreChat erwartet statt Umgebungsvariablen einen YAML-Block. Das erfordert mehr Schreibaufwand und bietet dafür Benennung und Modellsteuerung:

# 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"

Die Zeile titleModel lohnt sich unabhängig vom Endpunkt zu übernehmen: LibreChat erzeugt einen Gesprächstitel mit einem Modellaufruf. Wenn Sie dafür das günstigste Modell Ihrer Liste festlegen, werden die Titel nicht zu dem Tarif des Modells abgerechnet, mit dem Sie gerade zufällig chatten.

Warum ein Gateway dahintersetzen

Beide Clients können mehrere Anbieter gleichzeitig enthalten, daher ist ein Gateway nicht erforderlich. Es ändert jedoch, wie viele Dinge Sie konfigurieren und wie viele Rechnungen Sie erhalten: eine Basis-URL und ein Schlüssel statt eines Kontos, eines Zugangsdaten-Satzes und einer Abrechnungsbeziehung pro Modellfamilie. Eine weitere Familie wird anschließend als Modell-ID in einer Liste hinzugefügt und nicht als neue Integration.

Kunavo stellt die OpenAI-kompatible Oberfläche bereit, die beide Clients verwenden; daher ist die oben genannte Basis-URL alles, was einer der beiden benötigt. Die Einrichtungsdetails pro Client finden Sie im Integrations-Hub, die Endpunktreferenz unter Chat Completions, und die Anleitung zur OpenAI-kompatiblen API erläutert, was „kompatibel“ umfasst und was nicht.

Häufig gestellte Fragen