Kurz gesagt: Ich habe drei Strategien sauber getestet, und keine hat bestanden. Hier die Details, weil das Vorgehen spannender ist als das Ergebnis. Gebaut habe ich alles zusammen mit Claude Code: Daten laden, Backtest-Engine, Auswertung. Meine wichtigste Regel: Strategie und Bestehensbedingungen werden festgeschrieben, BEVOR die erste Zahl berechnet ist. Hinterher wird nichts mehr hingebogen. 📊 Die Daten • Dow-Jones-Minutenkurse (Dukascopy USA30, Bid und Ask) von 2019 bis 2025 • nur echte US-Börsentage, 9:30–16:00 New Yorker Zeit: 1.760 Handelstage • Kosten: 4 Punkte je Trade (Slippage plus Kommission für den Micro-Dow-Future) • Kurslücken immer zum schlechteren Kurs gerechnet • Vergleich: 1.000 Durchläufe mit zufälliger Richtung. Eine Strategie muss besser sein als Münzwurf. • Bestanden nur mit Profitfaktor ≥ 1,2 (Gewinne geteilt durch Verluste) und Plus in der Mehrheit der Jahre 1️⃣ Ausbruch aus der Eröffnungsrange Hoch und Tief der ersten Minuten nach Börsenstart. Bricht der Kurs aus, geht es in Ausbruchsrichtung rein. Stop auf der Gegenseite, abends raus. ➡️ Beste Variante im Prüfzeitraum 2023–2025: Profitfaktor 0,99. Nicht besser als Zufall. 2️⃣ Intraday-Momentum (aus einer Studie von 2018) Die Richtung der ersten halben Stunde sagt die letzte halbe Stunde voraus, so die Idee. ➡️ Profitfaktor 0,77, kein Jahr im Plus, schon VOR Kosten negativ. Der Effekt ist im Dow nicht mehr da. 3️⃣ Trendfolge mit nachgezogenem Stop Läuft der Kurs eine Weile in eine Richtung: mitgehen und den Stop hinterherziehen. 9 Kombinationen aus Anlaufzeit und Stop-Abstand getestet. ➡️ Alle 9 verlieren nach Kosten, die beste kommt auf 0,95. Vor Kosten bleiben rund 2 Punkte Plus je Trade, bei 4 Punkten Kosten. Und selbst das ist nicht besser als Zufall. 💡 Was ich mitnehme • Die Kosten entscheiden. Viele Ideen sehen vor Kosten gut aus und sind danach tot. • Ohne vorab festgelegte Regeln findet man IMMER eine Einstellung, die in der Vergangenheit toll aussieht. • Hebel macht aus null keinen Gewinn. Er vergrößert nur die Schwankung.

Ollama hat bei Qwen3.8 Flash Next nachgezogen: https://github.com/ollama/ollama/releases/tag/v0.40.16 Im Release steht, dass das Modell auf Apple Silicon rund 27 GiB weniger Speicher braucht. Die genauen Zahlen stehen im zugehörigen Pull Request: Der fest belegte Speicher sinkt von 97,6 auf 70,8 GiB, Ziel sind Macs mit 128 GB. Neu ist die Größenordnung nicht. Ich hatte Flash Next im September auf meinem Mac mit 96 GB laufen, über llama.cpp mit einer 4-Bit-GGUF-Fassung. Belegt waren 65 bis 69 GB, stabil mit 131K Kontext als Coding-Modell. Ollama holt hier also auf. Wie Ollama spart, ist trotzdem lehrreich: Das Modell trägt eine Tabelle von 26,8 GiB mit, von der pro Token nur wenige Zeilen gebraucht werden. Statt sie komplett in den Speicher zu laden, liest Ollama die benötigten Zeilen bei Bedarf von der Platte. Eins zu eins vergleichbar sind die Zahlen mit meinem Test nicht, weil Ollama eine andere Quantisierung nutzt und Teile des Modells bewusst in höherer Genauigkeit hält. Laut Pull Request, weil lange Antworten mit durchgehend 4 Bit schlechter werden. Für die Praxis zählt etwas anderes: 70 GB auf einem 96-GB-Mac heißt, daneben läuft fast nichts mehr. Bei mir musste das lokale Modell, an dem meine n8n-Workflows hängen, für den Test aus. Coding-Modell und Automatisierung gleichzeitig ging nicht. Daraus eine Faustregel für die eigene Planung: Rechne vom gesamten RAM ab, was dauerhaft läuft (Betriebssystem, Browser, n8n, andere Modelle). Was übrig bleibt, ist das echte Budget für ein großes Modell samt Kontext. Passt es dort nicht hinein, plane es als eigenes Gerät oder als festes Zeitfenster, nicht als Dienst neben allem anderen. Ob Ollama, llama.cpp oder MLX, ändert daran wenig. Wie macht ihr das: Läuft euer größtes Modell dauerhaft neben dem Rest oder nur in festen Zeitfenstern?

