Warum langer Kontext den VRAM frisst — und was Mamba-Hybride daran ändern

TL;DR

Bei einem Transformer wächst der KV-Cache linear mit Kontextlänge und Nutzerzahl. Ein 8B-Modell mit 32k Kontext und 20 parallelen Nutzern braucht 80 GiB allein für den Cache — fünfmal so viel wie die Gewichte. Mamba-Hybride halten den Cache nahezu konstant. Der Preis: schwächeres Zurückgreifen auf weit zurückliegende Details.

Die Rechnung, die vor dem Sizing niemand macht

Fast jede Sizing-Diskussion im Mittelstand endet bei den Modellgewichten. 8B in Q4 sind 5 GB, also reicht eine 24-GB-Karte, fertig. Diese Rechnung ist falsch, sobald mehr als eine Person gleichzeitig fragt und die Prompts länger werden als ein Chat-Zweizeiler.

Der KV-Cache ist der Grund. Ein Transformer berechnet für jedes Token, das er schon gesehen hat, zwei Vektoren — Key und Value — und behält sie im Grafikspeicher, damit er sie beim nächsten Token nicht neu berechnen muss. Das ist ein sinnvoller Handel: Rechenzeit gegen Speicher. Das Problem ist, dass die Speicherseite dieses Handels mit jedem Token wächst und mit jedem gleichzeitigen Nutzer noch einmal multipliziert wird.

Die Formel ist keine Magie:

KV-Cache (Byte) = 2 × Schichten × KV-Heads × Head-Dim × Token × Bytes/Wert × Nutzer

Setzen wir Llama 3.1 8B ein — 32 Schichten, 8 KV-Heads durch Grouped-Query Attention, Head-Dimension 128, FP16:

2 × 32 × 8 × 128 × 2 Byte = 131.072 Byte = 128 KiB pro Token

128 KiB klingt harmlos. Bei 32.768 Token Kontext sind es exakt 4 GiB — für eine einzige Sitzung. Zwanzig Sachbearbeiter, die parallel je ein längeres Dokument im Kontext haben, brauchen 80 GiB.

Alle Werte in der Tabelle stammen aus derselben Formel oben, nicht aus einem Benchmark — Sie können sie mit Ihren eigenen Schicht- und Head-Zahlen aus der config.json des Modells nachrechnen. Die Gewichtsspalte ist schlicht Parameterzahl mal zwei Byte (8,03 Mrd. bzw. 70,6 Mrd.).

Lesen Sie die Zeile für das 8B-Modell noch einmal. Der Cache ist gut fünfmal größer als die Gewichte. Auf einer H100 mit 80 GB passt dieses Szenario nicht — nicht wegen des Modells, sondern wegen des Gedächtnisses seiner Nutzer.

Genau hier scheitern RAG-Projekte in der Praxis. Die Retrieval-Pipeline schiebt zehn Dokumentabschnitte in jeden Prompt, der Kontext wächst von 2k auf 20k, und plötzlich bedient dieselbe Maschine statt zwanzig nur noch drei Leute gleichzeitig. Die beiden Faktoren, die wirklich weh tun, sind Kontextlänge und Parallelität — nicht die Modellgröße. Wer das beim Sizing übersieht, kauft die falsche Karte. Wie die Rechnung im Gesamtkontext aussieht, steht im Sizing-Leitfaden für KI-Anwendungen.

Was State-Space-Modelle anders machen

Mamba geht das Problem an der Wurzel an: Es speichert die Vergangenheit gar nicht erst vollständig.

Statt für jedes gesehene Token ein Key-Value-Paar aufzuheben, führt ein State-Space-Modell einen Zustand fester Größe mit, den es bei jedem neuen Token aktualisiert. Wer schon mit rekurrenten Netzen gearbeitet hat, erkennt das Muster wieder — mit dem Unterschied, dass Mamba-2 die Zustandsübergänge so strukturiert, dass sie beim Training parallelisierbar bleiben statt Token für Token durchlaufen zu werden.

