Unsere experimentelle Konfiguration: ein Modell mit ca. 83,6 GB, das lokal auf einer preisgünstigen RTX 3060 läuft

Das ist unglaublich!

Qwen3.8-Flash-Next IQ3_S (~83,6 GB) läuft lokal auf einer preisgünstigen RTX 3060 12 GB mit nur 48 GB System-RAM!

Bis zu 68 Token/Sekunde Dekodierung, ~916 Token/Sekunde Eingabeaufforderungsverarbeitung und eine 30.000-Token-Eingabeaufforderung, die in nur 34 Sekunden verarbeitet wird.

Unterstützt von Strata von coldniko. Keine Cloud-Inferenz. Nur erschwingliche Consumer-Hardware!

Vollständige Benchmarks, Hardware-Spezifikationen, Optimierungen und Kompromisse unten.

Im letzten Abschnitt können Sie direkt zu den wichtigsten Erkenntnissen springen.

Die Hardware hinter diesen Ergebnissen

Keine Rechenzentrums-GPU, kein teurer Multi-GPU-Server und keine umfangreiche RAM-Konfiguration.

Das gesamte Experiment wurde auf einem recht gewöhnlichen Consumer-/Workstation-PC durchgeführt.

CPU

• Intel Core Ultra 7 265 (Arrow Lake)
• 20 Kerne / 20 Threads
• Bis zu 5,3 GHz
• 30 MB L3-Cache
• AVX-VNNI/BF16-Unterstützung; kein AVX-512

Hauptplatine

• ASUS Pro Q870I-C
• Intel Q870-Chipsatz, LGA1851
• Mini-ITX-Formfaktor

Erinnerung

• 48 GB DDR5-5600 (2 × 24 GB Micron)
• Ungefähr 46 GiB nutzbar

GPU

• NVIDIA GeForce RTX 3060 12 GB
• GA106, Rechenleistung 8.6
• PCIe 4.0 ×16
• 170 W konfigurierte Leistungsgrenze

Lagerung

• Lexar NM1090 PRO 2 TB
• PCIe 5.0 ×4 NVMe

OS

• Ubuntu 24.04.5 LTS
• Linux-Kernel 7.0.0-38
• NVIDIA-Treiber 615.71.10

Netzwerk

• Intel 1 GbE Ethernet

Das entscheidende Detail: Das Modell ist deutlich größer als der verfügbare VRAM und RAM zusammen.

Genau das macht dieses Experiment interessant.

Modell-, Engine- und Speicherarchitektur

Modell

Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S

Zwei GGUF-Shards:

• 54.82 GB
• 28.80 GB
• Gesamt: 83,62 GB (77,87 GiB)

Zusätzliche Komponenten

• Gepackte dichte Gewichte: ~1,5 GiB
• MTP-Entwickler für spekulative Dekodierung
• BF16 Vision-Adapter: ~866 MB
• CPU-basierter Vision-Encoder (12 Threads)

Inferenz-Engine

• Strata engine 0.1.52
• CUDA 13.0-Backend
• CUDA-Architektur sm_86

Tatsächliche Speicherzuordnung

• GPU-VRAM: 11,14 GiB verwendet
• Residente Experten für System-RAM: 24 GiB
• Verbleibende Expertendaten werden von NVMe gestreamt
• Keine Swap-Aktivität während der normalen Inferenz

Wichtige Konfigurationseinstellungen

--expert-cache auto
--prefill 4096
--spec 4
--spec-min-p 0.5
--mtp mtp/rt
--max-context 32768
--kv int8
--kv-grow
--kv-resident 32768
--vision
--vram-reserve-mib 960
--pool-workers 12
--conversation-cache-mib 1536
--prompt-cache-tail
--prompt-cache-spread
--resident-experts
--resident-budget-gib 24

Dies ist kein herkömmliches Setup, bei dem das gesamte Modell in den GPU-Speicher geladen wird.

Strata nutzt GPU-Speicher, System-RAM, Experten-Caching und NVMe-Speicher zusammen.

Die wichtige Optimierung besteht darin, teure Expertentransfers zu minimieren und gleichzeitig die Produktivität der GPU aufrechtzuerhalten.

Echte Benchmark-Ergebnisse

Gleiches Modell, gleiche Hardware, zwei Routing-Konfigurationen.

