Was ein Modell an Hardware braucht

Ein Sprachmodell belegt auf einem Rechner zwei Posten. Der erste ist die Datei mit den Gewichten, und ihre Größe rechnet Beurteilen und Einordnen, Kapitel 01 aus der Parameterzahl vor. Der zweite entsteht erst beim Arbeiten: der KV-Cache, in dem das Modell für jedes Token des Gesprächs Zwi­schen­er­geb­nisse ablegt. Er wächst mit der Länge des Textes und kann größer werden als die Gewichte.

Dieses Kapitel rechnet beide Posten an einem Beispiel aus. Es zeigt außerdem, warum ein Modell einen Text in einem Zug einliest und seine Antwort deutlich langsamer schreibt. Die Ursache im Modell beschreibt Grundkurs, Kapitel 02. Hier geht es um die Folge für die Hardware.

Zwei Posten belegen den Speicher

Das Beispiel ist Qwen3-30B-A3B-Instruct-2507 von Alibaba. Laut Modellkarte (externe Seite, huggingface.co) hat es 30,5 Milliarden Parameter, von denen je Token 3,3 Milliarden rechnen. Es ist also ein Mixture-of-Experts-Modell. Von Haus aus verarbeitet es 262.144 Token.

Die Gewichte sind der feste Posten. Sie liegen im Speicher, sobald das Modell geladen ist, und ihre Größe bleibt danach gleich.

Der KV-Cache ist der bewegliche Posten. Ein Modell, das antwortet, schaut bei jedem neuen Token auf alle Token davor. Damit es deren Zwischenwerte nicht jedes Mal neu berechnet, hält es sie bereit. Je Token und Schicht sind das ein Satz Schlüssel (Keys) und ein Satz Werte (Values). Daher kommt der Name. Je länger Eingabe und Antwort zusammen sind, desto mehr Platz belegt er. Wie Schlüssel und Werte in der Aufmerksamkeit zusammenwirken, steht in Kapitel 01.

Die Gewichte richten sich nach der Genauigkeit

Wie viel Platz die Gewichte brauchen, folgt aus zwei Zahlen: der Parameterzahl und den Bit je Parameter. Vom Beispiel gibt es drei verbreitete Fassungen.

Die Fassung in 8 Bit bietet Alibaba selbst an. Laut Modellkarte der FP8-Fassung (externe Seite, huggingface.co) werden die Gewichte dafür blockweise umgerechnet. Ein Block umfasst nach der Kon­fi­gu­ra­ti­ons­datei derselben Ablage 128 mal 128 Werte und hat einen eigenen Skalierungsfaktor. Insgesamt wiegt die Fassung 51 Prozent derjenigen in 16 Bit. Was über die Hälfte hinausgeht, sind fast ganz die beiden Matrizen für das Vokabular am Ein- und Ausgang, die in 16 Bit bleiben. Die Ska­lie­rungs­fak­toren machen wenige Megabyte aus.

Die Fassung in 4 Bit stammt aus der Ollama-Bibliothek (externe Seite, ollama.com), die sie mit 19 GB angibt. Die Datei wiegt 18.556.685.856 Byte, also 18,6 Gigabyte, und llama.cpp meldet beim Laden im Mittel 4,86 Bit je Gewicht.

Den Schritt von 16 auf 8 oder 4 Bit nennt man Quantisierung. Was er an Genauigkeit kostet und wann er geschieht, steht in Beurteilen und Einordnen, Kapitel 01.

Der KV-Cache wächst mit jedem Token

Wie viel der KV-Cache je Token belegt, lässt sich aus drei Angaben ausrechnen. Das Beispiel hat 48 Schichten und 4 Schlüssel-Wert-Köpfe, so steht es auf der Karte der ersten Fassung vom April 2025 (externe Seite, huggingface.co) und der Fassung 2507 (externe Seite, huggingface.co). Jeder Kopf rechnet laut Kon­fi­gu­ra­ti­ons­datei (externe Seite, huggingface.co) mit 128 Zahlen. Schlüssel und Werte belegen in 16 Bit je Zahl 2 Byte. Eigene Rechnung:

2 × 48 × 4 × 128 × 2 Byte = 98.304 Byte je Token

Das ist knapp ein Zehntel Megabyte. Bei 4.096 Token belegt der KV-Cache damit 0,4 Gigabyte, bei 32.768 Token 3,2 Gigabyte. Bei der vollen Länge von 262.144 Token sind es 25,8 Gigabyte, mehr als die Gewichte in 4 Bit.

Eine eigene Messung trifft die Rechnung auf das Byte. Gemessen wurde am 19.10.2026 auf einem MacBook Pro mit M4 Max und 64 GB, mit llama.cpp Build 11669. Das Programm meldet bei 4.096 Token 384 MiB und bei 32.768 Token 3.072 MiB, also 0,4 und 3,2 Gigabyte. Die Formel dahinter erklärt die zweite Ebene.

Der Hersteller kennt den Engpass. Die Modellkarte rät bei Speichermangel, die Kontextlänge zu verkürzen, etwa auf 32.768 Token.

Drei Modelle brauchen bei voller Länge fast gleich viel

Die eigene Messung umfasst zwei weitere Modelle in 4 Bit. Das eine ist Qwen3-4B-Instruct-2507, das Beispiel aus Kapitel 01, das andere Gemma 4 31B von Google. Angelegt hat llama.cpp den Cache bei 4.096 und 32.768 Token. Für die volle Länge von 262.144 Token hat es den Bedarf beim Start vorausberechnet, um zu prüfen, ob der Speicher reicht.

