Rankiem 17 sierpnia otworzyłem statystyki użycia API i początkowo pomyślałem, że gdzieś popełniłem błąd.
DeepSeek zużywał pieniądze mniej więcej pięć razy szybciej niż zwykle.
Wiedziałem, że zmiana cen nadchodzi. DeepSeek zapowiedział ją kilka dni wcześniej, ale traktowałem ją jak zwykłą podwyżkę: może 20%, 50%, w skrajnym przypadku dwa razy więcej.
Nie aż tyle.
To nie był błąd billingowy. Nowe stawki faktycznie weszły w życie. DeepSeek oficjalnie przeniósł V4 Flash i V4 Pro na peak/off-peak pricing od 16 sierpnia, 16:00 UTC, czyli już 17 sierpnia czasu chińskiego. Reuters przed zmianą informował, że w zależności od modelu, typu tokena i pory dnia podwyżki wyniosą od 50% do 1,100%. Termin jest zapisany w change logu DeepSeek API.
Wtedy inna wiadomość o DeepSeek nagle stała się znacznie ciekawsza: model weights są publiczne. Skoro inne firmy mogą samodzielnie uruchamiać ten sam model, dlaczego muszę kupować inference bezpośrednio od DeepSeek?
Ile DeepSeek kosztował wcześniej, a ile kosztuje teraz
Przed zmianą cennika DeepSeek V4 Flash kosztował:
| DeepSeek V4 Flash | Stara cena za 1M tokenów |
|---|---|
| Input, cache miss | $0.14 |
| Cached input | $0.0028 |
| Output | $0.28 |
Te wartości nadal widać na starszej stronie cen DeepSeek, a Reuters podawał te same stawki 3 sierpnia.
Oficjalny deepseek-v4-flash, odpowiadający DeepSeek-V4-Flash-0731, kosztuje obecnie:
| Off-peak | Peak | |
|---|---|---|
| Input, cache miss | $0.22 | $0.44 |
| Cached input | $0.007 | $0.014 |
| Output | $0.66 | $1.32 |
Okresy peak trwają od 01:00 do 04:00 UTC i od 06:00 do 10:00 UTC zgodnie z aktualną stroną cen DeepSeek.
Moja obserwacja, że rachunek był mniej więcej pięć razy wyższy, nie oznacza więc, że każda kategoria tokenów podrożała dokładnie pięciokrotnie. W porównaniu ze starymi cenami:
- peak cache-miss input wzrósł z $0.14 do $0.44, czyli 3.14×;
- output z $0.28 do $1.32, czyli 4.71×;
- cache hit z $0.0028 do $0.014, dokładnie 5×.
Przy workloadzie generującym dużo outputu prawie pięciokrotny wzrost realnych wydatków jest więc całkowicie możliwy.
Najpierw szukałem innego sprzedawcy tego samego modelu
Mogłem po prostu zrezygnować z DeepSeek. Na rynku są Qwen, GLM, Kimi, MiniMax, Mistral i wiele innych LLM.
Zmiana modelu dodaje jednak kolejną zmienną. Trzeba ponownie sprawdzić odpowiedzi, prompt compatibility, długość generowania, zachowanie przy długim kontekście, sampling parameters i resztę.
Najpierw chciałem sprawdzić prostszy wariant.
Czy mogę pozostać przy DeepSeek V4 Flash, ale przestać kupować inference od DeepSeek?
Tu ważna jest precyzja terminologii. DeepSeek nie opublikował po prostu „kodu źródłowego sieci neuronowej” w takim sensie, w jakim developer publikuje source tree aplikacji. Trafniej powiedzieć, że opublikował model weights i materiały potrzebne do ich uruchomienia.
Oficjalne repozytorium deepseek-ai/DeepSeek-V4-Flash-0731 jest publicznie dostępne na Hugging Face. Repozytorium i weights są objęte MIT License, a DeepSeek pokazuje nawet przykład uruchomienia modelu przez vLLM na jednym node z czterema GB300.
To całkowicie zmienia ekonomię. Zewnętrzny provider nie musi kupować tokenów od DeepSeek i odsprzedawać ich z marżą. Może uruchomić otwarte weights na własnej infrastrukturze i sprzedawać moc obliczeniową własnego sprzętu.
Oczywiście hasło „uruchom DeepSeek lokalnie” upraszcza temat. Repozytorium 0731 ma około 167 GB, a oficjalny przykład deploymentu korzysta z czterech GB300. To nie jest docker compose up na VPS-ie za $20. Pliki są widoczne na stronie plików modelu.
Dla firmy inference z GPU clusterem sytuacja wygląda jednak inaczej. Licencja przestaje być główną barierą; pozostają hardware, energia, GPU utilization, batching, software stack i efektywność inference.
Znalazłem Runware
Po dość długich poszukiwaniach Runware okazał się jedną z najciekawszych opcji.
Jak znalazłem Runware? Moim ulubionym sposobem researchu. Najpierw poprosiłem AI o napisanie szczegółowego promptu do wyszukania najtańszego, ale wiarygodnego providera inference dokładnie dla tego modelu. Następnie uruchomiłem około 15–20 osobnych wyszukiwań z tym promptem, zebrałem wszystkie wyniki, wrzuciłem je do jednego końcowego czatu i poprosiłem o porównanie kandydatów oraz wskazanie najmocniejszej opcji. Dopiero potem ręcznie sprawdziłem zwycięzcę: stronę modelu, ceny, dokumentację i samo API.
AI pomogło mi rozszerzyć zakres poszukiwań, ale nie podjęło za mnie ostatecznej decyzji. Runware przeszedł moją ręczną weryfikację, sam go podłączyłem i rekomendacja w tym artykule wynika już z mojego własnego testu.
Obecnie oferuje dokładnie checkpoint DeepSeek-V4-Flash-0731 z kontekstem 1M, a nie anonimowy model „DeepSeek-compatible”. Strona modelu podaje:
| Runware | Cena za 1M tokenów |
|---|---|
| Input | $0.076 |
| Cached input | $0.014 |
| Output | $0.153 |
Na początku myślałem, że źle odczytałem miejsce przecinka.
Najciekawsze porównanie nie jest jednak z nowymi, drogimi cenami DeepSeek. Chodzi o stare stawki, które już wcześniej wydawały się bardzo niskie.
Stary input DeepSeek kosztował $0.14. Runware kosztuje $0.076. Runware jest więc około 45.7% tańszy, a stary DeepSeek był około 1.84× droższy.
Stary output kosztował $0.28. Runware kosztuje $0.153. Runware jest około 45.4% tańszy, a stary DeepSeek był około 1.83× droższy.
Po dużej podwyżce cen znalazłem API zewnętrznego dostawcy dla tego samego checkpointu V4 Flash 0731, które nie tylko jest tańsze od nowego DeepSeek, ale kosztuje prawie połowę tego, co stary, tani DeepSeek.
W porównaniu z dzisiejszym oficjalnym cennikiem różnica jest jeszcze większa. Off-peak Runware jest około 2.9× tańszy przy cache-miss input i 4.3× tańszy przy output. W peak różnice wynoszą około 5.8× i 8.6×.
Jest jeden ważny wyjątek: tanie cache hity. DeepSeek pobiera obecnie $0.007/M za cached input off-peak, a Runware $0.014/M. Workload z bardzo wysokim udziałem cache hitów nie powinien być więc porównywany wyłącznie zwykłymi cenami input/output.
Niska cena nic nie znaczy, jeśli API nie działa
Sama tabela cen mi nie wystarcza. LLM API po $0.000001 za request jest bezużyteczne, jeśli połowa requestów kończy się błędem.
Podłączyłem więc Runware i zacząłem wysyłać realne requesty.
Zachowałem dwa snapshoty usage dashboardu. Pierwszy pokazywał:
790 requests
56 success
734 errors
Samo w sobie wygląda to fatalnie. Później dashboard pokazywał:
1,570 requests
836 success
734 errors
Między tymi pomiarami liczniki zmieniły się dokładnie o:
+780 requests
+780 successful
+0 new errors
Nie traktuję tego jako dowodu 99.999% uptime. Te dane niczego takiego nie dowodzą, a dwa snapshoty nie wyjaśniają też przyczyny pierwszych 734 błędów.
Mogę powiedzieć coś węższego: w kolejnych 780 requestach licznik successful wzrósł o 780, a licznik errors nie zmienił się wcale.
API było w tym oknie testowym również szybkie. W widocznej części logu większość udanych wywołań kończyła się w ułamku sekundy do około 1.5 sekundy. Krótkie requesty, które widziałem, często kosztowały około $0.000005–$0.000018. Po setkach udanych wywołań dashboard nadal pokazywał około jednego centa całkowitych wydatków.
Wtedy Runware przestał być dla mnie tylko wierszem w tabeli. Naprawdę podłączyłem API, generowało odpowiedzi, a testowy ruch kosztował prawie nic.
To nie jest reklama — a Runware testuję dopiero od jednego dnia
Chcę powiedzieć to wprost, bo pozytywny fragment o jednym providerze łatwo może wyglądać jak materiał sponsorowany. Tak nie jest. Runware się ze mną nie kontaktował i ja również nie kontaktowałem się z Runware. Nikt z firmy nie prosił mnie o napisanie tego artykułu.
Poza tym korzystam z usługi dopiero od jednego dnia. Za tydzień albo miesiąc mogę z niej odejść, jeśli pojawią się problemy z niezawodnością, jakością odpowiedzi, cenami lub czymkolwiek innym. To nie jest długoterminowy werdykt.
Z drogiego oficjalnego DeepSeek API odszedłem od razu, bo nie chciałem dalej przepalać pieniędzy po nowych stawkach w czasie szukania alternatywy. Po prostu przeniosłem ruch i natychmiast zacząłem testować Runware.
Na razie jestem z tej decyzji bardzo zadowolony. Gdy kończyłem ten artykuł, Runware miał już za sobą 1.000 udanych requestów AI z mojego ruchu. To nadal nie dowodzi przyszłego uptime ani działania w każdej skali, ale wystarcza mi, by powiedzieć, że nie jest to provider znaleziony wyłącznie w cenniku: naprawdę go używam.
Moja rekomendacja jest więc celowo ograniczona: sam sprawdziłem Runware, dziś działa u mnie dobrze i na ten moment polecam go wypróbować. Jeśli usługa się zmieni, moja opinia też może się zmienić.
DeepSeek mógł stworzyć własnego konkurenta cenowego
Od tego miejsca mówię już o interpretacji, a nie bezpośrednio obserwowanym fakcie.
DeepSeek znalazł się w nietypowej pozycji biznesowej. Wydał bardzo konkurencyjny model i jednocześnie pozwolił rynkowi uruchamiać go niezależnie.
Dopóki oficjalne API DeepSeek było ekstremalnie tanie, napięcie to było prawie niewidoczne. Po co szukać cudzego GPU clustera, skoro DeepSeek sprzedawał inference za $0.14/$0.28?
Po podwyżce rachunek się zmienia. Jeśli oficjalne API kosztuje w peak $0.44 input i $1.32 output, a niezależny provider oferuje ten sam publiczny checkpoint za $0.076/$0.153, ekonomiczna motywacja do sprawdzenia alternatywy jest bardzo silna.
To nie jest przypadkowy loophole. MIT License opublikowanych weights pozwala na szerokie użycie, także komercyjne, a oficjalne repozytorium zawiera instrukcje self-hostingu.
Dlatego nie nazywałbym Runware po prostu „resellerem tokenów DeepSeek”. Trafniejszy obraz wygląda tak:
DeepSeek
│
├── oficjalne DeepSeek API
│
└── otwarte weights DeepSeek V4 Flash
│
├── infrastruktura Runware
├── inni dostawcy inference
└── własny GPU clusterTen sam model nie jest już związany z jednym sprzedawcą inference.
Czy otwarcie weights było błędem biznesowym?
Nie przedstawiałbym tego jako faktu.
Stwierdzenie „DeepSeek otworzył model, konkurenci mogą sprzedawać go taniej, więc DeepSeek musi stracić pieniądze” byłoby zbyt proste. Nie znamy wewnętrznej ekonomii firmy.
Strategia open-weight może mieć inne zalety:
- szerszą dystrybucję modelu;
- więcej integracji;
- większy wpływ na ekosystem;
- szansę na stanie się de facto standardem w produktach zewnętrznych;
- więcej developerów;
- enterprise adoption;
- popularność badawczą;
- presję na konkurentów.
Reuters również zwracał uwagę na nacisk chińskich twórców modeli na open-weight jako sposób osiągania szerokiej adopcji wśród developerów w swojej relacji z chińskiego rynku AI.
Dlatego dla mnie za wcześnie, by nazywać tę decyzję błędem biznesowym. Bardziej ograniczony wniosek wydaje mi się uzasadniony:
Otwierając weights, DeepSeek dobrowolnie zrezygnował z monopolu na inference własnego modelu.
Kiedy oficjalne API staje się znacznie droższe, skutki tej decyzji są lepiej widoczne. DeepSeek konkuruje wtedy nie tylko z Qwen, OpenAI, Anthropic czy Moonshot, ale w pewnym sensie także z firmami sprzedającymi inference dla otwartego modelu DeepSeek.
Dla kupujących API to świetna sytuacja. Dla strategii monetyzacji — dużo bardziej skomplikowana.
Dlaczego nie hostuję DeepSeek samodzielnie
Następna myśl jest oczywista: skoro firmy zewnętrzne mogą uruchamiać DeepSeek i sprzedawać inference, dlaczego nie zrobić tego samemu?
Bo między „model można pobrać za darmo” a „inference jest darmowe” istnieje ogromna różnica.
Weights można pobrać. GPU nie.
Trzeba kupić lub wynająć drogi hardware, zapewnić wystarczająco dużo VRAM, załadować ogromny checkpoint, skonfigurować inference engine, batching, KV cache, monitoring, scaling i redundancy, a potem mieć wystarczająco dużo ruchu, aby GPU nie stały przez większość czasu bezczynnie.
Oficjalny przykład DeepSeek dla V4 Flash 0731 wykorzystuje jeden node z czterema GB300.
Dla wyspecjalizowanego providera inference taka inwestycja może mieć sens, bo koszt infrastruktury rozkłada się na wielu klientów. Dla pojedynczego developera płacenie $0.076 za milion tokenów input może być znacznie bardziej racjonalne niż duża inwestycja w GPU i późniejsze utrzymywanie wysokiego utilization.
Na razie wolę kupować inference. Ale znacznie lepiej rozumiem, za co właściwie płacę.
Najważniejsza lekcja z tego poranka
Na początku dnia patrzyłem na DeepSeek jak na zwykłe SaaS API: istnieje model DeepSeek, więc DeepSeek decyduje, ile kosztuje jego używanie.
Wieczorem mój model mentalny był inny: istnieje checkpoint DeepSeek i istnieje konkurencyjny rynek firm gotowych uruchomić ten checkpoint dla mnie.
To dwa fundamentalnie różne rynki.
Przy zamkniętym modelu cena API jest w dużej mierze kontrolowana przez właściciela modelu. Przy open weights na permissive license cenę inference kształtuje również konkurencja między providerami infrastruktury.
17 sierpnia ta różnica stała się dla mnie bardzo konkretna. Stary DeepSeek V4 Flash kosztował $0.14 input i $0.28 output. Nowa oficjalna cena DeepSeek dochodzi do $0.44/$1.32 w peak. Runware obecnie oferuje DeepSeek-V4-Flash-0731 za $0.076/$0.153.
Sam przetestowałem to API i działało dla ruchu, który do niego wysłałem.
Czy za miesiąc ceny będą takie same? Nie wiem. Czy ten sam provider obsłuży dowolną skalę i dowolny profil ruchu? Tego również nie udowodniłem.
Ale jedno się zmieniło: po tej podwyżce nie zakładam już automatycznie, że oficjalne API twórcy modelu open-weight jest najlepszym miejscem do kupowania inference.
Teraz najpierw sprawdzam, kto jeszcze może uruchomić te same weights i ile za to chce.