Eine Parameterzahl ist noch kein Hardwareplan.

Ein Sprachmodell enthält viele gelernte Zahlenwerte, die Gewichte. Die Parameterzahl beschreibt ihre Anzahl, nicht unmittelbar den freien VRAM, den eine bestimmte Anwendung benötigt. Zusätzlich verarbeitet die Laufzeit Eingaben und Zwischenergebnisse und hält dafür weitere Speicherbereiche vor.

Gewichte sind Modellwerte, die beim Training angepasst wurden. Aktivierungen sind Zwischenwerte einer konkreten Berechnung. Sie entstehen bei der Verarbeitung und sind nicht einfach weitere dauerhaft gelernte Parameter. Auch Tokenizer, zusätzliche Tensoren und Verwaltungsdaten gehören je nach Format und Anwendung zum Gesamtpaket.

Parameter × Bits ÷ 8: eine Orientierung für die Gewichte.

Für eine idealisierte Abschätzung gilt: Parameterzahl × Bits pro Gewicht / 8. Wir rechnen mit einem frei gewählten Beispiel von 125 Milliarden Gewichten, die hier jeweils dasselbe Speicherformat verwenden. Diese Rechnung ist kein vermessener Modell-Download und keine VRAM-Mindestanforderung.

Eigene Rechnung: 125 × 10⁹ Gewichte, ohne Zusatzbedarf
FormatBits/GewichtDezimale GBUngefähr GiB
FP3232500465,66
FP16 / BF1616250232,83
ideale 8-Bit-Ablage8125116,42
ideale 4-Bit-Ablage462,558,21

Beispiel mit 4 Bit: 125 × 10⁹ × 4 / 8 = 62,5 × 10⁹ Bytes. Ein GB hat 10⁹ Bytes, ein GiB 2³⁰ Bytes. Unterschiedliche Einheiten erklären also einen Teil scheinbar abweichender Größenangaben.

FP16 und BF16 belegen für diese Gewichte jeweils 16 Bit, unterscheiden sich aber in ihrer Zahlendarstellung. Quantisierung verwendet weniger Bits beziehungsweise eine kompaktere Darstellung. Dabei können zusätzliche Skalen, Blockinformationen und unterschiedlich gespeicherte Tensoren nötig sein. Deshalb ist eine reale 4-Bit-Datei nicht zwingend exakt vier Bits je gezähltem Parameter groß.

Quantisierung kann Speicher sparen und die nutzbare Rechengeschwindigkeit beeinflussen. Sie kann auch die Ergebnisqualität verändern. Wie stark das ausfällt, hängt vom Verfahren, Modell und Einsatz ab; „weniger Bits ist immer gleich gut“ wäre ebenso falsch wie eine pauschale Geschwindigkeitszusage.

RAM und VRAM sind verschiedene Speicherorte.

RAM ist der Arbeitsspeicher, auf den die CPU zugreift. Eine diskrete Grafikkarte hat eigenen VRAM für GPU-Berechnungen. Daten zwischen beiden Bereichen zu bewegen kostet Zeit und nutzt eine Verbindung wie PCIe. Systeme mit gemeinsamem Speicher funktionieren anders; auch dort bleiben Kapazität und Bandbreite wichtige Grenzen.

Modelldatei auf SSD / DatenträgerGewichte · Format · MetadatenRAM · geladene Teile / DateiseitenCPU kann mit Daten im RAM rechnenTransfersVRAM · Modellteile + LaufzeitdatenGPU rechnet · Cache benötigt PlatzTokenverarbeitung auf CPU / GPU
Mögliche Aufteilung bei separatem RAM und VRAM: Laden und Transfers bewegen Daten; CPU und GPU rechnen. Nicht jedes Gewicht muss pro Token diesen gesamten Weg nehmen. CPU-Verarbeitung kann ohne GPU stattfinden; Unified Memory und Backend verändern die Aufteilung.

Ein Backend kann einen Teil der Modellberechnung auf der GPU und einen Teil auf der CPU ausführen. Es kann Gewichte im RAM halten, ausgewählte Teile in den VRAM laden oder sie bei Bedarf übertragen. Welche Variante „CPU-Offloading“ oder „GPU-Offloading“ konkret meint, hängt vom Backend ab. Speicherort und ausführender Prozessor sind nicht immer dieselbe Entscheidung.

Mehr RAM kann deshalb ein größeres Modell nutzbar machen, ohne dass es vollständig in den VRAM passt. Das beseitigt aber nicht die Kosten für CPU-Arbeit, Übertragungen oder knappe Speicherbandbreite. Eine größere Gesamtkapazität ist kein Versprechen für eine flüssige Antwortgeschwindigkeit.

Zum Gewichtsspeicher kommt der Bedarf der laufenden Anfrage.

