Ich sah zu, wie ein 27-GB-Modell mittendrin bei der Inferenz abstürzte, während eine 6,6-GB-Alternative vor sich hin schnurrte, als hätte sie sonst nichts zu tun.
Dieser Moment — sitze ich vor meiner RTX 5070 Ti, starre auf einen Segfault-Fehler in WSL2 — brachte etwas auf den Punkt, das ich seit zwei Jahrzehnten in dieser Branche skeptisch sehe: Parameteranzahl ist eine Eitelkeitsmetrik. Das ist, was in Pressemitteilungen und Investor-Pitches zitiert wird. Das ist, was Investoren warm ums Herz werden lässt. Aber es ist fast nie das, was ein Modell wirklich nützlich auf deinem Schreibtisch macht.
Ich habe qwen3.5:9B durch 18 Tests gegen fünf konkurrierende Modelle gejagt — speziell für lokale Agent-Arbeit, also die echte Arbeit, wo du tatsächlich Tools aufrufst, strukturierte Daten verarbeitest und schnell genug Ergebnisse bekommst, dass du keine Kaffeepause brauchst. Der Gewinner stand außer Frage.
Der Benchmark, über den niemand spricht: Strukturierter Tool-Aufruf
Hier liegt das, was Spreu von Weizen bei lokalen Agenten trennt — und Alibabas Ingenieure haben das offenbar besser verstanden als die meisten.
Wenn du die meisten Sprachmodelle fragst, ein Tool zu benutzen — sagen wir, ein Verzeichnis aufzulisten oder eine Datenbank abzufragen — vergraben sie den Funktionsaufruf irgendwo in einer weitschweifigen Prosa-Antwort. Du brauchst dann Parsing-Logik, Fehlerbehandlung, Wiederholungsmechanismen. Ein echtes Desaster. Einige Modelle machen das besser als andere, aber die meisten zwingen dich, eine fragwürdige Extraktions-Layer zu bauen.
“Nur Modelle mit nativem tool_calls-Support und Q4_K_M-Quantisierung liefen reibungslos.”
Qwen3.5:9B gibt ein sauberes, eigenständiges tool_calls-Feld in JSON zurück. Das war’s. Kein Parsing. Keine Regex-Akrobatik. Keine Gebete an die Python-Götter. Größere Konkurrenten wie Qwen2.5:14B und Qwen2.5-coder:14B vergruben dieselbe Information in Reintext und zwangen dich, Extraktions-Layer zu bauen und sie um 23 Uhr zu debuggen.
Ich habe dieses spezifische Szenario über fünf Modelle getestet. Qwen3.5:9B hat es zu 100% hinbekommen. Gemma 4 E4B (ein 9,6-GB-Modell) brauchte 30 Minuten Ollama-Tuning, um von 3 Tool-Aufrufen auf 14 zu kommen. Selbst dann unterlief es der Konsistenz des kleineren Modells. Die 27B-Varianten? Stabilitätsprobleme, die Production-Deployment unmöglich machten.
Wo VRAM zum echten Engpass wird (Spoiler: immer)
Lass mich direkt sein: Konsumenten-GPU-Speicher ist die echte Begrenzung bei lokaler KI-Arbeit — nicht die Modell-Raffinesse.
Qwen3.5:9B brauchte 6,6 GB VRAM auf meiner RTX 5070 Ti und ließ reichlich KV-Cache-Platz sowie Raum für längere Kontexte übrig. Ein Q4_K_M-quantisiertes 27B-Modell? 16 GB — die Karte war vollständig maxiert. Und dann begannen die Abstürze. TurboQuants Segfault-Bug in WSL2 verschärfte die Situation und verwandelte das, was ein unkomplizierter Inferenz-Lauf sein sollte, in einen Debugging-Albtraum.
Ich hielt akribische Notizen. Hier ist, was wirklich passierte:
Größere-Modell-Befürworter sagen immer “füg einfach mehr VRAM hinzu.” Klar, wenn du 8.000 Dollar für eine A100 rumliegen hast. Aber wenn du lokale Agenten auf einer Consumer-GPU laufen lässt — was ehrlich gesagt die meisten von uns tun — ist VRAM die harte Begrenzung. Nicht theoretische Fähigkeit. Nicht Benchmark-Scores. Echter, physischer Speicher.
Qwen3.5:9B respektiert diese physikalische Realität.
Der Token-Effizienz-Trick, den niemand diskutiert
Hier wird es seltsam — und hier passieren auch die echten Gewinne.
Qwen3.5:9B unterstützt einen think=false-Parameter, der interne Reasoning-Token deaktiviert. Selbe Aufgabe. Anderer Token-Verbrauch. Wir reden von 1024+ Token runter auf 131. Eine 8- bis 10-fache Reduktion. Das ist kein Rundungsfehler — das ist ein Phasenwechsel, wie sich das Modell verhält.
Warum ist das wichtig? Weil längere Kontext-Fenster und mehr Tool-Ergebnisse in denselben VRAM-Footprint passen. Du kannst komplexere Agent-Schleifen laufen lassen
