Zum Inhalt

AI-Provider einrichten

Drei Provider zur Wahl. Pro Instanz ist genau einer als Chat-Provider aktiv; das Embedding-Modell lässt sich unabhängig davon konfigurieren.

Ollama (lokal, empfohlen für Self-Hosting)

Vorteile

  • Anfragen an das Modell bleiben im Stack (die Web-Suche der KI geht trotzdem nach außen, siehe Datenschutz)
  • Keine API-Kosten
  • Kein Cloud-Konto nötig (das Ollama-Image und die Modelle werden einmalig aus dem Internet geladen)

Voraussetzungen

  • Mehrere GB RAM für ein brauchbares Modell — kleine 3B-Modelle laufen mit wenigen GB, größere Modelle brauchen deutlich mehr. Plane Ollama nicht auf einer knapp bemessenen Instanz ein.
  • GPU empfohlen, aber optional (NVIDIA mit nvidia-container-toolkit)
  • Disk-Platz für die heruntergeladenen Modelle

Aktivieren

Admin → System → KI:

  1. KI aktiviert einschalten — der Hauptschalter für Chat, Service-Analyse und Wiki-Embeddings.
  2. Karte Lokale KI (Ollama-Container) → Ollama aktivieren. Vesana lädt das Ollama-Image und startet den Container; das dauert beim ersten Mal einige Minuten. Die Einstellung bleibt über Updates erhalten.

Deaktivieren stoppt und entfernt den Container. Heruntergeladene Modelle bleiben standardmäßig erhalten; mit Heruntergeladene Modelle mitlöschen wird auch ihr Speicherplatz freigegeben.

Ohne Oberfläche geht es auch per .env — die Oberfläche schreibt denselben Wert:

# .env
COMPOSE_PROFILES=ai

docker compose --profile ai up -d ollama

GPU-Beschleunigung

Im Compose-File ist der GPU-Passthrough für den ollama-Service standardmäßig auskommentiert:

ollama:
  image: ollama/ollama:latest
  profiles: [ai]
  # Für GPU-Beschleunigung einkommentieren (nvidia-container-toolkit nötig):
  # deploy:
  #   resources:
  #     reservations:
  #       devices:
  #         - capabilities: [gpu]

Ohne GPU läuft Ollama auf der CPU — für kleinere Modelle brauchbar, für große spürbar langsamer.

Modell wählen

Admin → System → KI, Provider Ollama, Abschnitt Chat-Modell:

  • Vier vorgeschlagene Modelle, eins je Größenklasse (sehr klein bis groß), mit Download-Größe, Parameterzahl und der Einschätzung passt / knapp / zu groß — gemessen am freien Arbeitsspeicher des Servers (nur wenn Ollama auf demselben Server läuft). Empfohlen ist die größte Klasse, die bequem passt, sonst die kleinste, die knapp passt. Die Vorschläge kommen vom Vesana-Lizenz-Portal, das jede Nacht die aktuellen Modelle der Ollama-Bibliothek nachsieht; ist es nicht erreichbar, zeigt Vesana eine eingebaute Liste. Herunterladen lädt ein Modell, der Fortschritt streamt live; ein Klick auf ein installiertes Modell macht es zum aktiven Chat-Modell.
  • Anderes Modell verwenden: beliebigen Namen aus der Ollama-Bibliothek eintragen und mit Enter herunterladen.
  • Weitere installierte Modelle listet alles Übrige; installierte Modelle lassen sich dort auch wieder löschen.

Größere Modelle liefern in der Regel bessere Antworten, brauchen aber entsprechend mehr RAM/VRAM.

Die Server-Adresse von Ollama lässt sich unter Erweitert: Server-Adresse ändern auf eine eigene Ollama-Instanz umstellen.

Embedding-Modell (Wiki-Suche)

Nur sichtbar, wenn die Vorschau-Funktion „Wiki“ eingeschaltet ist. Abschnitt Wiki-Suche: nomic-embed-text herunterladen und per Klick aktivieren. Ist kein eigenes Embedding-Modell gesetzt, rechnet Vesana die Embeddings mit dem Chat-Modell — das geht, ist aber langsamer und ungenauer.

Anthropic (Cloud)

Voraussetzungen

  • Anthropic-Account + API-Key
  • Outbound-Zugriff auf die Anthropic-API

