LM Studio-Parser-Fehler beeinträchtigen Qwen3.5-Toolaufrufe und logisches Denken

LM Studio Parser-Probleme betreffen Argumentationsmodelle

LM Studios Server-Parser enthält mehrere Fehler, die Tool-Aufrufe und die Argumentation in Modellen wie Qwen3.5 und DeepSeek-R1 beeinträchtigen. Diese Probleme können dazu führen, dass Modelle defekt erscheinen, obwohl das Problem tatsächlich im Parser liegt.

Die Fehler

1. Parser scannt innerhalb von <think>-Blöcken nach Tool-Aufruf-Mustern

Wenn Argumentationsmodelle über Tool-Aufruf-Syntax in ihren <think>-Blöcken nachdenken, behandelt LM Studios Parser diese Erwähnungen als tatsächliche Tool-Aufruf-Versuche. Dies erzeugt eine rekursive Falle, in der das Modell über Tool-Aufrufe nachdenkt, der Parser Tool-Aufruf-ähnliche Token im Denkprozess findet, der Parse-Vorgang fehlschlägt, der Fehler an das Modell zurückgegeben wird und der Zyklus sich wiederholt.

Das Modell kann ein Tool-Aufruf-Problem buchstäblich nicht debuggen, weil die Beschreibung des Problems es reproduziert. Ein Modell sagte ausdrücklich: "Ich gerate in eine Schleife, in der meine Gedanken über Tool-Aufruf-Syntax als tatsächliche Tool-Aufruf-Marker interpretiert werden" – und dieser Satz selbst löste den Parser aus.

Dies wurde erstmals im Februar 2025 als Issue #453 gemeldet und bleibt über ein Jahr später offen.

Workaround: Deaktivieren Sie die Argumentation mit {%- set enable_thinking = false %}. Dies behebt das Problem sofort und ermöglicht 20+ aufeinanderfolgende erfolgreiche Tool-Aufrufe.

2. Registrierung eines zweiten MCP-Servers unterbricht die Tool-Aufruf-Verarbeitung für den ersten

Dieser Fehler ist klar und deterministisch. Tests mit lfm2-24b-a2b bei temperature=0.0 zeigen:

• Nur KG-Server aktiv: Das Modell ruft search_nodes korrekt auf, der Parser erkennt <|tool_call_start|>-Token, das Tool wird ausgeführt, Ergebnisse werden zurückgegeben. Funktioniert perfekt.
• Webfetch-Server hinzufügen (nicht einmal aufrufen): Das Modell gibt <|tool_call_start|>[web_search(...)]<|tool_call_end|> als Rohtext im Chat aus. Die speziellen Token werden nicht mehr erkannt. Das Tool wird nie ausgeführt.

Allein die Registrierung eines zweiten MCP-Servers – ohne ihn aufzurufen – verändert, wie der Parser die Tool-Aufrufe des ersten Servers behandelt. Gleiches Modell, gleiche Eingabe, gleicher Zielserver. Nur eine Variable geändert.

Workaround: Registrieren Sie nur den MCP-Server, den Sie für jede Aufgabe benötigen. Dies ist für agentische Workflows unpraktisch.

3. Serverseitige reasoning_content/content-Trennung erzeugt leere Antworten, die Erfolg melden

Dies betrifft alle, die Argumentationsmodelle über die API nutzen, unabhängig davon, ob sie Tool-Aufrufe verwenden oder nicht. Wenn eine einfache Eingabe an Qwen3.5-35b-a3b über /v1/chat/completions gesendet wird, mit der Bitte, XML-Tags für die Argumentation aufzulisten, antwortete der Server:

{
  "content": "",
  "reasoning_content": "[3099 Token detaillierter Überlegungen]",
  "finish_reason": "stop"
}

Das Modell leistete umfangreiche Arbeit – 3099 Token Argumentation – blieb jedoch in einer Denkschleife innerhalb von <think> stecken und erzeugte nie eine Ausgabe im content-Feld. Der Server gab finish_reason: "stop" mit leerem Inhalt zurück und meldete Erfolg.

Das bedeutet:

• Jedes Evaluierungsharness, das finish_reason == "stop" prüft, akzeptiert stillschweigend leere Antworten
• Jedes agentische Framework propagiert leere Zeichenketten weiter
• Jeder Benutzer sieht eine leere Antwort und schließt, dass das Modell defekt ist
• Die tatsächliche Argumentation ist in reasoning_content gefangen – das Modell leistete echte Arbeit, die niemand sieht, außer er prüft dieses Feld explizit

Dies ist serverseitig, kein UI-Fehler, bestätigt durch Inspektion der rohen API-Antwort und des LM Studio Server-Logs. Die reasoning_content/content-Trennung erfolgt, bevor die Antwort einen Client erreicht.

Fehlerinteraktion

Dies sind keine unabhängigen Probleme. Sie interagieren, um systemische Probleme mit Tool-Aufrufen und Argumentation in LM Studio zu erzeugen.