Modus A: schnelles, aufenthaltsorientiertes Experten-Routing (Vorstufe = 1,5)

Kalte Zeit bis zum ersten Token:

• 1K: 3.7 s
• 4K: 4.9 s
• 8K: 9.7 s
• 16K: 17.3 s
• 30K: 33.9 s

Zum Vergleich: Modus B deaktiviert das residentielle Routing (prior = 0):

500-Token-Generierungslauf:

• Schnell: 62 tok/s, 7,1 s insgesamt
• Präzise: 21 Tok/s, 20,8 s insgesamt

Geschwindigkeitsmessungen wurden mit clientseitigen Streaming-Timings abgeglichen.

Hauptbeobachtung:

Das Deaktivieren des Cache-basierten Routings kann die Decodierungsgeschwindigkeit um etwa das 2–2,4-fache reduzieren.

Es gibt jedoch einen wichtigen Grund, aggressives Routing nicht für jede Arbeitslast aktiviert zu lassen. Mehr dazu im nächsten Abschnitt.

Geschwindigkeit vs. Modellqualität: der versteckte Kompromiss

Bei dieser Strata-Engine-Version verwenden GPUs mit ≤13 GB VRAM automatisch standortabhängiges Routing:

STRATA_ROUTE_PRIOR=1.5

Dadurch werden Experten bevorzugt, die bereits im schnellen Speicher verfügbar sind, anstatt immer die Experten auszuwählen, die der ursprüngliche Router bevorzugen würde.

Der Nutzen ist dramatisch:

• Experten-Cache-Trefferquote: 97,2 % im Schnellmodus
• Ohne Voreingenommenheit: 65,3 %
• Speicherlesevorgänge während der verglichenen Arbeitslast: 5,5 GiB vs. 46 GiB
• Dekodierungsgeschwindigkeit: ca. 2× schneller

Dies ist jedoch KEINE kostenlose Optimierung.

Eine Änderung der Expertenauswahl kann das Modellverhalten ändern, die Abweichung vom ursprünglichen Modell erhöhen und sich auf lange Überlegungen oder Arbeitsabläufe der Agenten auswirken.

Laut der Entwicklerbewertung zu 10 Agentenaufgaben:

• Routing vor 1,5: 4,5/10
• Routing vor 0: 5,6/10

Die Basisergebnisse selbst schwankten zwischen den Läufen, es handelt sich also um ein Richtungsergebnis und nicht um eine definitive Qualitätsmessung.

Meine eigenen sechs kurzen Agentenüberprüfungen haben in beiden Modi bestanden.

Allerdings stellte ein separater Eindeutigkeitsstresslauf Wiederholungen offen:

• Schnellmodus: 205 Zeilen, 96 Duplikate
• Präziser Modus: 209 Zeilen, 79 Duplikate

Die Schlussfolgerung ist einfach:

• Schnelle Weiterleitung für Chat, interaktive Nutzung und kurze Aufgaben.
• Originelles Routing für längere, qualitätsbewusste Agenten-Workflows.

Und die Benchmark-Geschwindigkeit allein sollte niemals mit der Modellqualität verwechselt werden.

Promptes Caching verändert alles

Eines der beeindruckendsten Ergebnisse war nicht die Dekodierungsgeschwindigkeit. Es handelte sich um die Reaktionszeit für wiederholte Anfragen über dieselbe Eingabeaufforderung.

Mit einer vollständig zwischengespeicherten Eingabeaufforderung:

Das bedeutet bei diesen Läufen etwa 45- bis 90-mal weniger Zeit bis zum ersten Token.

Der Prompt-Cache macht einen großen Unterschied, wenn dasselbe lange Dokument wiederholt abgefragt wird oder eine Konversation mit einem stabilen Kontext geführt wird.

Die Engine ist auch für das Konversations-Caching konfiguriert:

• 1.536 MiB Cache-Budget
• Mindestens 4.096 Token zum Parken
• Mindestschwelle für freien Speicher: 1.536 MiB

Es gibt einen Haken: Diese Ergebnisse beziehen sich auf identische Eingabeaufforderungen mit einem vollständig wiederverwendbaren Cache.

Das bedeutet nicht, dass willkürliche neue 30K-Token-Eingabeaufforderungen in einer halben Sekunde verarbeitet werden.

