Lokaler LLM-Glossar

Du merkst bei LLM-Themen schnell: Die Begriffe klingen simpel, aber in der Praxis entscheiden sie über Kosten, Stabilität und Nerven. Hier sind die wichtigsten Begriffe so erklärt, wie man sie im Betrieb wirklich braucht.

Token

Praxis-Szenario: Dein Agent antwortet plötzlich teuer und langsam, obwohl du „nur ein paar Sätze“ geschickt hast.

  • Was ist das wirklich: Die kleinste Recheneinheit fürs Modell – nicht Wörter, sondern Text-Schnipsel.
  • Warum relevant: Kosten, Latenz und Limits hängen direkt an Tokenzahl.
  • Typische Missverständnisse: „Kurz im UI = wenig Tokens“ stimmt oft nicht, vor allem mit langen Systemprompts.
  • Wann man es NICHT braucht: Bei Mini-Demos. Sobald du produktiv gehst, musst du es messen.

Kontextfenster (Context Window)

Praxis-Szenario: Der Bot „vergisst“ nach ein paar Nachrichten die Hälfte vom Thread.

  • Was ist das wirklich: Maximaler Token-Speicher, den das Modell pro Request sieht.
  • Warum relevant: Bestimmt, wie viel Verlauf, Doku und Tool-Output du stabil mitgeben kannst.
  • Typische Missverständnisse: Großes Fenster heißt nicht automatisch gute Langzeitlogik.
  • Wann man es NICHT braucht: Single-shot Q&A ohne Verlauf.

Embedding

Praxis-Szenario: Suche findet irrelevanten Müll, obwohl die Infos in deinen Docs stehen.

  • Was ist das wirklich: Numerische Repräsentation von Textbedeutung als Vektor.
  • Warum relevant: Basis für semantische Suche, RAG und gute Wissens-Treffer.
  • Typische Missverständnisse: Embeddings sind keine „Mini-LLMs“ – sie erzeugen keine Antworten.
  • Wann man es NICHT braucht: Wenn du nur keyword-basierte Volltextsuche brauchst.

RAG (Retrieval-Augmented Generation)

Praxis-Szenario: Der Assistent halluziniert interne Prozesse, obwohl die Doku existiert.

  • Was ist das wirklich: Antworten + vorheriger Dokumentenabruf statt blindem Modellwissen.
  • Warum relevant: Aktuelle, überprüfbare Antworten aus deinem echten Wissensbestand.
  • Typische Missverständnisse: „RAG löst Halluzinationen komplett“ – nein, schlechte Retrieval-Pipeline liefert schlechte Antworten.
  • Wann man es NICHT braucht: Für rein allgemeines Wissen ohne interne Datenquellen.

Vektordatenbank

Praxis-Szenario: Mit 5.000+ Dokumenten wird deine Suche zäh und ungenau.

  • Was ist das wirklich: DB für Ähnlichkeitssuche auf Embedding-Vektoren (z. B. Qdrant, Weaviate).
  • Warum relevant: Macht semantische Suche bei großen Datenmengen erst praktikabel.
  • Typische Missverständnisse: „Ich brauche sofort eine Vektordatenbank“ – bei kleinen Sets reicht oft erstmal SQLite + gutes Chunking.
  • Wann man es NICHT braucht: Reality Check: In 80% kleiner interner Setups am Anfang nicht nötig.

Chunking

Praxis-Szenario: RAG findet Texte, aber die Antwort wirkt trotzdem zusammenhanglos.

  • Was ist das wirklich: Aufteilen von Dokumenten in sinnvolle Abschnitte fürs Retrieval.
  • Warum relevant: Falsche Chunkgröße zerstört Relevanz und Kontext.
  • Typische Missverständnisse: „Je kleiner desto besser“ – zu kleine Chunks verlieren Bedeutung.
  • Wann man es NICHT braucht: Bei sehr kurzen, klar strukturierten Einzeltexten.

System Prompt

Praxis-Szenario: Das Modell antwortet jeden Tag anders, obwohl Userfragen gleich sind.

  • Was ist das wirklich: Oberste Verhaltensregel für Stil, Grenzen und Prioritäten.
  • Warum relevant: Ohne sauberen Systemprompt kein reproduzierbares Verhalten.
  • Typische Missverständnisse: „Langer Prompt = besser“ – oft wird’s nur teuer und widersprüchlich.
  • Wann man es NICHT braucht: Quasi nie in produktiven Agenten-Setups.

Temperature

