vLLM und Tool Calls: Warum jeder zwölfte Aufruf scheitert und wie Constrained Decoding das behebt

Das Problem

Wer offene Modelle selbst hostet, sieht oft schlechtere Ergebnisse als die Benchmarks versprechen. Ubicloud hat eine Ursache gefunden: ungenaue Tool Calls. Beim Betrieb von Kimi K2.6 mit vLLM 0.28 entsprach nur 92 % der Aufrufe dem erwarteten Schema, also scheiterten rund 2 von 25. In Agenten-Sitzungen mit vielen Runden verschmutzen Fehlermeldungen und Wiederholungen den Kontext, die Qualität sinkt und die Kosten steigen.

Warum Modelle danebenliegen

Ein Sprachmodell zieht Token nach Wahrscheinlichkeit und prüft keinen Typ. Dazu kommt: Modelle sind auf vielen Tool-Datensätzen trainiert und erfinden gern Namen, die sie kennen, etwa search_web statt web_search oder city_name statt location. Moonshot AI bietet dafür den Benchmark K2VV ToolCall (2000 Anfragen), der Trigger-Ähnlichkeit und Schema-Genauigkeit misst.

Die Lösung: Constrained Decoding

Die Inferenz-Engine lässt in jedem Schritt nur Token zu, die zum Tool-Schema passen. vLLM nutzt dafür Structural Tags der XGrammar-Bibliothek. Der Pfad ist fest: Tool-Call-Beginn, Name, Index, Argumente (schema-beschränktes JSON), Ende. Der Mehraufwand ist laut Ubicloud vernachlässigbar, weil die Token-Masken vorab berechnet werden.

Fallstrick: Standard ausgeschaltet

Nach dem Wechsel auf die vLLM-Version mit Upstream-Unterstützung (ab 0.25) fiel die Genauigkeit wieder auf 91 %. vLLM hatte das Verhalten als Standard deaktiviert, weil es bei manchen Modellen Probleme macht (gpt-oss-20b, Qwen 3.6, GLM 5.1), Grammatik-Übersetzungsfehler auftreten und die Kombination mit Speculative Decoding Fehler auslösen kann. Aktivieren lässt es sich über das Server-Flag --tool-strict-level (ab vLLM 0.31).

Ergebnis

Mit aktiviertem Constrained Decoding erreichte Ubicloud bei Kimi K2.6 und DeepSeek V4 Flash 100 % Schema-Genauigkeit. Die Lehre: Die Qualität, die man sieht, hängt nicht nur vom Modell ab, sondern auch von Engine und Einstellungen.