seitlich verschiebbar

eigene Messung mit llama.cpp Build 11669, 19.10.2026

Die Werte bei 262.144 Token sind die Vorausberechnung von llama.cpp. Die Summen sind aus den Byte gerechnet, deshalb weicht die letzte Stelle bei gerundeten Posten mitunter ab. Ein Gigabyte sind hier eine Milliarde Byte, die 2,5 Gigabyte von Qwen3-4B sind binär gezählt 2,3 GiB. Mit den Rechenpuffern des Programms kommen 42,6, 45,0 und 44,0 Gigabyte heraus.

Die beiden anderen Dateien sind gut siebenmal so groß wie die kleinste. Bei voller Länge brauchen alle drei für Datei und Cache zwischen 41 und 44 Gigabyte. Die Spanne beträgt gut 3 Gigabyte, rund 7 Prozent des größten Werts. Der Cache ist bei Qwen3-4B 15,5-mal so groß wie die Datei, beim Beispiel 1,4-mal und bei Gemma 4 1,2-mal.

Qwen3-4B legt je Token sogar mehr ab als das große Qwen-Modell, 147.456 Byte. Es hat 8 Schlüssel-Wert-Köpfe in 36 Schichten, das Beispiel 4 in 48. Gemma 4 sieht laut Kon­fi­gu­ra­ti­ons­datei (externe Seite, huggingface.co) in 50 seiner 60 Schichten nur die jüngsten 1.024 Token. Die zweite Ebene erklärt dieses Gleitfenster.

Die Herstellerkarte von Qwen3-4B-Instruct-2507 enthält denselben Rat wie die des Beispiels: bei Speichermangel die Kontextlänge auf etwa 32.768 Token kürzen (Modellkarte (externe Seite, huggingface.co)).

Die Kontextlänge stellt oft das Programm ein

Ohne eigene Angabe wählt die Laufzeit, wie lang der Kontext sein darf. Ollama (externe Seite, docs.ollama.com) richtet sich dabei nach dem Grafikspeicher des Geräts:

• unter 24 GiB (25,8 GB) 4.096 Token,
• von 24 bis 48 GiB 32.768 Token,
• ab 48 GiB (51,5 GB) 262.144 Token.

llama.cpp (externe Seite, github.com) übernimmt ohne Angabe die Länge, die im Modell steht. Reicht der Speicher dafür nicht, verkürzt es sie von sich aus, bis hinunter auf 4.096 Token.

Auf einem Gerät mit viel Speicher nehmen damit beide Programme von sich aus die volle Länge, llama.cpp allerdings nur, sofern sie hineinpasst. Auf dem Messgerät stellte Ollama 0.40.6 für das Beispiel 262.144 Token ein und belegte beim Laden 32 Gigabyte. Dort ist eine Einstellung gesetzt, die den Cache etwa halbiert. Ohne sie wären es nach eigener Rechnung 44,3 Gigabyte für Gewichte und Cache, dazu die Rechenpuffer. Die dritte Ebene zeigt die Einstellung und die Messung.

Für Entscheider folgt daraus eine Lesart. Die 19 GB auf der Bibliotheksseite sind die Größe der Gewichte. Was das Modell beim Arbeiten zusätzlich braucht, hängt an der Kontextlänge, und dazu macht die Seite keine Angabe.

Einlesen rechnet, Antworten liest

Eine Antwort entsteht in zwei Phasen. Im Prefill liest das Modell die ganze Eingabe in einem Durchgang ein. Im Decode entsteht die Antwort Token für Token, und jedes Token braucht einen eigenen Durchgang durch das Modell.

Die beiden Phasen stoßen an verschiedene Grenzen. Beim Einlesen rechnen viele Token zugleich mit denselben Gewichten, die Rechenwerke sind ausgelastet. Beim Antworten muss für jedes einzelne Token alles Nötige aus dem Speicher geholt werden, und die Rechenwerke warten. Apple (externe Seite, machinelearning.apple.com) fasst es so: Die Rechenleistung begrenzt die Zeit bis zum ersten Token, die Spei­cher­band­breite die Erzeugung danach.

Apple hat das an einem Chipwechsel gemessen, mit je einem MacBook Pro mit M4 und M5 und einer Eingabe von 4.096 Token. Vom M4 zum M5 bekam die Grafikeinheit eigene Beschleuniger für Matrizen, die Neural Accelerators. Die Bandbreite stieg um rund 28 Prozent. Die Zeit bis zum ersten Token sank auf ein Drittel bis ein Viertel, das Tempo der Antwort stieg um 19 bis 27 Prozent. Die Antwort folgte also der Bandbreite.

Die eigene Messung zeigt den Abstand der Phasen an einem Gerät. Das Beispiel las auf dem MacBook Pro rund 1.600 Token je Sekunde ein. Seine Antwort schrieb es mit 127 Token je Sekunde. Das Einlesen war damit knapp dreizehnmal so schnell. Wie sich Bandbreite und Rechenleistung über die Jahre entwickeln, steht in Beurteilen und Einordnen, Kapitel 05.

Das große Modell antwortet fast so schnell wie das kleine

