Inside OpenClaw #3: Warum wir unser KI-Modell ersetzt haben — und 6x weniger Speicher brauchen

Ein Modell, das die Spielregeln ändert

Solche Modellwechsel und ihre Implikationen fließen direkt in meine KI & Automatisierungs-Beratung ein. Unser bisheriges Setup lief stabil: Mistral Small 24B auf vLLM, AWQ-quantisiert, die richtigen Flags gesetzt, Tool-Calling funktionierte zuverlässig. Aber zwei Grenzen blieben: 32.000 Token Context und 14 GB VRAM allein für die Modell-Weights — auf einer GPU mit 24 GB.

Dann erschien Qwen3.5-35B-A3B. Ein Modell, das auf dem Papier unmöglich klingt: 35 Milliarden Parameter, aber nur 3 Milliarden davon gleichzeitig aktiv. 262.000 Token Context-Fenster. Und schneller als unser bisheriges, kleineres Modell.

Nach drei Tagen intensivem Testen, Benchmarking und Konfigurieren läuft es jetzt produktiv — auf derselben Hardware, ohne einen Cent zusätzliche Investition.

Die Architektur dahinter: Warum dieses Modell anders ist

Herkömmliche Transformer-Modelle speichern für jedes verarbeitete Token einen Key-Value-Eintrag im Arbeitsspeicher der GPU — den sogenannten KV-Cache. Bei langen Konversationen wächst dieser linear: Mehr Kontext bedeutet mehr Speicher. Bei 32.000 Token und einem 24B-Modell wie Mistral belegt der KV-Cache bereits rund 4 GB.

Qwen3.5-35B-A3B bricht mit diesem Prinzip auf zwei Ebenen:

Mixture of Experts (MoE): Das Modell hat 35 Milliarden Parameter, aktiviert aber pro Token nur 3 Milliarden. Die restlichen Parameter sind spezialisierte “Experten”, die nur bei Bedarf einspringen. Das Ergebnis: Die Inferenz-Geschwindigkeit eines 3B-Modells bei der Qualität eines deutlich größeren.

Mamba2 State Space Model: 30 der 40 Schichten im Modell verwenden keine klassische Attention mehr. Stattdessen arbeiten sie mit einem fixen State von nur 15 MB — unabhängig davon, wie lang der Kontext ist. Nur 10 Schichten behalten einen traditionellen KV-Cache, und selbst diese nutzen nur je 2 KV-Heads statt der üblichen 8 oder mehr.

Das Ergebnis in Zahlen:

6,5x weniger KV-Cache bedeutet: Das Context-Fenster skaliert quasi kostenlos. Die Geschwindigkeit bei 4.000 Token Kontext ist nahezu identisch mit der bei 262.000 Token.

Der Weg dorthin war nicht trivial

Ein drei Tage altes Modell in Produktion zu bringen hat seinen Preis. Drei Hürden, die wir lösen mussten:

vLLM kennt das Modell noch nicht

Unsere bisherige Infrastruktur basiert auf vLLM. Aber vLLM 0.16.0 hat die Qwen3.5-Architektur (Qwen3_5MoeForConditionalGeneration) schlicht noch nicht in seiner Registry. Das Modell ist zu neu. Ein Upgrade auf die Nightly-Version hätte 21 Pakete geändert und CUDA heruntergestuft — zu riskant für ein Produktionssystem.

Ollama funktioniert — bis zum Speicherlimit

Ollama 0.17 unterstützt das Modell. Der erste Test mit der Standard-Quantisierung (Q4_K_M, 23 GB) sah vielversprechend aus. Bis wir den Context auf 262K setzten: 30+ GB Gesamtverbrauch auf einer 24-GB-GPU. Das System fiel auf Unified Memory zurück — und jede Antwort brauchte über sechs Minuten.

Die Lösung: Kleinere Quantisierung + llama-server direkt

Statt Ollama nutzen wir jetzt llama-server (aus dem llama.cpp-Projekt) direkt. Mit einer Q3_K_XL-Quantisierung von bartowski passen die Modell-Weights in nur 16 GB statt 23 GB. Der entscheidende Hebel war der Q8 KV-Cache: Statt FP16 wird der KV-Cache in 8-Bit Ganzzahlen gespeichert — bei minimalem Qualitätsverlust, aber halbiertem Speicherverbrauch.

Die finale Konfiguration:

• Q3_K_XL Quantisierung — 15,96 GB Weights (statt 23 GB bei Q4)
• Q8 KV-Cache — halbiert den Cache-Speicher
• Flash Attention — Pflicht für die Mamba2-Architektur
• Alle 41 Layers auf GPU — kein CPU-Offloading, kein Unified-Memory-Fallback

Benchmark-Ergebnisse: Was die Hardware tatsächlich leistet

Gemessen mit llama-bench auf der RTX 4090, Flash Attention aktiv, Q8 KV-Cache:

Bei typischen OpenClaw-Konversationen — ein System-Prompt von ~13.500 Token plus Chat-Verlauf — bewegen wir uns im Bereich von 16K bis 65K Token. Das entspricht 88 bis 112 Token pro Sekunde bei der Text-Generierung. Spürbar schneller als die ~45 tok/s mit Mistral.

Selbst bei vollem 262K-Kontext antwortet das Modell noch mit 55 tok/s — das ist schneller als viele Cloud-APIs.

Was bedeutet das für die Praxis?

Der Modellwechsel hat drei konkrete Auswirkungen:

Keine neue Hardware nötig. Dieselbe RTX 4090, die vorher Mistral Small 24B mit 32K Context betrieben hat, betreibt jetzt Qwen3.5-35B-A3B mit 262K Context. Das Investment in die lokale GPU-Infrastruktur war bereits getätigt — das neue Modell macht sie um ein Vielfaches leistungsfähiger.

262K Context verändert, was ein Agent tun kann. Mit 32K Token mussten lange Dokumente gekürzt, Konversationen komprimiert und Kontext verworfen werden. Mit 262K Token kann der Agent ganze Vertragswerke, Code-Repositories oder mehrstündige Chat-Verläufe im Kontext halten — ohne Information zu verlieren.

DSGVO-konform, 0 € laufende Kosten. Keine Cloud-API, keine Daten, die das Unternehmensnetzwerk verlassen. Jede Anfrage wird lokal verarbeitet. Die einzigen laufenden Kosten sind Strom.

Und falls das neue Modell in einem Edge-Case Probleme macht: Mistral Small 24B steht als Fallback bereit. Ein Swap-Script schaltet in unter 60 Sekunden zwischen beiden Modellen um.

Nächster Schritt

Sie wollen lokale KI-Infrastruktur, die mit der Entwicklung Schritt hält — ohne bei jedem Modellwechsel neue Hardware kaufen zu müssen? Ich zeige Ihnen, wie das in der Praxis funktioniert.

→ Erstgespräch vereinbaren — kostenfrei

→ Oder zuerst mehr lesen: Lokales LLM als KI-Agent — ohne Cloud