Glossar

Schnelle Erklärungen zu Begriffen, die in diesen Dokumenten verwendet werden. Jeder Eintrag führt zur entsprechenden Seite mit detaillierten Informationen.

​

Tokens

Kleine Textabschnitte – meist nur wenige Zeichen oder ein Wortstück – die das Modell liest und verarbeitet. Ihre Eingabe wird in Tokens zerlegt, bevor das Modell sie verarbeitet; die Antwort entsteht ebenfalls Token für Token. Siehe Wie die Inferenz funktioniert.

​

Vorverarbeitung versus Dekodierung

Prefill is the model reading your entire prompt at once, before writing anything back — it’s compute-bound and is what “time to first token” measures. Decode is the model generating the reply one token at a time — it’s memory-bandwidth-bound and is what tokens/sec measures. See How inference works.

​

Dichte Modelle versus Modell-Mischungen aus Experten-Netzwerken (MoE)

Ein dichtes Modell verwendet alle Parameter für jedes Token. Ein Modell-Mischung aus Experten-Netzwerken – beispielsweise mit 30B-A3B bzw. 30B Gesamtparametern, wovon 3B aktiv sind – nutzt jeweils nur einen Teil der Parameter pro Token. Dadurch ist die Dekodierung schneller als bei einem dichten Modell gleicher Größe; dennoch muss der gesamte Parameterbestand im Speicher vorhanden sein. Siehe Eine Modellbeschreibung lesen.

​

Genauigkeit

Precision is how many bits the runtime uses to store or compute with each number in the model, such as bf16, FP16, FP8, or 4-bit formats. Lower precision usually means less memory and faster data movement, but it can reduce quality if the quantization is too aggressive. See Quantization and Quantization formats and the hardware they need.

​

Inferenz-Framework

Ein Inferenz-Framework ist die Engine, die das Modell lädt, Berechnungen ausführt, Batching sowie den KV-Cache verwaltet und außerdem eine API bereitstellt. Ollama und LM Studio sind auf eine einfache Nutzung vor Ort ausgelegt; vLLM, SGLang, llama.cpp, TensorRT-LLM sowie MLX bieten hingegen detailliertere Steuerungsmöglichkeiten hinsichtlich Durchsatz, Parallelität und hardware-spezifischen Kerneln. Weitere Informationen finden Sie unter Bereitstellung und Skalierung.

​

Kernel

Ein Kernel ist die unterste Ebene der GPU- oder CPU-Logik, die spezifische Operationen wie Matrixmultiplikation, Attention-Mechanismen, Quantisierungs- und Dequantisierungsvorgänge sowie Sampling durchführt. Quantisierungsformate sind nur dann nützlich, wenn die Laufzeitumgebung Kernel besitzt, die sie verstehen; beispielsweise erfordert NVFP4 Unterstützung durch Blackwell Tensor Cores, während GGUF mithilfe der llama.cpp-Backends breit einsetzbar ist. Weitere Details finden Sie unter Quantisierungsformate und benötigte Hardware.

​

Tensor-Parallelismus (TP)

Tensor-Parallelismus verteilt die Gewichte sowie Berechnungen einer Modellschicht auf mehrere GPUs. Er kommt zum Einsatz, wenn ein Modell für eine einzelne GPU zu groß ist oder wenn eine GPU nicht genügend Anfragen verarbeiten kann. Dadurch wird der Speicherbedarf pro GPU verringert; allerdings müssen die GPUs während jedes Vorwärtspasses synchronisiert werden, weshalb schnelle Verbindungen erforderlich sind. vLLM stellt dies über --tensor-parallel-size bereit; TensorRT-LLM beschreibt dieselbe Vorgehensweise unter dem Begriff TP. Weitere Informationen finden Sie unter Bereitstellung und Skalierung.

​

Datensparallelismus (DP)

Data parallelism runs separate copies of the model on separate GPUs or instances so each copy can process different requests. It increases request throughput when the model already fits per replica. vLLM’s data-parallel deployment docs describe this as replicating model weights across instances or GPUs to process independent batches. See Serving and scaling.

​

Experten-Parallelismus (EP)

Expert-Parallelismus kommt bei Modellen mit gemischten Experten zum Einsatz. Anstatt jeder GPU eine vollständige Kopie aller Experten zuzuweisen, platziert der Laufzeitumgebung verschiedene Experten auf unterschiedlichen GPUs und leitet Token an die GPU weiter, die den jeweiligen Experten verwaltet. Dadurch lässt sich die Lokalität sowie die Durchsatzrate bei großen MoE-Modellen verbessern; gleichzeitig entstehen jedoch zusätzlicher Routing- und Synchronisationsaufwand. Weitere Informationen finden Sie unter Bereitstellung und Skalierung.