Auf Hacker News ist mir ein Projekt aufgefallen, das sparse Mixture-of-Experts-Modelle komplett im System-RAM rechnen lässt, ohne GPU: https://github.com/synchopate/llama-modchip Was dort steht: llama-modchip ist ein Satz Kernel-Patches für ggml/llama.cpp plus Quantisierungs-Transcoder und Runtime-Tools, für x86_64 (AVX-512/AVX2) und ARM64 (NEON/SVE/Apple Metal). Die Vorzeigezahl ist DeepSeek-V4-Flash mit 284,33 Mrd. Gesamtparametern, davon 13,17 Mrd. aktiv, verteilt auf 43 MLA-Layer und 256 geroutete Experten, Top-6 pro Layer ohne Pruning. Bei 1,71 bpw liegen 56,56 GiB auf der Platte, Peak VmRSS bei 256K Kontext 57,61 GiB – laut Projekt passt das ohne NVMe-Swap in die rund 62,5 GiB nutzbaren RAM eines 64-GB-Linux-Systems. Ein Standard-UD-IQ1_S-Build desselben Modells bräuchte 76,87 GiB und würde dort kippen. Durchsatz: 44,36 tok/s Prefill auf 16 Kernen Zen 5, 9,1–14,7 tok/s Generierung. Interessanter finde ich die kleineren Zeilen der Tabelle. Nemotron-3.5-30B-A3B mit 3,75 bpw sind 14,35 GiB und laufen laut Projekt auf 16–32 GB mit 25,0–60,4 tok/s, 256K Kontext belegt dort 432 MB KV. Im Hybrid-Setup mit CPU plus 16-GB-GPU nennt das Repo 80,80 tok/s, auf einer 8-Channel-Threadripper-Workstation 111,62 tok/s für das 30B-Modell. Für die eigene Einordnung würde ich deshalb nicht mit der Gesamtparameterzahl rechnen, sondern mit zwei Größen: Erstens, wie viel Modellgewicht bei der gewählten bpw überhaupt im Speicher liegen muss – das ist die Zahl, die über „passt / passt nicht" entscheidet. Zweitens, wie viele Parameter pro Token tatsächlich aktiv sind, denn die müssen über die Speicherbandbreite wandern. Bei 13,17 Mrd. aktiven Parametern ist das ein ganz anderer Bandbreitenhunger als bei einem dichten Modell gleicher Größe. Auf Apple Silicon ist genau das die Stelle, an der die unified memory bandwidth zur harten Grenze wird – das Projekt nennt Metal und ARM64 als unterstützt, aber die Messwerte in der Tabelle sind x86.

