vLLM Tool Calling: Parser je Modellfamilie, tool_choice und Strict-Modus in vLLM 0.32

Was vLLM für Tool-Aufrufe braucht

Ein Modell gibt einen Tool-Aufruf als Text in seinem eigenen Format aus: JSON in Tags bei Modellen im Hermes-Stil, Python-ähnliche Aufrufe bei Llama 4, das Harmony-Format bei gpt-oss. Der OpenAI-kompatible Server von vLLM überträgt diesen Text nur dann in das Feld tool_calls der Antwort, wenn Sie ihn mit --enable-auto-tool-choice und dem passenden --tool-call-parser der Modellfamilie starten. Ohne den richtigen Parser landet der Aufruf als Text in content, und das Agenten-Framework sieht keinen Tool-Aufruf.

Parsebare Aufrufe erzwingt vLLM nur mit einem benannten Tool, mit tool_choice: "required" oder im Strict-Modus; im Standardmodus auto wird der Text des Modells so gelesen, wie er kommt.

Alles Folgende stammt aus der Tool-Calling-Dokumentation von vLLM für Release 0.32.0 (Seite vom 8. Oktober 2026) und aus der Entwicklungsdokumentation vom 23. Oktober 2026, gelesen am 24. Oktober 2026, sofern keine andere Quelle genannt ist. vLLM veröffentlicht etwa alle zwei Wochen ein Release, und Parsernamen und Standards ändern sich mit ihnen; prüfen Sie daher die Seite des Releases, das Sie festlegen.

Drei Server-Flags steuern das Verhalten. --enable-auto-tool-choice lässt das Modell selbst entscheiden, wann es ein Tool aufruft; --tool-call-parser nennt den Parser; --chat-template ist optional und verweist auf ein Template, das „handles tool-role messages and assistant-role messages“ mit Tool-Aufrufen, für Checkpoints, deren eigenes Template das nicht tut. Der Schnellstart der Dokumentation betreibt meta-llama/Llama-3.1-8B-Instruct mit --tool-call-parser llama3_json und dem Template tool_chat_template_llama3.1_json.jinja aus den Beispielen von vLLM. Ein viertes Flag, --tool-parser-plugin, registriert einen selbst geschriebenen Parser.

Welcher Parser für welche Modellfamilie

Der Parser richtet sich nach der Modellfamilie, nicht nach der Größe. Die Dokumentation von vLLM nennt etwa dreißig Parser; die Tabelle zeigt die Familien, die Unternehmen am häufigsten auf unseren Servern betreiben, mit den Hinweisen der Dokumentation.

Tool-Calling-Dokumentation von vLLM, Release 0.32.0 (8. Oktober 2026) und Entwicklungsversion (23. Oktober 2026), gelesen am 24. Oktober 2026. Qwen3 aus dem Function-Calling-Leitfaden von Qwen; DeepSeek-V4-Flash, GLM-5.3 und Gemma 4 aus den Rezepten von vLLM sowie qwen3_coder aus der Karte von Qwen3-Coder-Next, wie in unserem Leitfaden zur Wahl eines offenen LLM für einen Unternehmensassistenten und auf unserer Seite zu Servern für Coding-Agenten zitiert.

Drei Einträge brauchen eine Erläuterung. Bei gpt-oss liest der Parser openai das Harmony-Format, auf das die Modelle trainiert sind. Für Qwen3-Coder nennt die Dokumentation qwen3_xml, während die Modellkarten, auch die von Qwen3-Coder-Next, vLLM mit qwen3_coder starten; laut Release Notes von 0.32.0 ist qwen3_xml ein Alias von qwen3_coder (Pull Request 60136), ab diesem Release wählen also beide Namen denselben Parser. Für Llama 3.1 und 3.2 warnt die Dokumentation, „Parallel tool calls are not supported for Llama 3“, und das Modell könne Arrays als Strings serialisieren; ein als Liste typisiertes Argument kommt dann als "[1, 2]" an. Sie warnt außerdem, „Llama's smaller models frequently fail to emit tool calls in the correct format“ mit dem Parser pythonic.

Release 0.32.0 hat einen Parser hf eingeführt, der das Antwort-Template aus der tokenizer_config.json des Checkpoints liest. Laut Entwicklungsdokumentation „cannot be combined with other reasoning or tool call parsers“ er und lehnt Strict-Tools, erzwungene oder benannte Tool-Wahl und parallel_tool_calls=false ab; er taugt eher für einen schnellen Test als für einen Agenten im Betrieb.

Wir bauen GPU-Server und richten offene Modelle mit vLLM darauf ein; senden Sie uns die geplante Modellfamilie und die Tools, die Ihre Agenten aufrufen sollen, und unser Team antwortet mit einer Konfiguration und den Einstellungen für Parser und Template als Ausgangspunkt.

tool_choice: auto, required, benannt und none

Das Feld tool_choice der Anfrage legt fest, ob das Modell ein Tool aufrufen darf, muss oder nicht darf, und damit auch, ob vLLM die Ausgabe einschränkt.