Praxis-Szenario: Antworten schwanken zu stark zwischen „genial“ und „komplett daneben“.

  • Was ist das wirklich: Regler für Zufälligkeit bei der Token-Auswahl.
  • Warum relevant: Niedrig = stabil/konservativ, hoch = kreativer aber riskanter.
  • Typische Missverständnisse: „Mehr Temperature = intelligenter“ – nein, nur variabler.
  • Wann man es NICHT braucht: Bei deterministischen Tasks (Extraktion, Klassifikation, Routing).

Top-k / Top-p (Sampling)

Praxis-Szenario: Du drehst Temperature, aber das Verhalten bleibt merkwürdig inkonsistent.

  • Was ist das wirklich: Zusätzliche Auswahlregeln, welche Kandidaten-Tokens überhaupt in Frage kommen.
  • Warum relevant: Feintuning für Stil und Stabilität jenseits von Temperature.
  • Typische Missverständnisse: Alles gleichzeitig hochdrehen macht’s nicht „besser“, nur chaotischer.
  • Wann man es NICHT braucht: Bei Standard-Chatbots mit guten Defaults.

Halluzination

Praxis-Szenario: Der Bot liefert selbstsichere Antworten mit komplett erfundenen Details.

  • Was ist das wirklich: Sprachlich plausible, aber faktisch falsche Ausgabe.
  • Warum relevant: Größtes Risiko bei Support, Compliance und internen Entscheidungen.
  • Typische Missverständnisse: „Neues Modell = keine Halluzinationen mehr“ – Wunschdenken.
  • Wann man es NICHT braucht: Der Begriff ist immer relevant, sobald Fakten wichtig sind.

Inference (Inferenz)

Praxis-Szenario: Alles läuft im Test, aber unter Last bricht Antwortzeit ein.

  • Was ist das wirklich: Ausführung des Modells zur Laufzeit (Antwortgenerierung).
  • Warum relevant: Hier entstehen Kosten, Wartezeit und Skalierungsprobleme.
  • Typische Missverständnisse: Training ist „das Teure“ – im Alltag frisst oft Inferenz das Budget.
  • Wann man es NICHT braucht: Nur wenn du Modelle gar nicht selbst betreibst und alles managed einkaufst.

Latenz

Praxis-Szenario: Nutzer brechen ab, obwohl Antwortqualität okay ist.

  • Was ist das wirklich: Zeit vom Request bis zur (ersten/vollen) Antwort.
  • Warum relevant: UX-Killer Nummer 1 in Chat-Anwendungen.
  • Typische Missverständnisse: Nur Tokens/s zählen – nein, TTFT ist oft wichtiger.
  • Wann man es NICHT braucht: Offline-Batchjobs ohne Interaktion.

Durchsatz (Throughput)

Praxis-Szenario: Ein User ist schnell, zehn parallele User machen alles langsam.

  • Was ist das wirklich: Menge an Requests/Tokens, die dein System pro Zeit schafft.
  • Warum relevant: Entscheidet, ob dein Setup Lastspitzen überlebt.
  • Typische Missverständnisse: Gute Single-User-Performance heißt nicht gute Multi-User-Performance.
  • Wann man es NICHT braucht: Solo-Tools ohne Parallelbetrieb.

Batching

Praxis-Szenario: GPU ist teuer, aber Auslastung bleibt erbärmlich niedrig.

  • Was ist das wirklich: Zusammenfassen mehrerer Requests zur effizienteren Modellverarbeitung.
  • Warum relevant: Mehr Throughput pro Hardware-Euro.
  • Typische Missverständnisse: Größeres Batch ist immer besser – kann Latenz brutal verschlechtern.
  • Wann man es NICHT braucht: Bei strikter Echtzeit-UX mit sehr wenigen Requests.

Speculative Decoding

Praxis-Szenario: Du brauchst schnellere Antworten, willst aber kein schwächeres Modell.

  • Was ist das wirklich: Vorschau-Generierung mit kleinem Modell, die vom großen Modell bestätigt wird.
  • Warum relevant: Kann Latenz spürbar drücken, ohne Qualität komplett zu opfern.
  • Typische Missverständnisse: „Gratis Speed“ – Setup und Tuning sind nicht trivial.
  • Wann man es NICHT braucht: Reality Check: Für kleine Setups oft overengineered.

Fine-Tuning

