Llama-server Responses API meldet abgeschnittene Ausgaben fälschlich als abgeschlossen

Ein wesentlicher Kompatibilitätsfehler wurde im OpenAI-kompatiblen /v1/responses-Endpunkt von llama-server identifiziert, der den Einsatz selbst gehosteter großer Sprachmodelle betrifft. Stand 20. Oktober 2026 besteht das Problem im llama.cpp-Build b11753 weiterhin: Der Server meldet gekürzte Antworten und unvollständige Tool-Aufrufe fälschlicherweise als erfolgreich abgeschlossen. Diese Diskrepanz stellt ein Risiko für Entwickler dar, die autonome Agenten erstellen, welche auf präzise Statusmeldungen angewiesen sind, um nachgelagerte Aufgaben auszuführen.

Was passiert ist

Das Kernproblem liegt darin, wie llama-server interne Generierungszustände in das Format der Responses API übersetzt. Wenn eine Anfrage das durch max_output_tokens definierte Token-Limit erreicht, erkennt die zugrunde liegende Chat-Completion-Engine den Stop-Grund korrekt als "length" (Länge). Bei der Konvertierung dieses Ergebnisses in ein Responses-API-Objekt setzt der Server jedoch das Statusfeld unabhängig davon, ob die Ausgabe vollständig war oder abgeschnitten wurde, fest auf "completed" (abgeschlossen). Dieses Verhalten betrifft sowohl die Standard-Textgenerierung als auch Szenarien mit Funktionsaufrufen (Function Calling).

