llm mode

llm mode schaltet das Chat-Backend eines Mandanten in einem Schritt um — also das Sprachmodell, das Apparat für den Dialog mit dem Vault nutzt. Damit wechselst du bequem zwischen Betriebsarten:

Der eigentliche Aufwand beim Umschalten ist eine Handvoll Einstellungen in der Umgebung des Mandanten. llm mode schreibt genau die und baut anschließend den Container des Mandanten neu auf, damit die neue Konfiguration greift — du tippst ein Wort statt fünf Zeilen plus Neustart.

Nur der Chat wird pro Mandant umgeschaltet. Die Bedeutungssuche (Embeddings) läuft in einem geteilten Hintergrunddienst, der alle Mandanten zugleich bedient — sie hat installationsweit eine Konfiguration und wird von llm mode bewusst nicht angetastet. Umgeschaltet wird also das Sprachmodell des Dialogs, nicht das Embedding-Modell.

Aktiven Modus anzeigen

Ohne Argument zeigt das Kommando, welcher Modus für den Mandanten gerade aktiv ist:

apparat llm mode

LLM:
  driver:   ollama
  endpoint: http://ollama:11434
  model:    qwen2.5:7b-instruct
  auth:     none
Embedding:
  driver:   ollama
  endpoint: http://ollama:11434
  model:    jina/jina-embeddings-v2-base-de
  auth:     none

Reachability: apparat vector:ping && apparat chat:ping

Die Anzeige nimmt selbst keine Verbindung auf. Ob die Dienste antworten, prüfen vector ping und chat ping.

Auf lokal zurückstellen

apparat llm mode local

Setzt das Chat-Modell des Mandanten auf den mitgelieferten lokalen Container zurück. Jeder vorher gesetzte Wert (Endpunkt, Modell, Zugangstoken) wird sauber überschrieben; du musst nichts von Hand zurückräumen.

Auf ein Profil umstellen

Ein Profil bündelt die Zugangsdaten eines Chat-Backends. Die Profildateien liegen pro Mandant unter llm-profiles/<mandant>/<profil>.env — bewusst nicht mitversioniert, damit der Zugangstoken niemals im Repository landet. Lege die Datei einmalig an, zum Beispiel als Profil studio für den Mandanten local:

# llm-profiles/local/studio.env
APPARAT_LLM_DRIVER=openai
APPARAT_LLM_ENDPOINT=http://192.168.10.20:8001
APPARAT_LLM_MODEL=qwen3.6-35b-a3b
APPARAT_LLM_API_KEY=<zugangstoken>
APPARAT_LLM_THINKING=false

Die Adresse ist die Basis-URL ohne /v1 — Apparat hängt den Rest selbst an. Der Zugangstoken ist optional; ein Endpunkt ohne Anmeldung lässt die API_KEY-Zeile weg. Das Profil enthält nur die fünf Chat-Schlüssel; Embedding-Werte gehören nicht hinein (sie sind geteilt).

Danach genügt der Profilname:

apparat llm mode studio

Das Kommando übernimmt die Profilwerte, ergänzt fehlende Schlüssel aus dem lokalen Standard, zeigt maskiert, was sich geändert hat, und baut den Web-Container des Mandanten neu auf, damit die Konfiguration sofort greift. Ein Neustart allein würde die neue Umgebung nicht einlesen — sie wird beim Erzeugen des Containers gesetzt.

Zum Prüfen, ob das Backend antwortet:

apparat vector ping && apparat chat ping

Mehrere Mandanten

Läuft mehr als ein Mandant, wählst du den Ziel-Mandanten wie überall in der CLI — per --tenant:

apparat llm mode studio --tenant=redaktion

Ohne Angabe nimmt das Kommando den einzigen vorhandenen Mandanten; bei mehreren ohne Wahl fragt es nach (am Terminal) bzw. verweigert (im Skript). Jeder Mandant hat seine eigenen Profildateien unter llm-profiles/<mandant>/ und seine eigene Chat-Konfiguration — ein Mandant sieht das Backend eines anderen nie.

Ohne Neuaufbau schreiben

Soll das Kommando nur die Datei schreiben, ohne den Container neu aufzubauen, unterdrückt --no-restart den Schritt und nennt stattdessen das Recreate-Kommando zum späteren Anwenden:

apparat llm mode studio --no-restart

Das ist auf dem Produktivserver der Regelfall: dort schreibt llm mode die Konfiguration, den Neuaufbau des Mandanten-Containers löst der Betreiber im eigenen Compose-Projekt aus (siehe die Betriebsdokumentation).