Bei einem Mixture-of-Experts-Modell rechnet je Token nur ein Teil der Gewichte, beim Beispiel 3,3 von 30,5 Milliarden. In 4 Bit sind das rund 2,0 Gigabyte, die je Token gelesen werden. Qwen3-4B ist dicht gebaut und liest bei jedem Token seine ganze Datei, 2,5 Gigabyte.

In der eigenen Messung schrieben beide Modelle fast gleich schnell, Qwen3-4B 133 und das Beispiel 127 Token je Sekunde. Dabei ist die Datei des Beispiels gut siebenmal so groß. Den Speicherbedarf bestimmt die Gesamtzahl der Parameter, das Tempo die aktive Zahl. Nach der gelesenen Datenmenge allein wäre das Beispiel sogar ein Viertel schneller. Es nutzt die Bandbreite aber zu einem kleineren Teil, das rechnet die zweite Ebene nach. Wie ein solches Modell je Token rechnet, erklärt der Beitrag Wie ein Mixture-of-Experts-Modell rechnet. Was die Bauform für kleine Modelle heißt, steht in KI jenseits der Sprachmodelle, Kapitel 10.

Diese Regel gilt bei kurzem Kontext. Beim Antworten liest das Modell neben den Gewichten auch die Schlüssel und Werte aller vorigen Token, so beschreibt es die Arbeit zur Grouped-Query Attention (externe Seite, arxiv.org). Bei 32.768 Token liest das Beispiel so für jedes neue Token 3,2 Gigabyte aus dem Cache, mehr als seine aktiven Gewichte. Was das für das Tempo heißt, misst die dritte Ebene.

Drei Zahlen prüfen ein Gerät

Ob ein Modell auf ein Gerät passt und wie schnell es dort antwortet, lässt sich an drei Zahlen prüfen.

1. Speicher. Er muss Gewichte und KV-Cache fassen, dazu die Rechenpuffer und alles, was daneben läuft. Auf einem Mac teilen sich Prozessor und Grafik einen Speicher. Wie viel davon die Grafik nutzen kann, zeigt die zweite Ebene.
2. Spei­cher­band­breite. Sie begrenzt, wie schnell die Antwort kommt. Apple nennt sie in den technischen Daten, beim Messgerät 546 GB/s (Datenblatt (externe Seite, support.apple.com)). Geteilt durch die Byte, die je Token gelesen werden, ergibt sie eine Obergrenze für die Token je Sekunde.
3. Die Kontextlänge der Aufgabe. Ein kurzer Wortwechsel braucht wenig davon, ein langes Dokument viel. Sie entscheidet, ob der KV-Cache ein Randposten bleibt oder den größten Teil des Speichers belegt. Dazu gehört die Frage, welche Länge die Laufzeit von sich aus einstellt.

Der Überblick hat die beiden Posten an einem Beispiel gezeigt. Diese Ebene leitet die Formel für den KV-Cache her und zeigt, wie zwei Bauformen ihn verkleinern. Danach folgen die beiden Phasen einer Antwort an einem Chipwechsel, der Unterschied zwischen Unified Memory und eigener Grafikkarte und eine Obergrenze für das Tempo. Das Beispiel bleibt Qwen3-30B-A3B-Instruct-2507.

Die Formel für den KV-Cache

Jede Schicht legt für jedes Token einen Schlüssel und einen Wert ab. Beide bestehen je Schlüssel-Wert-Kopf aus so vielen Zahlen, wie die Kopfdimension angibt. Daraus folgt:

KV-Cache je Token = 2 × Schichten × Schlüssel-Wert-Köpfe × Kopfdimension × Byte je Zahl

Die 2 steht für Schlüssel und Wert. Byte je Zahl sind 2 bei 16 Bit, und 16 Bit sind bei llama.cpp voreingestellt (Doku des Servers (externe Seite, github.com)).

Die Arbeit zu vLLM (externe Seite, arxiv.org) rechnet 2023 genauso, am Modell OPT-13B. Sie multipliziert Schlüssel und Wert mit 5.120 Zahlen Breite, 40 Schichten und 2 Byte. Ein einzelnes Token belegt dort 800 Kilobyte, gezählt zu je 1.024 Byte. Bei OPT hat jeder Abfragekopf seinen eigenen Schlüssel-Wert-Kopf. Deshalb steht in der Rechnung die volle Breite des Modells.

Im Quelltext von llama.cpp steht dieselbe Formel (Quelltext, Build 11669 (externe Seite, github.com)). Je Schicht legt das Programm einen Tensor für die Schlüssel und einen für die Werte an. Seine Breite ist die Kopfdimension mal die Zahl der Schlüssel-Wert-Köpfe, seine Länge die Kontextlänge.

Die eigene Messung vom 19.10.2026 hält die Rechnung gegen das Programm. Gemessen wurde auf einem MacBook Pro mit M4 Max und 64 GB, mit llama.cpp Build 11669 und dem Cache in 16 Bit. Die Werte für Qwen3-4B-Instruct-2507 stammen aus dessen Kon­fi­gu­ra­ti­ons­datei (externe Seite, huggingface.co), die für das Beispiel aus Modellkarte (externe Seite, huggingface.co) und Kon­fi­gu­ra­ti­ons­datei (externe Seite, huggingface.co).

llama.cpp meldet den Cache in MiB, zu je 1.048.576 Byte. Die 4.608 MiB sind 4,8 Gigabyte, die 3.072 MiB 3,2 Gigabyte. Auch bei 4.096 Token trifft die Rechnung genau, mit 576 und 384 MiB.

