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.