LobeChat bringt mehrere Modellanbieter in einer Oberfläche zusammen. Das ist bequem, doch die Key-Verwaltung wird oft vernachlässigt: Wer hat den Key angelegt, welche Modelle darf er aufrufen, liegt er im Browser oder in der Datenbank, wandert er in ein Backup, und bleibt er nach dem Austritt eines Teammitglieds gültig? Dieser Beitrag beschreibt eine umsetzbare Vorgehensweise in den Schritten Anlegen, Konfigurieren, Speichern, Rotieren, Teamrichtlinie und Fehlersuche.

Hinweis: LobeChat und LobeHub sind Produkte und Marken der jeweiligen Inhaber; OpenAI ist eine Marke von OpenAI, Inc. Dieser Beitrag dient der technischen Erläuterung; es besteht keine Zugehörigkeit oder Partnerschaft mit den genannten Unternehmen. Oberfläche, Variablennamen und Speicherart ändern sich mit der Version; maßgeblich ist die aktuelle offizielle Dokumentation. Modelle und Preise richten sich nach den Modellpreisen auf dieser Website.

1. Zuerst drei Arten von Keys unterscheiden

„LobeChat API Key“ bezeichnet häufig drei verschiedene Dinge:

  • Konto- oder Plattformzugang: dient der Anmeldung bei LobeHub Cloud oder einer Enterprise-Plattform; die Rechte legt die Plattform fest.
  • Anbieter-Key: wird von OpenAI, Anthropic, Google usw. ausgestellt und beim jeweiligen Anbieter eingetragen.
  • Gateway-Key: wird von einem OpenAI-kompatiblen Gateway ausgestellt; ein Key kann Modelle mehrerer Anbieter aufrufen.

Dieser Beitrag behandelt die dritte Art; die Hinweise gelten auch für andere Anbieter-Keys, die Sie in LobeChat eintragen. Ein Gateway-Key dient nicht zur Anmeldung und erreicht keine privaten Schnittstellen der Client-Anbieter. Bei der Konfiguration wählen Sie den OpenAI-kompatiblen Zugang oder einen benutzerdefinierten Anbieter, statt den Key in ein anbieterspezifisches Feld zu schreiben.

2. Key anlegen: zuerst Zweck und Obergrenze festlegen

Legen Sie keinen Key an, bevor klar ist, wer ihn nutzt. Die umgekehrte Reihenfolge spart später viel Arbeit:

  1. Öffnen Sie die Registrierungsseite des ZSQH AI Gateway, registrieren Sie sich und melden Sie sich in der Konsole an.
  2. Rufen Sie die Seite für API-Keys auf und erstellen Sie einen neuen Key.
  3. Benennen Sie Nutzer, Umgebung und Zweck eindeutig, etwa lobe-team-prod, nicht test.
  4. Legen Sie Obergrenze und Ablaufdatum fest; falls unterstützt, begrenzen Sie die verfügbaren Modelle nach Projekt.
  5. Prüfen Sie das Kontoguthaben, damit der Key nicht erst nach der Konfiguration an fehlendem Guthaben scheitert.
  6. Kopieren Sie den Key in einen Passwortmanager, nicht zuerst in Gruppenchat, Dokument oder Ticket.

Prüfen Sie danach auf der Kommandozeile, ob Key, Adresse und Modell zusammenpassen:

export ZSQH_API_KEY="sk-IhrSchluessel"

curl -sS "https://ai.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $ZSQH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"IhreModellID","messages":[{"role":"user","content":"Antworte nur mit OK"}]}'

Enthält die Antwort das Feld choices, funktioniert die Kette. Bei 401 prüfen Sie zuerst den Key, bei 404 den Pfad /v1, bei „model not found“ die Modell-ID.

3. Serverseitige Umgebungsvariablen und Nutzerkonfiguration

Keys in LobeChat können auf zwei Ebenen liegen, mit völlig unterschiedlicher Wirkung:

Ebene Ort Geltungsbereich Geeignet für
Serverseitige Umgebungsvariable Deployment-Umgebung, lobehub.env, Secret-Management gesamte Instanz einheitlicher Teamzugang, Standardmodelle
Nutzerseitige Anbieterkonfiguration Einstellungen nach Anmeldung einzelnes Konto eigener Key, kurzer Test
Gateway-Key Gateway-Konsole Abrechnung pro Key Limits, Audit, Sperrung

OPENAI_API_KEY auf dem Server ist ein gemeinsamer Key: Alle Personen mit Zugriff auf die Instanz können ihn verwenden. Nutzer können in den Einstellungen auch einen eigenen Key hinterlegen; im Datenbankmodus des Servers wird dieser verschlüsselt gespeichert, abhängig von KEY_VAULTS_SECRET. Geht dieses Geheimnis verloren, lassen sich gespeicherte Nutzer-Keys möglicherweise nicht mehr entschlüsseln – beim Deployment also unbedingt sichern.

