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 mit einem API-Schlüssel getätigte Aufruf wird unter dem Budget getaktet, das der Anbieter diesem Schlüssel gewährt – Anfragen und Token pro Minute, je Modell –, sodass ein Fan-out nie in 429-Fehler läuft. Das Budget wird nicht eingetippt: Es wird aus den Antwort-Headern des Anbieters ausgelesen, aus einer Ablehnung gelernt, wenn der Anbieter nichts angibt, oder als letzte Möglichkeit von einem Eigentümer eingetragen.
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 → Modellauswahl pro Aufgabe ein bevorzugtes Modell 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, Health-Checks oder ein Fähigkeitstest, für den keine Route antwortet | Ja (per Preissynchronisierung oder Validierung) |
| Keine strukturierte Ausgabe | Fähigkeitstest: weder der Tool-Kanal noch der native Kanal auf irgendeiner erreichbaren Route | Ja, nur durch eine spätere Fähigkeitsprüfung |
| 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.
Die Modellseite zeigt allen den globalen Katalog: Anbieterpreise, gemessene Fähigkeiten und die Punktzahlen, die jedes Modell in den als globale Bewertungsquellen veröffentlichten Benchmark-Szenarien erzielt hat. Sie liest zwei statische JSON-Dateien, die beim nächtlichen Modellabgleich neu geschrieben werden und die Sie herunterladen und weiterverwenden können. Ein Modell, das der Anbieter nicht mehr bereitstellt (deaktiviert als „model not found“), wird ausgelassen; alle anderen Modelle des Katalogs werden aufgeführt.
/data/models.json — die Tabelle: ein Eintrag pro Provider × Modell, mit Nachschlagetabellen für Provider, Szenarien und Spezifikationen./data/benchmarks.json — jedes öffentliche Benchmark-Ergebnis, gruppiert nach Modellschlüssel.Beide werden mit einem ETag und einem einstündigen öffentlichen Cache ausgeliefert, gzip-kodiert, sofern der Client dies akzeptiert. Das Feld version wird bei jeder Änderung hochgezählt, an die sich ein Consumer anpassen müsste.
generated_at, counts, default_weightsWann die Datei geschrieben wurde, wie viele Modelle, Anbieter und Szenarien sie enthält und die Gewichtung aus Qualität / Geschwindigkeit / Kosten (in Prozent) hinter jeder Gesamtpunktzahl.providers[], scenarios[], specs{}Nachschlagetabellen: Modelle verweisen per Index auf einen Anbieter und auf die Szenarien; specs sind die öffentlichen Benchmark-Scores der Modellgewichte (intelligence, coding, math und der Rest unter extra), abgelegt nach kanonischem Schlüssel, sodass Reseller desselben Modells sie gemeinsam nutzen.models[].key, model, display_name, canonical_keyDer zusammengesetzte Schlüssel, den die API akzeptiert (provider::model), die rohe Modell-ID, ihre Bezeichnung und die anbieterübergreifende Identität.models[].pricingListenpreise des Anbieters in USD pro Million Tokens: input, output, cache_read, cache_write, cache_write_1h, reasoning_output, sowie web_search_per_query mit zugehöriger Einheit. Vor jeglicher Tarifprovision.models[].capabilities[]Die zutreffenden Flags: vision, pdf_input, audio_input, audio_output, video_input, tool_calls, tool_choice, response_schema, strict_structured_output, reasoning, reasoning_effort, web_search, prompt_caching, embeddings, requires_streaming. Ein fehlendes Flag bedeutet false oder nicht gemessen.models[].context_length, max_input_tokens, max_output_tokens, deprecation_date, latencyLimits, das Abkündigungsdatum des Herstellers, sofern angekündigt, und die erfassten Latenzwerte (Tokens pro Sekunde, Zeit bis zum ersten Token).models[].enrichment_capable, disabled_tasks[]Ob das Modell überhaupt einen Kanal für strukturierte Ausgabe besitzt und für welche Aufgaben die App ihn nie anbietet (Klassifizierung und Arbitrierung benötigen Tool-Aufrufe; Schema- und Beispielgenerierung folgen der Sperre für die Schemagenerierung).models[].scores{task}Pro Aufgabentyp (enrichment, schema_generation, sample_generation): der Mittelwert von Qualität, Geschwindigkeit und Kosten über die öffentlichen Szenarien dieser Aufgabe, der Gesamtwert bei den Standardgewichtungen sowie die Szenario-Indizes. Geschwindigkeit und Kosten sind relativ zu den anderen Modellen im selben Szenario.Wie die Qualitäts-, Geschwindigkeits- und Kosten-Scores berechnet werden, wird in Benchmark Scoring erklärt.