LLMs verständlich erklärt: Training, Modellgröße, Quantisierung und K-Quants

LLMs wirken von außen oft wie Magie. Man tippt eine Frage ein, bekommt eine überraschend brauchbare Antwort zurück und hat schnell das Gefühl, hier müsse „Verstehen" im Spiel sein. Technisch passiert aber etwas deutlich Nüchterneres: Ein großes Sprachmodell berechnet Schritt für Schritt, welches Token als Nächstes am besten zum bisherigen Kontext passt [1, 3].

Genau darin liegt die Stärke moderner LLMs. Sie schreiben nicht deshalb überzeugend, weil sie Sprache „kennen" wie ein Mensch, sondern weil sie auf riesigen Textmengen statistische Muster gelernt haben. Viele dieser Modelle basieren auf der Transformer-Architektur, die Beziehungen zwischen Tokens über Self-Attention verarbeitet und deshalb besonders gut mit Sprache, langen Kontexten und komplexen Abhängigkeiten umgehen kann [1, 2].

Wer verstehen will, warum lokale Modelle plötzlich in 4-Bit-Varianten auftauchen, weshalb ein 32B-Modell nicht automatisch besser ist als ein kleineres Modell und was Kürzel wie Q4_K_M überhaupt bedeuten, muss ein paar Grundlagen sauber voneinander trennen. Dieser Beitrag macht genau das: Was LLMs sind, wie sie trainiert werden, welche Architekturunterschiede in der Praxis relevant sind und warum Quantisierung für lokale KI fast immer eine Hauptrolle spielt.

Was sind LLMs eigentlich?

Large Language Models, kurz LLMs, sind große Deep-Learning-Modelle, die natürliche Sprache verarbeiten, fortsetzen und erzeugen können, weil sie auf sehr großen Textmengen trainiert wurden [1]. Ein LLM erzeugt Text dabei in der Regel nicht als fertigen Absatz auf einmal, sondern sequenziell: Für den bisherigen Kontext wird jeweils das wahrscheinlich nächste Token berechnet [1, 3].

Ein Token ist die grundlegende Recheneinheit eines Sprachmodells. Je nach Tokenizer kann das ein ganzes Wort, ein Wortteil, ein einzelnes Zeichen oder auch ein Satzzeichen sein [3]. Diese scheinbar kleine technische Ebene ist wichtig, weil sie erklärt, warum LLMs intern nicht mit „Wörtern" oder „Bedeutungen" im menschlichen Sinn arbeiten, sondern mit numerischen Repräsentationen von Tokenfolgen.

Der Begriff „Large" bezieht sich dabei nicht nur auf die Dateigröße eines Modells. Gemeint sind vor allem die Zahl der gelernten Parameter, die Menge der Trainingsdaten und der enorme Rechenaufwand, der nötig ist, um solche Modelle überhaupt zu trainieren [1, 4]. Deshalb können LLMs Aufgaben wie Zusammenfassen, Übersetzen, Ideensammlung, Programmierhilfe oder Textentwurf oft erstaunlich gut bearbeiten: Viele dieser Probleme lassen sich als Vorhersage der wahrscheinlichsten Token-Fortsetzung formulieren [1].

Wichtig ist aber die nüchterne Einordnung. LLMs „wissen" nicht im menschlichen Sinn, was wahr ist. Sie erzeugen plausible Ausgaben auf Basis gelernter Muster und des aktuellen Prompts [1, 5]. Genau deshalb können sie hilfreiche Antworten liefern — und im nächsten Moment überzeugend klingende Fehler, veraltete Informationen oder frei erfundene Details produzieren [1, 5].

Wie und womit werden LLMs trainiert?

Der Kern fast aller modernen LLMs beginnt mit Pretraining. Dabei wird ein Modell auf sehr großen Sammlungen aus Text, Code und anderen Dokumenten trainiert, die zuvor gesammelt, bereinigt, dedupliziert und vorverarbeitet wurden [1]. Beim klassischen kausalen Sprachmodelltraining lautet die Grundaufgabe dann erstaunlich schlicht: Aus einer bisherigen Token-Sequenz das nächste Token vorhersagen [3, 6].

