DeepSeek verhoogde de prijzen — ik vond dezelfde V4 Flash goedkoper dan het oude tarief

Op de ochtend van 17 augustus opende ik mijn API-gebruiksstatistieken en dacht ik eerst dat ik ergens een fout had gemaakt.

DeepSeek verbruikte geld ongeveer vijf keer zo snel als ik gewend was.

Ik wist dat er een prijswijziging aankwam. DeepSeek had die enkele dagen eerder aangekondigd, maar ik had hem in mijn hoofd opgeslagen als een normale verhoging: misschien 20%, 50%, desnoods een verdubbeling.

Niet zoveel.

Er was geen billing-bug. De nieuwe tarieven waren echt ingegaan. DeepSeek zette V4 Flash en V4 Pro officieel vanaf 16 augustus om 16:00 UTC over op peak/off-peak-prijzen, wat in China al 17 augustus was. Reuters had voor de wijziging gemeld dat de stijgingen, afhankelijk van model, tokentype en tijdstip, tussen 50% en 1,100% zouden liggen. Het tijdstip staat in de DeepSeek API change log.

Op dat moment werd een ander bericht over DeepSeek ineens veel interessanter: de model weights zijn openbaar. Als andere bedrijven hetzelfde model zelf kunnen draaien, waarom zou ik inference dan per se rechtstreeks bij DeepSeek moeten kopen?

Wat DeepSeek vroeger kostte en wat het nu kost

Voor de prijswijziging kostte DeepSeek V4 Flash:

Die cijfers staan nog op een oudere DeepSeek-prijspagina, en Reuters noemde op 3 augustus dezelfde tarieven.

De officiële deepseek-v4-flash, die overeenkomt met DeepSeek-V4-Flash-0731, kost nu:

De peak-periodes lopen van 01:00 tot 04:00 UTC en van 06:00 tot 10:00 UTC volgens de huidige DeepSeek-prijspagina.

Mijn observatie dat de rekening ongeveer vijf keer hoger was, betekent dus niet dat elke tokencategorie exact vijf keer duurder werd. Vergeleken met de oude prijs:

• steeg peak cache-miss input van $0.14 naar $0.44, oftewel 3.14×;
• steeg output van $0.28 naar $1.32, oftewel 4.71×;
• steeg een cache hit van $0.0028 naar $0.014, exact 5×.

Voor een workload met veel output is een werkelijke kostenstijging van bijna vijf keer dus heel goed mogelijk.

Ik zocht eerst een andere verkoper van hetzelfde model

Ik had DeepSeek gewoon kunnen vervangen. Er zijn inmiddels Qwen, GLM, Kimi, MiniMax, Mistral en talloze andere LLM's.

Maar een modelwissel voegt een nieuwe variabele toe. Responses, prompt compatibility, generatielengte, gedrag bij lange context, sampling parameters en andere eigenschappen moeten opnieuw worden gecontroleerd.

Ik wilde eerst een eenvoudiger idee testen.

Kan ik DeepSeek V4 Flash behouden, maar stoppen met inference kopen bij DeepSeek?

Daarbij is de terminologie belangrijk. DeepSeek publiceerde niet simpelweg de “broncode van het neurale netwerk” zoals een ontwikkelaar de source tree van een applicatie publiceert. Nauwkeuriger is dat DeepSeek de model weights en het materiaal om ze uit te voeren heeft gepubliceerd.

De officiële repository deepseek-ai/DeepSeek-V4-Flash-0731 is openbaar beschikbaar op Hugging Face. Repository en weights gebruiken de MIT License en DeepSeek geeft zelfs een voorbeeld van uitvoering met vLLM op één node met vier GB300's.

Dat verandert de economie. Een derde provider hoeft niet per se DeepSeek-tokens te kopen en met opslag door te verkopen. Hij kan de open weights op zijn eigen infrastructuur draaien en rekenkracht op zijn eigen hardware verkopen.