Aber für interaktive lokale KI ist ein warmer Cache ein entscheidender Faktor.

Das SSD-Rätsel: PCIe 5.0 ist nicht der Flaschenhals

Das NVMe-Laufwerk wirkte zunächst verdächtig langsam. Wir haben die PCIe-Verbindung, die Speichertopologie und das tatsächliche E/A-Verhalten untersucht.

Das Laufwerk: Lexar NM1090 PRO 2 TB, PCIe 5.0 ×4.

Verifizierte PCIe-Verbindung:

• Aktueller Link: 32,0 GT/s ×4
• Maximale Verbindung: 32,0 GT/s ×4
• CPU-Root-Port: 32,0 GT/s ×4

Das Laufwerk läuft also mit voller PCIe 5.0-Verbindungsgeschwindigkeit.

Direkte, nicht zwischengespeicherte Lese-Benchmarks:

• Einzelstream, 1–4 MiB-Blöcke: 2,9–3,4 GB/s
• Vier parallele Streams: 10,94 GB/s
• Vier Streams, 64-KiB-Blöcke: 2,25 GB/s
• Vier Streams, 4 KiB-Blöcke: 0,26 GB/s (~63.000 IOPS)

Das parallele Ergebnis von 10,94 GB/s ist besonders wichtig: Es übertrifft die praktische Bandbreite von PCIe 4.0 ×4.

Warum ist der Single-Stream-Durchsatz viel geringer?

Denn PCIe-Bandbreite ist nicht dasselbe wie Durchsatz auf Anwendungsebene.

Warteschlangentiefe, E/A-Größe, Anforderungsparallelität und Latenz sind alle von Bedeutung.

Das Expertenlademuster von Strata ähnelt viel eher dem Fall geringer Parallelität als einem synthetischen Benchmark mit maximalem Durchsatz.

Beobachteter Engine-Speicherdurchsatz:

• Schnelles Routing: ~0,3 GB/s
• Ursprüngliches Routing: ~2,4 GB/s

Der Unterschied liegt darin, wie viele Experten abgerufen werden müssen, und nicht in einem PCIe-Downgrade.

Noch ein nützliches Detail: Die RTX 3060 selbst ist ein PCIe 4.0-Gerät. Dass die Verbindung zu Gen1 im Leerlauf abbricht, ist ein normales Energieverwaltungsverhalten.

Überprüfen Sie immer, welches Gerät Sie messen, bevor Sie ein PCIe-Problem diagnostizieren.

Eine wichtige Lektion: Lassen Sie Linux nicht ein 83,6-GB-Modell auf einem 48-GB-Computer zwischenspeichern

Beim ersten Start ist ein ernstes Problem aufgetreten.

Die erste Konfiguration ermöglichte ein gepuffertes Laden der Modelldateien.

Das Modell ist ~83,6 GB groß, während das System nur über 48 GB physischen RAM verfügt.

Unter dieser Arbeitslast stand Linux unter starkem Druck zur Speicherrückgewinnung. Die Maschine reagierte fast nicht mehr, einschließlich der SSH-Konnektivität, und erforderte einen erzwungenen Neustart.

Die Lösung bestand darin, die Ladestrategie zu ändern und Speicherschutzmaßnahmen einzuführen.

Aktuelle Einstellungen:

• STRATA_UNBUFFERED_LOAD=1
• STRATA_RESIDENT_HEADROOM_GIB=10
• 24 GiB-Budget für Resident-Experten
• Speicherverfügbarkeit vor dem Start überprüft
• 12 GiB zusätzlicher Sicherheitsspielraum in der Startrichtlinie

Nach diesen Änderungen:

• Keine Swap-Aktivität während der normalen Inferenz
• Zum beobachteten Zeitpunkt waren etwa 34,6 GiB RAM im Einsatz
• Ungefähr 12,7 GiB verfügbar
• Stabile Erzeugung unter Last

Die Lektion:

Es ist möglich, ein Modell auszuführen, das größer als Ihr physischer Speicher ist, aber die Speicherberechnung ist absolut entscheidend.

Seiten-Cache-Druck, angeheftete Modelldaten, residente Experten und KV-Cache müssen gemeinsam betrachtet werden.

Kopieren Sie nicht blind die Flags für maximale Leistung von Maschinen mit viel größeren RAM-Konfigurationen.