Der Rechner zeigt für drei Modelle Gewichte und KV-Cache bei drei Kontextlängen. Die Werte des Cache sind aus den Kon­fi­gu­ra­ti­ons­da­teien gerechnet und gegen die eigene Messung gehalten. Die Konfiguration von Gemma 4 31B (externe Seite, huggingface.co) sieht in den vollen Schichten gleiche Schlüssel und Werte vor. llama.cpp Build 11669 legt beide trotzdem getrennt an, und die Rechnung folgt dem Programm.

Bei 262.144 Token käme der Cache von Qwen3-4B-Instruct-2507 auf 38,7 Gigabyte. Das ist fast das Fünffache seiner Gewichte in 16 Bit, die 8,0 Gigabyte wiegen. Diesen Wert hat llama.cpp nur vorausberechnet, zugeteilt wurde der Cache in der Messung bei 4.096 und 32.768 Token.

Geteilte Köpfe sparen ein Vielfaches

Das Beispiel rechnet die Aufmerksamkeit mit 32 Abfrageköpfen und hält dafür 4 Schlüssel-Wert-Köpfe vor. Je acht Abfrageköpfe teilen sich also einen. Das Verfahren heißt Grouped-Query Attention. Die Arbeit dazu (externe Seite, arxiv.org) beschreibt es 2023 als Mitte zwischen zwei Extremen: einem Schlüssel-Wert-Kopf je Abfragekopf und einem einzigen für alle.

Nach Abschnitt 2.2 der Arbeit sinken mit der Zahl der Schlüssel-Wert-Köpfe der Cache und die Datenmenge, die je Token geladen werden muss, im selben Verhältnis. Die Qualität blieb in ihren Versuchen nahe am Aufbau mit einem Kopf je Abfragekopf. Gemessen haben die Autoren an T5-Modellen, die sie nachträglich auf geteilte Köpfe umgestellt und mit 5 Prozent des ursprünglichen Rechenaufwands nachtrainiert haben.

Eigene Rechnung: Hätte das Beispiel für jeden der 32 Abfrageköpfe einen eigenen Schlüssel-Wert-Kopf, wäre sein Cache achtmal so groß. Das wären 786.432 Byte je Token und bei voller Länge 206,2 Gigabyte. Qwen3-4B-Instruct-2507 spart mit 8 statt 32 Köpfen das Vierfache. Wie die Köpfe im Block angeordnet sind, zeigt Kapitel 01.

Kleine Modelle sprengen die Faustregel zuerst

Beurteilen und Einordnen, Kapitel 01 gibt für den Speicher eine Näherung an: Dateigröße plus ein Viertel. Das Viertel deckt den KV-Cache bis zu einer bestimmten Länge. Die Grenze ergibt sich, wenn man das Viertel der Datei durch den Cache je Token teilt. Eigene Rechnung, Cache in 16 Bit, eine Anfrage, Rechenpuffer außen vor:

Die Näherung reicht also bei kurzen Texten. Wie lang der Kontext ist, stellt oft die Laufzeit ein, bei Ollama (externe Seite, docs.ollama.com) nach dem Grafikspeicher:

• Unter 24 GiB stellt Ollama 4.096 Token ein. Die Näherung reicht für alle drei Modelle, bei Qwen3-4B knapp. Mit den gemessenen 0,36 Gigabyte Rechenpuffer reicht sie bei Qwen3-4B nicht mehr.
• Von 24 bis 48 GiB sind es 32.768 Token. Für die beiden großen Modelle reicht sie, für Qwen3-4B fehlt Platz: 4,8 Gigabyte Cache bei 2,5 Gigabyte Datei.
• Ab 48 GiB sind es 262.144 Token. Dort reicht sie bei keinem der drei.

Die GQA-Arbeit (externe Seite, arxiv.org) nennt einen allgemeinen Grund: Der Cache wächst mit der Breite eines Modells, Parameterzahl und Rechenaufwand wachsen mit dem Quadrat der Breite.

Bei den drei Modellen hier wirken zwei Bauentscheidungen stärker. Qwen3-30B-A3B ist laut Kon­fi­gu­ra­ti­ons­datei (externe Seite, huggingface.co) mit 2.048 Zahlen sogar schmaler als Qwen3-4B mit 2.560 (externe Seite, huggingface.co) und hält 4 statt 8 Schlüssel-Wert-Köpfe vor. Seine übrigen Parameter stecken in 128 Experten (externe Seite, huggingface.co). Sie vergrößern die Datei, und der Cache bleibt dabei gleich. Gemma 4 31B spart mit einem Gleitfenster, das der nächste Abschnitt beschreibt.

Ein Gleitfenster deckelt den Speicher

Manche Modelle sehen in einem Teil ihrer Schichten nur die jüngsten Token. Google begründet das im Bericht zu Gemma 3 (externe Seite, arxiv.org) mit dem Speicher: Bei langem Kontext schwelle der KV-Cache beim Betrieb stark an. Gemma 3 wechselt deshalb lokale und globale Schichten ab. Die lokalen sehen nur die letzten 1.024 Token, und allein die globalen sehen den ganzen Text.

Abschnitt 5.2 des Berichts beziffert die Wirkung an einem Versuchsmodell mit 2 Milliarden Parametern. Mit lauter globalen Schichten kostet der Cache bei 32.000 Token 60 Prozent zusätzlich zum Modell. In der Fassung mit dem Verhältnis 1:3 und einem Fenster von 1.024 Token sind es weniger als 15 Prozent. Für die Aufteilung von Gemma 3, fünf lokale je globaler Schicht, zeigt der Bericht den Verlauf in Abbildung 6.