Dieses Verfahren wird oft als self-supervised learning beschrieben, weil die Zielstruktur direkt aus dem Trainingsmaterial selbst entsteht. Das Modell braucht also keine manuell an jedes Textstück angehefteten Labels. Der Text liefert sein Lernsignal gleich selbst: Das nächste Token ist das Ziel [6].

Technisch läuft das Training als große Optimierungsschleife. Das Modell macht eine Vorhersage, vergleicht sie mit dem tatsächlichen nächsten Token, berechnet einen Fehler und passt seine Gewichte über Gradientenverfahren so an, dass der Fehler über viele Trainingsschritte hinweg kleiner wird [6]. Was von außen wie Sprachkompetenz aussieht, ist auf dieser Ebene zunächst also Statistik, Optimierung und sehr viel Rechenarbeit.

Genau deshalb ist die Hardwarefrage kein Nebenschauplatz. Große Modelle werden typischerweise auf vielen GPUs oder anderen Beschleunigern trainiert, weil Training und Inferenz großer LLMs extrem rechen- und energieintensiv sind [1].

Nach dem Pretraining ist die Arbeit meist noch nicht vorbei. Häufig folgt Fine-Tuning, bei dem ein Basismodell auf bestimmte Aufgaben, Branchen, Antwortformate oder Zielverhalten angepasst wird [1]. Ein wichtiger Spezialfall ist Instruction Tuning: Das Modell lernt, menschliche Anweisungen besser zu befolgen, statt nur rohe Textmuster fortzusetzen [7].

Besonders bekannt wurde in diesem Zusammenhang RLHF — also Reinforcement Learning from Human Feedback. OpenAI beschreibt für InstructGPT einen mehrstufigen Prozess aus überwachtem Fine-Tuning mit menschlichen Beispielen, einem Reward Model auf Basis menschlicher Präferenzvergleiche und anschließender Optimierung per Reinforcement Learning [7]. Ziel ist nicht nur sprachliche Flüssigkeit, sondern hilfreichere, wahrheitsgetreuere und weniger schädliche Antworten [7].

Neuere offene Modelle kombinieren teils mehrere dieser Stufen: Pretraining, Supervised Fine-Tuning, Reinforcement-Learning-Phasen und weitere modellbasierte Verfahren. OpenAI beschreibt einen solchen Mix beispielsweise auch für gpt-oss [8].

Gibt es Open-Source-LLMs — oder nur Open Weight?

An dieser Stelle beginnt ein Begriffsdurcheinander, das in der Praxis ständig auftaucht. Viele sprechen von Open Source, obwohl eigentlich Open Weight gemeint ist. Das ist nicht dasselbe [9, 10].

Nach der Definition der Open Source Initiative reicht es bei Software nicht aus, dass Dateien einfach herunterladbar sind. Open Source umfasst unter anderem freie Weitergabe, erlaubte Modifikation und diskriminierungsfreie Nutzung [9]. Für KI-Systeme geht die Open Source AI Definition noch weiter: Sie verlangt zusätzlich nachvollziehbare Informationen über Daten, Code und die Herleitung der Parameter, damit ein System tatsächlich veränderbar und überprüfbar ist [10].

Genau deshalb sind viele populäre LLMs streng genommen eher Open-Weight-Modelle. Ihre Gewichte sind öffentlich verfügbar, aber Trainingsdaten, Datenaufbereitung oder der vollständige Trainingsprozess liegen oft nicht vollständig offen [10].

Trotzdem gibt es inzwischen eine Reihe offen verfügbarer Modelle, die für Praxis, Forschung und lokale Nutzung sehr relevant sind. Beispiele sind Qwen, MiniMax-M1, Mistral-Modelle, BLOOM und OpenAI gpt-oss [8, 11, 12, 13, 23].

Alibaba Cloud beschreibt Qwen3 als Modellfamilie mit öffentlich verfügbaren Gewichten, darunter Dense- und Mixture-of-Experts-Varianten von 0,6B bis 235B-A22B [11]. Die zugehörigen Repositories nennen Apache 2.0, und auch die Model Card von Qwen3-235B-A22B weist apache-2.0 aus [11, 24].

MiniMax-M1 wird im technischen Bericht als Open-Weight-Modell mit hybrider MoE-Architektur, Lightning Attention, 456 Milliarden Gesamtparametern und 45,9 Milliarden aktiven Parametern pro Token beschrieben [23]. Laut MiniMax unterstützt M1 nativ ein Kontextfenster von 1 Million Tokens, und die Modellgewichte werden über offizielle Hugging-Face- und GitHub-Konten bereitgestellt [25].

Mistral bewirbt eigene offene Modelle für Training, Distillation, Fine-Tuning und Deployment [12]. BLOOM wiederum ist ein autoregressives LLM aus dem BigScience-Projekt, das laut Model Card Text in 46 Sprachen und 13 Programmiersprachen erzeugen kann [13]. Und mit gpt-oss-120b sowie gpt-oss-20b hat auch OpenAI zwei Open-Weight-Sprachmodelle unter Apache-2.0-Lizenz veröffentlicht [8].

Für die Praxis ist deshalb eine einfachere Frage oft hilfreicher als die reine Etikettendebatte: Was ist konkret offen — nur die Gewichte, oder auch Daten, Code, Lizenzrechte und Trainingsdokumentation? Genau davon hängt ab, ob ein Modell nur nutzbar, wirklich anpassbar oder tatsächlich offen nachvollziehbar ist [8, 9, 10].

Welche Architekturunterschiede sind bei LLMs wirklich wichtig?

Wenn von Architektur gesprochen wird, geht es nicht um Marketingnamen, sondern um den inneren Aufbau des Modells: Welche Komponenten der Transformer-Familie werden verwendet, wie werden Eingaben verarbeitet und wie entsteht daraus Ausgabe-Text? [21]

Ein zentraler Unterschied ist die Aufteilung in encoder-only, decoder-only und encoder-decoder [21]. Encoder-only-Modelle sind vor allem auf das Verstehen und Repräsentieren von Eingabetext ausgelegt, etwa für Klassifikation, Suche, Embeddings oder Textanalyse [21]. Decoder-only-Modelle setzen Text autoregressiv von links nach rechts fort und sind deshalb die typische Grundlage moderner Chat- und Textgenerierungsmodelle [21]. Encoder-Decoder-Modelle kombinieren beide Seiten und kommen oft bei Sequence-to-Sequence-Aufgaben wie Übersetzung, Zusammenfassung oder Fragebeantwortung zum Einsatz [21].

Viele heutige Chat-LLMs gehören zur decoder-only-Familie, weil diese Architektur sehr gut zur Next-Token-Vorhersage passt [3, 21]. Das erklärt auch, warum sich viele Fähigkeiten moderner Sprachmodelle aus demselben Grundprinzip ableiten lassen: Kontext lesen, nächste Token-Fortsetzung berechnen, wiederholen.

Ein zweiter wichtiger Unterschied betrifft Dense-Modelle und Mixture of Experts, kurz MoE [8, 22]. Bei einem Dense-Modell werden für eine Vorhersage im Wesentlichen immer dieselben Modellteile genutzt. Bei einem sparsamen MoE-Modell entscheidet ein Router pro Token, welche Expertenteile aktiv werden [22].

Mistral beschreibt Mixtral beispielsweise als sparse Mixture-of-Experts-Netzwerk, bei dem in jeder Schicht zwei von acht Expertengruppen pro Token ausgewählt werden [22]. Dadurch kann ein MoE-Modell sehr viele Gesamtparameter besitzen, aber pro Token nur einen Teil davon aktiv einsetzen [8, 22]. OpenAI nennt für gpt-oss-120b etwa 117 Milliarden Gesamtparameter, aber nur 5,1 Milliarden aktive Parameter pro Token [8].

Genau hier liegt ein wichtiger Praxispunkt: Weniger aktive Parameter bedeuten nicht automatisch, dass ein Modell insgesamt wenig Speicher benötigt. MoE senkt vor allem die pro Token notwendige Berechnung. Die Gewichte der Experten müssen in der Regel trotzdem verfügbar sein. Ein MoE-Modell ist also nicht automatisch ein RAM- oder VRAM-Sparmodell. Es kann aber ein sehr gutes Verhältnis aus Modellkapazität und Inferenzkosten liefern, während Dense-Modelle oft einfacher vorhersehbar, einfacher zu betreiben und einfacher zu trainieren sind.

Zusätzlich unterscheiden sich LLMs über Varianten der Attention, ihre maximale Kontextlänge, den Tokenizer, Positionskodierung und verschiedene Speicher- oder Inferenzoptimierungen [2, 16, 21]. Self-Attention ist dabei der Kern moderner Transformer, weil sie gewichtet, welche Tokens für andere Tokens im Kontext wichtig sind [2]. Die Kontextlänge bestimmt wiederum, wie viele Tokens ein Modell gleichzeitig berücksichtigen kann — ein entscheidender Punkt bei langen Dokumenten, Chatverläufen oder großen Codebasen [2, 8].

Deshalb können zwei Modelle mit ähnlicher Parameterzahl in der Praxis sehr unterschiedlich wirken. Architektur, aktive Parameter, Kontextfenster, Attention-Mechanik und Inferenzoptimierungen entscheiden oft mehr über das reale Nutzungsprofil als eine einzelne Marketingzahl [8, 16, 21].

Was bedeutet Modellgröße oder Parameterzahl?

Wenn ein Modell mit 4B, 32B oder 120B bezeichnet wird, ist damit in der Regel die ungefähre Anzahl seiner Parameter gemeint — also 4 Milliarden, 32 Milliarden oder 120 Milliarden gelernte Zahlenwerte im Netzwerk [8, 11, 14]. Diese Parameter bestimmen, wie Eingaben verarbeitet und Ausgaben berechnet werden [14].

Größer bedeutet dabei oft mehr Kapazität, um Muster in Trainingsdaten abzubilden. Größer bedeutet aber nicht automatisch besser [4, 7]. Ein Modell mit mehr Parametern kann leistungsfähiger sein, aber es kann auch ineffizienter, schwerer betreibbar oder für bestimmte Aufgaben schlicht unnötig groß sein.

Genau das zeigt auch ein bekanntes Ergebnis aus der InstructGPT-Arbeit: Dort wurde ein 1,3B-Parameter-Modell mit menschlichem Feedback in menschlichen Bewertungen gegenüber einem 175B-Parameter-GPT-3-Modell bevorzugt [15]. Modellgröße ist also nur eine Dimension. Trainingsziel, Datenqualität, Alignment und Feintuning können genauso entscheidend sein [7, 15].

Für die Praxis zählt außerdem, was die Größe technisch nach sich zieht: mehr Speicherbedarf, höhere Hardwareanforderungen und oft geringere Geschwindigkeit in der Inferenz [8, 16].

Bei Mixture-of-Experts-Modellen muss man noch genauer hinschauen. OpenAI nennt für gpt-oss-120b insgesamt 117 Milliarden Parameter, aber nur 5,1 Milliarden aktive Parameter pro Token [8]. Für gpt-oss-20b sind es laut derselben Quelle 21 Milliarden Gesamtparameter und 3,6 Milliarden aktive Parameter pro Token [8]. Wer Modelle vergleichen will, sollte deshalb nicht nur auf die Schlagzeile schauen, sondern auf Gesamtparameter, aktive Parameter, Architektur, Kontextlänge, Quantisierung und Benchmarks [8, 16].

Was bedeutet Bit-Quantisierung?

Sobald LLMs lokal laufen sollen, taucht fast zwangsläufig das Thema Quantisierung auf. Gemeint ist damit, dass Gewichte oder Aktivierungen eines Modells mit geringerer numerischer Präzision gespeichert oder verarbeitet werden [16, 17].

Statt ein Modell vollständig in 32-Bit- oder 16-Bit-Fließkommazahlen abzulegen, können Gewichte auch in niedrigeren Formaten wie 8-Bit oder 4-Bit repräsentiert werden [16, 17]. Das reduziert den Speicherbedarf und kann die Inferenz beschleunigen, weil weniger Daten bewegt und verarbeitet werden müssen [16, 17]. Hugging Face beschreibt Quantisierung genau in diesem Sinn als Methode, um Speicher- und Rechenkosten zu senken und größere Modelle in begrenzten Speicher zu laden [16]. IBM beschreibt sie als Umwandlung hochpräziser Werte wie FP32 oder FP16 in niedrigere Präzision wie INT8 [17].

Der Haken ist der offensichtliche: Weniger Präzision kann Qualität kosten [18]. Werte werden gröber approximiert, und diese Approximation kann sich auf Antwortqualität, Stabilität oder Feinheiten im Modellverhalten auswirken. llama.cpp weist darauf hin, dass Quantisierung Modellgewichte schrumpfen und Inferenz beschleunigen kann, dabei aber auch Qualitätsverluste verursachen kann, die sich beispielsweise über Perplexity oder Kullback-Leibler-Divergenz beobachten lassen [18].

Als grobe Faustregel gilt: Je niedriger die Bitzahl, desto kleiner das Modell — aber desto größer das Risiko, dass die Qualität leidet [16, 18]. Ein 8-Bit-Modell bleibt meist näher am ursprünglichen Modell, benötigt aber mehr Speicher [16, 17]. Ein gut gemachtes 4-Bit-Modell ist dagegen oft genau die Schwelle, ab der lokale Nutzung auf Consumer-Hardware überhaupt praktikabel wird [16, 18].

Was bedeutet K-Quants?

Wer lokale GGUF-Modelle herunterlädt, stolpert früher oder später über Dateinamen wie Q4_K_M, Q5_K_M oder Q6_K. Genau hier beginnt für viele die Verwirrung.

K-Quants sind Quantisierungsformate aus dem llama.cpp- / GGML- / GGUF-Ökosystem [18, 19]. Typische Varianten sind Q2_K, Q3_K_M, Q4_K_S, Q4_K_M, Q5_K_M oder Q6_K [18, 19]. Das Q steht praktisch für Quantisierung, die Zahl beschreibt grob die Zielpräzision in Bits, und das K verweist auf die K-Quant-Familie [19].

Die Suffixe S, M und L stehen üblicherweise für Varianten wie small, medium und large — also für unterschiedliche Qualitäts- und Speicherkompromisse innerhalb derselben Bitklasse [19]. Entscheidend ist dabei: K-Quants sind nicht einfach nur „alles auf 4 Bit runtergerundet". Sie arbeiten mit Block- und Superblock-Strukturen sowie Skalenwerten, um Speicherbedarf und Qualitätsverlust besser auszubalancieren [20].

In der llama.cpp-Diskussion zu QX_4 wird beschrieben, dass Superblocks mehrere Quantisierungsblöcke zusammenfassen und quantisierte Skalen nutzen, um die effektiven Bits pro Gewicht niedrig zu halten [20]. Ein dort beschriebenes Beispiel für 4-Bit-Quantisierung arbeitet mit Superblocks aus 16 Blöcken à 8 Gewichten und eigenen quantisierten Skalen, was effektiv auf 5,125 Bits pro Gewicht hinausläuft [20].

In der Praxis heißt das: Q4_K_M ist oft ein sehr brauchbarer Sweet Spot für lokale Nutzung. Das Modell ist stark komprimiert, liefert aber meist bessere Qualität als ältere oder einfachere 4-Bit-Quantisierungen [18, 20]. Q5_K_M braucht mehr Speicher, kann dafür aber näher an der Qualität des unquantisierten Modells liegen [18, 20]. Q6_K ist noch größer und wird häufig dann gewählt, wenn Qualität wichtiger ist als minimale Dateigröße [18, 19].

Für lokale LLMs ist die Wahl zwischen Q4_K_M, Q5_K_M und Q6_K deshalb kein reines Detail, sondern ein typischer Alltagskompromiss zwischen RAM oder VRAM, Geschwindigkeit und Antwortqualität [16, 18, 20].

Fazit: Nicht nur Modellgröße entscheidet, sondern das Zusammenspiel

LLMs sind große, meist Transformer-basierte Sprachmodelle, die durch Next-Token-Vorhersage trainiert und durch Fine-Tuning weiter auf nützliche Antwortmuster ausgerichtet werden [1, 3, 7]. Ihre Leistungsfähigkeit hängt aber nicht nur an der Parameterzahl. Datenqualität, Trainingsverfahren, Architektur, Alignment, Inferenzsystem und Quantisierung sind mindestens genauso entscheidend [1, 7, 8].

