DeepSeek V4.1 Flash Tool Calling hält Einzug in vLLM: Was die Tags mit Leerzeichen kaputt gemacht haben

DeepSeek V4.1 Flash ist seit dem 10. September 2026 allgemein verfügbar, und in den ersten zwölf Tagen seines Bestehens hatte das Modell eine Lücke, über die niemand schrieb: Es konnte Schlussfolgerungen ziehen, es konnte Bilder sehen, es konnte eine Million Tokens Kontext halten, und es konnte nicht zuverlässig ein Tool über den am weitesten verbreiteten offenen Serving-Stack aufrufen. Diese Lücke ist nun in vLLM geschlossen – nicht mit einem Konfigurations-Flag, sondern mit einer Parser-Neufassung. Zwei Pull Requests tragen die Arbeit, und der Grund, warum sie nötig waren, ist der interessante Teil.

Die Kurzfassung: DeepSeek V4.1 Flash gibt seine Tool-Aufrufe in einem Tag-Format aus, das der vorhandene DeepSeek V4 Detector nicht erkennt, sodass bei einer Standard-vLLM-Bereitstellung das Tool-Call-Markup als gewöhnlicher Text statt als strukturierte Ausgabe ankommt. Nichts schlägt fehl. Das Modell wirkt, als hätte es einfach abgelehnt, die Funktion aufzurufen. Wenn Sie Agent-Schleifen gegen ein selbst gehostetes DeepSeek V4.1 Flash getestet und daraus geschlossen haben, dass das Modell schlecht mit Tools umgehen kann, dann ist es sehr wahrscheinlich genau das, was Sie sich angesehen haben.

Was sich im Serving-Stack tatsächlich geändert hat

Das Tool-Call-Parsing von vLLM für DeepSeek-Modelle lag eine Zeit lang an zwei Stellen: ein Python-Frontend und ein neueres Rust-Frontend, wobei die Arbeit auf Grammatikebene an das XGrammar-Projekt delegiert wurde. Die Unterstützung für V4.1 Flash herüberzubringen bedeutete, die C++-deepseek_xml-Konvertierung innerhalb von XGrammar in den Rust-Builder zu portieren und dann die eigene Kodierung des Modells in das Tokenizer-Verzeichnis von vLLM einzubinden.

• Die Arbeit am Rust-Frontend ist PR #56235, der die XGrammar-C++-deepseek_xml-Konvertierung in den Rust-Builder portiert. Sie liefert 18 neue Tests speziell für V4.1, und die vollständigen bestehenden Suites – 472 Tests in vllm-parser und 326 in vllm-chat – bleiben grün.

• Die Arbeit am Python-Frontend ist PR #56408, die sich noch im Entwurfsstadium befindet. Sie hängt davon ab, dass zuerst eine vorgelagerte XGrammar-Änderung (mlc-ai/xgrammar#885) einfließt, und meldet 110 bestandene Tests, wenn diese Abhängigkeit angewendet wird.

• Das neue Encoding-Modul ist vllm/tokenizers/deepseek_v41_encoding.py – eine separate Datei statt eines Branches innerhalb des V4-Encodings, was zeigt, dass die Tag-Grammatik sich tatsächlich unterscheidet und nicht bloß erweitert wird.

• Der Aufruf ist explizit: --tool-parser deepseek_v41. Es gibt keinen Auto-Erkennungs-Fallback, der unauffällig das Richtige tut.

Die mit Leerzeichen versehenen Tags sind die ganze Geschichte.

Der Grund dafür, dass es einen neuen Parser gibt statt eines erweiterten regulären Ausdrucks, ist der Leerraum. DeepSeek V4.1 Flash schreibt seine DSML-Tool-Tags mit Leerzeichen zwischen den Tokens. Das Muster des V4-Detektors erwartet die Form ohne Leerzeichen, sodass keine Übereinstimmung gefunden wird, und eine fehlgeschlagene Übereinstimmung ist in einem Tool-Call-Parser konstruktionsbedingt still – der Text wird als Inhalt durchgereicht, statt einen Fehler auszulösen.