Gemma 4 31B zeigt die Wirkung in der eigenen Messung. Laut Kon­fi­gu­ra­ti­ons­datei (externe Seite, huggingface.co) sehen 50 seiner 60 Schichten nur die letzten 1.024 Token. Für sie legt llama.cpp einen festen Block von 1.200 MiB an, das sind 1,3 Gigabyte: Platz für das Fenster und 512 weitere Token für einen Stapel neuer Eingaben. Diese Größe bleibt ab 1.536 Token Kontext gleich. Mit der Länge wachsen allein die 10 Schichten, die den ganzen Text sehen.

Ein zweites Beispiel ist gpt-oss-20b von OpenAI. Laut Kon­fi­gu­ra­ti­ons­datei (externe Seite, huggingface.co) wechseln seine 24 Schichten zwischen einem Fenster von 128 Token und dem vollen Kontext. Es hat 8 Schlüssel-Wert-Köpfe mit je 64 Zahlen. Eigene Rechnung für die 12 Schichten mit vollem Kontext: 24.576 Byte je Token, bei der vollen Länge von 131.072 Token 3,2 Gigabyte. OpenAI gibt das Modell für Systeme ab 16 Gigabyte Speicher an (Bericht (externe Seite, arxiv.org)). Gemessen ist gpt-oss-20b hier nicht.

Ein Chipwechsel trennt die beiden Phasen

Im November 2025 hat Apple (externe Seite, machinelearning.apple.com) sechs Modelle auf zwei Rechnern gemessen. Der eine war ein MacBook Pro mit M5 und 24 GB, der andere ein ähnlich ausgestattetes MacBook Pro mit M4. Gemessen wurde mit mlx_lm.generate bei einer Eingabe von 4.096 Token. Das Tempo der Antwort gilt für 128 weitere Token. Die Grafikeinheit des M5 hat eigene Beschleuniger für Matrizen, die Neural Accelerators, und MLX nutzt sie ab macOS 26.2.

Nach Apple begrenzt die Rechenleistung die Zeit bis zum ersten Token, und dort greifen die neuen Beschleuniger. Die Spei­cher­band­breite begrenzt die Erzeugung jedes weiteren Tokens. Sie stieg vom M4 zum M5 von 120 auf 153 GB/s, um den Faktor 1,275, und Apple rundet auf 28 Prozent. Für die Rechenleistung nennt Apple keinen Faktor.

seitlich verschiebbar

Apple, Tabelle 1, 19.11.2025 (apple-mlx-m5-2025)

Tabelle 1 des Beitrags nennt je Modell zwei Beschleunigungen und den Speicher im Betrieb.

Die Antwort wurde also um 19 bis 27 Prozent schneller, etwas weniger als die Bandbreite gewachsen ist. Das erste Token kam bis zu viermal so schnell. Die letzte Zeile ist die erste Fassung des Beispiels vom April 2025 in 4 Bit, mit denselben Schichten, Köpfen und Experten. Sie blieb mit 17,31 Gigabyte unter 18 Gigabyte, gemessen mit 4.096 Token Eingabe.

Ein zweites Chippaar zeigt dieselbe Einteilung. Im Beitrag zur verteilten Ausführung (externe Seite, machinelearning.apple.com) vom Oktober 2026 nennt Apple die Zeit bis zum ersten Token im Kern rechengebunden und das Antworttempo band­brei­ten­ge­bunden. Vom M3 Ultra zum M5 Ultra stieg die Bandbreite von 819 GB/s auf 1,2 TB/s, also um den Faktor 1,47. Das Antworttempo stieg nach dem Beitrag um das 1,6-Fache, in seiner Tabelle 3 um das 1,55- bis 1,59-Fache. Es wuchs also etwas stärker als die Bandbreite. Einen Grund dafür nennt der Beitrag nicht.

Unified Memory und eigene Grafikkarte

Auf einem Mac mit Apple-Chip teilen sich Prozessor und Grafik einen Arbeitsspeicher. Apple nennt das Unified Memory. Das Framework MLX (externe Seite, github.com) baut darauf: Seine Arrays liegen im gemeinsamen Speicher, und eine Operation kann auf Prozessor oder Grafik laufen, ohne dass Daten kopiert werden.

Die Grafik nutzt davon einen Teil. Apples Schnittstelle Metal nennt eine Größe, die die Grafik belegen kann, ohne langsamer zu werden (Entwicklerdoku (externe Seite, developer.apple.com)). Auf dem Messgerät mit 64 GB (Datenblatt (externe Seite, support.apple.com)) meldet Metal 55.662,79 MB, also 55,7 Gigabyte.

Das Gerät selbst meldet 68.719.476.736 Byte Arbeitsspeicher, denn Apple zählt die 64 GB binär. Der Grafik stehen damit 81 Prozent zu. Dieser Anteil gilt für dieses Gerät. Für andere Speichergrößen nennt Apple keinen.

Denselben Wert liest Ollama als Grafikspeicher, auf dem Messgerät 51,8 GiB. Daraus folgt die Kontextlänge von 262.144 Token, denn die Staffel der Doku (externe Seite, docs.ollama.com) setzt sie ab 48 GiB.

