Model-Provider¶
Agentlab bringt drei eigene Model-Provider mit — KARLI, KARLI (AISL) und tokeneurope — neben den Standard-Langflow-Providern (OpenAI, Anthropic usw.). Anders als in früheren Versionen gibt es keine dedizierte Komponente „KARLI Model Provider" — Provider werden über die Standard-Langflow-Modellkomponenten angesprochen.
Die Modelle sind nach Typ gegliedert:
- LLMs — Chat-Modelle von KARLI, KARLI (AISL) und tokeneurope, wählbar in jeder modell-fähigen Komponente (Language Model, Agent usw.).
- Embeddings — Embedding-Modelle von KARLI und KARLI (AISL), wählbar in der Embedding-Model-Komponente.
- Datenextraktion — Dokument- und Audio-Extraktions-Modelle, von der Read File-Komponente genutzt, wenn ihr Backend auf
karlioderaislsteht. KARLI und KARLI (AISL) sind die einzigen Anbieter in dieser Kategorie.
KARLI¶
KARLI ist der Standard-Provider und bietet LLMs, Embeddings und Dokumentextraktion über die KARLI-Plattform.
Zugangsdaten¶
Der KARLI-Provider nutzt zwei getrennte Endpoints — einen LiteLLM-Proxy für LLM-Inferenz (inkl. Tool Calling) und das KARLI-Backend für Dienste wie Dokumentextraktion. Jeder Endpoint hat eine eigene Basis-URL und einen eigenen API-Key.
| Variable | Pflicht | Secret | Beschreibung |
|---|---|---|---|
LITELLM_BASE_URL |
Nein | Nein | Basis-URL des LiteLLM-Proxys für LLM-Inferenz. Fällt auf die Umgebungsvariable LITELLM_BASE_URL zurück; ohne Konfiguration gilt der Produktions-Endpoint. |
LITELLM_API_KEY |
Ja | Ja | API-Key für LLM-Inferenz über den LiteLLM-Proxy. Fällt auf die Umgebungsvariable LITELLM_API_KEY zurück. |
KARLI_BASE_URL |
Nein | Nein | Basis-URL des KARLI-Backends (für Dokumentextraktion und andere Backend-Dienste). Fällt auf die Umgebungsvariable KARLI_BASE_URL zurück. |
KARLI_API_KEY |
Nein | Ja | API-Key für KARLI-Backend-Dienste (z. B. Dokumentextraktion). Fällt auf die Umgebungsvariable KARLI_API_KEY zurück. |
Wann wird KARLI_API_KEY benötigt?
Nur beim direkten Zugriff auf die Agentlab-API ohne Karli-Studio-Session. Beim Zugang über Karli Studio wird automatisch ein JWT verwendet und dieses Feld ignoriert. Leer lassen, wenn Studio genutzt wird.
KARLI_API_KEY ist ein separater Schlüssel von LITELLM_API_KEY. Der LiteLLM-Key deckt Modellinferenz ab; der KARLI-Key deckt Backend-Dienste wie Dokumentextraktion ab.
KARLI (AISL)¶
KARLI (AISL) erreicht den AI Service Layer — ein einzelnes Gateway vor Chat, Embeddings und Dokumentextraktion — mit einer einzigen Zugangsberechtigung statt der zwei Basis-URLs und zwei Schlüssel des KARLI-Providers.
Beide Provider bieten derzeit nicht dieselben Modelle an. Der Katalog von AISL wird vom Gateway gelesen und spiegelt daher wider, was die jeweilige Instanz tatsächlich anbietet; die Modellnamen werden sich an die von KARLI angleichen, sobald das Gateway sie übernimmt.
Beide Provider können gleichzeitig aktiv sein. KARLI bleibt bis zur Umstellung auf den eigenen Kubernetes-Stack im Produktivsystem in Betrieb — dieser Provider kommt also additiv hinzu, bestehende Flows laufen unverändert weiter auf KARLI.
Zugangsdaten¶
Da ein Gateway alle Dienste bedient, gibt es genau einen Schlüssel und keine Basis-URLs in der Oberfläche:
| Variable | Pflicht | Secret | Beschreibung |
|---|---|---|---|
AISL_API_KEY |
Ja | Ja | API-Key für den AI Service Layer — deckt Chat, Embeddings und Dokumentextraktion gemeinsam ab. Fällt auf die Umgebungsvariable AISL_API_KEY zurück. |
Die Gateway-Adresse ist eine Instanz-Einstellung, die vom Betrieb gesetzt wird und im Provider-Formular nicht erscheint:
| Umgebungsvariable | Pflicht | Beschreibung |
|---|---|---|
AISL_BASE_URL |
Ja | Root-URL des AI-Service-Layer-Gateways, z. B. https://gateway.dev.aisl.karli.ai. Chat und Embeddings laufen über {AISL_BASE_URL}/v1, die Extraktion über {AISL_BASE_URL}/api/v1. |
Wann wird AISL_API_KEY benötigt?
Dieselbe Regel wie bei KARLI: nur beim direkten Zugriff auf die Agentlab-API ohne Karli-Studio-Session. Über Karli Studio wird für die Dokumentextraktion automatisch ein JWT verwendet.
Dokumentextraktion erfordert Object Storage
Die AISL-docparse-API lädt das Dokument selbst über eine vorsignierte URL herunter, statt einen Upload entgegenzunehmen. Das setzt LANGFLOW_STORAGE_TYPE=s3 voraus; auf Instanzen mit lokalem Dateispeicher stattdessen das Extraktions-Backend docling oder den Provider KARLI verwenden.
Modellkatalog¶
Die Chat- und Embedding-Listen werden live von {AISL_BASE_URL}/v1/models gelesen, die Extraktionsliste von {AISL_BASE_URL}/api/v1/services?type=docparse. Ist das Gateway nicht erreichbar, greift ein mitgelieferter Katalog, damit die Auswahllisten gefüllt bleiben.
tokeneurope¶
tokeneurope ist ein europäisch gehosteter Model-Provider mit OpenAI-kompatibler LLM-Schnittstelle. Wie KARLI erscheint er als wählbarer Provider in jeder modell-fähigen Komponente.
Zugangsdaten¶
| Variable | Pflicht | Secret | Beschreibung |
|---|---|---|---|
TOKENEUROPE_BASE_URL |
Nein | Nein | Basis-URL für den tokeneurope-Endpoint. Fällt auf die Umgebungsvariable TOKENEUROPE_BASE_URL zurück. |
TOKENEUROPE_API_KEY |
Ja | Ja | API-Key für tokeneurope-Modellinferenz. Fällt auf die Umgebungsvariable TOKENEUROPE_API_KEY zurück. |
tokeneurope bietet derzeit ausschließlich LLMs — Embedding- oder Datenextraktions-Modelle sind nicht verfügbar.
Verfügbare Provider einschränken¶
Eine Instanz lässt sich über die Umgebungsvariable MODEL_PROVIDERS auf eine Teilmenge der Provider begrenzen — eine kommaseparierte Liste der Provider-Namen, exakt wie oben geschrieben:
MODEL_PROVIDERS=KARLI,KARLI (AISL),Ollama
Nicht gesetzt oder leer bedeutet keine Einschränkung. Namen ohne passenden Provider werden ignoriert.
Dies ist eine Beschränkung auf Betriebsebene und unabhängig von der Konfiguration der Zugangsdaten: Ein Provider wird normalerweise angeboten, sobald jemand seinen API-Key hinterlegt — ein Provider, der in MODEL_PROVIDERS fehlt, bleibt jedoch auch mit hinterlegtem Key ausgeblendet. Die Liste wirkt auf alle Modell-Auswahllisten (LLM, Embedding, Extraktion), die /api/v1/models-API und die Provider-Abfrage des Builder-Assistenten.
Datensouveränität
Für Deployments mit Anforderungen an Datensouveränität beschränkt MODEL_PROVIDERS die Instanz auf genehmigte Provider, und die Karli-Studio-Administration steuert auf Plattform-Ebene, welche Provider freigeschaltet sind, sodass nur Modelle aus genehmigten Regionen erreichbar sind.