Dieser Fehlermodus verdient es, eingehender betrachtet zu werden, denn er ist die kostspieligste Art. Ein Parser, der eine Exception auslöst, ist an einem Nachmittag behoben. Ein Parser, der eine wohlgeformte Zeichenkette zurückgibt, die Markup enthält, nach dem der Aufrufer nie gefragt hat, wirkt wie ein Problem mit der Modellqualität, und Teams reagieren darauf, wie man auf ein Problem mit der Modellqualität reagieren würde: Sie probieren andere Prompts aus, fügen Beispiele hinzu, wechseln das Modell. Zwölf Tage sind lang genug, dass eine Menge davon im Stillen passiert sein kann.

Es bedeutet außerdem, dass die Behebung kein Tuning-Parameter ist. Sie können sich nicht aus einem Detektor herausprompten, der nicht zum Ausgabeformat Ihres Modells passt, und Sie können es nicht im Client durch Nachbearbeitung beheben, denn wenn der Text Ihren Client erreicht, ist die Struktur bereits verloren. Es muss im Serving-Stack geschehen, und genau dort ist es jetzt auch.

Warum dies für V4.1 Flash wichtiger ist als für V4

Tool-Aufrufe sind für dieses spezielle Modell kein Nice-to-have. DeepSeek V4.1 Flash ist ein Mixture-of-Experts-Modell mit 552 Milliarden Parametern, bei dem 8 Milliarden Parameter bei der Eingabe und 16 Milliarden bei der Ausgabe aktiv sind, mit einem Kontextfenster von 1 Mio. Token und einer maximalen Ausgabe von 384K Token. Die Aufteilung der aktiven Parameter ist der entscheidende Hinweis: Das Modell ist darauf ausgelegt, eine große Eingabe – ein Repository, eine Dokumentensammlung, einen langen Tool-Trace – aufzunehmen und eine lange, strukturierte Antwort auszugeben. Das ist die Form eines Agenten, nicht die eines Chats.

Der Rest der Launch-Spezifikation weist in dieselbe Richtung. MIT-lizenzierte Gewichte, 890 Bytes KV-Cache pro Token, 45 Billionen Pretraining-Tokens, native Vision. Die KV-Cache-Zahl ist diejenige, die bei 1M Kontext operativ zählt: Sie macht ein langes Agenten-Transkript bezahlbar, wenn es resident bleiben soll, und sie ist der Grund, warum das Modell als billiger Arbeiter in einer Schleife plausibel ist, die ein teureres Modell überwacht.

Was die zwölftägige Tool-Calling-Lücke zu einem echten Kostenfaktor statt zu einer Fußnote macht. Ein Modell, dessen wirtschaftliche Rechtfertigung darauf beruht, der Hochvolumen-Ausführende in einer Agenten-Pipeline zu sein, ist wenig wert, wenn die Pipeline aus ihm keinen strukturierten Aufruf herausholen kann.

Was ist noch offen?

Der ehrliche Stand der Dinge, Stand 22. September 2026:

• Der Rust-Frontend-Pfad (PR #56235) ist derjenige mit vollständiger Testabdeckung sowohl für die neuen V4.1-Fälle als auch für die bereits vorhandenen Test-Suites. Wenn Sie einen vLLM-Build verwenden, der ihn enthält, steht Ihnen der Parser heute zur Verfügung.

• Der Python-Frontend-Pfad (PR #56408) ist ein Entwurf und hat eine externe Abhängigkeit. Wenn Sie an einen Build gebunden sind, der älter als die XGrammar-Änderung ist, bietet das Python-Frontend Ihnen noch kein V4.1-Tool-Parsing.

• Weil der Aufruf explizit erfolgt, behält ein Deployment, das vLLM aktualisiert, aber seine Start-Flags nicht ändert, das alte Verhalten bei. Dass der Parser existiert und dass der Parser verwendet wird, sind zwei verschiedene Dinge.

• Es gibt noch keine öffentlichen Belege für einen unabhängigen Tool-Calling-Benchmark, der gegen V4.1 Flash mit dem neuen Parser durchgeführt wurde. Was wir wissen, ist, dass die technische Infrastruktur funktioniert und die Tests bestehen. Ob die Tool-Calling-Qualität des Modells gut ist, ist eine separate Frage, die der Merge nicht beantwortet.

An diesem letzten Punkt sollte man festhalten. Eine Parser-Korrektur verschiebt das Modell von „kann nicht bewertet werden“ zu „kann bewertet werden“. Sie ist eine Voraussetzung für ein Urteil, nicht das Urteil.

Wenn Sie den Serving-Stack nicht selbst betreiben möchten

Es gibt einen kürzeren Weg. DeepSeek V4.1 Flash ist über den dafür vorgesehenen Endpoint von OrcaRouter verfügbar, was bedeutet, dass das Tool-Calling-Verhalten als normaler API-Aufruf ankommt statt als Build-Problem – keine XGrammar-Version, die abgeglichen werden muss, kein Frontend, das ausgewählt werden muss, kein Launch-Flag, an das man sich erinnern muss. Der Grund, warum das hier konkret wichtig ist: Der Fix ist an zwei Stellen mit unterschiedlicher Reife gelandet, und ein gehosteter Endpoint macht diese Entscheidung hinfällig.

Derselbe Schlüssel erreicht auch die übrigen Modelle, die Sie zum Vergleich heranziehen würden, was die nützliche Eigenschaft ist, wenn die Frage nicht lautet „ist dieser Parser korrekt“, sondern „ist dieses Modell gut genug für meine Schleife“. Sie können DeepSeek V4.1 Flash als günstigen Executor hinter eine Routing-Regel setzen und es bei einem fehlgeschlagenen Aufruf auf ein stärkeres Modell umleiten, ohne einen zweiten Vertrag oder ein zweites SDK. Ein Modell auszuprobieren, dessen Tool-Calling-Unterstützung zwei Wochen alt ist, ist genau die Situation, für die automatisches Failover existiert.

Was als Nächstes ansehen

Drei Dinge würden daraus statt einer Klempnergeschichte ein Urteil machen:

• PR #56408 verlässt den Entwurfsstatus, was den Python-Frontend-Pfad real machen und die Zwei-Klassen-Support-Situation beenden würde.

• Eine unabhängige Agenten- oder Tool-Calling-Evaluierung gegen V4.1 Flash auf einem festen Serving-Stack. Das Modell ist seit zwölf Tagen verfügbar, und der Parser ist seit weniger als dieser Zeit nutzbar. Daher sollte man jede Tool-Calling-Wertung, die man derzeit für es zitiert sieht, hinterfragen — das Setup zählt genauso viel wie das Modell.

• Ob andere Serving-Stacks folgen. vLLM ist derjenige mit öffentlichen PRs; das Problem der Tags mit Leerzeichen ist nicht vLLM-spezifisch, daher trägt jeder Stack, der den V4-Detektor übernommen hat, ohne ihn aus der V4.1-Ausgabe neu herzuleiten, denselben stillen Fehler in sich.

Bis das erste davon eintrifft, ist die zutreffende Zusammenfassung eng gefasst und es wert, klar ausgesprochen zu werden: DeepSeek V4.1 Flash ist ein GA-Modell mit Gewichten unter MIT-Lizenz, einem Kontext von 1 Mio. Token und einer Ausgabengrenze von 384K, und sein Tool-Calling funktioniert jetzt auf dem Rust-Pfad in vLLM mit einem expliziten Parser-Flag. Das ist ein echter Schritt und noch kein Ergebnis.