​

Mehrfach-Token-Vorhersage (MTP)

Multi-token prediction trains or adds auxiliary heads that predict more than one future token. At inference time, runtimes can use those predictions for speculative decoding: draft several tokens, verify them with the target model, and keep the accepted tokens. The current DeepSeek-V4-Flash-0731 checkpoint bundles a related DSpark speculative-decoding module that vLLM enables with method: dspark and SGLang enables with DSPARK. See Serving and scaling.

​

Tool-Aufruf

Die Fähigkeit eines Modells, eine strukturierte Anfrage zum Aufruf einer externen Funktion oder eines Tools zurückzugeben – anstatt lediglich gewöhnlichen Text – damit agentische Clients entsprechende Aktionen ausführen können. Zuverlässiger Tool-Aufruf ist ein entscheidendes Auswahlkriterium für Coding-Agents sowie andere automatisierte Clients. Weitere Informationen finden Sie unter Welches lokale Modell für welche Aufgabe?.

​

Temperatur und Top-p

Einstellungen zur Stichprobenauswahl, die bestimmen, wie vorhersagbar oder abwechslungsreich die Ausgabe des Modells ausfällt. Eine niedrigere Temperatur führt zu deterministischeren und repetitiven Ergebnissen; eine höhere Temperatur erzeugt vielfältigere, gelegentlich weniger kohärente Ausgaben. Top-p (Nukleus-Stichprobenverfahren) begrenzt die Auswahl an Tokens auf jene Menge, deren Gesamtwahrscheinlichkeit genau p erreicht, wodurch unwahrscheinliche Optionen vor der Auswahl entfernt werden. Beide Parameter werden vom Client zusammen mit dem Prompt übermittelt.

​

Embeddings

Numerische Vektordarstellungen von Texten, die vor allem für Suchvorgänge, Informationsabruf sowie Vergleiche der Ähnlichkeit genutzt werden – nicht jedoch zur Erstellung von Gesprächsantworten. Embedding-Modelle stellen ein eigenständiges Werkzeug dar; sie unterscheiden sich von Chat-Modellen. Weitere Details dazu finden Sie unter Welches lokale Modell für welche Aufgabe?.

​

Kontextfenster

Die maximale Anzahl an Tokens, die ein Modell in einer einzigen Konversation verarbeiten kann – einschließlich Prompt und Antwort. Ein größeres Kontextfenster erlaubt die Verarbeitung umfangreicherer Texte, erhöht jedoch den Speicherbedarf durch den KV-Cache. Weitere Informationen finden Sie unter KV-Cache und Kontext.

​

Quantisierung

Die Speicherung der Gewichte eines Modells in geringerer numerischer Präzision, wodurch dessen Größe reduziert und die Inferenzgeschwindigkeit gesteigert wird – auf Kosten der Ausgabequalität. Bezeichnungen für GGUF-Quantisierungen wie Q4_K_M geben die verwendete Bitbreite sowie die Quantisierungsart an. Weitere Details finden Sie unter Quantisierung.

​

KV-Cache

Die fortlaufende Aufzeichnung der Schlüssel-Wert-Darstellungen, die das Modell während der Konversationsverarbeitung anlegt; dadurch muss es bei jedem neuen Token nicht erneut alle vorherigen Tokens verarbeiten. Die Größe des KV-Caches hängt von der Kontextlänge sowie der Batch-Größe ab; er belegt ebenso wie die Modellgewichte Speicherplatz. Weitere Informationen finden Sie unter KV-Cache und Kontext.

​

GGUF

Abkürzung für GGML Universal File – das Dateiformat, das von Backends auf Basis von llama.cpp (etwa Ollama und LM Studio) genutzt wird, um Modellgewichte zu speichern. Meist werden mehrere quantisierte Varianten desselben Modells bereitgestellt. Dieses Format löst die älteren GGML/GGJT-Formate ab; daher findet man in älteren Repositories und Tools noch den Begriff „GGML“. Lesen Sie dazu Anleitung zur Modellbeschreibung sowie die Spezifikationen des GGUF-Formats.

​

Nachdem das Vokabular nun erläutert wurde

Diese Begriffe tauchen ständig auf, sobald man Modelle lokal ausführt – speichern Sie diese Seite ab und kehren Sie immer wieder hierher zurück. Sobald ein Modell auf localhost läuft und Anfragen beantwortet, ist der logische nächste Schritt, es von einem anderen Rechner aus zu nutzen.