Ricursive Intelligence hat Ripple-65B Preview veröffentlicht, ein dichtes Modell mit offenen Gewichten, und die Ankündigung ist für uns aus einem anderen Grund interessant als für die Benchmark-Leute: https://www.ricursive.com/ripple Die Fakten aus der Meldung: 65 Mrd. Parameter, von Null trainiert, 12 Billionen Token Pretraining, Unterstützung für bis zu 1 Mio. Kontextlänge. Auf TerminalBench 2.1 erreicht das Modell 80,52 und liegt damit vor Reflection Beam 501B (80,1), Meta Muse Spark Open 816B (76,4), Thinking Machines Inkling 975B (63,8) und NVIDIA Nemotron 3 Ultra 550B (56,4). Die Gewichte liegen auf Hugging Face, Hosting gibt es über Together AI, GMI Cloud und OpenRouter, Fireworks folgt laut Anbieter noch. Die kompletten Entwicklungskosten inklusive Pretraining-Ladder, Datenmischung, Evals, synthetischer Daten und finalem Lauf werden mit 32 Mio. Dollar angegeben – nach eigener Schätzung ein Zehntel der vorherigen Open-Weight-Spitze beim Agenten-Coding. Die Meldung zitiert als Kontrast über 100 Mio. Dollar für GPT-4 und Prognosen von bis zu 1 Mrd. Dollar pro Frontier-Lauf. Der für mich spannendste Satz ist aber der zur Architektur: Ripple ist dicht, kein MoE. Begründet wird das mit niedriger Latenz pro Token und ausdrücklich damit, dass das kleine Parameter-Budget auf lokalen Geräten wie NVIDIA DGX Spark effizient läuft – Hardware mit viel Rechenleistung, aber wenig Speicherbandbreite im Vergleich zu Rechenzentrums-Beschleunigern. Praktisch heißt das erstmal: 65B dicht ist auf den meisten Macs, die hier vertreten sind, kein Alltagsmodell. Die Denkhilfe dafür ist simpel. Bei einem dichten Modell wandert pro Token der komplette Gewichtssatz durch den Speicher. Also: Gewichtsgröße in GB geteilt durch die Speicherbandbreite deiner Maschine in GB/s ergibt die theoretische Obergrenze an Tokens pro Sekunde – real liegt man darunter. Ein 65B-Modell in 4 Bit landet grob im Bereich von 35 bis 40 GB plus KV-Cache und Overhead. Rechne das für deine Bandbreite durch, dann weißt du vorher, ob das Sinn ergibt, statt es herunterzuladen und zu hoffen. Und beim Thema 1 Mio. Kontext: Die Meldung sagt nichts darüber, wie sich das auf Prefill-Zeiten auswirkt. Das ist genau die Zahl, die bei lokalen Agentenschleifen über die Brauchbarkeit entscheidet.

Es geht um einen kurzen Beitrag von Simon Willison, der für mich mehr über das Verhältnis Frontier zu lokal sagt als die meisten Benchmark-Grafiken: https://simonwillison.net/2026/Nov/3/qwen-can-interpret-model-weights/ Ausgangspunkt ist "Sparks of Weight-Space Programming" von Rikiya Takehi, Jayden Teoh, Alex Zhang und Omar Khattab. Die These: Frontier-Modelle, im Paper vor allem GPT-6 Astra, können rohe Gewichte eines neuronalen Netzes lesen und verändern – als reiner Text aus Fließkommazahlen, ohne Trainingsloop. Laut Abstract erkennt Astra am Gewichtsblob, worauf ein Netz trainiert wurde, schreibt kleine spielfähige Netze aus dem Stand, und bei Qwen3.5-0.8B identifiziert es eine Ursache für Reasoning-Loops, editiert 0,016 % der Gewichte und hebt MATH-500 von 7,9 % auf 48,1 %, IFEval verdreifacht sich. Willison trennt zwei Fragen, die im Paper vermischt sind: Was kann ein Modell ohne Tools mit rohen Gewichten? Und was kann es, wenn es Code ausführen darf? Matthew Honnibal nennt das Zusammenwerfen irreführend, Sean Goedecke zerlegt das Qwen3.5-Beispiel als die Schritte, die auch ein menschlicher ML-Forscher gegangen wäre. Willison konzentriert sich auf die Variante ohne Tools – und hat eines der Beispiele mit Qwen 3.8 27B auf seinem Laptop nachgespielt. Das Modell schafft die Interpretation ebenfalls. Wichtig: Das heißt nicht "lokal ist so gut wie Astra". Die Gewichts-Edits mit den großen Sprüngen sind eine andere Liga, und GPT-6 Astra läuft auf keiner Maschine hier. Interessant ist, dass die Fähigkeit als solche offenbar nicht an die Cloud gebunden ist. Der praktische Teil ist eher eine Rechenhilfe als eine Anleitung: Ein 27B-Modell in 4-bit-Quantisierung liegt grob bei 15 GB Gewichten. Dazu kommt der KV-Cache, der mit der Kontextlänge wächst – bei solchen Gewichts-Aufgaben ist der Prompt aus Fließkommazahlen der eigentliche Kostentreiber, nicht die Antwort. Faustregel zum Abschätzen: Gewichte plus Kontextbedarf plus Puffer für das System. Auf 32 GB unified memory ist das machbar, aber nicht komfortabel, wenn der Prompt lang wird. Wer prüfen will, ob so eine Aufgabe überhaupt in sein Setup passt, schaut zuerst auf die Tokenzahl des Prompts, nicht auf die Parameterzahl.