LibreChat vs Open WebUI: quale accetta un endpoint personalizzato con meno attrito

Entrambi funzionano in modalità self-hosted, entrambi parlano il protocollo OpenAI ed entrambi svolgono il lavoro. I confronti che si posizionano per questa domanda allineano tabelle di funzionalità. Questo risponde alla domanda più circoscritta che probabilmente ti ha portato qui: quale dei due accetta un endpoint personalizzato compatibile con OpenAI con meno attrito e cosa offre ciascuno in cambio.

Tutto ciò che viene affermato qui sotto proviene dal README di ciascun progetto. Non c'è alcun benchmark né un verdetto su quale sia migliore, perché non abbiamo eseguito nessuno dei due a una scala che giustifichi una conclusione del genere.

Da dove nasce ciascuno

Il modello è che Open WebUI ha investito soprattutto nel lato della distribuzione e del recupero, mentre LibreChat nel lato dei provider e degli agenti. Quale di questi aspetti ti interessa è di solito un criterio di scelta migliore del conteggio delle funzionalità.

Indirizzare Open WebUI verso un gateway

Due variabili d'ambiente e sei operativo:

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

Poiché il selettore dei modelli può essere riempito da GET /v1/models, un endpoint che offre diverse famiglie le inserisce tutte nello stesso menu a tendina — gli ID di Claude e GPT compaiono insieme senza una seconda configurazione.

Indirizzare LibreChat verso un gateway

LibreChat vuole un blocco YAML invece delle variabili d'ambiente: richiede più scrittura, ma offre controllo sui nomi e sui modelli:

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

La riga titleModel è quella che vale la pena copiare indipendentemente dall'endpoint: LibreChat genera il titolo di una conversazione con una chiamata al modello e fissarlo sul modello più economico del tuo elenco impedisce che i titoli vengano fatturati alla tariffa del modello con cui stai conversando in quel momento.

Perché mettere un gateway dietro uno dei due

Entrambi i client possono gestire più provider contemporaneamente, quindi un gateway non è obbligatorio. Cambia però il numero di elementi da configurare e di fatture da gestire: un'unica base URL e un'unica chiave al posto di un account, una credenziale e un rapporto di fatturazione per ogni famiglia di modelli. Aggiungere successivamente una famiglia diventa l'inserimento di un model ID in un elenco invece di una nuova integrazione.

Kunavo offre la superficie compatibile con OpenAI utilizzata da entrambi i client, quindi la base URL sopra riportata è tutto ciò di cui hanno bisogno. I dettagli di configurazione per ciascun client sono disponibili nell'hub delle integrazioni, il riferimento dell'endpoint è in chat completions e la guida all'API compatibile con OpenAI spiega cosa include e cosa non include la “compatibilità”.

Domande frequenti