DeepSeek V4 Flash coûte 14,9 fois moins cher sur cache chaud, selon un benchmark de 14 fournisseurs

Le benchmark a mesuré un seul dispositif : des cibles de 1 000, 10 000 et 100 000 tokens d'entrée, chacune associée à un budget de 100 ou 1 000 tokens de sortie, température 0 et raisonnement désactivé. Les requêtes froides portaient un préfixe unique, les requêtes chaudes répétaient le même prompt. Le site précise qu'il s'agit de mesures de serving, pas de scores de qualité des tâches.

Dans l'étude, le coût n'est pas le prix affiché du token d'entrée. Il correspond aux frais totaux de la requête divisés par les tokens d'entrée et multipliés par un million, ce qui inclut les frais de sortie. Sur l'échantillon, les requêtes de DeepSeek V4 Flash à 100 000 tokens d'entrée et 100 tokens de sortie coûtent 14,9 fois moins cher à chaud qu'à froid.

Le routage n'est pas stable d'un appel à l'autre

Le benchmark a aussi consigné les noms d'upstreams renvoyés par OpenRouter pour chaque forme de requête. Ces noms changent selon l'état du cache. Pour les appels froids à 1 000 d'entrée et 100 de sortie, la liste était menée par Baidu avec 18 appels, Relace avec 14 et AkashML avec 13. La même forme à chaud était menée par Relace avec 24, CoreWeave avec 16 et DeepSeek avec 11.

À 100 000 d'entrée et un budget de sortie de 100 tokens, les requêtes froides sont allées surtout à Baidu (7), DigitalOcean (3), Relace (3) et Wafer (3). Les requêtes chaudes de même forme sont allées à Relace (14), Together (6) et CoreWeave (5). Les auteurs préviennent que la largeur des segments n'est que la part des appels, que les noms désignent des upstreams déclarés et non des machines vérifiées, et que cette distribution seule n'établit pas pourquoi le routage a changé.

Côté vitesse, Telnyx a mené la vitesse de génération médiane dans les 12 conditions. La latence du premier token dépendait de la forme de la requête, pas d'un vainqueur unique. Le site définit le time to first token comme le temps écoulé entre le début de la requête et le premier delta de contenu ou de raisonnement reçu par le client, temps réseau et file d'attente compris. La vitesse de décodage correspond aux tokens de complétion déclarés divisés par le temps écoulé entre le premier et le dernier delta de sortie. Les réponses non streamées ne produisent aucune mesure de vitesse de décodage.

Le chronométrage ne porte que sur les appels réussis.

Part de cache et taux d'échec

L'étude rapporte la part de cache comme la somme des tokens d'entrée mis en cache divisée par la somme des tokens d'entrée pour les succès ayant déclaré les deux, mesurée sur des prompts répétés de 10 000 avec un budget de sortie de 100 tokens. C'est une part de tokens, pas le pourcentage de requêtes ayant touché un cache, et la séquence chaude inclut sa requête initiale.

Les taux d'échec sont détaillés par cible d'entrée, budget de sortie et état du cache. Les auteurs notent qu'une route peut se comporter différemment quand le même prompt demande une réponse plus longue. Le taux d'échec est le nombre d'appels échoués divisé par les appels mesurés dans cette condition, en comptant les erreurs HTTP, de transport et de réponse. Les comptages exacts et les intervalles descriptifs figurent dans des tableaux sous les graphiques, et les enregistrements bruts sont téléchargeables. Un zéro déclaré signifie qu'aucun échec n'a été observé dans l'échantillon, et le benchmark marque les champs non mesurés comme non rapportés plutôt que comme zéro.

Pour les acheteurs, la lecture pratique est étroite. L'écart entre froid et chaud est assez grand pour que la réutilisation de prompt, et non le seul choix du fournisseur, domine peut-être la facture des charges de travail répétées. Mais les mêmes chiffres montrent qu'un prompt répété peut atterrir sur un upstream différent, ce qui change l'application même d'une remise de cache.