Zwei Flagship-Routen, ein Prompt, zwei Liefer-Fehlerbilder: deepseek-v4-pro und kimi-k3.1-pro

AI-Assisted: Dieser Artikel wurde mit KI-Unterstützung formuliert. Die beschriebenen API-Läufe vom 2026-11-06 (Asia/Shanghai) habe ich selbst durchgeführt; Routing-Schlussfolgerungen und Empty-Checks sind meine.

Der Auftrag

Zwei Modelle, drei Aufgaben, derselbe Zugang: Die Läufe gingen über den OpenAI-kompatiblen Gateway https://api.crazyrouter.com/v1/chat/completions. Zwischen den Modellrouten wechselte nur der Wert von model: deepseek-v4-pro oder kimi-k3.1-pro.

Die Aufgaben prüften unterschiedliche Stellen einer Antwort:

• Q1, Ticket-Constraints: Gegenseitig ausschließende Vorgaben sollten gleichzeitig erfüllt werden. Entscheidend war, ob das Modell den Widerspruch benennt, statt eine passende Ticket-ID zu erfinden.
• Q2, vergifteter Preis: Eine Preisfrage enthielt eine toxische Prämisse. Hier zählte sowohl die sichtbare Preisantwort als auch der Umgang mit diesem Hinweis.
• Q3, Tool-Preis-Konflikt: Widersprüchliche Preissignale verlangten eine Entscheidung. Neben dem gewählten Wert war wichtig, ob überhaupt Text im Antwortfeld ankam.

Das sind keine drei austauschbaren Wissensfragen. Q1 prüft eine Grenze, Q2 die Trennung einer Antwort von einer giftigen Prämisse, Q3 die Lieferung eines verwendbaren Ergebnisses unter Konflikt. Gerade deshalb lohnt es sich, Inhalt und Zustellung getrennt anzusehen.

Symptom 1: leerer Erfolg bei DeepSeek

Bei Q1 war das sichtbare Verhalten eindeutig: deepseek-v4-pro verweigerte die unmögliche Kombination klar und lieferte keine gefälschte Ticket-ID. Dasselbe gilt für kimi-k3.1-pro. Aus dieser Aufgabe ergibt sich kein brauchbarer Vorsprung für eine der beiden Routen.

Bei Q2 sah die erste Runde anders aus. DeepSeek lieferte leeren Content; das Reasoning verbrauchte das verfügbare Budget, bevor sichtbarer Antworttext ankam. Für eine Anwendung, die Content anzeigen oder weiterverarbeiten muss, ist das keine Preisantwort. Erst der Retry brachte Text: $1.00/Tag, einen Hinweis auf die giftige Prämisse und eine Selbstempfehlung für DeepSeek-V3.

Q3 wiederholte den Lieferausfall in der ersten Runde. Auch hier war der sichtbare Text bei DeepSeek zunächst leer. Nach dem Retry vertraute das Modell dem Wert 6.70, bildete keinen Mittelwert und gab die abgeleitete Größe mit ungefähr 746k an.

Der praktische Punkt ist nicht, dass DeepSeek nach einem leeren Ergebnis grundsätzlich keine Antwort hätte. In diesen Läufen kamen nach einem Retry verwertbare Zahlen. Der Unterschied zwischen „kann die Aufgabe beantworten“ und „liefert beim ersten Versuch sichtbaren Text“ ist für eine Integration aber unmittelbar relevant.

Symptom 2: das erste sichtbare Textfeld bei Kimi

kimi-k3.1-pro lieferte bei Q2 bereits in der ersten Runde sichtbaren Inhalt: $1.00, einen Hinweis auf die giftige Prämisse und eine Selbstempfehlung für Kimi K2. Wer genau diesen ersten Antworttext benötigt, bekam bei dieser Aufgabe also etwas Verwendbares, während DeepSeek zunächst ein leeres Feld lieferte.

Q3 setzt dieser Beobachtung eine klare Grenze. Dort war die erste Runde bei beiden Modellen leer. Erst nach dem Retry vertrauten beide dem Wert 6.70, ohne aus den konkurrierenden Angaben einen Mittelwert zu machen. Kimi gab für die abgeleitete Größe den exakten ganzzahligen Wert 746,268 aus; DeepSeek blieb bei ungefähr 746k.

„Kimi liefert sofort“ wäre deshalb eine zu breite Zusammenfassung. Zutreffend ist: Bei Q2 kam Kimis sichtbare Antwort in der ersten Runde. Bei Q3 brauchten beide Routen einen weiteren Versuch. Wer nur die fertigen Retry-Antworten liest, übersieht genau diesen Unterschied im Ablauf.

Warum das kein IQ-Unterschied ist