Konfiguration

Admin → System → KI:

  1. Provider: Anthropic
  2. API-Key aus der Anthropic-Console einsetzen — die API-URL setzt Vesana selbst
  3. Modellname eintragen, z. B. claude-haiku-4-5-20251001 (schnell, günstig), claude-sonnet-5 oder claude-opus-5. Der Name muss gesetzt sein; Vesana ersetzt ein leeres Feld nicht durch ein Standardmodell.
  4. Nur mit eingeschaltetem Wiki: Anthropic bietet keine Embedding-API. Für die semantische Wiki-Suche braucht es zusätzlich den Ollama-Container mit nomic-embed-text (Karte Lokale KI und Abschnitt Wiki-Suche erscheinen dafür auch beim Provider Anthropic). Ohne Embedding-Modell findet die KI Wiki-Artikel nur per Volltextsuche.

Vesana merkt sich pro Modell, welche Parameter es ablehnt, und lässt sie bei weiteren Anfragen weg — neuere Modelle, die z. B. keine Temperature annehmen, funktionieren dadurch ohne Zusatzeinstellung. Bei solchen Modellen hat die Temperature-Einstellung keine Wirkung.

Kosten

Pay-as-you-go pro Token, abhängig vom gewählten Modell und der Nutzung. Kosten in der Anthropic-Console im Blick behalten, besonders bei vielen Tenants/Usern.

Externer OpenAI-kompatibler Anbieter

Für vLLM, LM Studio, text-generation-inference oder andere Endpoints mit OpenAI-kompatibler Chat-Completion-API:

Admin → System → KI:

  1. Provider: Externer Anbieter
  2. API-URL als Basis-URL ohne /v1 eintragen (z. B. http://gpu-server:8080 oder https://api.openai.com) — Vesana hängt /v1/chat/completions, /v1/embeddings und /v1/models selbst an
  3. API-Key (falls vom Endpoint verlangt)
  4. exakter Modellname des Anbieters

Embeddings für die Wiki-Suche laufen bei diesem Provider über den /v1/embeddings-Endpunkt desselben Anbieters.

Verbindung testen

Testen fragt beim gewählten Provider die Modell-Liste ab (verbraucht keine Tokens) und zeigt, ob er erreichbar und der Key gültig ist.

API-Key und Adresse gehören zusammen

Ein gespeicherter API-Key wird nur an die Adresse geschickt, für die er gespeichert wurde. Wer den Anbieter oder die API-URL ändert, muss den Key neu eingeben — sonst lehnt Vesana das Speichern und den Test ab.

Konfigurierbare Parameter

Parameter Bedeutung
provider ollama / anthropic / external
model Chat-Modell
embed_model Embedding-Modell; leer = Chat-Modell (bei Anthropic immer über Ollama)
temperature Default 0,3, einstellbar 0–1 unter Erweiterte Einstellungen — niedrig = sachlich, hoch = kreativ
api_url / api_key für Anthropic und Extern (Key verschlüsselt gespeichert)

Weitere Sampling-Parameter (Output-Länge, Nucleus-Sampling) sind aktuell nicht separat in der Admin-Oberfläche einstellbar.

Verhalten bei Provider-Ausfall

Ist der konfigurierte Provider nicht erreichbar (Anthropic-Outage, Ollama-Container gestoppt, externer Endpoint down), schlägt die Anfrage mit einer Fehlermeldung fehl — es gibt bewusst keinen automatischen Wechsel auf einen anderen Provider, um keine überraschenden Cloud-Kosten oder unerwarteten Datenabfluss zu einem anderen Anbieter auszulösen. Gecachte Service-Analysen bleiben unabhängig davon abrufbar.

Permission

admin.system für die gesamte Provider-Konfiguration (Provider, Modell, API-Key, Modell-Installation/-Löschung, Verbindungstest). Speichern und Testen verlangen zusätzlich eine frische Identitätsbestätigung. Den Ollama-Container ein- und ausschalten darf nur ein Super-Admin. Andere User sehen nur, ob AI aktiv ist, ohne Zugriff auf Provider-Details.

Anschluss

  • AI-Chat & Analyse — wofür der Provider gebraucht wird
  • Wiki — Embeddings sind nur sinnvoll, wenn Wiki-Artikel gepflegt sind