„Spoiler: yes, I can do it all on hardware that costs under $3,500“, schreibt Karim Elmaaroufi über seinen Versuch mit lokalen LLMs. Der Satz klingt zunächst nach der üblichen Geschichte vom gekündigten KI-Abo. Sein Ergebnis ist nüchterner: Auf einem AMD Ryzen AI Max+ 395 bekommt er ein Open-Weight-Modell mit 262.144 Tokens Kontext und mehreren Coding-Agenten zum Laufen. Seine Abos will er trotzdem behalten.
Genau diese Spannung macht den Test interessant. Ein Modell kann in den Speicher passen und dennoch zu langsam sein. Ein Server kann 32 Agenten bedienen und trotzdem keinen davon in einem angenehmen Tempo versorgen. Und ein Kontextfenster von 32k kann für viele Aufgaben reichen, obwohl es bei einem ungünstigen Dateizugriff schon vor dem ersten Edit voll ist. Wer lokale LLMs für Coding einsetzen will, muss deshalb Kapazität, Bandbreite, Kontext und Modellqualität getrennt betrachten.
Warum 32k Kontext schneller knapp werden als gedacht
Zum Kontext eines Coding-Agenten gehören mehr als deine letzte Frage. Systemprompt, Werkzeugbeschreibungen, Dateiinhalte, Befehlsausgaben und der bisherige Gesprächsverlauf belegen gemeinsam das Fenster. In Elmaaroufis aufgezeichneter Pi-Anfrage brauchten Systemprompt und vier Standardwerkzeuge bereits rund 1.640 Tokens, bevor eine Projektdatei gelesen war.
Wie schnell der Rest wächst, zeigt eine SWE-bench-Aufgabe aus Astropy. Fehlerbeschreibung, Implementierungsdatei und Tests belegen zusammen 4.474 Tokens. Nimmt der Agent zusätzlich die komplette Datei hinzu, in der CompoundModel definiert ist, steigt das Material auf 43.426 Tokens. Mit dem Grundbedarf von Pi sind es ungefähr 45.066 Tokens. Ein einziges 32k-Fenster kann diese Auswahl nicht gleichzeitig halten.
In der Praxis lesen Agenten meist nur Ausschnitte. Elmaaroufi wertete deshalb 500 öffentliche SWE-bench-Verified-Läufe mit Claude Sonnet 4 und mini-SWE-agent aus. Der Median erreichte 15.140 Tokens im größten aufgezeichneten Verlauf, der Spitzenfall 92.323. Nur 25 von 500 Aufgaben überschritten das komplette 32k-Fenster. Allerdings lagen 213 Aufgaben über 16.384 Tokens – genau dort beginnt Pi 0.85.1 bei einem 32k-Fenster standardmäßig zu kompaktieren, weil weitere 16.384 Tokens für die Antwort reserviert werden.
Das ist für mich der entscheidende Unterschied: 32k sind keine automatische Unbrauchbarkeitsgrenze. Sie sind aber auch nicht vollständig für Dateien und Verlauf verfügbar. Harness-Einstellungen, selektives Lesen und Kompaktierung bestimmen, wie viel Arbeit tatsächlich hineinpasst.
Speicherkapazität allein sagt wenig über das Tempo
Die Testmaschine hat 123 GiB nutzbaren Unified Memory, den CPU und integrierte GPU teilen. Der GPU stehen standardmäßig 61,7 GiB als gemeinsamer Pool zur Verfügung. Damit lässt sich ein großes Modell laden. Ob die Antworten schnell kommen, hängt jedoch davon ab, wie zügig die Gewichte für jedes neue Token aus dem Speicher gelesen werden.
Ein dichter, vier Bit quantisierter Qwen3.8-27B kam im vLLM-Test bei einer Anfrage auf 11,22 Tokens pro Sekunde. Elmaaroufi maß ungefähr 240 GB/s Speicherbandbreite und errechnete rund 16,7 GB gelesene Modellgewichte pro erzeugtem Token. Schon diese einfache Rechnung setzt eine theoretische Obergrenze von etwa 14 Tokens pro Sekunde. Ausreichender RAM verhindert hier einen Absturz, macht die Ausgabe aber nicht automatisch schnell.
Anders verhält sich das Mixture-of-Experts-Modell Qwen3.6-35B-A3B. Es hält insgesamt rund 35 Milliarden Parameter vor, aktiviert für ein Token aber nur einen Teil davon. Im Test mussten ungefähr 2,3 GB Gewichte pro Token gelesen werden. Die gemessene Einzelgeschwindigkeit stieg auf 42,34 Tokens pro Sekunde. Zehn gleichzeitige Anfragen erzeugten zusammen 126,41 Tokens pro Sekunde, im Mittel also 12,64 je Anfrage. Das ist schneller als beim dichten Modell, aber die Gesamtleistung verteilt sich weiterhin auf alle aktiven Nutzer.
Was das volle 262k-Fenster im Speicher kostet
Für das volle Kontextfenster nutzte Elmaaroufi Qwen3.6-35B-A3B mit 262.144 Tokens. Das Modell kombiniert klassische Aufmerksamkeit mit Gated DeltaNet: Nur zehn von 40 Schichten halten einen vollständigen KV-Cache über den Verlauf. Mit einem Cache in Acht-Bit-Präzision ergibt seine Rechnung rund 10 KiB je Token. Ein Verlauf mit 32.768 Tokens benötigt damit ungefähr 0,3125 GiB, das volle Fenster etwa 2,5 GiB.
Die beiden Backends verwalten ihren Speicher unterschiedlich. llama.cpp belegte im vollständigen Aufbau rund 24 GiB GPU-sichtbaren Speicher, darunter eine 20,2-GiB-Gewichtsdatei und den Cache. vLLM reservierte 52,5 GiB als gemeinsamen Pool für Gewichte, Cache und Arbeitsdaten. Diese Zahl ist nicht der Verbrauch eines einzigen Verlaufs. Ebenso reservieren 32 Agenten nicht automatisch 32 vollständige 262k-Caches; ihre getrennten Verläufe füllen den vorhandenen Pool erst während der Arbeit.
Das Fenster ließ sich also konfigurieren und im Speicher halten. Die wichtigere Frage lautet danach: Wie stark fällt die Ausgabe ab, wenn ein Verlauf tatsächlich lang wird?
Langer Kontext macht die Wahl des Backends sichtbar
Bei kurzen Prompts lief llama.cpp in diesem Aufbau mit 58,7 Tokens pro Sekunde, vLLM mit dem alternativen TRITON_ATTN-Backend mit 44,6. Bei 51.028 bereits vorhandenen Prompt-Tokens blieben 47,7 beziehungsweise 28,3 Tokens pro Sekunde übrig. Das vLLM-Standardbackend ROCM_ATTN fiel dagegen von 38,6 auf 1,7 Tokens pro Sekunde.
Ein kurzer Geschwindigkeitstest hätte diesen Unterschied verborgen. Erst der lange Verlauf zeigt, ob die Attention-Implementierung den KV-Cache effizient durchsuchen kann. Elmaaroufi vermutet anhand des Quellcodes, dass das Standardbackend in dieser Konfiguration auf einen ungünstigen Fallback zurückfiel. Er hat den Anteil dieses Mechanismus nicht isoliert gemessen, die Kurven unterscheiden sich dennoch deutlich.
Für einen eigenen Test heißt das: Die Angabe „unterstützt 262k Kontext“ beschreibt zunächst eine Konfiguration. Sie sagt noch nicht, ob die letzten 50.000 Tokens mit brauchbarem Tempo verarbeitet werden. Genau dort lohnt ein Test mit den eigenen Projekten statt mit einem kurzen Chat-Prompt.
Wie viele lokale Coding-Agenten praktisch übrig bleiben
Über OMAR startete Elmaaroufi bis zu 32 getrennte Pi-Sitzungen. Als persönliche Komfortgrenze setzte er 20 Tokens pro Sekunde und Agent. llama.cpp blieb bis zu sechs gleichzeitigen Agenten über dieser Marke, vLLM bis zu vier. Bei 32 Agenten erreichte vLLM zwar 235,4 Tokens pro Sekunde insgesamt, pro Agent blieben im Mittel 7,3. llama.cpp kam insgesamt auf 132 und pro Agent auf 4,1.
Auch die Skalierung verlief nicht gleichmäßig. Bei llama.cpp sank der Gesamtdurchsatz beim Sprung von acht auf neun Anfragen deutlich, weil das Vulkan-Backend oberhalb von acht Tokens pro Rechenschritt einen anderen Kernelpfad nutzte. vLLM zeigte beim Wechsel von vier auf fünf Agenten eine kleinere Stufe, die der Autor mit vorbereiteten HIP-Graph-Größen erklärt. Mehr parallele Prozesse führen auf dieser Hardware also nicht automatisch zu mehr nutzbarer Arbeit.
Die Messungen simulierten lange, gleichzeitige Ausgaben mit Witzen. Sie beweisen nicht, dass sechs Agenten sechs reale Coding-Aufgaben erfolgreich lösen. Dateioperationen, Tests und Pausen verändern die Last, und die Qualität des quantisierten Modells wurde in diesem Aufbau nicht separat bewertet.
Was ein 32k-Kontextfenster nun wirklich bedeutet
32k reichen für einen großen Teil der beobachteten SWE-bench-Verläufe, doch Pi nutzt mit der Standardeinstellung nur die erste Hälfte, bevor es kompaktieren muss. Ein größeres Fenster lässt sich auf Unified-Memory-Hardware betreiben, wenn Modellarchitektur, Quantisierung und KV-Cache zusammenpassen. Für das Arbeitsgefühl sind Speicherbandbreite und Attention-Backend mindestens genauso wichtig wie die nominelle Kontextgröße.
Der Versuch liefert damit keinen einfachen Ersatz für Claude Code oder Codex. Elmaaroufi verweist selbst auf eine deutliche Qualitätslücke in allgemeinen Modellvergleichen und hat die tägliche Coding-Leistung seines Setups noch nicht ausreichend geprüft. Sein belastbares Ergebnis ist kleiner und hilfreicher: Ein lokales System unter 3.500 Dollar kann ein 262k-Fenster bereitstellen und mehrere Agenten in brauchbarem Tempo versorgen – solange du nicht aus der Zahl 32 gleich 32 produktive Entwickler machst.
Wenn du so ein System planst, frage deshalb in dieser Reihenfolge: Passt das Modell in den Speicher? Reicht die Bandbreite für ein einzelnes Token? Bleibt das Backend bei langem Kontext schnell? Und wie viele Agenten liegen noch über deiner persönlichen Komfortgrenze? Erst danach ist die Kontextzahl auf dem Datenblatt wirklich etwas wert.
Quelle: Karim Elmaaroufi auf kael.tech.blog
