Kleine Sprachmodelle im Praxistest – Teil 4

Computerkram

Qwen3 Coder vs. Devstral: Ein Vergleich der Sprachmodelle für die Programmierung

In diesem Teil habe ich mit zwei Sprachmodellen gearbeitet, die sich speziell für Programmieraufgaben eignen: Qwen3 Coder 30B A3B Instruct und Devstral Small 2507 jeweils in der MLX-Version über LM Studio. Beide Modelle sollen Entwicklern bei der Erstellung, Fehlerbehebung und Optimierung von Code helfen. Doch wie schlagen sie sich im direkten Vergleich? Hier sind meine Erfahrungen aus verschiedenen Tests.

Test 1: C++-Programmierung mit Zed und LM Studio

Für den ersten Test habe ich beide Modelle in Zed, einem modernen Code-Editor, getestet. Die Prompts wurden auf Englisch direkt im Editor-Fenster gestellt. Ich ließ mir fünf Programme generieren:

  1. Tic Tac Toe (erst normal, dann mit zufällig spielendem Gegner)
  2. Vier gewinnt (erst normal, dann mit nicht-zufälligem Gegner)
  3. Minesweeper

Ergebnisse:

  • Tic Tac Toe:
    • Beide Modelle liefern fehlerfreie C++-Programme.
  • Tic-Tac-Toe mit Computer-Gegner:
    • Devstral hatte hier einen Fehler: Es wurden zwei Variablen, innerhalb eines do-Blocks deklariert und dann versucht, in der abschließenden while-Bedingung darauf zuzugreifen, wo sie allerdings nicht mehr sichtbar sind. Devstral konnte den Fehler jedoch selbst korrigieren, indem ich die Compiler-Fehler mitgab und die entsprechende Funktion markierte.
    • Qwen3 Coder hatte keine Fehler.
  • Vier gewinnt:
    • Beide Modelle generierten den Code ohne Fehler, sowohl für die Zwei-Spieler-Variante als auch für eine Version mit Computer-Gegner, der diesmal nicht rein zufällig spielen durfte.
  • Minesweeper:
    • Qwen3 Coder lieferte einen fehlerfreien Code.
    • Devstral generierte und zeigte zunächst nur ein „board for reference“. Nach der Aufforderung, das Spiel spielbar zu machen, generierte es einen Code, bei dem am Anfang bereits die Zahlen (aber nicht die Bomben) aufgedeckt waren. Zudem gab es gelegentlich einen segmentation fault. Ich habe diese Fehler nicht weiter analysiert.

Fazit des C++-Tests:

Qwen3 Coder hat die Nase vorn. Während beide Modelle bei einfachen Aufgaben gut funktionierten, zeigte Qwen3 Coder eine höhere Zuverlässigkeit, insbesondere bei komplexeren Anforderungen wie Minesweeper. Außerdem ist Qwen3 Coder deutlich schneller.

Test 2: Python-Libraries für XQuery

Im zweiten Test habe ich beide Modelle in Zed, diesmal im Chatfenster des rechten Docks, nach Python-Libraries für XQuery gefragt. Bei diesem Nischen-Thema hatte ich vor etwa anderthalb Jahren noch mit keinem Sprachmodell zielführende Hinweise bekommen, daher hatte ich an sich nicht viel Hoffnung, aber es kam anders…

Ergebnisse:

Qwen3 Coder funktionierte zunächst nicht im Zed Chatfenster. Eine Fehlermeldung wies auf ein Problem mit dem Prompt-Template hin. Der Fix bestand darin, in LM Studio das Prompt-Template des normalen Qwen3 zu verwenden.

Qwen3 Coder suchte dann mit pip nach möglicherweise passenden Paketen und hätte mir fast auf Verdacht lxml installiert (nein, das kann kein XQuery, nur XPath!).

Aus einem leeren Projekt heraus gestartet zeigte Devstral aus Modellwissen im Chat teils nützliche, aber auch inzwischen eingestellte Projekte.

Aus LM Studio heraus (ohne Systemprompts und Toolzugriff über Zed) lieferten beide Modelle teils eingestellte Projekte als Vorschläge oder Hinweise auf Packages, die nur so heißen, als könnten sie XQuery und in Wahrheit etwas ganz anderes sind, aber auch teils nützliche Hinweise!

Bis zu diesem Punkt lief das schon mal bedeutend besser als vor anderthalb Jahren. Das ist noch nicht super, aber der eine Hinweis auf ein existierendes Package das tatsächlich XQuery kann und auch noch maintained wird, war auf jeden Fall hilfreich.

Als ich später den Test aus einem in Zed geöffneten Python-Projekt heraus wiederholte, schauten übrigens erst mal beide Modelle meinen Code durch, ob ich nicht schon etwas hatte, und fanden das dann auch.