Eine Grafikkarte im PC hat ihren eigenen Speicher. Die GeForce RTX 5090 bringt 32 GB (externe Seite, nvidia.com) mit. Das Beispiel in 4 Bit braucht bei 32.768 Token 21,8 Gigabyte für Gewichte und Cache und passt hinein. Bei 262.144 Token braucht es 44,3 Gigabyte, mehr als die Karte hat. Beides ist eigene Rechnung, ohne Rechenpuffer.

Die Rechen­zen­trums­karte H100 hat in der Fassung SXM laut Datenblatt (externe Seite, nvidia.com) 80 GB bei 3,35 TB/s. In 16 Bit braucht das Beispiel bei voller Länge 86,8 Gigabyte. Damit reicht eine Karte nicht. Wie sich ein Modell auf mehrere Karten verteilt, zeigt die dritte Ebene.

Passt ein Modell nicht ganz in den Grafikspeicher, lassen sich Schichten auslagern. llama.cpp hat dafür einen Schalter mit der Höchstzahl der Schichten im Grafikspeicher (Doku (externe Seite, github.com)). Die übrigen Schichten rechnet der Prozessor aus dem Hauptspeicher.

Ollama lädt ein Modell auf eine einzige Grafikkarte, wenn es dort hineinpasst. Das spart nach der FAQ (externe Seite, docs.ollama.com) Datenverkehr über den PCI-Bus.

In llama.cpp gibt es für MoE-Modelle eigene Schalter, die die Experten auf den Prozessor legen. Sie beschreibt der Beitrag Wie ein Mixture-of-Experts-Modell rechnet.

Die Obergrenze für das Tempo ist eine Division

Beim Antworten liest das Modell je Token seine aktiven Gewichte und den KV-Cache. Teilt man die Spei­cher­band­breite durch diese Byte, ergibt sich eine Obergrenze für die Token je Sekunde. Annahme: Die ganze aktive Menge wird je Token einmal gelesen. Zwischenspeicher im Chip und die Auswahl der Experten bleiben außen vor.

Beim Beispiel in 4 Bit sind das je Token rund 2,0 Gigabyte aktive Gewichte, 3,3 Milliarden Parameter mal 4,86 Bit. Bei fast leerem Kontext fällt der Cache kaum ins Gewicht. Eigene Rechnung:

Gemessen ist nur die mittlere Zeile, am 20.10.2026 mit llama.cpp Build 11669.

Auf dem M4 Max schrieb das Beispiel 127 Token je Sekunde. Das sind 46 Prozent der Obergrenze. Qwen3-4B kam auf 133 von rund 220 Token je Sekunde, also 61 Prozent. Die Obergrenze sagt, was die Bandbreite höchstens zulässt. Erreicht wurden 46 bis 61 Prozent davon.

Mit langem Kontext wächst der Nenner. Bei 32.768 Token liest das Beispiel je Token 2,0 Gigabyte Gewichte und 3,2 Gigabyte Cache. Die Obergrenze sinkt damit auf rund 105 Token je Sekunde. Wie weit die Messung dem folgt, zeigt die dritte Ebene.

Die zweite Ebene hat die Formel für den KV-Cache hergeleitet und eine Obergrenze für das Tempo ausgerechnet. Diese Ebene misst, wie weit das Tempo bei langem Kontext der Rechnung folgt. Danach geht es um drei Stellschrauben der Laufzeit: die Genauigkeit des Cache, die Reservierung beim Laden und die Verteilung auf mehrere Grafikkarten. Am Ende steht die Nachrechnung einer Herstellerangabe.

Langer Kontext bremst auch das Antworten

Beim Antworten liest das Modell je Token die Gewichte und dazu die Schlüssel und Werte aller vorigen Token. Die Arbeit zur Grouped-Query Attention (externe Seite, arxiv.org) nennt genau das als Engpass bei jedem Schritt der Ausgabe. Mit wachsendem Kontext wächst also die Datenmenge je Token.

Gemessen wurde das mit llama-bench: 512 Token Eingabe und 128 Token Antwort, hinter einem schon gefüllten Kontext von 0, 8.192 und 32.768 Token. Jede Stufe lief fünfmal, in drei Durchgängen, der Cache in 16 Bit, Flash Attention an. Gerät war ein MacBook Pro mit M4 Max und 64 GB, Programm llama.cpp Build 11669, Datum der 20.10.2026. Es ist eine Messreihe an einem Vormittag.

Auf dem Gerät liefen dabei andere Programme. Die Systemlast lag zwischen rund 2 und 12. Ein Durchgang von Qwen3-4B war gestört, seine leere Stufe lag rund 30 Prozent unter den beiden anderen. Er ist deshalb nicht gewertet. Die Tabelle nennt die Spanne der übrigen Durchgänge.

Die Vorhersage ist eine eigene Rechnung. Sie geht von der Obergrenze aus der Bandbreite bei diesem Kontext aus. Davon nimmt sie den Anteil, den das Modell bei leerem Kontext erreicht hat: 61 Prozent bei Qwen3-4B, 46 beim Beispiel. Gerechnet wird mit den je Token gelesenen Gewichten, 2,5 und 2,0 Gigabyte, und mit dem Cache nach der Formel der zweiten Ebene.

seitlich verschiebbar

eigene Messung mit llama.cpp Build 11669, 20.10.2026

