Zum Inhalt

Modellrouting

Stand: 2026-05-30

Konzept

User sehen genau ein Modell: Lanstyle AI. Das Routing entscheidet intern welches Backend-Modell genutzt wird. User muessen keine Modellauswahl treffen.

Modelle

Alias Backend Sichtbarkeit Zweck
lanstyle/ai qwen3:32b alle User Hauptmodell fuer alle Aufgaben
lanstyle/architect qwen3:32b intern/admin komplexe Planung (gleicher Backend)
lanstyle/agent-stable qwen3:32b intern/admin OpenCode Agent Sessions
lanstyle/fast qwen3:32b intern/admin schnelle Checks, Voice-Antwortbeginn
lanstyle/embed nomic-embed-text:latest intern RAG Embeddings

Backend-Modelle auf GB10

Modell Groesse Typ Einsatz
qwen3:32b 20 GB Dense Q4_K_M Hauptmodell: Reasoning, Ops, Coding, Tool-Calling
qwen3:235b-a22b 142 GB MoE Q4_K_M Installiert, aber nicht aktiv: ueberschreitet GB10 GPU-VRAM
nomic-embed-text:latest 274 MB Embedding RAG/Knowledge Vektoren

VRAM-Budget (GB10 DGX Spark, 128 GB Unified Memory)

qwen3:235b-a22b belegt ~142 GB. Durch MoE-Architektur (nur 22B aktiv pro Token) und Unified Memory funktioniert das mit minimalem Swap.

Routing-Regeln

  • Alle User-Anfragen (OpenWebUI, OpenCode) laufen ueber lanstyle/ai.
  • Der Lanstyle AI Gateway kann intern lanstyle/fast fuer Voice-Kurzantworten waehlen.
  • lanstyle/architect ist der gleiche Backend wie lanstyle/ai (kein Modellwechsel noetig).
  • Experimentelle Modelle (qwen3.6:35b-a3b) sind nicht im produktiven Routing.

LiteLLM Virtual Keys

Key Modelle Zweck
lanstyle-openwebui nur lanstyle/ai Open WebUI Benutzer
OpenCode Operator Keys alle lanstyle/* OpenCode CLI Admin

Open WebUI

User sehen nur Lanstyle AI als Modell. Kein Modell-Picker, kein Verwirrungspotenzial. Die Tools (hermes_context_search, Infrastruktur-Abfragen) sind automatisch verfuegbar.