Aber erst mal musste das Programm ja geschrieben werden, deswegen ließ ich nach der Auswahl eines Python-Packages für XQuey beide Modelle Code generieren, der aber zunächst nicht funktionierte.

Beim Versuch, das Programm unter Angabe der Fehlermeldung sowie mit der in den Chat hineinkopierten Dokumentation von der Webseite zu korrigieren, trat dann ein unerwartetes Problem auf:

Qwen3 Coder zeigte bei größerem Kontext (wie eben hier dem Auszug aus der Dokumentation) seltsames Verhalten: Es wiederholte Teile des Kontextes endlos. Dies könnte mit dem Context-Window zusammenhängen, das in Wahrheit nur 32K zu sein scheint (obwohl eigentlich 256K einstellbar ist). Auf der Model Card bei Huggingface gibt es einen Hinweis: „If you encounter out-of-memory (OOM) issues, consider reducing the context length to a shorter value, such as 32,768.“ Dies deckt sich mit meiner Beobachtung. Auch wenn es bei mir zu keinem Abbruch mit Fehlermeldung kam, war eine Arbeit mit mehr als ca. 32K Tokens nicht möglich. (Korrektur: Dies scheint die MLX-Version zu betreffen, die „unsloth“-Version, die GGUF verwendet, scheint zu funktionieren, siehe Teil 6.)

Devstral lieferte dagegen auf die gleiche Anfrage hin ein korrigiertes Programm, sowohl aus LM Studio als auch aus Zed. (Dort allerdings erst im zweiten Anlauf nach einer Korrekturrunde.)

Generell ist beim Arbeiten mit großem Context-Window zu beachten, dass die Verarbeitung des Prompts dann lange dauert und bis zur ersten Antwort mehrere Minuten vergehen können. Weitere Anfragen werden dann aber normalerweise wieder schneller beantwortet.

Fazit des XQuery-Tests:

Qwen3 Coder war schon irgendwie hilfreich, aber auch sehr holprig. Das Context-Window ist in Wahrheit nur 32K groß, und für die Nutzung aus dem Zed-Chatfenster war eine manuelle Anpassung des Prompt-Templates in LM Studio nötig. Nur Devstral war in der Lage, mit großem Kontext zu arbeiten.

Gesamtfazit

Insgesamt ist das Ergebnis also nicht eindeutig:

  • Qwen3 Coder ist deutlich schneller als Devstral (das Verhältnis ähnelt dem zwischen Qwen3 und Mistral) und bei C++-Aufgaben besser.
  • Allerdings kann das zu kleine Context-Window problematisch werden, (Korrektur: siehe Teil 6, das für Qwen3 gesagte gilt sinngemäß auch für Qwen3 Coder) und für die Nutzung aus dem Zed-Chatfenster war eine manuelle Anpassung erforderlich.
  • Beide Modelle können Projekte durchsuchen und Tools nutzen, z. B. kann Qwen3 Coder auch pip verwenden, um zu sehen, welche Packages in Python installiert sind.

Fazit: Beide Modelle haben ihre Stärken und Schwächen. Qwen3 Coder ist schneller und zuverlässiger bei C++-Aufgaben, während Devstral bei Python-Fragen manchmal die bessere Lösung bietet und mit einem größeren Kontext arbeiten kann. Die Wahl des Modells hängt also vom konkreten Anwendungsfall ab.

Im übrigen habe ich mir auch für diesen Beitrag wieder von Mistral 3.2 helfen lassen, aus Stichpunkten Fließtext zu generieren. Ich würde sagen, das kann man schon sehr gut produktiv einsetzen.

Nachtrag: Vergleich mit nicht-coding-optimierten Modellen

Um zu untersuchen, ob die nicht auf Programmieren optimierten Modelle prinzipiell auch für Coding-Aufgaben geeignet wären, habe ich zusätzlich Qwen3 (nicht Coder), Mistral Small und Gemma3 mit der Minesweeper-Aufgabe getestet, um einen umfassenderen Eindruck zu gewinnen.

Qwen3 lieferte wie Qwen3 Coder einen fehlerfreien Code. Dies ist zunächst keine große Überraschung, da Qwen3 Coder auf dem gleichen Modell basiert.

Bei Mistral gab es ähnliche Probleme wie bei Devstral, auch das ist nicht überraschend, da auch diese beiden Modelle eine ähnliche Architektur haben.

Auch bei Gemma3 gab es Fehler. Die 27B-Version war besser als die 12B-Variante.

Die nicht für Coding optimierten Modelle sind also prinzipiell ebenfalls benutzbar, haben allerdings den Nachteil, dass sie nicht auf Tool-Unterstützung trainiert sind. Dass sie stattdessen Bildverarbeitung unterstützen bringt, für die Programmierung nichts.

Meine Empfehlung für Anwendungen in der Programmierung bleibt daher weiterhin Qwen3 Coder oder Devstral, letzteres insbesondere wenn das zu kleine Context-Window von Qwen3 Coder zum Problem wird.