Praxis-Szenario: Prompts werden immer länger, aber das Verhalten bleibt trotzdem inkonsistent.

  • Was ist das wirklich: Nachtrainieren eines Modells auf deinen Daten/Tasks.
  • Warum relevant: Stabileres Verhalten und weniger Prompt-Akrobatik.
  • Typische Missverständnisse: Fine-Tuning ersetzt RAG – nein, sind unterschiedliche Werkzeuge.
  • Wann man es NICHT braucht: Wenn gutes Prompting + RAG dein Problem schon löst.

LoRA

Praxis-Szenario: Voll-Fine-Tuning ist zu teuer, aber du brauchst Domain-Anpassung.

  • Was ist das wirklich: Parameter-effizientes Fine-Tuning über zusätzliche Adapter-Gewichte.
  • Warum relevant: Viel günstiger als komplettes Modell neu zu trainieren.
  • Typische Missverständnisse: LoRA macht jedes Modell automatisch „domänenscharf“ – Datenqualität bleibt der Boss.
  • Wann man es NICHT braucht: Wenn du nur Stil/Outputformat steuern willst.

QLoRA

Praxis-Szenario: Du willst LoRA nutzen, hast aber keine Monster-GPU im Rack.

  • Was ist das wirklich: LoRA-Training auf quantisierten Gewichten, um Speicher zu sparen.
  • Warum relevant: Macht Fine-Tuning auf kleinerer Hardware realistisch.
  • Typische Missverständnisse: „Gleich gut wie Full Precision in jedem Fall“ – kommt auf Task und Daten an.
  • Wann man es NICHT braucht: Wenn du gar nicht tunen musst.

Prompt Injection

Praxis-Szenario: Usertext versucht plötzlich, deine internen Regeln zu überschreiben.

  • Was ist das wirklich: Manipulation des Modells über bösartige Instruktionen im Input oder in Quellen.
  • Warum relevant: Sicherheitsrisiko für Datenzugriff, Tool-Nutzung und Aktionen.
  • Typische Missverständnisse: „Ein langer Systemprompt schützt komplett“ – nein, nur Defense-in-Depth hilft.
  • Wann man es NICHT braucht: Nie ignorieren, sobald externe Inhalte verarbeitet werden.

Guardrails

Praxis-Szenario: Ein Agent darf Tools ausführen und soll trotzdem keinen Blödsinn anrichten.

  • Was ist das wirklich: Technische + prozessuale Schutzschichten (Policies, Validatoren, Tool-Gates).
  • Warum relevant: Macht den Unterschied zwischen Demo und verantwortbarem Betrieb.
  • Typische Missverständnisse: Guardrails sind nur „Content-Filter“ – nein, sie müssen auch Aktionen absichern.
  • Wann man es NICHT braucht: Nur bei komplett isolierten Spielwiesen ohne echte Wirkung.

Hinweis: Wenn du merkst, dass ein Begriff nur theoretisch „cool“ klingt, aber kein echtes Problem bei dir löst: weglassen. Das spart Komplexität und Geld.

Abkürzungen schnell erklärt (die man ständig hört)

Wenn du in LLM-Threads das Gefühl hast, alle reden in Geheimcode: völlig normal. Hier sind die Kürzel, die in der Praxis wirklich zählen.

RAG

Retrieval-Augmented Generation

  • Was ist das wirklich: Modell + Dokumentenabruf vor der Antwort.
  • Warum relevant: Holt Fakten aus deinen echten Quellen statt aus dem Modell-Bauchgefühl.
  • Typische Missverständnisse: „Mit RAG halluziniert nichts mehr.“ Leider nein.
  • Wann man es NICHT braucht: Wenn du keine eigene Wissensbasis anbinden willst.

MoE

Mixture of Experts

  • Was ist das wirklich: Mixture of Experts – pro Token werden nur Teile des Modells aktiv.
  • Warum relevant: Gute Qualität bei besserer Effizienz möglich.
  • Typische Missverständnisse: Mehr Experts = automatisch besser.
  • Wann man es NICHT braucht: Für Nutzer ist oft nur Latenz/Qualität wichtig, nicht die Architektur.

SFT

Supervised Fine-Tuning

  • Was ist das wirklich: Supervised Fine-Tuning auf gelabelten Beispielen.
  • Warum relevant: Bringt Modellverhalten in eine gewünschte Richtung.
  • Typische Missverständnisse: SFT löst jede Domänenfrage ohne gute Datenqualität.
  • Wann man es NICHT braucht: Wenn Prompt + RAG dein Problem schon sauber lösen.

RLHF / DPO