Tool-Calling-Dokumentation von vLLM, Release 0.32.0, gelesen am 24. Oktober 2026; required ab vLLM 0.8.3.

Bei einer benannten Funktion „vLLM will use structured outputs to ensure the response matches the tool parameter object“, und die Dokumentation warnt vor „several seconds of latency (or more)“ beim ersten Aufruf, während die Grammatik kompiliert. Mit required muss das Modell einen oder mehrere Tool-Aufrufe erzeugen, wie viele, hängt von der Anfrage ab. Beides schränkt nur die Syntax ein: Die Dokumentation sagt ausdrücklich, Sie erhalten „a validly-parsable function call - not a high-quality one“. Das Modell kann weiterhin die falsche Funktion wählen oder einen Argumentwert erfinden.

auto ist das, was Agenten-Frameworks senden, und dort liegt die Schwachstelle. In Release 0.32.0 gilt: „the model generates tool calls without any grammar and malformed markup can leak into the response“, sofern keine Strict-Einstellungen greifen. Mit none gehen die Tool-Definitionen standardmäßig trotzdem in den Prompt; --exclude-tools-when-tool-choice-none entfernt sie und spart Prompt-Token bei Aufrufen, die keine Tools brauchen.

Strict-Modus: strict: true und --tool-strict-level

Der Strict-Modus bringt eingeschränkte Dekodierung in den Modus auto. Es gibt zwei Schalter, einen je Tool in der Anfrage und einen für den ganzen Server.

Je Tool. Eine Tool-Definition mit strict: true legt das Argumentschema dieses Tools fest; die Dokumentation betont, „a tool that omits strict keeps its arguments unconstrained“, auch wenn ein anderes Tool derselben Anfrage strikt ist. Sie empfiehlt den Strict-Schema-Stil von OpenAI: additionalProperties: false, jedes Feld als erforderlich gelistet, optionale Felder als nullable typisiert. Dieselbe Seite vermerkt: „Most OpenAI-compatible clients and agent frameworks never set strict on their tools“; prüfen Sie also, was Ihr Framework sendet, bevor Sie sich darauf verlassen.

Je Server. --tool-strict-level kennt drei Werte. auto, der Server-Standard in 0.32.0, folgt der Tool-Wahl der Anfrage und dem strict-Flag jedes Tools. function soll „Constrain the tool-call envelope (markup and the function name) for every request with tools“. parameter soll „Additionally pin argument schemas for every tool, as if every tool had strict: true.“ Die Umgebungsvariable VLLM_ENFORCE_STRICT_TOOL_CALLING steht standardmäßig auf true; auf false gesetzt, schaltet sie diese Einschränkungen unabhängig von strict ab.

Die Entwicklungsdokumentation vom 23. Oktober 2026 ergänzt Standards je Parser: Ist die Option nicht gesetzt, „the tool parser's default level applies: function for glm47, auto for the other parsers“, und --tool-strict-level auto hebt das auf. Die Seite zu 0.32.0 nennt keinen solchen Parser-Standard; rechnen Sie also mit einem späteren Release und prüfen Sie die Dokumentation der Version, die Sie betreiben.

Welche Stufe passt, hängt von den Tools ab. function verhindert fehlerhaftes Markup und erfundene Funktionsnamen, ohne das Modell stark einzuschränken. parameter zwingt zusätzlich jedes Argument in sein Schema und passt zu internen APIs mit festen Schemata. Testen Sie beide Stufen an einer Stichprobe echter Agentenaufgaben und zählen Sie falsche Tool-Wahl, falsche Argumente und als Text gelieferte Aufrufe.

Reasoning-Modelle und Tool-Aufrufe

Modelle, die vor der Antwort nachdenken, etwa Qwen3 im Thinking-Modus oder DeepSeek-R1, brauchen neben dem Tool-Parser einen Reasoning-Parser, gesetzt mit --reasoning-parser. Die Reasoning-Dokumentation von vLLM für 0.32.0 (vom 1. Oktober 2026) nennt Namen wie deepseek_r1, qwen3, glm45, gemma4 und step3p5 und hält fest: „tool calling only parses functions from the content field, not from the reasoning“. Einen Aufruf, den das Modell noch während des Nachdenkens schreibt, führt vLLM also nicht als Tool-Aufruf aus. Die Entwicklungsdokumentation zeigt ein kombiniertes Beispiel für MiMo-Modelle: --tool-call-parser mimo, --reasoning-parser mimo und --enable-auto-tool-choice mit dem Chat-Template des Checkpoints.

Eingeschränkte Dekodierung und Reasoning beeinflussen sich. Laut Reasoning-Seite prüft die Structured-Output-Engine über das Token am Ende des Reasonings, ob Reasoning vorliegt, und die Seite zu Structured Outputs warnt, dass bei Qwen3 Coder mit Reasoning „structured outputs might become disabled if the reasoning content does not get parsed“; Abhilfe ist die Option enable_in_reasoning von --structured-outputs-config. Scheitern strikte Aufrufe nur bei eingeschaltetem Thinking, prüfen Sie zuerst den Reasoning-Parser.