Häufige serverseitige Variablen:

  • OPENAI_API_KEY: gemeinsamer Gateway-Key.
  • OPENAI_PROXY_URL: überschreibt die Standardadresse von OpenAI und zeigt auf ein kompatibles Gateway.
  • OPENAI_MODEL_LIST: steuert die Modellliste, verleiht aber keine zusätzlichen Rechte.
  • KEY_VAULTS_SECRET: verschlüsselt Nutzer-Keys und Proxy-Adressen in der Datenbank.
  • AUTH_SECRET: für Sitzung und Authentifizierung, separat erzeugen.
  • DATABASE_URL: PostgreSQL-Verbindungszeichenfolge, im Servermodus erforderlich.

Schreiben Sie denselben Key nicht gleichzeitig in Umgebungsvariable und Nutzerkonfiguration, außer Sie wissen genau, welche Ebene wirkt. Prüfen Sie bei der Fehlersuche zuerst, welcher Key im Request verwendet wird, und danach die Gateway-Logs.

4. Mehrere Modelle und Anbieter konfigurieren

Die Syntax von OPENAI_MODEL_LIST: + fügt hinzu, - blendet aus, ModellID=Anzeigename<Fähigkeiten> definiert Anzeige und Fähigkeiten; Trennung durch Kommas. Beispiel:

-all,+model-a=Alltagsfragen<128000:fc:vision>,+model-b=Langtextanalyse<200000:reasoning>

Der erste Wert in den spitzen Klammern ist der maximale Kontext, danach folgen Fähigkeits-Tags, üblich sind fc (Funktionsaufruf), vision (Bild), file (Datei), reasoning (Schlussfolgern) und search (Websuche). Die Tags müssen den tatsächlichen Fähigkeiten entsprechen; falsche Angaben führen nicht sofort zu einem Fehler, aber später bei Plugins oder Bildaufgaben.

Für mehrere Anbieter gilt: ein Upstream-Endpunkt, eine Konfiguration.

  • Für dasselbe Gateway nur einen Anbieter-Eintrag anlegen und Zwecke über die Modellliste unterscheiden.
  • Für verschiedene Gateways oder Umgebungen je einen Eintrag mit Umgebungssuffix anlegen.
  • Jeder Eintrag erhält einen eigenen Key, damit Limits und Sperrung getrennt möglich sind.
  • Kopieren Sie nicht denselben Key, nur um mehr Modelle anzuzeigen; die Abrechnung wird sonst unübersichtlich.

Die Modellliste steuert nur die Anzeige; die tatsächlichen Rechte liegen im Gateway. Soll ein Key nur bestimmte Modelle aufrufen dürfen, stellen Sie das in der Konsole ein und verlassen sich nicht auf das Ausblenden in der Oberfläche.

5. Wo Keys liegen und wo sie abfließen

Nach Deployment-Art:

  • Lokaler oder Browser-Modus: Die Konfiguration liegt im lokalen Speicher des Browsers und kann beim Gerätewechsel oder Leeren des Caches verschwinden. Auf gemeinsam genutzten Rechnern keine langlebigen Keys speichern.
  • Server-Datenbankmodus: Nutzer-Keys werden verschlüsselt in PostgreSQL gespeichert, abhängig von KEY_VAULTS_SECRET. Backups enthalten Chiffrat, die Schlüsseldatei muss jedoch separat aufbewahrt werden.
  • Umgebungsvariablen-Datei: lobehub.env ist Klartext; nur für das Dienstkonto lesbar machen, nicht in Git und nicht im Image verteilen.
  • S3 und Backups: S3 enthält Dateien und Wissensdatenbanken, meist keine Keys; Datenbank-Backups und Deployment-Konfigurationen können jedoch indirekt sensible Informationen enthalten.

Achten Sie zudem auf Screenshots, Tickets und Chatverläufe. Viele Lecks entstehen nicht durch einen Datenbankangriff, sondern weil ein Key an der falschen Stelle eingefügt wurde.

6. Rotation und Sperrung

Empfohlen ist eine Rotation alle 90 Tage oder sofort bei Austritt, Geräteverlust oder Verdacht auf Offenlegung. Die Reihenfolge lautet: neu anlegen, umstellen, erst dann alten Key deaktivieren.

  1. Neuen Key mit gleichen Rechten anlegen, Name mit Datumssuffix.
  2. lobehub.env oder nutzerseitige Anbieterkonfiguration aktualisieren und jeden Eintrag prüfen.
  3. Dienst neu starten oder neu aufbauen und eine Testanfrage senden.
  4. In den Gateway-Logs bestätigen, dass der neue Key Aufrufe hat und der alte keinen neuen Traffic.
  5. Eine Zeit lang Fehlerrate und Nutzung beobachten, um vergessene Skripte oder Geräte zu finden.
  6. Alten Key deaktivieren, Aufzeichnungen eine Weile behalten und erst dann löschen.

Löschen Sie den alten Key nicht vor der Umstellung, sonst entsteht ein Fenster ohne Aufrufmöglichkeit. Bei Verdacht auf Offenlegung zuerst sperren, dann ungewöhnliche Nutzung und Aufrufquellen prüfen.