Die Konsequenz für den Speicher ist drastisch. Der Zustand ist bei 200.000 Token genauso groß wie bei 2.000. Was beim Transformer linear nach oben geht, ist beim Mamba-Modell eine Waagerechte.

Und jetzt der Teil, den Architektur-Ankündigungen gern klein drucken: Ein Zustand fester Größe kann nur eine feste Menge Information halten. Genau dort liegt die dokumentierte Schwäche. In der Forschungsliteratur zu Recall-Aufgaben — Telefonbuch-Lookups, Multi-Query Associative Recall, Fragen zu einem einzelnen Satz in einem langen Absatz — bleiben reine State-Space-Modelle deutlich hinter Transformern zurück, und zwar strukturell, weil die Zustandsgröße nicht mit der Eingabelänge mitwächst. Attention kann auf jedes einzelne frühere Token exakt zurückgreifen. Mamba hat eine Zusammenfassung.

Für eine Zusammenfassung ist das egal. Für "In welchem Absatz von Anhang C steht die Toleranzangabe?" nicht. Und ausgerechnet diese Präzisionsfrage stellen RAG-Nutzer den ganzen Tag.

Warum niemand rein auf Mamba setzt

Direkte Antwort: weil die beiden Schwächen komplementär sind und man sie gegeneinander wegschneiden kann.

Ein Hybrid streut wenige Attention-Schichten zwischen viele Mamba-Schichten. Die Attention-Schichten liefern das präzise Zurückgreifen, die Mamba-Schichten tragen den Großteil der Sequenzverarbeitung — und nur die wenigen Attention-Schichten bauen überhaupt einen KV-Cache auf. Das Verhältnis ist der eigentliche Design-Knopf.

Bei Jamba von AI21 liegt es bei 1:7, eine Attention-Schicht auf sieben Mamba-Schichten, dazu MoE in jedem zweiten Block. Das Jamba-Paper beziffert den KV-Cache bei 256k Kontext mit 4 GB — gegenüber 32 GB bei Mixtral 8x7B und 128 GB bei Llama-2 70B. Faktor 8 beziehungsweise 32, und das ist der einzige Grund, warum Jamba in int8 rund 256k Kontext auf eine einzelne 80-GB-Karte bekommt, wo Mixtral bei etwa 128k und Llama-2 70B bei etwa 36k aufhört.

Soofi S 30B-A3B, Mitte Juli 2026 veröffentlicht, geht ähnlich vor. 52 Schichten, davon 23 Mamba-2-Sequenzmischer, 23 granulare MoE-Schichten und sechs Grouped-Query-Attention-Schichten. Sechs von 52. Nur diese sechs tragen einen wachsenden Cache, der Rest hält einen Zustand konstanter Größe. Das Paper beziffert die Cache-Last mit rund 6 KB pro Token und Sequenz und damit 11- bis 53-mal niedriger als bei den dichten Vergleichsmodellen. Zur Einordnung: Für Llama 3.1 8B hat unsere Formel oben 128 KiB pro Token ergeben — bei einem Modell, das viermal kleiner ist.

Beim Durchsatz lohnt es, die Zahl genau zu lesen, statt die Pressemitteilung zu übernehmen. Gemessen wurde auf einer einzelnen B200 mit vLLM und TP=1. Der aggregierte Decode-Durchsatz liegt bei 4k Kontext bei 4,29k Token/s und bei 256k bei 4,30k Token/s; dazwischen fällt er an keinem Punkt mehr als rund 34 Prozent unter den 4k-Wert. Das ist keine Waagerechte, aber verglichen mit dem Einbruch dichter Modelle über dieselbe Spanne eine andere Größenordnung von Stabilität. Der oft zitierte Vorsprung stammt aus einem einzelnen Vergleich: Bei 40.000 Token Kontext und Batch 32 erreicht Soofi S 4,82k Token/s pro GPU gegen rund 0,52k bei Ministral 3 14B — Faktor 9,2. Gegen Qwen3.5 35B-A3B, selbst ein MoE, schrumpft derselbe Vorsprung auf Faktor 1,9. Wer daraus "achtmal schneller als alles Dichte" macht, verkauft einen Datenpunkt als Regel.