Qwen3-4B lag bei 8.192 Token etwas über der Vorhersage. Das Beispiel streute dort zwischen den Durchgängen von 68 bis 88 Token je Sekunde und blieb in allen unter der Vorhersage. Stabil ist der Wert des Beispiels bei 32.768 Token: In allen drei Durchgängen lag er bei 38 bis 39 Token je Sekunde. Das ist rund ein Fünftel unter der Vorhersage. Qwen3-4B lag bei dieser Länge einmal darunter und einmal darüber.

Woher die Abweichung beim Beispiel kommt, ist offen. In Frage kommen der Rechenaufwand der Aufmerksamkeit, der mit der Länge wächst, und die Umsetzung im Programm. Wer die Streuung kleiner haben will, misst auf einem Gerät, auf dem sonst nichts läuft.

Auch das Einlesen wird langsamer. Qwen3-4B las 512 neue Token bei leerem Kontext mit rund 1.650 Token je Sekunde ein, hinter 32.768 vorhandenen Token mit 272 bis 307. Beim Beispiel fiel das Einlesen von rund 1.600 auf 199 bis 221 Token je Sekunde. Wer lange Texte verarbeitet, sollte das Tempo deshalb bei seiner eigenen Länge messen. Die Werte bei leerem Kontext sagen dafür wenig.

Der Cache lässt sich gröber speichern

Wie die Gewichte lässt sich auch der Cache mit weniger Bit speichern. llama.cpp hält ihn voreingestellt in 16 Bit (Doku des Servers (externe Seite, github.com)). Es bietet gröbere Typen an, darunter 8 Bit mit dem Namen q8_0. Bei Ollama heißt die Einstellung OLLAMA_KV_CACHE_TYPE, voreingestellt sind dort ebenfalls 16 Bit. Laut FAQ (externe Seite, docs.ollama.com) braucht der Cache in 8 Bit etwa die Hälfte. Die gröberen Typen wirken dort nur bei eingeschalteter Flash Attention. Ollama schaltet Flash Attention selbst ein, wo Laufzeit und Gerät sie unterstützen.

Auf dem Messgerät steht die Einstellung auf q8_0, Flash Attention ist eingeschaltet. Das Beispiel lud Ollama 0.40.6 dort mit 262.144 Token Kontext, und der Cache belegte 13.056 MiB, also 13,7 Gigabyte. In 16 Bit wären es 24.576 MiB oder 25,8 Gigabyte. Das Verhältnis ist 0,53, nach eigener Rechnung also 8,5 von 16 Bit je Wert. Nach dem Quelltext von ggml speichert q8_0 zu je 32 Werten einen Skalierungsfaktor in 16 Bit, und daraus ergeben sich genau diese 8,5 Bit.

Die FAQ nennt auch eine Grenze. Modelle mit vielen Abfrageköpfen je Schlüssel-Wert-Kopf können durch die Quantisierung des Cache stärker an Genauigkeit verlieren. Beim Beispiel teilen sich acht Abfrageköpfe einen Schlüssel-Wert-Kopf. Wie viel es dabei verliert, ist hier nicht gemessen.

Die Quantisierung der Gewichte verkleinert den festen Posten, die des Cache den beweglichen. Beide lassen sich getrennt einstellen. Was die Quantisierung der Gewichte kostet, steht in Beurteilen und Einordnen, Kapitel 01.

Reserviert ist mehr als belegt

Ollama 0.40.6 legt den Cache beim Laden für die volle Länge an. Nach dem ersten Aufruf des Beispiels zeigte ollama ps auf dem Messgerät 32 GB, einen Kontext von 262.144 Token und als Laufzeit llama.cpp. Das Programm meldete den Cache dabei in voller Größe, 13.056 MiB. Der Platz ist damit ab dem Laden reserviert, gleich wie lang das Gespräch tatsächlich wird.

Seit Version 0.40.0 nimmt Ollama auf Apple Silicon die Laufzeit MLX, für alle Bauformen, die sie unterstützt (Release Notes (externe Seite, github.com)). Das Beispiel lief über llama.cpp. Ob Ollama mit MLX ebenso vorab reserviert, ist hier nicht gemessen.

Wie lang der Kontext ist, wählt Ollama ohne eigene Angabe nach dem Grafikspeicher (Doku (externe Seite, docs.ollama.com)). Die Doku sagt dazu, dass eine größere Länge mehr Speicher braucht. Wer den Speicher für anderes braucht, setzt die Länge deshalb selbst.

Mehrere gleichzeitige Anfragen vervielfachen den Posten. Jede braucht ihren eigenen Cache. Laut FAQ (externe Seite, docs.ollama.com) wächst der Speicher mit der Zahl paralleler Anfragen mal der Kontextlänge, eingestellt über OLLAMA_NUM_PARALLEL und OLLAMA_CONTEXT_LENGTH. Das ist die Kehrseite des Vorteils, den Beurteilen und Einordnen, Kapitel 01 für den eigenen Server beschreibt: Er rechnet sich, wenn viele Anfragen im selben Durchlauf laufen.

Ein Server wie vLLM ist um diesen Posten gebaut. Die Arbeit dazu (externe Seite, arxiv.org) beschreibt den Cache je Anfrage als groß. Er wächst und schrumpft mit der Anfrage. vLLM meldet beim Start, wie viele Token in den Speicher passen, der nach den Gewichten für den KV-Cache bleibt. Reicht das für die gewünschte Last nicht, rät die Doku (externe Seite, docs.vllm.ai) zu weiteren Karten oder Rechnern.