In Tests mit Modellen wie Gemma-3-1b-it und Qwen3-0.6B lieferten Anfragen, die auf acht Tokens begrenzt waren, einen Status "completed" mit null unvollständigen Details zurück, obwohl der Text mitten im Satz endete. Noch kritischer: Durch Token-Limits abgeschnittene Tool-Aufrufe gaben ungültige JSON-Argumente zurück – etwa {"path": "/ –, wurden aber dennoch als abgeschlossene Elemente markiert. Clients, die diesem Statusflag vertrauen, könnten versuchen, fehlerhaftes JSON zu parsen oder teilweise ausgeführte Befehle zu starten, was zu stillen Fehlern oder unerwarteten Problemen in Produktionsumgebungen führt.

Wichtige Details

• Der Fehler betrifft den llama.cpp-Build b11753 und wirkt sich spezifisch auf den /v1/responses-Endpunkt aus, während /v1/chat/completions korrekt finish_reason: "length" meldet.
• Abgeschnittene Argumente für Tool-Aufrufe werden als gültige function_call-Elemente mit dem Status "completed" zurückgegeben, obwohl sie fehlerhaftes JSON enthalten, das nicht geparst werden kann.
• Streaming-Antworten senden ebenfalls kein response.incomplete-Ereignis, sondern enden mit response.completed und lassen das erwartete Signal function_call_arguments.done aus.
• Der einzige zuverlässige Indikator für eine Kürzung in der Responses API ist die Prüfung, ob usage.output_tokens gleich dem angeforderten max_output_tokens ist, wobei dies eher eine Heuristik als ein definitiver Status ist.
• Der Quellcode in tools/server/server-task.cpp enthält sieben Stellen, an denen der Status fest auf "completed" gesetzt wird, ohne Logik zum Auslesen des zugrunde liegenden Stop-Grunds oder zum Setzen des Status auf "incomplete".
• Bis zum 20. Oktober 2026 war kein Upstream-Fix oder Pull Request für das Issue ggml-org/llama.cpp#30773 zusammengeführt worden.

Hintergrund

Die Responses API ist eine neuere Spezifikation, die für agentenähnliche Interaktionen entwickelt wurde und es Modellen ermöglicht, strukturierte Ausgaben einschließlich Reasoning-Schritten und Tool-Aufrufen zurückzugeben. Llama-server implementiert dies, indem eingehende Responses-Anfragen intern in standardmäßige Chat Completions-Anfragen konvertiert werden. Während der Generierungsprozess korrekt funktioniert, scheitert die Übersetzungsschicht daran, den finish_reason der Chat Completion auf die Felder status und incomplete_details der Responses API abzubilden. Diese einseitige Konvertierung verwirft kritische Fehlersignale, sodass Clients nicht wissen, dass das Modell seinen Gedanken oder Befehl nicht zu Ende geführt hat.

Für Entwickler verdeutlicht dies eine häufige Falle bei Kompatibilitätsschichten: Die Sicherstellung, dass Fehlerzustände und Randbedingungen über API-Übersetzungen hinweg erhalten bleiben. Ein Statusfeld ist nur dann nützlich, wenn es negative Ergebnisse genau widerspiegeln kann. In diesem Fall priorisiert der Server die Rückgabe von Inhalten gegenüber der Kommunikation der Vollständigkeit und geht davon aus, dass die meisten Antworten innerhalb der Limits liegen. Diese Annahme bricht bei komplexen Aufgaben zusammen, die lange Kontexte oder präzise Tool-Ausführungen erfordern.

Warum das wichtig ist

Für Teams, die selbst gehostete KI-Agenten betreiben, führt dieser Bug zu einer subtilen, aber gefährlichen Zuverlässigkeitslücke. Autonome Systeme verlassen sich oft auf das status-Feld, um zu entscheiden, ob sie eine Aufgabe fortsetzen sollen. Wenn ein Agent einen "completed"-Status für einen abgeschnittenen Dateipfad oder Code-Snippet erhält, könnte er versuchen, einen Teilbefehl auszuführen. Dies kann zu Datenkorruption, fehlgeschlagenen Deployments oder Sicherheitslücken führen, wenn die teilweise Eingabe von nachgelagerten Systemen falsch interpretiert wird. Das Risiko ist am höchsten bei kleinen Modellen oder komplexen Prompts, bei denen Token-Limits häufig erreicht werden.

Darüber hinaus erschwert dieses Problem das Debugging. Da der Server keinen Fehler meldet, können Logs erfolgreiche Abschlüsse anzeigen, selbst wenn die Ausgabe unbrauchbar ist. Entwickler könnten den Fehler fälschlicherweise den Reasoning-Fähigkeiten des Modells oder dessen JSON-Formatierungsfähigkeiten zuschreiben, statt die infrastrukturelle Kürzung zu identifizieren. Diese Irreführung verschwendet Engineering-Zeit und kann zu unnötigem Modellwechsel oder Prompt-Engineering-Tweaks führen, die die Ursache nicht beheben.

Was Sie tun können

• Implementieren Sie clientseitige Validierungen, um jede Antwort, bei der usage.output_tokens gleich max_output_tokens ist, als potenziell abgeschnitten zu behandeln und die Integrität der Ausgabe vor der Verwendung zu überprüfen.
• Validieren Sie alle Argumente für Tool-Aufrufe streng als JSON vor der Ausführung; lehnen Sie jedes function_call-Element ab, das beim Parsen fehlschlägt, unabhängig vom gemeldeten Status.
• Bevorzugen Sie die Nutzung des /v1/chat/completions-Endpunkts für kritische Aufgaben, wenn Ihre Anwendungsarchitektur dies zulässt, da er für abgeschnittene Ausgaben korrekt finish_reason: "length" meldet.
• Erhöhen Sie die Limits für max_output_tokens in Agent-Workflows, um die Häufigkeit von Kürzungen zu reduzieren und sicherzustellen, dass das Modell ausreichend Platz hat, um komplexe Reasonings oder Tool-Definitionen abzuschließen.
• Führen Sie diagnostische Skripte wie check-llama-responses-status.sh gegen Ihre Deployment-Umgebung aus, um zu bestätigen, ob Ihre spezifische Version und Konfiguration von diesem hartcodierten Statusverhalten betroffen ist.
• Überwachen Sie Upstream-Repositories auf Patches für das llama.cpp-Issue #30773 und erwägen Sie, einen Fix beizusteuern, der den Stop-Grund der Chat Completion auf das Statusfeld der Responses API abbildet, falls Sie die Kapazität dazu haben.