Stromverbrauch, Thermik und Inferenzkosten

Dies ist eine weitere angenehme Überraschung.

Gemessene Komponentenleistung:

Leerlauf mit geladenem Modell:

• CPU: ~5.8 W
• GPU: 15–18 W

Während der Generierung:

• CPU: ~62.8 W
• GPU: 152–167 W
• Kurze GPU-Spitzenwerte liegen bei etwa 174 W

Geschätzte Gesamtsystemleistung an der Wand (nicht mit einem Wandmessgerät gemessen):

• Leerlauf: ~54 W
• Erzeugung: ~280 W

Beobachtete Temperaturen:

• GPU unter Last: 62–68 °C
• GPU im Leerlauf: ~40°C
• NVMe: 38–47°C

Keine thermische Drosselung beobachtet.

Bei einem angenommenen Strompreis von 0,25 €/kWh:

• 24 Stunden Leerlauf: ~0,32 €
• 30 Tage ununterbrochen im Leerlauf: ~9,72 €
• Eine Stunde aktive Erzeugung: ~0,07 €

Dadurch ist es durchaus realistisch, zu Hause einen leistungsfähigen, die Privatsphäre schützenden lokalen KI-Endpunkt zu betreiben.

Dabei handelt es sich natürlich um geschätzte Stromkosten, nicht um die Gesamtbetriebskosten. Hardware-Abschreibung, Kühlung und Wartung sind ausgeschlossen.

Wo das RTX 3060-Setup keinen Sinn mehr ergibt

Diese Konfiguration eignet sich hervorragend für kurze interaktive Anfragen, weist jedoch Einschränkungen auf.

Am wichtigsten:

• Maximaler Kontext: 32.768 Token
• Eine Eingabeaufforderung nahe 32 KB lässt nicht genügend Platz für die Generierung
• Die praktische Benchmark-Obergrenze lag bei ~30.165 Eingabe-Tokens
• Denken/Argumentieren kann Hunderte zusätzlich generierter Token verbrauchen
• Lang andauernde Agentensitzungen werden schnell eingeschränkt

Zum Vergleich habe ich das gleiche Modell auf einem leistungsstärkeren lokalen System mit einer 24-GB-GPU ausgeführt.

Gemessene Leistung auf diesem System:

• 4K-Eingabeaufforderungsvorausfüllung: 1.339 Token/s
• 4K-Dekodierung: 94 tok/s
• 16K-Prompt-Vorausfüllung: 2.956 Token/s
• 16K-Dekodierung: 125 tok/s
• Maximaler Kontext: 262.144 Token
• 15 Arbeitsthreads

Das RTX 3060-System liefert in vergleichbaren Fällen einen viel geringeren Vorfülldurchsatz und etwa die Hälfte des Dekodierungsdurchsatzes bei einem Achtel des verfügbaren Kontexts.

Allerdings ist die 12-GB-Karte weitaus zugänglicher und dennoch beeindruckend nützlich.

Mein aktueller Ansatz:

• Leistungsstärkere Hardware für komplexe Agenten mit langer Laufzeit
• Erschwingliche 12-GB-GPUs für Chat, kurze Arbeitsabläufe, Experimente und Backup-Inferenz

Es geht nicht darum, so zu tun, als ob eine billige GPU eine High-End-Maschine ersetzen würde.

Der Punkt ist, wie viel nützliche lokale KI bereits auf kostengünstiger Hardware ausgeführt werden kann.

Was könnte noch optimiert werden?

Das System funktioniert bereits gut, es gibt jedoch einige interessante Möglichkeiten für weitere Experimente.

Gleichzeitige Schlussfolgerung

Die Option --slots 2 könnte den Gesamtdurchsatz bei zwei gleichzeitigen Gesprächen verbessern.

Für diesen Workload ist ein geschätzter Gesamtdurchsatz von +10–12 % möglich, er bedarf jedoch einer Validierung.

Das bedeutet nicht, dass ein einzelnes Gespräch 12 % schneller wird.

Größere Vorfüllchargen

Aktuell: --prefill 4096

Kandidat: --prefill auto:16384

Größere Prefill-Fenster könnten die Verarbeitung langer Eingabeaufforderungen verbessern, aber der verfügbare VRAM ist bereits knapp.

Da etwa 11,14 GiB der 12 GiB der GPU belegt sind, muss das Speicherverhalten sorgfältig gemessen werden.

