LLM-Anbieter und -Modelle verwalten, Modelle aus externen Registrys synchronisieren, Health-Checks durchführen und API-Keys pro Organisation für eine unabhängige Abrechnung konfigurieren.
Entity Enricher unterstützt eine breite Palette von LLM-Providern. Jeder Provider kann mehrere Modelle mit individueller Preisgestaltung, individuellen Fähigkeiten und Konfiguration haben.
Viele Teams leiten LLM-Traffic über ein Unternehmens-AI-Gateway, einen regionalen Endpunkt oder einen nicht integrierten Anbieter – zum Beispiel einen Enterprise-LiteLLM-Proxy, Cloudflare AI Gateway oder Alibaba DashScope (für Qwen-Modelle). Diese fügen Sie als eigenen Standard-Anbieter (OpenAI-kompatibel)mit einer benutzerdefinierten Basis-URL hinzu.
acme-openai-gw). Integrierte Namen wie openai oder anthropic sind reserviert. https://gateway.example.com/v1. Dieses Feld ist für jeden Provider erforderlich, für den Entity Enricher keinen integrierten Client hat. https:// URLs sein. Loopback- und private Adressbereiche (localhost, 10.x, 192.168.x) werden abgelehnt, um SSRF zu verhindern — ein selbst gehosteter Server muss über das Internet erreichbar sein. Für ein lokales Ollama verwenden Sie stattdessen den dedizierten Ollama-Tunnel./v1-Protokoll unterstützen (Chat Completions, /models). {endpoint}/models, um den Schlüssel und die Basis-URL zu verifizieren, bevor Sie eine Anreicherung ausführen.Jeder Provider hat eine Einstellung Maximale gleichzeitige Aufrufe pro Schlüssel (seine Rate-Limit-Überschreibung). Sie begrenzt, wie viele LLM-Aufrufe ein einzelner API-Schlüssel parallel ausführt – und deckt dabei jeden Ablauf ab, der den Schlüssel verwendet: das Fan-out der Mehrfach-Expertise-Enrichment, Klassifizierung, Arbitration sowie Schema-/Sample-Generierung.
Dies ist getrennt vom Limit für maximale gleichzeitige Jobs Ihres Tarifs, das begrenzt, wie viele Anreicherungs-Jobs Ihre gesamte Organisation gleichzeitig über alle Provider hinweg ausführt.
Jedes Modell verfolgt seine Fähigkeiten, die als Symbole im Modellauswähler angezeigt werden:
| Fähigkeit | Beschreibung |
|---|---|
| Vision | Kann Bild- und visuelle Eingaben verarbeiten |
| Tool-Aufrufe | Unterstützt Function Calling / Tool-Nutzung |
| Audio-Eingabe | Kann Audioeingaben verarbeiten |
| PDF-Eingabe | Kann PDF-Dokumente verarbeiten |
| Prompt-Caching | Unterstützt Prompt-Caching zur Kostenreduzierung |
| Reasoning | Erweiterte Denk- / Chain-of-Thought-Fähigkeiten |
| Embeddings | Wandelt Text in einen Vektor um, statt zu antworten – damit werden semantische IDs aufgelöst. Embedding-Modelle bilden eine eigene Familie mit eigener Vektorgröße und erscheinen nie in einer Anreicherungsauswahl |
Die Angabe eines Modells ist optional. Anreicherung, Schemagenerierung und Beispielgenerierung akzeptieren alle auto — und behandeln ein weggelassenes Modell als auto —, was auf dem Server pro Aufgabe in dem Moment aufgelöst wird, in dem der Job startet. Der Lauf meldet, welches Modell gewählt wurde; automatisch bedeutet also nie undurchsichtig.
Inhaber können unter Einstellungen → Organisation → Standardwerte ein bevorzugtes Modell pro Aufgabe festlegen. Ist für die jeweilige Aufgabe eines gesetzt, hat es Vorrang.
Ohne Fixierung fällt die Wahl auf das Modell mit dem besten Gesamtscore aus Ihren Benchmarks der Scoring-Quelle — Ihren eigenen Messungen von Qualität, Geschwindigkeit und Kosten auf Ihren eigenen Schemas. Fehlt jede Scoring-Quelle, wird die Anfrage abgelehnt, statt zu raten.
Wenn Sie die Websuche aktivieren oder ein Dokument anhängen, das unverändert gesendet werden muss, beschränkt das die Kandidaten auf Modelle, die das tatsächlich können – und wenn keines infrage kommt, erhalten Sie eine explizite Fehlermeldung statt einer stillen Herabstufung.
Ein Modell kann auch nur für eine Aufgabe gesperrt werden, ohne deaktiviert zu sein: Ein Modell, das gut anreichert, aber schlechte Schemas erzeugt, lässt sich ausschließlich in den Auswahllisten für die Schema- und Beispielgenerierung ausblenden — entweder für Ihre Organisation oder global durch einen Administrator. Überall sonst bleibt es voll verfügbar — ein sanfteres Mittel als die Deaktivierung weiter unten.
Halten Sie die Modellpreise durch Synchronisierung aus externen Registrys aktuell. Der Synchronisierungsprozess erkennt neue Modelle, Preisänderungen und entfernte Modelle automatisch.
Die Standard-Preisquelle. Ruft Daten aus der von der Community gepflegten LiteLLM-Registry auf GitHub ab, mit echten API-Modellnamen, Preisen, Kontextlängen und Fähigkeiten.
Deckt ~30 Provider ab. Enthält keine Anzeigenamen, Benchmarks oder Generierungsgeschwindigkeit.
Eine alternative Quelle von pricepertoken.com. Enthält Anzeigenamen, Benchmarks (Coding- und Mathematik-Werte) und Generierungsgeschwindigkeit (Tokens pro Sekunde).
Deckt ~20 Provider ab. Bietet umfangreichere Metadaten als LiteLLM.
Ein offizieller, authentifizierter Katalog für GLM-Modell-Identifikatoren, mit Preisen, die direkt aus der Z.AI-Dokumentation übernommen wurden, und dort recherchierten Lücken bei den Funktionen.
Ersetzt Z.AI-Einträge, die zuvor aus LiteLLM und PricePerToken importiert wurden.
Prüfen Sie proaktiv, ob Modelle erreichbar sind, indem Sie einen minimalen Health-Check-Prompt ausführen. So werden fehlerhafte Modelle erkannt, bevor Benutzer während der Anreicherung auf Fehler stoßen.
Zustandsprüfungen können für alle Modelle, die Modelle eines bestimmten Anbieters oder ein einzelnes Modell ausgeführt werden. Die Ergebnisse werden in Echtzeit über SSE gestreamt, mit einem Fortschrittsbalken, der die Anzahl der bestandenen und fehlgeschlagenen Prüfungen anzeigt.
Wenn ein Anreicherungsaufruf mit einem Fehler „Modell nicht gefunden“ fehlschlägt, wird das Modell automatisch deaktiviert, um wiederholte Fehler zu verhindern. Dies geschieht in Echtzeit während des normalen Anreicherungsbetriebs.
| Deaktivierungsgrund | Festgelegt von | Automatisch reaktiviert? |
|---|---|---|
| Modell nicht gefunden | Anreicherungsfehler oder Health-Checks | Ja (per Preissynchronisierung oder Validierung) |
| Durch Sync entfernt | Preissynchronisierung (Modell verschwunden) | Ja (wenn das Modell erneut im Registry erscheint) |
| Manuell | Admin-Umschalter in der Benutzeroberfläche | Nein (nur manuelle Reaktivierung) |
Organisationen können ihre eigenen LLM-Provider-API-Schlüssel für unabhängige Abrechnung und Nutzungsverfolgung konfigurieren. Das System verwendet eine zweistufige Schlüsselauflösung mit LRU-Auswahl:
Schlüssel pro Organisation, die auf der Seite „API-Schlüssel“ konfiguriert werden. Unterstützt mehrere Schlüssel pro Anbieter mit LRU-Rotation. Verschlüsselt mit Fernet.
Systemweite Schlüssel, die von Administratoren verwaltet werden. Für alle Organisationen freigegeben. Unterstützt außerdem mehrere Schlüssel pro Provider mit LRU-Rotation.
Jede Anreicherung hält fest, welcher Schlüssel verwendet wurde, sodass Sie die Kosten pro Schlüssel nachverfolgen können. Schlüssel unterstützen Health Checks und Nutzungszähler. Innerhalb eines Pools wird als Nächstes der aktivierte Schlüssel mit dem ältesten Zeitstempel der letzten Verwendung gewählt; ein Schlüssel verlässt die Rotation nur, wenn Sie ihn manuell deaktivieren — ein Fehler des Anbieters nimmt also niemals unbemerkt einen Schlüssel außer Betrieb. Wie Sie Schlüssel verwalten, erfahren Sie im Leitfaden API Keys.
Exportieren Sie Ihre gesamte Provider- und Modellkonfiguration als JSON zur Sicherung oder Übertragung auf eine andere Instanz. Der Import ist immer ein Upsert: Bestehende Provider und Modelle werden anhand des Namens abgeglichen und an Ort und Stelle aktualisiert, während neue hinzugefügt werden – nichts wird gelöscht.
Der Export umfasst Anbietereinstellungen, Modellkonfigurationen, Preise, Funktionen und die kanonischen Modellspezifikationen – niemals jedoch API-Schlüssel, die separat gespeichert werden. Konfigurieren Sie API-Schlüssel nach dem Import separat. Systemadministratoren sichern den vollständigen globalen Katalog; Organisationsinhaber exportieren und importieren nur die Anbieter und Modelle ihrer eigenen Organisation – der gemeinsame globale Katalog kann nicht per Import erstellt oder bearbeitet werden.