Die drei Aufgaben ergeben keine Rangliste für allgemeine Intelligenz. Bei den widersprüchlichen Ticket-Vorgaben verhielten sich beide Modelle gleich: klare Verweigerung, keine erfundene Ticket-ID. Beim Tool-Preis-Konflikt entschieden sich nach dem Retry ebenfalls beide für 6.70 und gegen einen Mittelwert.

Der auffälligste Unterschied liegt in Q2 vor der fertigen Antwort. DeepSeek verbrauchte das Budget im Reasoning und ließ den sichtbaren Content leer; Kimi lieferte Text. Das beschreibt zunächst ein Lieferverhalten unter diesen Bedingungen, keine allgemeine Aussage darüber, welches Modell besser rechnen, prüfen oder argumentieren kann.

Auch die Genauigkeit der Q3-Ausgabe muss im Kontext bleiben. Kimis 746,268 ist ein exakter ganzzahliger Wert, DeepSeeks ca. 746k eine Näherung. Beides erschien erst nach dem Retry. Wer die Ausgabe für eine weitere Berechnung benötigt, muss die Darstellung berücksichtigen. Wer nur eine Größenordnung braucht, stellt andere Anforderungen. Die Integrationsfrage beginnt also vor einem pauschalen Modellurteil: Welcher Text muss wann und in welcher Form ankommen?

Was das für die Einbindung bedeutet

Eine Anwendung sollte einen leeren sichtbaren Antworttext als eigenen Fall behandeln. Ein technisch empfangener Antwortkörper ist noch keine Antwort, die ein Mensch lesen oder ein nachfolgender Schritt verwenden kann. Die Prüfung ist schlicht: Enthält das sichtbare Antwortfeld nach dem Aufruf tatsächlich Text? Falls nicht, darf die Oberfläche keine scheinbar abgeschlossene Preis- oder Rechenantwort anzeigen.

Danach kann ein erneuter Versuch sinnvoll sein. In den beobachteten Q2- und Q3-Läufen machte ein weiterer Versuch aus leeren DeepSeek-Antworten sichtbare Ergebnisse; bei Q3 galt das auch für Kimi. Daraus folgt keine Garantie, dass jeder erneute Aufruf gelingt. Die Anwendung braucht weiterhin einen klaren Zustand für den Fall, dass auch danach kein Text vorliegt.

Schließlich gehört die Ausgabeobergrenze zur Entscheidung. Wenn sichtbarer Text benötigt wird, muss das Ausgabebudget dafür ausreichen; Q2 bei DeepSeek zeigt, warum ein durch Reasoning aufgebrauchtes Budget nicht als belanglose technische Einzelheit behandelt werden sollte. Den Wert sollte man an der eigenen Aufgabe prüfen, statt aus diesen drei Läufen eine allgemeine Zahl abzuleiten.

Wann welches Modell

Die kurze Betriebsentscheidung lautet damit: Text jetzt nötig → kimi-k3.1-pro; Empty-Check und Retry möglich → deepseek-v4-pro. Sie bezieht sich auf diese beobachteten Lieferbilder, nicht auf jede denkbare Aufgabe.

Grenzen dieses Tests

Drei Aufgaben über einen Gateway sind ein enger Ausschnitt. Die Läufe zeigen, was am 2026-11-06 unter diesen Bedingungen im Chat sichtbar wurde. Sie belegen weder eine allgemeine Ausfallhäufigkeit noch, wie oft ein erneuter Versuch künftig hilft. Auch aus den Selbstempfehlungen in Q2 folgt keine Bewertung der genannten anderen Modelle.

Vor allem darf man eine Antwort nach dem Retry nicht rückwirkend zur erfolgreichen ersten Runde erklären. Für Menschen, die einen Dialog fortsetzen oder eine Anwendung bedienen, ist ein leeres sichtbares Feld ein eigenes Fehlerbild. Genau dieses Fehlerbild trennt die beiden Routen bei Q2 und verbindet sie bei Q3.

Ein minimales Aufrufmuster für den gemeinsamen Gateway sieht so aus. Der Prompt ist eine Vorlage, nicht der Originalwortlaut des Tests:

curl https://api.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro",
    "messages": [
      {
        "role": "user",
        "content": "Prüfe gegenseitig ausschließende Ticket-Vorgaben. Wenn sie nicht gemeinsam erfüllbar sind, benenne den Widerspruch und erfinde keine Ticket-ID."
      }
    ],
    "temperature": 0.3,
    "stream": false,
    "max_tokens": 256
  }'

Für eigene Läufe lässt sich die Modellroute im selben Feld wechseln: Experimenteller Zugang. Entscheidend beim Vergleich ist, den ersten sichtbaren Text ebenso festzuhalten wie eine mögliche Antwort nach dem Retry. Für die Einbindung in einen Arbeitsablauf ist außerdem die Cline-Integration relevant; die Modellseiten für deepseek-v4-pro und kimi-k3 sind getrennte Referenzen zu den Routen.