Zum tatsächlichen Speicherbedarf gehören je nach Architektur und Backend unter anderem Gewichte, Aktivierungen, Laufzeitpuffer und ein KV-Cache. Bei vielen attentionbasierten Modellen hält dieser Cache bereits berechnete Schlüssel- und Wertinformationen fest, damit frühere Verarbeitung nicht für jedes neue Token vollständig wiederholt werden muss.

Längere Kontexte und mehrere parallele Anfragen können den Cachebedarf erhöhen. Das genaue Wachstum hängt jedoch etwa von Schichtaufbau, Attention-Variante, Cacheformat und Sliding-Window- oder anderen Begrenzungen ab. Es gibt deshalb keine universelle Zusatzgröße „pro Modell“, die immer passt.

Die Summe ist entscheidend: Eine Gewichtsdatei kann gerade noch in den VRAM passen, während das Modell bei der gewünschten Kontextlänge oder Parallelität trotzdem keinen ausreichenden freien Laufzeitspeicher hat.

Weniger aktive Experten bedeutet nicht, dass der Rest verschwindet.

Bei einem Dense-Modell werden die entsprechenden dichten Modellteile für jedes Token berechnet. Bei Mixture of Experts (MoE) wählen Router nur bestimmte Experten pro Schicht und Token aus. Gemeinsame beziehungsweise dichte Teile können zusätzlich aktiv bleiben.

So kann sich die Zahl der pro Token aktiven Parameter deutlich von der Gesamtzahl unterscheiden. Die nicht ausgewählten Experten müssen dennoch irgendwo verfügbar sein: beispielsweise im RAM, in einem GPU-Cache oder in einem vom Backend unterstützten Nachladepfad. „Nur wenige Milliarden aktiv“ ist deshalb keine gleich große Speicheranforderung wie bei einem entsprechend kleinen vollständigen Modell.

Der veröffentlichte Strata-Film ist eine Fallstudie für diese Trennung. Die damalige Entwicklerdokumentation beschreibt eine Aufteilung mit GPU-Experten-Cache, RAM und CPU-Arbeit; je nach Pfad können auch Übertragungen zur GPU beteiligt sein. Wir übernehmen daraus keine pauschale Mindesthardware und keinen Benchmark. Insbesondere bedeutet der Filmtitel nicht, dass 125 Milliarden Parameter vollständig in 12 GB VRAM liegen.

Memory Mapping macht eine Datei zugänglich, aber nicht kostenlos.

Beim Modellladen werden Metadaten und Tensoren vorbereitet. Mit Memory Mapping kann eine Datei in den virtuellen Adressraum eingeblendet werden; das Betriebssystem lädt benötigte Seiten und kann sie zwischenspeichern. Daraus folgt weder, dass alle Gewichte sofort physisch im RAM liegen, noch dass eine SSD so schnell wie RAM oder VRAM wird.

Fehlt Arbeitsspeicher oder müssen ständig Daten nachgeladen werden, können Seitenzugriffe auf den Datenträger zum Engpass werden. Auch das erste Laden und die erste Antwort sind daher von der späteren Tokenausgabe zu unterscheiden.

Kapazität, Geschwindigkeit und Qualität getrennt prüfen.

Tokens pro Sekunde sind nur mit den Messbedingungen aussagekräftig: Modellversion, Quantisierung, Hardware, Kontext, parallele Anfragen und Backend gehören dazu. Das Einlesen eines Prompts ist eine andere Phase als das fortlaufende Erzeugen der Antwort. Eine hohe Ausgaberate sagt für sich genommen nichts über Antwortqualität oder Wartezeit bis zum ersten Token aus.

Für einen konkreten Versuch prüfst du daher zuerst Format-/Backend-Unterstützung und Lizenz, dann Gewichtsgröße und freie Speicherbereiche, anschließend den tatsächlichen Bedarf bei deiner Kontextlänge. Miss unter deinen Bedingungen und kontrolliere die Ergebnisse. Für die hier erklärte Orientierung sind keine erfundenen Tokens/s- oder FPS-Werte nötig.

Auch lokal ausgeführte Anwendungen können Netzfunktionen, Protokolle oder Werkzeuge haben. Berechtigungen und Datenschutzgrenzen bleiben deshalb relevant. Wie die Anfrage den Laufzeitbedarf mitbestimmt, zeigt die Kontextfenster-Erklärung.

Die Grundlagen im Serverbetrieb anwenden.

Diese Lernschritte verbinden das Thema mit einer konkreten Infrastruktur:

Passend dazu ansehen.

Veröffentlichte BitSicht-Videos mit Zusammenfassung, Kapiteln und einem Player, den du selbst aktivierst.

Quellen und Stand.

Fachlich geprüft am . Rechenwege, Beispiele und Diagramme sind eigene Darstellungen. Vereinfachte Beispiele sind gekennzeichnet. Laufende Dokumentation wurde für allgemeine Konzepte verwendet; produktspezifische Belege sind mit Stand oder Version benannt.