Qwen3.5-9B braucht 32KB pro Token für den KV-Cache

Alibabas Qwen3.5-9B nutzt volle Attention in nur 8 seiner 32 Schichten. Die anderen 24 nutzen ein lineares Verfahren, dessen Speicherbedarf nicht mit dem Gespräch wächst. Diese Teilung ist der Grund, warum ein Modell mit 9 Milliarden Parametern einen langen Chat auf einer 8GB-Grafikkarte halten kann.

Das Modell erschien im Februar 2026 unter der Apache-2.0-Lizenz. Die meiste Berichterstattung drehte sich um seine Testergebnisse. VentureBeat berichtete, es habe 81,7 auf GPQA Diamond erreicht, einem Wissenschaftstest auf Master-Niveau, und liege damit vor OpenAIs gpt-oss-120b mit 80,1. Für alle, die das Modell auf eigener Hardware betreiben, zählt der Aufbau der Schichten mehr als die Punktzahl.

Was ein KV-Cache ist und warum er wächst

Ein Sprachmodell liest das ganze Gespräch erneut, bevor es jedes neue Wort schreibt. Diese Arbeit jedes Mal zu wiederholen wäre langsam. Deshalb speichert das Modell Zwischenwerte, genannt Keys und Values, in einem Speicher namens KV-Cache.

Die Gewichte eines Modells sind ein fester Kostenblock. Der KV-Cache ist das nicht. Er wächst mit jedem Token im Gespräch.

Auf einer Maschine mit 8GB Speicher entscheidet dieser Unterschied viel. Eine Modelldatei kann problemlos laden und trotzdem keinen Platz mehr haben, sobald ein Chat lang wird. Wenn das passiert, verschiebt die Software meist Schichten auf den Hauptprozessor, statt gleich abzubrechen, und das Tempo fällt stark.

Wie Qwen3.5-9B seine Schichten aufteilt

Die Modellkarte von Qwen3.5-9B beschreibt den Stapel als 8 Wiederholungen eines Blocks aus 4 Schichten. Drei Schichten in jedem Block nutzen Gated DeltaNet, ein linear arbeitendes Attention-Verfahren. Die vierte nutzt gated volle Attention.

Lineare Attention hält einen laufenden Zustand fester Größe. Er wächst nicht, wenn der Text länger wird. Diese 24 Schichten kosten bei 4.000 Token also genauso viel wie bei 200.000.

Nur die 8 Schichten mit voller Attention halten einen Cache, der wächst. Die Modellkarte nennt ihre Form: 4 Key-Value-Köpfe, jeder 256 Dimensionen breit.

Damit lassen sich die Kosten pro Token ausrechnen. Multiplizieren Sie die 8 Schichten mit 2, weil Keys und Values beide gespeichert werden, dann mit 4 Köpfen, dann mit 256 Dimensionen, dann mit 2 Byte pro Wert. Das Ergebnis sind 32.768 Byte, also 32KB für jedes Token im Gespräch.

Was das bei echten Kontextlängen kostet

Die Modellkarte nennt eine native Kontextlänge von 262.144 Token, erweiterbar auf etwa 1.010.000. Bei 32KB pro Token sind die Cache-Kosten für jede Länge einfache Rechenarbeit.

Die zweite Spalte unten zeigt, was dasselbe Modell kosten würde, wenn alle 32 Schichten volle Attention nutzten statt 8. Das ist ein hypothetischer Wert, aufgeführt, um die Größe der Ersparnis zu zeigen.

Kontextlänge	KV-Cache von Qwen3.5-9B	Wenn alle 32 Schichten volle Attention nutzten
8.192 Token	0,25 GiB	1,0 GiB
32.768 Token	1,0 GiB	4,0 GiB
131.072 Token	4,0 GiB	16,0 GiB
262.144 Token	8,0 GiB	32,0 GiB

Der Entwurf spart bei jeder Länge das Vierfache an Cache-Speicher. Auf einer 8GB-Karte, die etwa 6,6GB an 4-Bit-Gewichten hält, ist das der Unterschied zwischen einem Gespräch über 32.000 Token und einem über 4.000.

Qwen hat dieselbe Idee seitdem weitergetrieben. Die Veröffentlichung von Qwen3.8-Flash-Next nutzt Gated DeltaNet ebenfalls in drei von vier Schichten, dazu einen spärlichen Experten-Entwurf.

Was das für Entwickler bedeutet

Die Parameterzahl ist ein schlechter Wegweiser dafür, ob ein Modell in eine bestimmte Speichermenge passt. Zwei Modelle gleicher Größe können sich allein bei den Cache-Kosten um das Vierfache oder mehr unterscheiden. Prüfen Sie den Aufbau der Schichten, bevor Sie einer Größenschätzung vertrauen.

Die Zahlen, die Sie suchen, stehen in der veröffentlichten Konfiguration des Modells: wie viele Schichten volle Attention nutzen, wie viele Key-Value-Köpfe jede davon hat und wie breit jeder Kopf ist. Diese drei Zahlen, mal zwei für Keys und Values und mal zwei für 16-Bit-Speicherung, ergeben die Kosten pro Token. Multiplizieren Sie mit der Kontextlänge, die Sie wirklich nutzen wollen.

Planen Sie den Cache ein, bevor Sie ein Kontextfenster wählen. Ein häufiger Fehler ist, den Kontext auf das Maximum des Modells zu setzen, nur weil das Maximum verfügbar ist. Die meisten lokalen Laufzeiten akzeptieren eine Einstellung, die nicht passt, und verschieben dann still Arbeit auf den Prozessor. Das sieht wie eine rätselhafte Verlangsamung aus und nicht wie ein Fehler.

Den Cache zu halbieren ist ebenfalls eine Möglichkeit. Die meisten Laufzeiten können den Cache mit 8-Bit-Genauigkeit statt 16-Bit speichern, was die Werte in der Tabelle oben bei kleinem Qualitätsverlust halbiert. Auf einer 8GB-Maschine ist das oft die Einstellung, die ein Modell von unbenutzbar zu angenehm macht.