DeepSeek V4 Flash kosztuje 14,9 razy mniej przy ciepłym cache. Benchmark 14 dostawców

Benchmark objął jeden kontrolowany układ: cele 1 000, 10 000 i 100 000 tokenów wejściowych, każdy w parze z budżetem 100 lub 1 000 tokenów wyjściowych, temperatura 0 i wyłączone rozumowanie. Zimne zapytania miały unikalny prefiks, ciepłe powtarzały ten sam prompt. Serwis wyraźnie zaznacza, że to pomiary serwowania, a nie oceny jakości wykonania zadania.

Koszt w badaniu to nie cena tokenu wejściowego z cennika. To całkowite opłaty za zapytanie podzielone przez tokeny wejściowe i pomnożone przez milion, więc opłaty za wyjście też są wliczone. W całej próbie zapytania DeepSeek V4 Flash z 100 000 tokenów wejściowych i budżetem 100 tokenów wyjściowych kosztowały 14,9 razy mniej ciepłe niż zimne.

Routing nie jest stabilny między wywołaniami

Benchmark zapisał też, jakie nazwy upstreamów zwracał OpenRouter dla każdego kształtu zapytania. Te nazwy zmieniają się wraz ze stanem cache. W zimnych wywołaniach z 1 000 tokenów wejścia i 100 wyjścia listę otwierał Baidu z 18 wywołaniami, Relace z 14 i AkashML z 13. Ten sam kształt na ciepło otwierał Relace z 24, CoreWeave z 16 i DeepSeek z 11.

Przy 100 000 wejścia i budżecie 100 tokenów wyjściowych zimne zapytania trafiały głównie do Baidu (7), DigitalOcean (3), Relace (3) i Wafer (3). Ciepłe zapytania o tym samym kształcie trafiały do Relace (14), Together (6) i CoreWeave (5). Autorzy ostrzegają, że szerokość segmentu to tylko udział wywołań, że nazwy to raportowane upstreamy, a nie zweryfikowane maszyny, i że sam ten rozkład nie wyjaśnia, dlaczego routing się zmienił.

W szybkości Telnyx prowadził medianę szybkości generowania we wszystkich 12 warunkach. Opóźnienie pierwszego tokenu zależało od kształtu zapytania, a nie od jednego zwycięzcy. Serwis definiuje czas do pierwszego tokenu jako liczony od startu zapytania do pierwszej delty treści lub rozumowania odebranej przez klienta, z czasem sieci i kolejkowania włącznie. Szybkość dekodowania to z kolei raportowane tokeny ukończenia podzielone przez czas od pierwszej do ostatniej delty wyjścia. Odpowiedzi niestrumieniowe nie dają pomiaru szybkości dekodowania.

Pomiar czasu obejmuje tylko udane wywołania.

Udział cache i wskaźniki błędów

Badanie podaje udział cache jako sumę tokenów wejściowych z cache podzieloną przez sumę tokenów wejściowych dla udanych wywołań, które raportowały jedno i drugie. Pomiar dotyczy powtarzanych promptów 10 000 z budżetem 100 tokenów wyjściowych. To udział tokenów, a nie odsetek zapytań trafiających w cache, a sekwencja ciepła zawiera swoje początkowe zapytanie.

Wskaźniki błędów są rozbite według celu wejściowego, budżetu wyjściowego i stanu cache. Autorzy zauważają, że trasa może zachowywać się inaczej, gdy ten sam prompt prosi o dłuższą odpowiedź. Wskaźnik błędów to nieudane wywołania podzielone przez zmierzone wywołania w danym warunku, z liczeniem błędów HTTP, transportu i odpowiedzi. Dokładne liczby i przedziały opisowe znajdują się w tabelach pod wykresami, a surowe zapisy można pobrać. Podane zero oznacza brak zaobserwowanej porażki w próbie, a benchmark oznacza niezmierzone pola jako nieraportowane, nie jako zero.

Dla kupujących praktyczny wniosek jest wąski. Luka między zimnym a ciepłym jest tak duża, że przy powtarzalnych obciążeniach to ponowne użycie promptu, a nie sam wybór dostawcy, może dominować w rachunku. Te same liczby pokazują jednak, że powtórzony prompt może trafić do innego upstreamu. To zmienia odpowiedź na pytanie, czy zniżka za cache w ogóle zadziała.