Natuurlijk klinkt “draai DeepSeek lokaal” eenvoudiger dan het is. De 0731-repository is ongeveer 167 GB en het officiële deploymentvoorbeeld gebruikt vier GB300's. Dit is geen docker compose up op een VPS van $20. De bestanden staan op de model file page.

Voor een inferencebedrijf met een GPU-cluster is het probleem echter anders. De licentie is dan niet meer de belangrijkste barrière; hardware, stroom, GPU utilization, batching, software stack en inference-efficiëntie blijven over.

Ik vond Runware

Na vrij lang zoeken was Runware een van de interessantste opties.

Hoe vond ik Runware? Met mijn favoriete manier van onderzoeken. Eerst vroeg ik een AI om een gedetailleerde prompt te schrijven voor het vinden van de goedkoopste serieuze inferenceprovider voor precies dit model. Daarna voerde ik met die prompt ongeveer 15–20 afzonderlijke zoekrondes uit, verzamelde alle resultaten, zette ze in één laatste chat en liet de kandidaten vergelijken om de sterkste optie te vinden. Pas daarna controleerde ik de winnaar zelf: modelpagina, prijzen, documentatie en de API.

De AI hielp dus om breder te zoeken, maar nam de uiteindelijke beslissing niet voor mij. Runware doorstond mijn handmatige controle, ik koppelde de dienst zelf en de aanbeveling in dit artikel is gebaseerd op die eigen test.

Het biedt momenteel exact de DeepSeek-V4-Flash-0731-checkpoint met 1M context, niet een naamloos “DeepSeek-compatible” model. De modelpagina vermeldt:

Eerst dacht ik dat ik de komma verkeerd had gelezen.

Maar de nuttigste vergelijking is niet met de nieuwe hoge DeepSeek-prijzen. Het is met de oude tarieven die al goedkoop leken.

Oude DeepSeek-input was $0.14. Runware kost $0.076. Runware is daarmee ongeveer 45.7% goedkoper, terwijl de oude DeepSeek-prijs ongeveer 1.84× hoger lag.

Oude DeepSeek-output was $0.28. Runware kost $0.153. Runware is ongeveer 45.4% goedkoper, terwijl het oude DeepSeek ongeveer 1.83× duurder was.

Na een grote prijsverhoging vond ik een API van een derde partij met dezelfde V4 Flash 0731-checkpoint die niet alleen goedkoper is dan het nieuwe DeepSeek, maar bijna de helft kost van het oude, goedkope DeepSeek.

Vergeleken met de huidige officiële prijzen is het verschil nog groter. Off-peak is Runware ongeveer 2.9× goedkoper voor cache-miss input en 4.3× goedkoper voor output. Tijdens peak zijn de verschillen ongeveer 5.8× en 8.6×.

Er is één belangrijke uitzondering: goedkope cache hits. DeepSeek vraagt momenteel $0.007/M voor cached input off-peak, terwijl Runware $0.014/M rekent. Een workload die vrijwel volledig uit cache hits bestaat, kan daarom niet alleen op gewone input/output-prijzen worden vergeleken.

Een lage prijs betekent niets als de API niet werkt

Een prijstabel is voor mij niet genoeg. Een LLM API van $0.000001 per request is waardeloos als de helft van de requests mislukt.

Dus koppelde ik Runware en begon echte requests te versturen.

Ik bewaarde twee snapshots van het usage dashboard. De eerste liet zien:

790 requests
56 success
734 errors

Op zichzelf ziet dat er verschrikkelijk uit. Later stond er:

1,570 requests
836 success
734 errors

Tussen die twee metingen veranderden de counters exact met:

+780 requests
+780 successful
+0 new errors

Ik beschouw dit niet als bewijs voor 99.999% uptime. Dat bewijst het niet, en die twee snapshots vertellen mij ook niet waardoor de oorspronkelijke 734 errors zijn veroorzaakt.

Wat ik wel kan zeggen is beperkter: tijdens de volgende 780 requests steeg de successful-counter met 780 en veranderde de error-counter helemaal niet.