Ein Punkt, den MoE-Ankündigungen systematisch verschleiern: Für den VRAM-Bedarf zählen die Gesamtparameter, nicht die aktiven. Alle 31,6 Mrd. Gewichte müssen im Speicher liegen, weil der Router pro Token andere Experten zieht — Soofi S braucht den Platz eines 31,6B-Modells. Die 3,2 Mrd. aktiven Parameter senken ausschließlich die Rechenlast pro Token, also Latenz und Durchsatz. Deshalb wiegt die Q4-GGUF auch rund 21 GB und nicht 2 GB. Wer ein MoE nach seiner aktiven Parameterzahl einkauft, kauft zu wenig Karte.

Zur Einordnung, wer dahintersteht: SOOFI steht für "Sovereign Open Source Foundation Models". Koordiniert wird das Konsortium vom KI Bundesverband, mit Fraunhofer IAIS/IIS, DFKI, TU Darmstadt, Universität Würzburg, ellamind und Merantix Momentum an Bord; die Förderung läuft über das IPCEI-CIS-Programm. Trainiert wurde auf 26,68 Billionen Token mit bewusst höher gewichtetem Deutsch, auf bis zu 512 NVIDIA-B200-GPUs (64 DGX-B200-Knoten, rund 253.000 GPU-Stunden) in der Industrial AI Cloud der Deutschen Telekom in München. Bei 31,6 Mrd. Parametern gesamt und ~3,2 Mrd. aktiven pro Token erreicht das Modell im Aggregat dichte 14- bis 27B-Modelle in Deutsch und Englisch und hat unter 17 offenen Basismodellen den besten Code-Aggregatwert in beiden Sprachen. Unter den vollständig offenen Modellen liegt es vor Olmo 3 32B und Apertus 70B. Nachprüfbar im Paper unter arXiv:2607.09424 und in der Modellkarte auf Hugging Face.

NVIDIA fährt mit der Nemotron-H-Linie dieselbe Strategie: Mehrheit der Attention-Schichten durch Mamba-2 ersetzt, wenige Attention-Schichten bleiben stehen. Das Muster ist also kein Ausreißer eines einzelnen Labors.

Was mit Soofi S heute wirklich läuft — und was nicht

Hier wird es unbequem, und genau hier werden die meisten Artikel über neue Modelle unehrlich.

Die Lizenz ist Stand 2. August 2026 nicht final. Das Basismodell trägt auf Hugging Face den Hinweis, es werde unter einer permissiven Lizenz erscheinen — welche genau, steht nicht da. Die GGUF-Repos laufen unter "Other" mit dem Vermerk, der Lizenztext werde nachgezogen, sobald das Basismodell einen hat. Wenn Ihre Rechtsabteilung vor einem Produktivbetrieb eine benannte Lizenz sehen will, ist das ein Stopper. Kein technischer, ein juristischer.

Es sind Preview-Gewichte. Das Basismodell ist ausdrücklich nicht instruction-getuned, nicht aligned, nicht safety-getuned. Die Instruct- und Reasoning-Varianten stecken in der Beta. Ein Basismodell in ein Mitarbeiter-Frontend zu hängen, geht schief — es beantwortet keine Anweisungen, es setzt Text fort.

Die Laufzeitunterstützung ist ungleich verteilt. vLLM funktioniert und wurde für die Durchsatzmessungen selbst verwendet, für SGLang gibt es Docker-Images, unter Transformers braucht es trust_remote_code=True, weil das Modell eigenen Architektur-Code mitbringt. GGUF-Quantisierungen der Instruct-Preview existieren in Q4_K_M (~21 GB), Q5_K_M (~26 GB) und Q8_0 (~33,6 GB) und lassen sich direkt ziehen:

# Instruct-Preview als GGUF, Q5_K_M — braucht ein aktuelles llama.cpp bzw. Ollama
ollama run hf.co/Soofi-Project/Soofi-S-Instruct-Preview-GGUF:Q5_K_M

Zwei Fallstricke dazu, beide vom Anbieter selbst in der Modellkarte dokumentiert: Ollama arbeitet mit Go-Templates und wendet die im GGUF eingebettete Jinja-Chat-Vorlage nicht an — Sie brauchen ein eigenes Template, sonst bricht das ChatML-Format und Antworten landen im Thinking-Block. Und die Tensorspalten des Modells (2688/1856/3712) sind nicht durch 256 teilbar, weshalb jeder K-Quant-Tensor auf einen Nicht-K-Typ zurückfällt: Q5_K_M landet effektiv auf q5_1, Q4_K_M auf q4_1, und Q6_K wird gar nicht erst angeboten, weil es nach dem Fallback so groß wäre wie Q8_0. Größe und Qualität weichen damit von dem ab, was man bei diesen Quant-Namen sonst erwartet.

Hybride Mamba-Architekturen in llama.cpp sind jung. Für Nemotron 3 Nano 30B-A3B gab es im März 2026 zwei Fehlerberichte (llama.cpp #20307 und #20570), bei denen das Laden mit GGML_ASSERT(d_inner % (n_group*n_embd) == 0) in mamba-base.cpp abbrach — betroffen waren CUDA, CPU, ROCm und Vulkan gleichermaßen. Beide sind inzwischen geschlossen; der Punkt ist nicht, dass dieser eine Bug offen wäre, sondern dass die SSM-Pfade jünger sind als die Attention-Pfade und nicht jede Dimensionierung sauber abdecken. Wer heute ein Hybrid-Modell über llama.cpp oder Ollama produktiv fahren will, sollte damit rechnen, dass ein Versionssprung etwas kaputt macht, das gestern lief — und die eingesetzte Version deshalb pinnen.

Unsere Position: Für einen Evaluationsaufbau ist Soofi S heute interessant und einen Nachmittag wert. Für einen produktiven Rollout warten Sie auf die finale Lizenz und eine stabile Instruct-Version. Wenn Sie den Weg über eine lokale Installation gehen wollen, steht die Grundlage in der Ollama-Anleitung für Ubuntu.

Wann sich der Architekturwechsel rechnet — und wann nicht

Für kurze Prompts und wenige Nutzer ist dieses ganze Thema irrelevant. Wir sagen das so deutlich, weil die Versuchung groß ist, aus einer interessanten Architektur einen Beschaffungsgrund zu machen.

Konkret: Wenn Ihre Anwendung Prompts unter 4.000 Token verarbeitet und selten mehr als fünf Leute gleichzeitig fragen, liegt Ihr KV-Cache im niedrigen einstelligen Gigabyte-Bereich. Er ist dann nicht Ihr Engpass — die Modellgröße ist es, oder die Speicherbandbreite Ihrer Karte. Ein Architekturwechsel löst hier ein Problem, das Sie nicht haben, und handelt Ihnen dafür schwächere Detailtreue ein.

Umgekehrt lohnt der Blick auf einen Hybrid, wenn mindestens zwei dieser Punkte zutreffen:

1. Kontextlängen über 16k, weil Verträge, Prüfberichte oder Codebasen am Stück verarbeitet werden
2. Mehr als 15 gleichzeitig aktive Sitzungen im Tagesbetrieb
3. Der Cache verdrängt bereits Gewichte — Sie mussten --max-model-len oder --max-num-seqs künstlich deckeln
4. Deutsch ist die dominante Arbeitssprache, was bei Soofi S ein zusätzliches Argument ist

Fehlt Punkt 3, warten Sie ab. Die Architektur läuft Ihnen nicht weg, die Werkzeugkette holt in den nächsten Monaten auf, und ein Modell mit offener Lizenzfrage gehört nicht in eine Beschaffungsentscheidung. Für Mehr-GPU-Aufbauten mit klassischen Transformern bleibt der vLLM-Cluster für 70B-Modelle der solidere Weg.

Die billigeren Antworten, die Sie zuerst ausprobieren sollten

Bevor Sie die Architektur tauschen, tauschen Sie die Datentypen. Das kostet einen Neustart statt eines Projekts.

KV-Cache in FP8. vLLM kann den Cache in FP8 statt BF16 halten. Das halbiert den Cache-Speicher — aus den 80 GiB von oben werden 40 GiB — und kostet keinen Durchsatz, sondern bringt welchen: Die vLLM-Untersuchung vom 22. April 2026 misst für Llama 3.1 8B unter Last 14,9 Prozent mehr Output-Durchsatz und 13 Prozent kürzere Gesamtlaufzeit. Getestet wurde über eine breite Modellpalette — Llama 3.1 8B, Llama 3.3 70B, Qwen3-30B-A3B in zwei Varianten, Qwen3.5 27B, Kimi K2.5, GPT-OSS-20B und Gemma 4 E2B — mit dem Fazit, dass --kv-cache-dtype fp8 der beste Startpunkt für lange Kontexte ist.

Ein Detail aus derselben Untersuchung gehört in genau diesen Artikel, weil es ausgerechnet den Langkontext-Fall betrifft: Auf Hopper-Tensorkernen verlor die FP8-Akkumulation bei Kontraktionslängen jenseits 100k Token Präzision. In einem Needle-in-a-Haystack-Test bei 128k Kontext fiel die Trefferquote von 91 Prozent unter BF16 auf 13 Prozent unter FP8. Erst eine zweistufige Akkumulation über ein echtes FP32-Register hat das auf 89 Prozent zurückgeholt. Praktische Konsequenz: Schalten Sie FP8 nicht auf einer alten vLLM-Version ein und messen Sie Ihren Recall danach selbst nach, statt dem Flag zu glauben. Für Schichten, bei denen sich FP8 nicht lohnt — etwa Sliding-Window-Attention mit fester Fenstergröße, deren Cache ohnehin gedeckelt ist — gibt es --kv-cache-dtype-skip-layers.

# Cache halbieren, ohne Modell oder Hardware zu wechseln
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --kv-cache-dtype fp8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92

PagedAttention. Wer noch mit einem selbstgebauten Transformers-Loop oder einem alten Serving-Stack arbeitet, verschenkt Speicher an Fragmentierung. Das PagedAttention-Paper (Kwon et al., SOSP 2023, arXiv:2309.06180) misst in den Vorgängersystemen 60 bis 80 Prozent Verschnitt im reservierten KV-Speicher; vLLM drückt ihn unter 4 Prozent, indem der Cache in Blöcke fester Größe zerlegt und wie virtueller Speicher verwaltet wird. Wenn Sie diese Umstellung noch nicht gemacht haben, ist sie der größte Hebel im ganzen Artikel — noch vor jeder Architekturdiskussion. Der Einstieg steht in der vLLM-Anleitung für den Mittelstand.

Kürzere Kontexte durch besseres Chunking. Der unbeliebteste Rat, weil er Arbeit an der Pipeline bedeutet statt an der Infrastruktur. Viele RAG-Aufbauten schieben pauschal zehn oder zwanzig Abschnitte in den Prompt, weil das der Standardwert des Frameworks ist. Ein Reranker, der aus zwanzig Kandidaten die besten drei auswählt, senkt den Kontext um den Faktor sechs — und den Cache im selben Verhältnis. Die Antwortqualität steigt dabei meistens sogar, weil das Modell weniger irrelevanten Text durchsuchen muss.

Unsere Empfehlung in dieser Reihenfolge: erst Chunking und Reranking, dann FP8, dann PagedAttention verifizieren, und erst danach über Architekturen reden. Welche Karte zu welchem Lastprofil passt, klärt der GPU-Vergleich für LLM-Inferenz.

FAQ

Was ist der KV-Cache und warum wächst er mit dem Kontext?

Der KV-Cache speichert die Key- und Value-Vektoren aller bereits verarbeiteten Token, damit ein Sprachmodell sie beim nächsten Token nicht neu berechnen muss. Weil für jedes zusätzliche Token ein weiteres Paar dazukommt, wächst er linear mit der Kontextlänge und zusätzlich mit der Zahl gleichzeitiger Anfragen. Bei langen Kontexten wird er größer als die Modellgewichte selbst.

Wie viel VRAM kostet ein 32k-Kontext bei 20 parallelen Nutzern?

Für ein Modell wie Llama 3.1 8B mit 32 Schichten, 8 KV-Heads und Head-Dimension 128 sind es in FP16 rund 128 KiB pro Token, also 4 GiB bei 32.768 Token und 80 GiB bei 20 gleichzeitigen Sitzungen. Bei einem 70B-Modell mit 80 Schichten liegt derselbe Fall bei rund 200 GiB. Die Modellgewichte sind in beiden Fällen der kleinere Posten.

Was kostet der Umstieg auf ein Mamba-Hybrid-Modell?

An Lizenzgebühren nichts — die Gewichte sind frei herunterladbar, wobei bei Soofi S die endgültige Lizenz Stand August 2026 noch nicht benannt ist. Die realen Kosten liegen in der Arbeitszeit: Evaluation gegen das bestehende Modell, Anpassung der Chat-Vorlagen, erneute Tests der Antwortqualität bei Detailfragen. Rechnen Sie mit mehreren Personentagen — und prüfen Sie vorher, ob eine Umstellung auf FP8-KV-Cache das Speicherproblem nicht schon für einen Serverneustart löst.

Mamba-Hybrid oder klassischer Transformer — was ist besser?

Das hängt am Lastprofil, nicht an der Architektur. Bei kurzen Prompts und wenigen Nutzern ist ein klassischer Transformer die bessere Wahl, weil er auf Detailfragen präziser zurückgreift und die Werkzeugkette ausgereifter ist. Ab etwa 16.000 Token Kontext und mehr als 15 parallelen Sitzungen kippt der Vorteil zum Hybrid, weil dessen Cache nicht mehr nennenswert mitwächst.

Läuft Soofi S schon in Ollama und vLLM?

Teilweise. vLLM und SGLang werden vom Projekt unterstützt, und es gibt GGUF-Quantisierungen der Instruct-Preview, die sich direkt aus dem Hugging-Face-Repo in Ollama ziehen lassen. Stand August 2026 ist die endgültige Lizenz allerdings nicht benannt, die Instruct-Variante ist eine Preview, Ollama wendet die mitgelieferte Chat-Vorlage nicht automatisch an, und die Unterstützung hybrider Mamba-Architekturen in llama.cpp ist jung — für verwandte Modelle gab es im Frühjahr 2026 Ladefehler, die erst nachträglich behoben wurden.

Der nächste Schritt

Rechnen Sie vor jeder Architekturentscheidung eine einzige Zahl aus: Ihren KV-Cache-Bedarf bei realistischer Kontextlänge und realistischer Nutzerzahl, mit der Formel aus dem ersten Abschnitt. In den meisten Fällen erklärt diese Zahl allein, warum die GPU unter Last einbricht — und in ebenso vielen Fällen ist die Antwort ein FP8-Flag, nicht ein neues Modell. Zeigt die Zahl dagegen, dass Ihre Hardware grundsätzlich zu klein dimensioniert ist, gehen Sie einen Schritt zurück zum Sizing für KI-Anwendungen.