Structured Outputs ohne Tools

Viele „Tool“-Anwendungen sind Extraktionsaufgaben: ein Ticket hinein, ein JSON-Objekt mit Kategorie und Priorität heraus. Dafür braucht es keinen Tool-Parser. Die Structured Outputs von vLLM, mit den Backends xgrammar oder guidance, die je Anfrage automatisch gewählt werden, schränken eine Antwort auf ein JSON-Schema ein, über response_format mit json_schema oder über das Feld structured_outputs mit json, regex, choice, grammar oder structural_tag. Die älteren Felder guided_json wurden in vLLM 0.12.0 entfernt. Für ein festes Ausgabeformat ist das einfacher und verlässlicher als ein auto-Aufruf mit einem einzigen Tool, und es funktioniert mit jedem Modell, auch einem ohne Tool-Parser.

Wenn Tool-Aufrufe als Text ankommen

Aus der Dokumentation ergeben sich fünf Ursachen, und jede lässt sich am Server prüfen.

1. Keine automatische Tool-Wahl. Ohne --enable-auto-tool-choice können auto-Anfragen keine Tool-Aufrufe liefern. Prüfen Sie die Kommandozeile oder die Container-Definition, mit der der Server gestartet wurde.
2. Falscher Parser. Ein Parser hermes an einem Modell, das Aufrufe im Python-Stil schreibt, findet nichts zum Parsen, und der Aufruf bleibt in content. Wählen Sie den Parser nach der Familie in der Tabelle oben oder nach der Modellkarte; Release 0.32.0 prüft außerdem beim Start, ob der Tool-Parser passt (Pull Request 59749), lesen Sie also das Start-Log.
3. Falsches oder fehlendes Chat-Template. Llama 3.1 und einige andere Familien brauchen das in der Dokumentation von vLLM genannte Template, das Nachrichten mit den Rollen tool und assistant für das Modell formatiert. Mistral-Checkpoints über das Transformers-Backend brauchen das mitgelieferte Template, weil der Standard „requires 9-digit tool call IDs“.
4. Reasoning nicht getrennt. Ein Modell im Thinking-Modus ohne --reasoning-parser mischt Reasoning und Aufrufe in content, und der Tool-Parser kann an dieser Mischung scheitern.
5. Uneingeschränktes auto. Fehlerhafte Argumente im Modus auto sind ohne Strict-Einstellungen erwartetes Verhalten. Setzen Sie strict: true an den Tools oder erhöhen Sie --tool-strict-level.

Tool-Aufrufe kosten auch Kapazität. Jeder Agentenschritt sendet die Tool-Definitionen mit dem Gesprächsverlauf erneut, eine lange Tool-Liste verlängert also jeden Prompt; unsere Leitfäden zur GPU-Dimensionierung für KI-Agenten und zu Servern für LLM-Agenten mit langem Kontext übersetzen das in GPU-Speicher und Prefill-Zeit. Für ein Workflow-Tool an vLLM behandelt unser Artikel zu KI-Agenten mit n8n und privatem LLM die Client-Seite und unser Artikel zur Sicherheit von MCP die Tool-Server dahinter.

Parser, Versionen und Sicherheit

Ein Tool-Parser liest Text, den das Modell erzeugt hat, und ein Modell lässt sich über seine Eingabe lenken. Advisory GHSA-79j6-g2m3-jgfw (CVE-2025-9141, eingestuft als High, 8,8, veröffentlicht am 20. August 2025) beschrieb Remote Code Execution im Parser qwen3_coder: Bei Parametern ohne oder mit unbekanntem Typ rief der Parser Pythons eval() auf das Argument auf, sodass ein angemeldeter Nutzer, der das Modell Code als Argument übergeben ließ, diesen auf dem Server ausführen konnte. Betroffen war vLLM ab 0.10.0 bis vor 0.10.1.1, das den Fehler behob, und nur Server mit --enable-auto-tool-choice und diesem Parser. Unsere Seite zu Sicherheitslücken in vLLM und der richtigen Version ordnet die Advisories von 2026 danach, wie ein Endpunkt erreichbar ist.

Die Tool-Aufrufe selbst sind ein zweites Risiko. vLLM formatiert den Aufruf nur; Ihre Anwendung führt ihn aus, mit allen Rechten, die sie hat. Geben Sie Agenten nach Möglichkeit nur lesende Tools, prüfen Sie Argumente vor der Ausführung erneut und lassen Sie Aufrufe, die Daten ändern, von einer Person freigeben, wie unser Artikel zu Prompt Injection erklärt. Unser Service Private AI/ML mit Engineering durch unseren Partner Vixen.UNO richtet offene Modelle mit vLLM ein und verbindet sie mit Unternehmenssystemen; beschreiben Sie den Ablauf, den Ihre Agenten übernehmen sollen, und wir schlagen Modell, Parser-Einstellungen und Server vor.

FAQ