DeepSeek V4 Flash kostet mit warmem Cache 14,9-mal weniger, Benchmark über 14 Anbieter

Der Benchmark misst einen einzigen, kontrollierten Aufbau: Eingabeziele von 1.000, 10.000 und 100.000 Token, jeweils mit einem Budget von 100 oder 1.000 Ausgabe-Token, Temperatur 0 und abgeschaltetem Reasoning. Kalte Anfragen trugen einen eindeutigen Prefix, warme Anfragen wiederholten denselben Prompt. Die Seite stellt ausdrücklich klar: Das sind Serving-Messungen, keine Werte zur Aufgabenqualität.

Die Kosten in der Studie sind nicht der gelistete Preis pro Eingabe-Token. Sie ergeben sich aus den gesamten Anfragekosten geteilt durch die Eingabe-Token, multipliziert mit einer Million. Die Ausgabekosten sind also eingerechnet. Über die Stichprobe hinweg kosteten Anfragen von DeepSeek V4 Flash mit 100.000 Eingabe-Token und einem Ausgabebudget von 100 Token warm 14,9-mal weniger als kalt.

Das Routing ist zwischen Aufrufen nicht stabil

Der Benchmark protokollierte außerdem, welche Upstream-Namen OpenRouter für jede Anfrageform zurückgab. Diese Namen verschieben sich mit der Cache-Bedingung. Bei kalten Aufrufen mit 1.000 Eingabe- und 100 Ausgabe-Token führte Baidu die Liste mit 18 Aufrufen an, Relace mit 14 und AkashML mit 13. Dieselbe Form warm führte Relace mit 24 an, CoreWeave mit 16 und DeepSeek mit 11.

Bei 100.000 Eingabe-Token und einem Ausgabebudget von 100 Token gingen kalte Anfragen überwiegend an Baidu (7), DigitalOcean (3), Relace (3) und Wafer (3). Warme Anfragen derselben Form gingen an Relace (14), Together (6) und CoreWeave (5). Die Autoren warnen: Die Segmentbreite ist nur der Anteil der Aufrufe, die Namen sind gemeldete Upstreams und keine verifizierten Maschinen. Diese Verteilung allein belegt nicht, warum sich das Routing geändert hat.

Bei der Geschwindigkeit führte Telnyx die mittlere Generierungsgeschwindigkeit in allen 12 Bedingungen an. Die Latenz bis zum ersten Token hing von der Anfrageform ab, nicht von einem einzelnen Sieger. Die Seite definiert die Zeit bis zum ersten Token als Lauf vom Start der Anfrage bis zum ersten Inhalts- oder Reasoning-Delta, das der Client erhält, inklusive Netzwerk- und Wartezeit. Die Dekodiergeschwindigkeit ist gemeldete Completion-Token geteilt durch die verstrichene Zeit vom ersten bis zum letzten Ausgabe-Delta. Nicht gestreamte Antworten erzeugen keine Messung der Dekodiergeschwindigkeit.

Die Zeitmessung umfasst nur erfolgreiche Aufrufe.

Cache-Anteil und Fehlerraten

Den Cache-Anteil gibt die Studie an als Summe der gecachten Eingabe-Token geteilt durch die Summe der Eingabe-Token, und zwar für erfolgreiche Fälle, die beides meldeten. Gemessen wurde das an wiederholten 10.000-Prompts mit einem Ausgabebudget von 100 Token. Das ist ein Token-Anteil, nicht der Prozentsatz der Anfragen, die einen Cache trafen. Die warme Sequenz enthält ihre erste Anfrage.

Die Fehlerraten sind nach Eingabeziel, Ausgabebudget und Cache-Bedingung aufgeschlüsselt. Die Autoren merken an, dass eine Route anders reagieren kann, wenn derselbe Prompt eine längere Antwort verlangt. Die Fehlerrate ist fehlgeschlagene Aufrufe geteilt durch gemessene Aufrufe in dieser Bedingung; gezählt werden HTTP-, Transport- und Antwortfehler. Genaue Zahlen und beschreibende Intervalle stehen in Tabellen unter den Diagrammen, die Rohdaten sind herunterladbar. Eine angegebene Null bedeutet, dass in der Stichprobe kein Fehler beobachtet wurde. Nicht gemessene Felder markiert der Benchmark als nicht berichtet, nicht als Null.

Für Käufer ist die praktische Lesart eng. Der Abstand zwischen kalt und warm ist groß genug, dass bei wiederholten Workloads die Wiederverwendung von Prompts die Rechnung bestimmen dürfte, nicht allein die Wahl des Anbieters. Dieselben Zahlen zeigen aber, dass ein wiederholter Prompt bei einem anderen Upstream landen kann. Damit steht infrage, ob überhaupt ein Cache-Rabatt greift.