RLHF = Reinforcement Learning from Human Feedback · DPO = Direct Preference Optimization

  • Was ist das wirklich: Verfahren zur Verhaltensanpassung anhand Präferenzen (klassisch RLHF, moderner oft DPO).
  • Warum relevant: Formt Ton, Sicherheitsverhalten und Antwortstil.
  • Typische Missverständnisse: Das macht Modelle „wahr“ statt nur „angenehm“.
  • Wann man es NICHT braucht: Für kleine Inhouse-Use-Cases meist overkill.

LoRA / QLoRA / PEFT

LoRA = Low-Rank Adaptation · QLoRA = Quantized LoRA · PEFT = Parameter-Efficient Fine-Tuning

  • Was ist das wirklich: Parameter-effiziente Fine-Tuning-Methoden.
  • Warum relevant: Spart Hardware und Geld beim Tuning.
  • Typische Missverständnisse: „PEFT“ = ein einzelnes Verfahren (es ist eine Familie).
  • Wann man es NICHT braucht: Wenn du gar nicht trainieren musst.

GGUF / GPTQ / AWQ

GGUF = GGML Unified Format · GPTQ = Generalized Post-Training Quantization · AWQ = Activation-Aware Weight Quantization

  • Was ist das wirklich: Formate/Methoden rund um quantisierte Modelle (lokale Inferenz).
  • Warum relevant: Entscheidet, ob ein Modell auf deiner Hardware überhaupt läuft.
  • Typische Missverständnisse: Jede Quantisierung sei qualitativ gleich.
  • Wann man es NICHT braucht: Wenn du nur gehostete APIs nutzt.

FP16 / BF16 / FP8 / INT8 / INT4

FP16 = 16-bit Floating Point · BF16 = BFloat16 · FP8 = 8-bit Floating Point

  • Was ist das wirklich: Numerische Präzision beim Rechnen/Speichern.
  • Warum relevant: Direkter Hebel auf Speicherbedarf, Tempo und Qualität.
  • Typische Missverständnisse: Niedrigere Präzision ist immer „gleich gut, nur schneller“.
  • Wann man es NICHT braucht: Bei reinem API-Use ohne eigenen Inferenzbetrieb.

KV-Cache

Key-Value Cache

  • Was ist das wirklich: Zwischenspeicher für Attention-Zustände.
  • Warum relevant: Frisst bei langen Kontexten schnell viel VRAM.
  • Typische Missverständnisse: Nur Modellgewichte seien relevant für Speicherplanung.
  • Wann man es NICHT braucht: Bei ultrakurzen Inputs ohne Verlauf.

TTFT / TPS

TTFT = Time to First Token · TPS = Tokens per Second

  • Was ist das wirklich: Time to First Token und Tokens per Second.
  • Warum relevant: TTFT prägt UX, TPS prägt Durchsatz/Kosten.
  • Typische Missverständnisse: Nur TPS zählt.
  • Wann man es NICHT braucht: Offline-Batchjobs ohne Nutzerinteraktion.

P50 / P95 / P99

Latency Percentiles

  • Was ist das wirklich: Latenz-Perzentile statt Durchschnitt.
  • Warum relevant: Zeigt Ausreißer, die echte Nutzer treffen.
  • Typische Missverständnisse: Durchschnittslatenz reicht als KPI.
  • Wann man es NICHT braucht: Fast nie, sobald mehrere Nutzer da sind.

VRAM / OOM

VRAM = Video RAM · OOM = Out of Memory

  • Was ist das wirklich: GPU-Speicher und „Out of Memory“ Fehler.
  • Warum relevant: Hauptgrund, warum Setups in der Praxis scheitern.
  • Typische Missverständnisse: „Mehr RAM im Server“ behebt GPU-OOM.
  • Wann man es NICHT braucht: CPU-only Demos ohne Lastanspruch.

TGI / vLLM / LiteLLM

TGI = Text Generation Inference · vLLM = Virtual LLM Engine · LiteLLM = LLM Gateway/Router

  • Was ist das wirklich: Inferenz- und Gateway-Tools für Modellbetrieb.
  • Warum relevant: Bestimmen Routing, Stabilität, Observability und Kostenkontrolle.
  • Typische Missverständnisse: Das seien austauschbare „Starterkits“ ohne Architekturfolgen.
  • Wann man es NICHT braucht: Bei reinem Einzelmodell-Experiment ohne Produktivanspruch.

👉 Reality Check: Wenn du bei drei Abkürzungen schon Bauchweh bekommst, brauchst du nicht mehr Begriffe – du brauchst ein kleineres, stabileres Setup.