De API was in dat testvenster ook snel. In het zichtbare log duurden de meeste succesvolle calls een fractie van een seconde tot ongeveer 1.5 seconden. Korte requests die ik kon zien kostten vaak rond $0.000005–$0.000018. Na honderden succesvolle calls gaf het dashboard nog steeds maar ongeveer één cent totale kosten aan.

Vanaf dat moment was Runware voor mij niet langer alleen een rij in een vergelijkingstabel. Ik had de API daadwerkelijk gekoppeld, hij genereerde responses en mijn testverkeer kostte bijna niets.

Dit is geen reclame — en ik test Runware pas één dag

Ik wil dat expliciet zeggen, omdat een positief stuk over één provider al snel als gesponsorde content kan overkomen. Dat is het niet. Runware heeft mij niet benaderd en ik heb Runware ook niet benaderd. Niemand daar heeft mij gevraagd dit artikel te schrijven.

Bovendien gebruik ik de dienst pas één dag. Over een week of een maand kan ik net zo goed weer vertrekken als betrouwbaarheid, antwoordkwaliteit, prijzen of iets anders tegenvallen. Dit is geen oordeel voor de lange termijn.

Ik ben direct weggegaan bij de inmiddels dure officiële DeepSeek API, omdat ik tijdens het zoeken naar alternatieven niet verder geld wilde verbranden tegen de nieuwe tarieven. Ik verplaatste het verkeer en begon Runware meteen te testen.

Tot nu toe ben ik erg tevreden met die beslissing. Toen ik dit artikel afrondde, had Runware al 1.000 succesvolle AI-requests voor mij verwerkt. Dat bewijst nog steeds niets over toekomstige uptime of prestaties op iedere schaal, maar het laat wel zien dat dit niet alleen een provider uit een prijstabel is: ik gebruik hem daadwerkelijk.

Mijn aanbeveling is daarom bewust beperkt: ik heb Runware zelf gecontroleerd, vandaag werkt het goed voor mij en op dit moment raad ik aan het te proberen. Verandert de dienst, dan kan mijn mening ook veranderen.

DeepSeek heeft mogelijk zijn eigen prijsconcurrent gecreëerd

Vanaf hier gaat het om mijn interpretatie, niet om een direct waargenomen feit.

DeepSeek heeft zichzelf in een ongebruikelijke zakelijke positie gebracht. Het bedrijf bracht een zeer competitief model uit en gaf de markt tegelijk de mogelijkheid dat model zelfstandig te draaien.

Zolang de officiële DeepSeek API extreem goedkoop was, viel die spanning nauwelijks op. Waarom een GPU-cluster van een ander zoeken als DeepSeek zelf inference verkocht voor $0.14/$0.28?

Na de prijsverhoging verandert die rekensom. Als de officiële API tijdens peak $0.44 input en $1.32 output kost, terwijl een onafhankelijke provider dezelfde openbare checkpoint voor $0.076/$0.153 aanbiedt, wordt de economische reden om het alternatief te proberen heel sterk.

Dit is geen toevallige loophole. De MIT License van de gepubliceerde weights staat breed gebruik toe, inclusief commercieel gebruik, en de officiële repository bevat instructies voor self-hosting.

Daarom zou ik Runware niet simpelweg een “reseller van DeepSeek-tokens” noemen. Een nauwkeuriger beeld is:

DeepSeek
    │
    ├── officiële DeepSeek API
    │
    └── open DeepSeek V4 Flash weights
                   │
                   ├── Runware-infrastructuur
                   ├── andere inferenceproviders
                   └── je eigen GPU-cluster

Hetzelfde model is niet langer gekoppeld aan één verkoper van inference.

Was het publiceren van de weights een zakelijke fout?

Ik zou dat niet als feit presenteren.

Het zou te simpel zijn om te zeggen dat DeepSeek het model opende, concurrenten het nu goedkoper kunnen verkopen en DeepSeek dus noodzakelijk geld verliest. We kennen de interne economie van het bedrijf niet.

Een open-weight-strategie kan andere voordelen hebben:

• bredere verspreiding van het model;
• meer integraties;
• meer invloed op het ecosysteem;
• de kans een de facto standaard te worden in producten van derden;
• meer developers;
• enterprise adoption;
• populariteit in onderzoek;
• druk op concurrenten.

Reuters wees in zijn berichtgeving over de Chinese AI-markt ook op de nadruk die Chinese modelontwikkelaars leggen op open-weight-benaderingen om brede developer adoption te bereiken.

Daarom is het voor mij te vroeg om de beslissing een zakelijke fout te noemen. Een smallere conclusie vind ik wel verdedigbaar:

Door de weights te openen, gaf DeepSeek vrijwillig zijn monopolie op inference voor het eigen model op.

Wanneer de officiële API veel duurder wordt, worden de gevolgen van die keuze zichtbaarder. DeepSeek concurreert dan niet alleen met Qwen, OpenAI, Anthropic of Moonshot, maar in zekere zin ook met bedrijven die inference verkopen voor DeepSeeks eigen open model.

Voor API-kopers is dat uitstekend. Voor de monetisatiestrategie is het veel ingewikkelder.

Waarom ik DeepSeek niet zelf host

De volgende gedachte ligt voor de hand: als externe bedrijven DeepSeek kunnen draaien en inference kunnen verkopen, waarom doe ik dat dan niet zelf?

Omdat er een enorm verschil is tussen “het model is gratis te downloaden” en “inference is gratis”.

Weights kun je downloaden. GPU's niet.

Je moet dure hardware kopen of huren, genoeg VRAM beschikbaar hebben, een enorme checkpoint laden, de inference engine, batching, KV cache, monitoring, scaling en redundancy configureren en vervolgens genoeg verkeer hebben om de GPU's niet het grootste deel van de tijd idle te laten staan.

Het officiële DeepSeek-voorbeeld voor V4 Flash 0731 gebruikt één node met vier GB300's.

Voor een gespecialiseerde inferenceprovider kan die investering logisch zijn omdat de infrastructuurkosten over veel klanten worden verdeeld. Voor één developer kan $0.076 per miljoen inputtokens betalen veel rationeler zijn dan eerst veel geld in GPU's investeren en daarna hoge utilization proberen te behouden.

Voorlopig koop ik inference liever in. Maar ik begrijp nu veel beter wat ik eigenlijk koop.

De belangrijkste les van die ochtend

Aan het begin van de dag zag ik DeepSeek als een normale SaaS API: er is een DeepSeek-model, dus DeepSeek bepaalt wat het kost om het te gebruiken.

Aan het einde van de dag was mijn mentale model anders: er is een DeepSeek-checkpoint en er is een concurrerende markt van bedrijven die die checkpoint voor mij willen draaien.

Dat zijn fundamenteel verschillende markten.

Bij een gesloten model wordt de API-prijs grotendeels bepaald door de eigenaar van het model. Bij open weights onder een permissieve licentie wordt de inferenceprijs ook gevormd door concurrentie tussen infrastructuurproviders.

Op 17 augustus werd dat verschil voor mij heel concreet. Het oude DeepSeek V4 Flash kostte $0.14 input en $0.28 output. De nieuwe officiële DeepSeek-prijs loopt tijdens peak op tot $0.44/$1.32. Runware biedt DeepSeek-V4-Flash-0731 momenteel aan voor $0.076/$0.153.

Ik heb deze API zelf getest en hij werkte voor het verkeer dat ik ernaartoe stuurde.

Zijn die prijzen over een maand nog hetzelfde? Dat weet ik niet. Kan dezelfde provider elke schaal en elk verkeersprofiel aan? Dat heb ik ook niet bewezen.

Maar één ding is voor mij veranderd: na deze prijsverhoging ga ik er niet meer automatisch van uit dat de officiële API van de maker van een open-weight-model de beste plek is om inference te kopen.

Mijn eerste stap is nu kijken wie dezelfde weights nog meer kan draaien en hoeveel die partij daarvoor rekent.