Mehr System-RAM

Die Verwendung von --ple-io ram könnte mehr Modelldaten in den Systemspeicher bringen und Speicherlesevorgänge reduzieren.

Die Dokumentation des Entwicklers schlägt vor:

• +16–31 % Vorfüllleistung
• +3–11 % Dekodierungsleistung

Diese Konfiguration würde jedoch wesentlich mehr RAM erfordern, etwa 72+ GiB für das gemessene Layout.

Bei der aktuellen 48-GB-Konfiguration ist dies nicht praktikabel.

Spekulative Dekodierung

Die spekulative MTP-Dekodierung ist bereits aktiviert.

Beobachtete Akzeptanz: ~33–41 akzeptierte Token von 50–60 gedrafteten, oder etwa 65–70 %.

Längerer Kontext

Die aktuelle 32-KB-Grenze ist eine betriebliche Konfigurationsgrenze und kein Beweis dafür, dass das Modell selbst nur 32 KB unterstützt.

Eine Erhöhung erfordert eine erneute Überprüfung der Speicherkapazität, des KV-Cache-Verhaltens, der Latenz und der Stabilität.

Bei dieser Arbeitslast ist die Reduzierung teurer Lesevorgänge durch Experten und die Verbesserung der Zugriffsmuster möglicherweise wichtiger als die Erhöhung der maximalen sequentiellen Bandbreite des Laufwerks.

Wie immer: Benchmarken Sie die tatsächliche Arbeitslast, nicht nur die Hardware-Marketingzahlen.

Letzte Gedanken

Das zeigt dieses Experiment.

Ein quantisiertes MoE-Modell mit ca. 83,6 GB kann lokal ausgeführt werden auf:

• RTX 3060 12 GB
• 48 GB DDR5 RAM
• Consumer-Intel-CPU
• PCIe 5.0 NVMe SSD
• Ubuntu + Strata

Mit Messergebnissen bis:

• 68 tok/s warme Dekodierung
• 916 tok/s sofortige Verarbeitung
• 30.000-Token-Cold-Prompt in ca. 34 Sekunden
• Vollständig zwischengespeicherte 30-KByte-Eingabeaufforderung: ~0,44 s bis zum ersten Token
• Unter normalen Betriebsbedingungen kein Austausch

Es gibt jedoch wichtige Vorbehalte.

• Der maximal konfigurierte Kontext beträgt 32 KB
• Schnelles Experten-Routing ändert das Modellverhalten
• Die höchste Geschwindigkeit bedeutet nicht unbedingt die höchste Qualität
• Die Speicherleistung hängt von den Zugriffsmustern ab
• Die Speicherverwaltung erfordert eine sorgfältige Abstimmung
• Agenten mit langer Laufzeit profitieren von leistungsfähigerer Hardware

Mein besonderes Interesse gilt der praktischen Ökonomie lokaler KI.

Nicht nur die maximale Benchmark auf einem 10.000-Euro-System, sondern auch die brauchbare Leistung, die auf Consumer-Geräten und erschwinglichen Konfigurationen ab etwa 1.000 Euro erreichbar ist.

Datenschutz, Unabhängigkeit, kontrollierte Betriebskosten und praktischer Nutzen sind wichtiger als nur die Jagd nach beeindruckenden Benchmark-Zahlen.

Dies ist noch ein sich entwickelndes Experiment, und ich werde die Messungen, Fehler, Konfigurationsänderungen und Verbesserungen weiterhin mit Ihnen teilen.

Die Zukunft der lokalen KI wird bereits überraschend erschwinglich.

Spätere Ergänzungen

Oh, ich habe vergessen zu erwähnen, dass die GPU mit NVIDIA Unlock läuft, das erst vor ein paar Tagen, also letzte Woche, veröffentlicht wurde.

Ich habe jetzt meinen KI-Agenten gebeten, die gleichen Benchmarks ohne die Freischaltung durchzuführen, sodass wir die Ergebnisse in etwa 15–20 Minuten vergleichen können.

In den nächsten Tagen, aber nicht heute, werde ich diese GPU in ein System einbauen, das weniger als 1.000 US-Dollar kostet, und sehen, wie sie dort funktioniert.

Ursprünglicher Thread auf X · Alle Neuigkeiten