7. Teamrichtlinie: ein Key pro Person, getrennte Umgebungen

  • Ein Key pro Person und Zweck; für Automatisierung separate Keys.
  • Entwicklung, Test und Produktion getrennt, damit Testtraffic die Produktionsabrechnung nicht verfälscht.
  • Obergrenze, Ablaufdatum und Modellbereich setzen, wo möglich – mindestens die ersten beiden.
  • Gemeinsame Server-Keys nur für den Standardzugang verwenden, konservativ dosieren, damit Anomalien auffallen.
  • Ein Verzeichnis führen: Key-Name, Inhaber, Zweck, Anlage- und Ablaufdatum, aber nie den vollständigen Key.
  • Monatlich ungenutzte Keys, überschrittene Limits und auffällige Authentifizierungsfehler prüfen.
  • Anlage, Übergabe und Sperrung von Keys in Onboarding und Offboarding aufnehmen.
  • Festlegen, welche Daten in Cloud-Modelle dürfen; sensible Projekte vorher bewerten.
  • Regelmäßig die Modellpreise prüfen, da Preise und verfügbare Modelle sich ändern.

Auch in kleinen Teams sollte dokumentiert sein, wer beantragt, wer nutzt und wann ein Key abläuft. Im Störfall lässt sich die Ursache dann schnell eingrenzen.

8. Fehlersuche

Symptom Häufige Ursache Vorgehen
401 Unauthorized Key falsch, gesperrt oder mit Leerzeichen neu kopieren, Zugehörigkeit zum aktuellen Gateway prüfen
403 Forbidden Guthaben aufgebraucht, Rechte fehlen oder Modellbereich begrenzt Guthaben und Modellrechte in der Konsole prüfen
404 Not Found falscher API-Pfad nur bis /v1 verwenden
429 Too Many Requests Drosselung oder Guthabenobergrenze erreicht Nutzung und Parallelität prüfen
model not found Modell-ID falsch oder nicht freigeschaltet exakte Kennung von der Preisseite kopieren
Nutzer-Key plötzlich ungültig KEY_VAULTS_SECRET geändert oder fehlt ursprüngliches Geheimnis wiederherstellen und Key neu eintragen
curl funktioniert, Oberfläche nicht Konfiguration nicht gespeichert, Browser-Cache oder Proxy erneut speichern und Proxy prüfen

Unterscheiden Sie zuerst, ob „die Anwendung die Konfiguration nicht liest“ oder „das Gateway die Anfrage ablehnt“: Im ersten Fall prüfen Sie Umgebungsvariablen, Datenbank und Logs, im zweiten den HTTP-Statuscode.

Häufige Fragen

Liegt der API-Key von LobeChat im Browser oder auf dem Server?

Das hängt vom Deployment ab. Im Browser- oder lokalen Modus liegt er im lokalen Speicher; im Server-Datenbankmodus werden Nutzer-Keys verschlüsselt in PostgreSQL gespeichert, während der gemeinsame Key aus der Umgebungsvariable im Klartext in der Deployment-Umgebung liegt.

Muss der Nutzer einen Key eintragen, wenn der Server OPENAI_API_KEY konfiguriert hat?

Nein. Der Server-Key ist gemeinsam, Nutzer der Instanz können ihn direkt verwenden. Nutzer können zusätzlich einen eigenen Key für separates Guthaben oder andere Anbieter eintragen; die Priorität richtet sich nach der aktuellen Version.

Kann ein Key mehrere Modelle aufrufen?

In der Regel ja, sofern das Gateway diesem Key die Modelle erlaubt. Die Modellliste steuert nur die Anzeige; Rechte und Kontingente werden in der Gateway-Konsole festgelegt.

Was passiert bei einer Änderung von KEY_VAULTS_SECRET?

Bereits verschlüsselte Nutzer-Keys und Proxy-Adressen lassen sich möglicherweise nicht mehr entschlüsseln; die Nutzer-Keys werden plötzlich ungültig. Vorher sichern und die Migrationshinweise der aktuellen Version lesen; nicht unbedacht ändern.

Was ist bei einem geleakten Key zuerst zu tun?

Key deaktivieren oder löschen, um den Schaden zu stoppen, dann ungewöhnliche Nutzung, Aufrufquellen und Zeitraum prüfen. Danach Umgebungsvariablen-Datei, Datenbank-Backups, Repository, Chatverläufe und Screenshots kontrollieren und bei Bedarf weitere Zugangsdaten derselben Umgebung rotieren.

Fazit

Die Key-Konfiguration in LobeChat ist nicht kompliziert; schwierig ist die langfristige Verwaltung: nachvollziehbare Namen, Obergrenzen, geschützte Speicherung, klare Backup-Grenzen und die Fähigkeit, bei einem Leck sofort zu reagieren. Sie können sich beim ZSQH AI Gateway registrieren, einen Client-Key anlegen, den Betrieb testen und danach die Teamrichtlinie verschärfen; die Kosten prüfen Sie regelmäßig anhand der Modellpreise.

Weiterlesen: