Was Modellgewichte wirklich sind

Bevor ein KI-Modell wie ChatGPT oder Claude überhaupt genutzt werden kann, muss es erst „trainiert” werden. Training bedeutet: Das System liest enorme Mengen Text – Bücher, Webseiten, Code, Artikel – und passt dabei Millionen oder Milliarden interner Zahlen so lange an, bis es gelernt hat, sinnvolle Antworten auf Eingaben zu geben. Diese internen Zahlen sind die Modellgewichte, manchmal auch einfach „Parameter” genannt. Sie sind das Ergebnis des Trainings und das, was das Modell im Kern ist. Ohne sie ist ein Modell nichts als leere Architektur.

Was nach dem Training bleibt, ist also eine riesige Sammlung von Zahlen – bei großen Modellen heute mehrere Milliarden davon. Diese Zahlen werden auf einem Server oder einem lokalen Gerät gespeichert. Und genau hier liegt das erste praktische Problem: Je mehr Parameter ein Modell hat, desto leistungsfähiger ist es tendenziell – aber desto mehr Speicher und Rechenleistung braucht es auch. Das ist kein akademisches Detail, sondern entscheidet darüber, ob ein Modell auf einem Laptop läuft oder mehrere Hochleistungsserver braucht.

Dieser Artikel erklärt, was Modellgewichte konkret sind, wie sie gespeichert werden und welche Techniken existieren, um sie kleiner zu machen – ohne dabei zu viel von ihrer Qualität einzubüßen.

Was ein Parameter ist

Ein neuronales Netz besteht aus Schichten. Jede Schicht enthält Neuronen, und jede Verbindung zwischen Neuronen hat ein Gewicht – eine Zahl, die bestimmt, wie stark ein Signal weitergeleitet wird. Diese Zahlen sind die Parameter. Beim Training werden sie iterativ angepasst, bis das Modell auf dem Trainingsdatensatz möglichst gute Ausgaben produziert.

Nach dem Training sind die Gewichte fixiert. Was übrig bleibt, ist eine große Tabelle von Zahlen – in einem 70B-Modell sind das 70 Milliarden davon. Sie kodieren nicht explizit „Wissen” im menschlichen Sinne, sondern statistische Muster: welche Token-Folgen wahrscheinlich sind, wie Konzepte zueinander in Beziehung stehen, wie Sprachstrukturen aufgebaut sind.

Die Gewichte liegen typischerweise in Matrixform vor. Bei Transformer-Modellen dominieren die Gewichtsmatrizen der Attention-Mechanismen und der Feed-Forward-Schichten. Für Inferenz – also das eigentliche Nutzen des Modells – müssen diese Matrizen in den Arbeitsspeicher geladen werden. Das ist der erste Engpass.

Wie Gewichte gespeichert werden

Eine Zahl kann in verschiedenen Präzisionsstufen abgelegt werden. Je höher die Präzision, desto mehr Speicherplatz braucht sie – und desto mehr Bandbreite beim Lesen. Zur Einordnung, welche Formate in der Praxis vorkommen:

Format	Bits pro Wert	Größe bei 70B	Bemerkung
FP32	32 Bit	~280 GB	Training, maximale Präzision
BF16	16 Bit	~140 GB	Standard für moderne Modelle
FP16	16 Bit	~140 GB	Ähnlich BF16, anderer Exponent
INT8	8 Bit	~70 GB	Post-Training Quantisierung
INT4	4 Bit	~35 GB	Aggressivere Kompression
3-Bit	3 Bit	~26 GB	Grenze heutiger Qualität

BF16 ist das De-facto-Format für aktuelle große Modelle im Betrieb auf High-End-Hardware. Es bietet denselben Exponentenbereich wie FP32, aber reduzierte Mantissenpräzision – was für neuronale Netze in der Praxis gut funktioniert, weil die Gewichte selten extreme Präzision brauchen.

Für Consumer-Hardware und lokalen Betrieb sind INT4 und verwandte Formate entscheidend. Erst durch 4-Bit-Quantisierung passen Modelle wie Llama 3 70B auf einen einzelnen Rechner mit 48 GB VRAM – oder auf ein System mit genug schnellem RAM für CPU-Inferenz.

Drei Arten von Speicher — oft verwechselt

In der Praxis besteht der Speicherbedarf eines laufenden Modells aus drei unterschiedlichen Komponenten, die häufig durcheinandergebracht werden:

• Gewichte (Weights): Die fixen Parameter des Modells – sie werden einmal beim Start geladen und bleiben konstant
• Aktivierungen (Activations): Temporäre Zwischenwerte, die während eines Forward-Passes entstehen und danach verworfen werden
• KV-Cache: Gespeicherte Key- und Value-Vektoren aus dem Attention-Mechanismus für alle bisherigen Tokens im Gespräch

Während die Gewichte konstant sind, wachsen Aktivierungen und KV-Cache linear mit der Sequenzlänge. Deshalb kann ein Modell, das laut Tabelle „in den Speicher passt”, bei langen Prompts oder ausgedehnten Chats trotzdem an seine Grenzen stoßen.

Faustformel für den Engpass: Bei kurzen Prompts sind die Gewichte der dominierende Faktor. Bei langen Kontexten wird der KV-Cache zum eigentlichen Flaschenhals.

Der eigentliche Engpass: Speicherbandbreite

Bei der Inferenz ist nicht die reine Rechenleistung der limitierende Faktor, sondern wie schnell die Gewichte aus dem Speicher gelesen werden können. Jedes Mal, wenn das Modell ein Token generiert, müssen alle relevanten Gewichtsmatrizen geladen, mit dem aktuellen Zustand multipliziert und wieder verworfen werden.

Man spricht hier von einem memory-bound Problem: Die Geschwindigkeit wird nicht durch Rechenleistung (FLOPS), sondern durch Speicherzugriffe limitiert. Das ist ein wichtiger Unterschied zum Training — Training ist typischerweise compute-bound (Matrix-Multiplikationen dominieren), während Inferenz häufig memory-bound ist (Gewichte laden, multiplizieren, nächstes Token). Das erklärt, warum reine FLOPS-Vergleiche bei GPUs für Inferenz oft wenig aussagekräftig sind.

Das führt zu einem asymmetrischen Problem: Moderne GPUs haben enorme Rechenleistung in FLOPS, aber die Speicherbandbreite hält nicht Schritt. Ein H100 hat etwa 80 GB HBM3-Speicher mit rund 3,35 TB/s Bandbreite. Bei einem 70B-Modell in BF16 (140 GB) passt es nicht einmal auf eine einzelne Karte – und bei Multi-GPU-Setups entstehen Kommunikationskosten durch das Aufteilen der Gewichte.

Das ist der Grund, warum Quantisierung nicht nur Speicher spart, sondern auch Inferenz beschleunigt: Weniger Bytes bedeuten weniger Zeit zum Lesen, nicht nur weniger RAM-Bedarf.

Quantisierung: Was es gibt und wie es funktioniert

Quantisierung bedeutet, Gewichte von hoher Präzision auf ein niedrigeres Format zu komprimieren. Die grundlegende Frage: Wie viel Genauigkeit kann man verlieren, ohne die Modellqualität merklich zu verschlechtern?

GPTQ (Generative Pre-trained Transformer Quantization) nutzt eine zweite Ableitung des Verlustes, um zu bestimmen, welche Gewichte empfindlicher auf Änderungen reagieren, und komprimiert weniger empfindliche Gewichte stärker. AWQ (Activation-aware Weight Quantization) geht einen Schritt weiter: Es analysiert, welche Gewichte durch tatsächliche Aktivierungen besonders wichtig sind, und schützt diese gezielt. Beide Methoden produzieren bei 4 Bit deutlich bessere Ergebnisse als einfaches Runden.

Quantisierung spart Speicher — aber nicht kostenlos

Niedrig-bitige Formate müssen zur Laufzeit oft in höhere Präzision zurückgerechnet werden (Dequantisierung), bevor Matrixmultiplikationen stattfinden können. Das erzeugt einen Trade-off: weniger Speicherbandbreite auf der einen Seite, zusätzlicher Rechenaufwand pro Zugriff auf der anderen.

Moderne Implementierungen wie llama.cpp oder TensorRT-LLM versuchen, Dequantisierung und Berechnung zu fusionieren, sodass der Overhead möglichst gering bleibt. Trotzdem ist Quantisierung kein reiner „Free Lunch” — bei sehr aggressiver Kompression kann der zusätzliche Rechenaufwand den Bandbreitenvorteil teilweise auffressen.

Was Quantisierung kostet

Kein Format-Wechsel ist gratis. Die Qualität sinkt mit der Bitbreite – die Frage ist nur, wie stark. Für viele praktische Anwendungen ist der Unterschied zwischen einem gut quantisierten 4-Bit-Modell und dem Original in FP16 gering. Bei sehr kleinen Modellen (unter 7B Parametern) ist er deutlicher spürbar.

Die Grenze liegt heute bei etwa 3 Bit: Darunter bricht die Qualität in den meisten Benchmarks messbar ein. Das TurboQuant-Papier von Google Research zeigt, dass 3-Bit-Quantisierung des KV-Cache mit speziellen Methoden möglich ist, ohne die Genauigkeit sichtbar zu beeinflussen – aber das gilt für den Cache, nicht für die Modellgewichte selbst.

Zur Orientierung, welcher Kompromiss für welchen Einsatz passt:

Bitbreite	Qualitätsverlust	Praxisempfehlung
BF16/FP16	kein messbarer	Server, Cloud
INT8	minimal	gut geeignet
4-Bit (AWQ/GPTQ)	gering bis mittel	Consumer GPU, Laptop
3-Bit	spürbar	nur wenn nötig
2-Bit	erheblich	kaum praxistauglich

Schichtweise Quantisierung: nicht alle Gewichte gleich behandeln

Eine wichtige Erkenntnis der letzten Jahre: Nicht alle Schichten eines Modells reagieren gleich empfindlich auf Präzisionsverlust. Die ersten und letzten Schichten sowie Schichten mit hoher Aktivierungsstreuung sind empfindlicher. Moderne Quantisierungstools wie llama.cpp nutzen das: Sie erlauben gemischte Bitbreiten, wo kritische Schichten in höherer Präzision bleiben und unkritische stärker komprimiert werden.

Das Ergebnis sind Formate wie Q4_K_M oder Q5_K_S im GGUF-Format – der Buchstabe steht für die Bitbreite, K für k-Quant (schichtadaptiv) und M/S für Medium/Small. Ein Q4_K_M-Modell ist nicht einfach „alles in 4 Bit”, sondern ein differenzierter Kompromiss mit unterschiedlichen Präzisionen je nach Layer-Sensitivität.

Lokaler Betrieb: Was auf welcher Hardware läuft

Durch Quantisierung sind heute Modelle auf Consumer-Hardware betreibbar, die vor zwei Jahren noch Cluster-Infrastruktur gebraucht hätten. Die folgenden Zahlen gelten für die Gewichte allein — KV-Cache kommt für lange Kontexte erheblich obendrauf:

Modell	Format	Ungefähre Größe	Hardware
Llama 3 8B	Q4_K_M	~5 GB	MacBook M-Serie (16 GB), GPU ab 8 GB
Llama 3 70B	Q4_K_M	~40 GB	Mac Studio mit 48+ GB, 2× RTX 4090
Mistral 7B	Q4_K_M	~4 GB	Auch auf CPUs nutzbar
Gemma 2 27B	Q4_K_M	~16 GB	Einzelne RTX 4090 (24 GB)

VRAM vs. RAM vs. PCIe — ein unterschätzter Flaschenhals

Ein häufig übersehener Punkt beim lokalen Betrieb: Die Verbindung zwischen Speicher und Recheneinheit macht einen erheblichen Unterschied.

• VRAM (GPU-intern): sehr hohe Bandbreite — beim H100 rund 3,35 TB/s, bei Consumer-GPUs 600–900 GB/s
• RAM → GPU über PCIe: deutlich langsamer — PCIe 4.0 x16 liefert rund 32 GB/s, PCIe 5.0 das Doppelte

Wenn ein Modell nicht vollständig in den VRAM passt und Teile der Gewichte ständig über PCIe nachgeladen werden müssen, bricht die Inferenzgeschwindigkeit drastisch ein — ein Faktor 10 oder mehr ist keine Seltenheit. Apple Silicon bildet eine Ausnahme: Weil GPU und RAM einen gemeinsamen Pool teilen, entfällt der PCIe-Engpass, was CPU-Inferenz dort deutlich schneller macht als auf x86-Systemen.

Die praktische Konsequenz: „Passt das Modell in den VRAM?” ist oft die wichtigere Frage als „Passt es überhaupt ins System?”

Warum das für AGI-Skalierung relevant ist

Die Verbindung zum größeren Bild ist direkt: Mehr Fähigkeit bedeutet tendenziell größere Modelle. Größere Modelle bedeuten mehr Gewichte, mehr Speicherbedarf, mehr Bandbreitenanforderungen. Ohne Effizienzfortschritte bei der Gewichtskomprimierung und Speicherhierarchie skaliert der Ressourcenbedarf schneller als der Nutzen.

Das ist der Grund, warum Quantisierungsforschung keine Randdisziplin ist, sondern ein zentrales Gebiet: Sie bestimmt, welche Modellgrößen auf welcher Hardware wirtschaftlich betreibbar sind. Ein Modell, das nur auf einer Handvoll Spezialmaschinen läuft, ist für breite Nutzung irrelevant – egal wie gut es in Benchmarks abschneidet.

Gleichzeitig zeigen Ansätze wie Mixture-of-Experts (MoE), dass „mehr Parameter” nicht automatisch „mehr Gewichte im Speicher” heißen muss. Bei MoE-Modellen sind viele Parameter vorhanden, aber pro Token wird nur ein Bruchteil davon aktiviert — das senkt den Rechenaufwand. Ein wichtiges Missverständnis dabei: MoE reduziert nicht den Speicherbedarf der Gewichte, sondern nur die aktive Rechenlast pro Token. Alle Experten müssen weiterhin vollständig im Speicher verfügbar sein, weil das Routing sonst nicht funktioniert. Das Ergebnis: weniger FLOPS pro Token, aber weiterhin hoher VRAM-Bedarf für die Gesamtheit der Gewichte.

Die nächste Entwicklungsstufe von LLMs hängt damit nicht nur an besseren Trainingsdaten oder clevereren Architekturen, sondern genauso daran, wie viel Modell pro Watt und pro Dollar in den Speicher passt.

Faustregeln für die Praxis

Für diejenigen, die ein Modell lokal betreiben oder Inferenzinfrastruktur planen, lassen sich die wichtigsten Erkenntnisse auf wenige Punkte verdichten:

• 4-Bit ist aktuell der Sweet Spot für lokalen Betrieb — guter Kompromiss aus Qualität und Größe
• VRAM entscheidet mehr als FLOPS — ein Modell, das vollständig im VRAM liegt, ist um Größenordnungen schneller als eines, das PCIe braucht
• Lange Kontexte → KV-Cache einplanen — der wächst linear mit der Sequenzlänge und kann die Gewichtsgröße übersteigen
• Größere Modelle skalieren besser — ein gut quantisiertes 70B-Modell schlägt ein kleines Modell mit aufwändigem Prompting oft deutlich
• Quantisierung lohnt sich fast immer — aber nicht blind maximal aggressiv; unter 3 Bit sind spürbare Qualitätsverluste wahrscheinlich