Für die Praxis heißt das: Wer mit lokalen Modellen arbeitet, sollte nicht nur fragen „Wie viele Milliarden Parameter hat das Modell?", sondern auch: Welche Architektur nutzt es? Wie groß ist das Kontextfenster? Ist es Dense oder MoE? In welcher Quantisierung liegt es vor? Und welche Lizenz oder Offenheit bringt es tatsächlich mit?

Genau dort wird aus allgemeinem KI-Hype eine brauchbare technische Einordnung. Weniger Magie, mehr Mechanik. Weniger Marketing, mehr Systemverständnis. Und genau das ist die Grundlage, um lokale LLMs, Hardware-Anforderungen und Quantisierungsformate sinnvoll beurteilen zu können.

Quellen

[1] IBM. What Are Large Language Models (LLMs)? https://www.ibm.com/think/topics/large-language-models

[2] Google Machine Learning Crash Course. LLMs: What's a large language model? https://developers.google.com/machine-learning/crash-course/llm/transformers

[3] Hugging Face Transformers Docs. Causal language modeling. https://huggingface.co/docs/transformers/en/tasks/language_modeling

[4] NVIDIA Developer Blog. An Introduction to Large Language Models: Prompt Engineering and P-Tuning. https://developer.nvidia.com/blog/an-introduction-to-large-language-models-prompt-engineering-and-p-tuning/

[5] OpenAI / Achiam et al. GPT-4 Technical Report. https://arxiv.org/abs/2303.08774

[6] Hugging Face LLM Course. Training a causal language model from scratch. https://huggingface.co/learn/llm-course/chapter7/6

[7] OpenAI. Aligning language models to follow instructions. https://openai.com/index/instruction-following/

[8] OpenAI. Introducing gpt-oss. https://openai.com/index/introducing-gpt-oss/

[9] Open Source Initiative. The Open Source Definition. https://opensource.org/osd

[10] Open Source Initiative. The Open Source AI Definition 1.0. https://opensource.org/ai/open-source-ai-definition

[11] QwenLM / GitHub. Qwen3. https://github.com/QwenLM/Qwen3

[12] Mistral AI. Frontier AI LLMs, assistants, agents, services. https://mistral.ai/

[13] BigScience / Hugging Face. BLOOM Model Card. https://huggingface.co/bigscience/bloom

[14] Google Machine Learning Crash Course. Introduction to Large Language Models. https://developers.google.com/machine-learning/crash-course/llm

[15] Ouyang et al. Training language models to follow instructions with human feedback. https://arxiv.org/abs/2203.02155

[16] Hugging Face Transformers Docs. Quantization. https://huggingface.co/docs/transformers/en/main_classes/quantization

[17] IBM. What is Quantization? https://www.ibm.com/think/topics/quantization

[18] llama.cpp. Quantize README. https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md

[19] llama.cpp quantization table mirror with K-Quant BPW examples. https://gitlab.informatik.uni-halle.de/ambcj/llama.cpp/-/blob/3e916a07ac093045d88ef0c4fa78647ae0efc010/examples/quantize/README.md

[20] ggml-org / llama.cpp GitHub Issue. QX_4 quantization. https://github.com/ggml-org/llama.cpp/issues/1240

[21] Hugging Face LLM Course. Transformer Architectures. https://huggingface.co/learn/llm-course/chapter1/6

[22] Mistral AI. Mixtral of experts. https://mistral.ai/news/mixtral-of-experts

[23] MiniMax et al. MiniMax-M1: Scaling Test-Time Compute Efficiently with Lightning Attention. https://arxiv.org/abs/2506.13585

[24] Qwen / Hugging Face. Qwen3-235B-A22B Model Card. https://huggingface.co/Qwen/Qwen3-235B-A22B

[25] MiniMax. MiniMax-M1, the World's First Open-Source, Large-Scale, Hybrid-Attention Reasoning Model. https://www.minimax.io/news/minimaxm1