Was ein Betriebssystem als Speicher eines Modells anzeigt, ist eine dritte Größe. Der Bericht über eine eigene Diktier-App nennt für ein Modell drei Werte an drei Stellen des Systems, von etwa 1 bis etwa 13 Gigabyte. Alle drei stimmen und meinen Verschiedenes.

Mehrere Karten teilen ein Modell nach Schichten oder je Schicht

Passt ein Modell auf eine Karte, braucht es keine Verteilung. Passt es auf einen Rechner mit mehreren Karten, empfiehlt die Doku von vLLM (externe Seite, docs.vllm.ai) Tensor Parallelism.

Es gibt zwei Arten, ein Modell zu teilen. llama.cpp bietet beide an (Doku des Servers (externe Seite, github.com)):

• Nach Schichten (Pipeline). Jede Karte hält einen Block von Schichten samt deren Cache. Ein Token läuft nacheinander durch alle Karten.
• Innerhalb jeder Schicht (Tensor Parallelism). Jede Karte hält einen Teil jeder Schicht, und alle rechnen am selben Token zugleich. llama.cpp kennt dafür zwei Stellungen. Die eine teilt nur die Gewichte, Cache und Zwi­schen­er­geb­nisse liegen auf einer Hauptkarte. Die andere teilt auch den Cache und ist als experimentell gekennzeichnet.

Die Teilung nach Schichten verteilt den Speicher. Das Tempo der Antwort bleibt nach Apples Messung dabei im Wesentlichen gleich, denn jedes Token durchläuft die Schichten weiter nacheinander (Beitrag zur verteilten Ausführung (externe Seite, machinelearning.apple.com)).

Für das Beispiel heißt das: In 16 Bit braucht es bei voller Länge 86,8 Gigabyte, mehr als eine H100 mit 80 GB fasst. Für den Betrieb mit einer Million Token verteilt die Modellkarte das Modell auf vier Karten. Reicht dort der Platz für den Cache nicht, rät sie, die Länge zu kürzen oder auf mehr Karten zu verteilen.

Am oberen Ende passt ein Modell auf keinen einzelnen Rechner. Für Muse Spark Open nennt Apple (externe Seite, machinelearning.apple.com) in 16 Bit mehr als 1,6 Terabyte allein für die Parameter. In 4 Bit, im Format NVFP4, sind es rund 493 Gigabyte, knapp unter den bis zu 512 Gigabyte eines Mac Studio. Mit dem Speicher für die Zwi­schen­er­geb­nisse reicht ein Rechner trotzdem nicht. Apple verteilt das Modell deshalb auf zwei oder vier Mac Studio mit M5 Ultra.

Qwens 240 Gigabyte für eine Million Token, nachgerechnet

Die Modellkarte (externe Seite, huggingface.co) des Beispiels beschreibt auch einen Betrieb mit einer Million Token. Dafür nennt sie rund 240 Gigabyte Grafikspeicher insgesamt. Darin stecken nach ihrer Angabe die Gewichte, der KV-Cache und die Spitzen der Aktivierungen.

Eigene Rechnung mit der Formel aus der zweiten Ebene, alles in 16 Bit:

• Gewichte: 61,1 Gigabyte laut Indexdatei der Gewichte in der Ablage des Herstellers (externe Seite, huggingface.co).
• KV-Cache: 98.304 Byte je Token mal eine Million Token, also 98,3 Gigabyte.
• Zusammen: rund 160 Gigabyte.

Wie sich die 240 Gigabyte auf diese drei Posten verteilen, sagt die Karte nicht. Rechnerisch bleiben rund 80 Gigabyte für Aktivierungen und Reserve. Der Startbefehl der Karte für vLLM gibt dem Server 85 Prozent des Grafikspeichers frei, auf 240 Gigabyte gerechnet rund 204. Sicher zeigt die eigene Rechnung eines: Bei einer Million Token ist der Cache größer als die Gewichte, 98 zu 61 Gigabyte.

Dieselbe Rechnung geht mit jeder Modellkarte und Kon­fi­gu­ra­ti­ons­datei:

1. Schichten, Schlüssel-Wert-Köpfe und Kopfdimension ablesen.
2. Miteinander und mit 4 malnehmen, für Schlüssel und Wert zu je 2 Byte.
3. Mit der Kontextlänge malnehmen, die die Aufgabe braucht.
4. Die Gewichte dazuzählen und Platz für die Rechenpuffer lassen.

Qualität, Flash-Speicher und Messbedingungen stehen außerhalb der Rechnung

• Die Rechnung beantwortet zwei Fragen: ob ein Modell auf ein Gerät passt und wie schnell es dort höchstens antwortet. Wie weit kleine Modelle bei einer Aufgabe reichen, misst KI jenseits der Sprachmodelle, Kapitel 10.
• Apples Gerätemodell lädt seine Gewichte aus dem Flash-Speicher nach. Für diese Bauform gilt die Annahme dieses Kapitels nur eingeschränkt, alle Gewichte lägen im Arbeitsspeicher. Die zweite Ebene von KI jenseits der Sprachmodelle, Kapitel 10 beschreibt sie.
• Die Messwerte gelten für ein Gerät, einen Tag und eine Programmfassung. Wie stark solche Werte streuen und was sonst am Tempo dreht, zeigt der Bericht Elf Wege, ein lokales Modell schneller zu machen.