Ein 27B Hybrid-SSM-Modell mit 128k Kontext auf einer 12-GB-Laptop-GPU ausführen

n8n vs. Dify: Automation Platform vs. LLM App Builder — A Practical Comparison

Side-by-side comparison of n8n and Dify for AI-powered automation: architecture, use cases, when to use which, and how to run both in production with Docker Compose.

Das Problem

Ein Modell mit 27 Milliarden Parametern und einem Kontext von 128.000 Token auf einem Laptop auszuführen, klingt so, als bräuchte man eine 48-GB-GPU. Reine Transformer-Modelle benötigen einen KV-Cache, der linear mit der Kontextlänge wächst – bei 128k Token benötigt ein 27B-Modell allein für den Key-Value-Cache etwa 33 GB. Das entspricht dem VRAM von drei RTX 4080 Laptop-GPUs.

Der Flaschenhals sind nicht die Modellgewichte. Ein 27B-Modell mit Q4_K_M-Quantisierung ist etwa 17 GB groß – massiv, aber durch partielles CPU-Offloading handhabbar. Der Flaschenhals ist der KV-Cache, und das ist der Grund, warum die meisten Leute 7B-Modelle mit 8k Kontext nutzen und es dabei belassen.

Qwen3.8-27B ändert die Spielregeln. Es verwendet eine hybride Attention/SSM-Architektur: 48 seiner 65 Layer sind State-Space-Modelle im Mamba-Stil, die überhaupt keinen KV-Cache benötigen. Nur 17 Layer (jeder 4.) nutzen Standard-Attention. Der KV-Cache ist damit 5,9-mal kleiner als bei einem reinen Attention-Modell derselben Größe.

Dieser Artikel benchmarkt diese Behauptung auf echter Hardware: einer RTX 4080 Laptop mit 12 GB VRAM, unter Verwendung von llama.cpp mit CUDA.

Hardware

Modell

Konfiguration

22 von 65 Layern wurden auf die GPU ausgelagert (34 %), 43 verbleiben auf der CPU (66 %). Dies lässt bei einem maximalen Kontext von 128k einen GPU-Puffer von 3,4 GB.

./build/bin/Release/llama-server.exe \
  -m models/Qwen3.8-27B-ABLITERATED-Q4_K_M.gguf \
  -c 131072 \
  -ngl 22 \
  --temp 0.6 \
  --top-k 40 \
  -np 1

VRAM-Budget bei 128k Kontext

Die hybride Architektur teilt den KV-Cache auf natürliche Weise auf. Mit den Layern 0-21 auf der GPU (die 6 der 17 Attention-Layer enthalten) und den Layern 22-64 auf der CPU (die 11 Attention-Layer enthalten), verteilt sich der KV-Cache wie folgt:

Kontrafaktisch: Ein reines Attention-27B-Modell benötigt bei 128k einen KV-Cache von 32,7 GB. Das passt überhaupt nicht in 12 GB VRAM – man bräuchte eine zweite GPU oder eine Desktop-Karte. Die SSM-Layer reduzieren den KV-Cache um den Faktor 5,9, was das gesamte Setup erst ermöglicht.

Benchmark 1: Prefill-Geschwindigkeitsskalierung

Dies ist das interessanteste Ergebnis. Prefill beschreibt, wie schnell das Modell Ihren Input-Prompt verarbeitet. Bei reinen Attention-Modellen verschlechtert sich dies signifikant mit wachsendem Kontext, da jeder Attention-Layer eine Arbeit von O(n²) über die Sequenzlänge verrichtet.

Der Sprung von 512 Token auf 32.768 Token ist eine 64-fache Steigerung der Input-Größe. Die Prefill-Geschwindigkeit sinkt von 236 tok/s auf 191 tok/s – eine Degradation von nur 19 %. Bei einem reinen Attention-27B-Modell im gleichen Bereich würde man eine Degradation von 40-60 % erwarten.

Warum? Weil 74 % der Layer (die SSM-Layer) in Bezug auf die Kontextlänge O(1) sind. Sie verrichten die gleiche Menge an Arbeit, egal ob der Input 512 oder 32k Token umfasst. Nur die 17 Attention-Layer verursachen quadratische Kosten, und selbst diese werden über die SSM-Layer amortisiert.

Benchmark 2: Generierungsgeschwindigkeit

Die Generierung erzeugt einen Token nach dem anderen. Hier ist die Speicherbandbreite der Flaschenhals, nicht die Rechenleistung. Jeder Layer muss seine gesamte Gewichtsmatrix für jeden einzelnen Token lesen.

Die entscheidende Erkenntnis: Die Generierungsgeschwindigkeit ist über alle Kontextlängen hinweg konstant. Egal ob der Kontext 1k oder 128k Token umfasst, man erhält 2,76 tok/s. Die SSM-Layer tragen dazu bei – ihr Zustand ist ein Puffer fester Größe, sodass das Wachstum des KV-Caches in den Attention-Layern nicht dominiert.

Die zweite Erkenntnis: GPU-Layer haben einen abnehmenden Grenznutzen. Die Steigerung von 10 auf 22 GPU-Layer bringt +35 %. Von 22 auf 35 bringt sie nur noch +6 %. Der Flaschenhals ist die DDR5-RAM-Bandbreite für die 43 CPU-Layer. Die GPU ist schnell, bleibt aber im Leerlauf, während sie darauf wartet, dass die CPU-Layer fertig werden.

Benchmark 3: End-to-End Agentic Turn

Ein typischer agentischer Coding-Durchgang: Kontext senden (Projektdateien, Gesprächshistorie, Tool-Outputs), eine Antwort erhalten (Tool-Aufruf, Code-Edit oder Analyse).

Die Generierungszeit ist bei jeder Kontextlänge identisch. Bei 8k Kontext macht die Generierung 54 % des Durchgangs aus. Bei 32k sind es nur noch 21 %. Der Flaschenhals verschiebt sich von einer ausgewogenen Last hin zu einer Prefill-dominanten Last, aber die Generierung wird niemals langsamer.

Was das für Agentic Coding bedeutet

Kontext ist (fast) kostenlos

Bei einem reinen Attention-Modell macht jede Datei, die Sie zum Kontext hinzufügen, die Generierung langsamer, da der KV-Cache wächst. Bei hybridem SSM betrifft das Hinzufügen von Kontext nur die 26 % der Layer, die Attention nutzen. Die Kosten dafür, Ihr gesamtes Projekt in den Kontext zu packen, sind minimal im Vergleich zu den fixen Generierungskosten.

Der Flaschenhals ist fixiert

Bei 2,76 tok/s hat jeder Agenten-Durchgang eine Untergrenze von etwa 46 Sekunden für 128 Output-Token (ein typischer Tool-Aufruf oder Code-Edit). Dies ist der Preis für das Ausführen von 43 Layern auf DDR5-RAM. Keine Kontext-Optimierung der Welt kann diese Zahl ändern.

MTP könnte die Generierungsgeschwindigkeit verdoppeln

Das Modell enthält eine integrierte MTP (Multi-Token Prediction) Draft-Layer für Speculative Decoding. Sobald dies von llama.cpp ordnungsgemäß unterstützt wird, könnte dies die Generierung von 2,76 auf 5–8 tok/s steigern, indem mehrere Token pro Forward Pass vorhergesagt werden. Dies ist die Optimierung mit der größten Auswirkung für dieses Setup.

Wann Hybrid-SSM wichtig ist (und wann nicht)

Wichtig:

• Agentische Workflows mit langem Kontext, bei denen das gesamte Projekt im Kontext benötigt wird
• Single-GPU-Setups, bei denen der VRAM der limitierende Faktor ist, nicht die Rechenleistung
• Szenarien, in denen die Prefill-Latenz eine Rolle spielt (interaktive Agenten, schnelle Iterationen)

Nicht wichtig:

• Chat mit kurzem Kontext (8k oder weniger) – reine Attention-Modelle sind hier konkurrenzfähig
• Multi-GPU-Setups, bei denen VRAM im Überfluss vorhanden ist
• Latenzkritische Bereitstellung, bei der die Generierungsgeschwindigkeit dominiert (SSM hilft hier nicht)

Der übergeordnete Punkt

Die Hybrid-SSM-Architektur von Qwen3.8 ist nicht nur eine inkrementelle Verbesserung. Sie verändert, was auf Consumer-Hardware möglich ist. Ein 27B-Modell mit 128k Kontext auf einer 12-GB-Laptop-GPU war vor sechs Monaten nicht machbar – nicht wegen der Modellqualität, sondern weil der KV-Cache physisch nicht passte.

Die Wahl der Architektur ist wichtiger als die Parameteranzahl. Ein 27B Hybrid-SSM-Modell passt dort hinein, wo ein 7B Pure-Attention-Modell an seine Grenzen stoßen würde. Wenn Sie ein Modell für lokale Inferenz mit langem Kontext auswählen, achten Sie zuerst auf die Architektur und erst an zweiter Stelle auf die Parameteranzahl.

Rohdaten

Alle Benchmarks wurden mit llama.cpp Commit 76da2450a (Build 9586), CUDA-Backend, -fa auto, jeweils 3 Wiederholungen durchgeführt. Test-Hardware: i9-14900HX, RTX 4080 Laptop 12 GB, 64 GB DDR5-5600.