Is de dalurenkorting van DeepSeek een koopje of een valstrik?

De modelmarkt beweegt zo snel dat een prijskaart of modelnaam al verouderd kan zijn voordat een proef is afgerond. Bij DeepSeek ligt vandaag een andere vraag voor: de grote off-peakkorting van V4.1 Flash afzetten tegen wachttijd, planning en herstelwerk. Dat klinkt administratief, maar raakt direct aan de kosten en betrouwbaarheid van een werkproces.

Deze afweging is lastig omdat het model zelf vaak maar een deel van de rekening vormt. Een goedkoper tarief kan meer controles vragen, terwijl een duurdere route juist tijd, juridische uitzonderingen of herstelwerk voorkomt. Daarom worden de actuele feiten eerst uit elkaar gehaald en daarna in een omgekeerde rekensom gezet.

Direct naar een onderdeel van dit artikel

Wat er nu werkelijk is veranderd

De rekening ontstaat buiten de kale tokenprijs

De omgekeerde rekensom maakt de grens zichtbaar

Drie scenario’s voor 2027 tot en met 2029

Het sterkste tegenargument verdient een echte plaats

Wat deze cijfers niet bewijzen

Wat een bedrijf nu moet vastleggen

De conclusie volgt uit de gemeten uitkomst

In het kort

Bij DeepSeek draait de actuele afweging om de grote off-peakkorting van V4.1 Flash afzetten tegen wachttijd, planning en herstelwerk. De prijs of licentie is maar één deel van de werkelijke rekening; kwaliteit, controle, snelheid en beheer bepalen wat een bruikbare uitkomst kost. De omgekeerde rekensom laat zien welke jaarlijkse besparing nodig is om de investering terug te verdienen. De redelijke keuze volgt daarom uit gemeten kosten per geaccepteerde taak en niet uit één opvallend tarief of benchmarkcijfer.

Wat er nu werkelijk is veranderd

Volgens de officiële documentatie geldt op de peildatum het volgende. DeepSeek publiceert voor V4.1 Flash een lager tarief tijdens daluren. De outputprijs daalt in de actuele tabel van $1,98 naar $0,60 per miljoen tokens. Ook cache-invoer wordt goedkoper. Dat is een tijdsgebonden prijs, geen garantie dat een willekeurige realtime aanvraag tegen het lage tarief wordt verwerkt. De datum van de bron en de datum waarop een productwijziging ingaat, zijn niet automatisch dezelfde. Waar een leverancier een vroegste datum, introductietarief of snelheidsclaim noemt, wordt dat hier dus ook zo behandeld.

Dat onderscheid voorkomt twee bekende fouten. Een aankondiging wordt niet gelijkgesteld aan algemene beschikbaarheid, en een open gewicht of gratis proef wordt niet beschreven als een kosteloze productiedienst. De technische toelichting laat bovendien zien dat context, cache, regio, licentie en servicelaag per variant kunnen verschillen.

De rekening ontstaat buiten de kale tokenprijs

De korting past bij werk dat in een wachtrij kan staan: nachtelijke classificatie, codecontrole of het voorbereiden van dossiers voor de volgende ochtend. Zij past minder goed bij een medewerker die tijdens een gesprek op antwoord wacht. Dan kan één minuut vertraging meer kosten dan duizenden tokens. Inkoopteams zien het modeltarief, maar niet altijd de tijd die nodig is voor gegevensclassificatie, controle, monitoring en herstel. Die verborgen uren verdwijnen niet doordat een leverancier de prijs per miljoen tokens verlaagt.

Vijf miljoen outputtokens kosten in dit eenvoudige voorbeeld $9,90 tegen het normale tarief en $3 tijdens daluren. De besparing is $6,90. Wie daarvoor een planner, foutafhandeling en een tweede productieroute bouwt, moet veel volume verwerken voordat de techniek zichzelf betaalt. Dit is bewust een rekenvoorbeeld en geen voorspelling van de uiteindelijke factuur. Het maakt zichtbaar welke variabele de uitkomst draagt. Toolkosten, valuta, belasting, cache en mislukte pogingen moeten alleen worden toegevoegd wanneer ze werkelijk in dezelfde route voorkomen.

De omgekeerde rekensom maakt de grens zichtbaar

Een project hoort niet te beginnen met de vraag hoeveel voordeel een model misschien oplevert, maar met de besparing die minimaal nodig is om de extra investering te rechtvaardigen. In het scenario hieronder bedraagt de startinvestering € 9.000 en komen daar € 5.000 jaarlijkse kosten bij. De gebruikte uurwaarde is €65.

De formule verdeelt de startinvestering eenvoudig over drie jaar en telt de jaarlijkse kosten op. Daarna wordt de som gedeeld door de waarde-eenheid. Zo ontstaat een drempel van 123,08 vermeden uren per jaar. Pas boven die grens is er in dit vereenvoudigde voorbeeld een positieve operationele kasbesparing.

Drie scenario’s voor 2027 tot en met 2029

Het lage scenario veronderstelt een voorzichtige ingebruikname, beperkte dekking en relatief veel menselijke controle. Het middenscenario gaat uit van herhaalbaar gebruik in enkele werkstromen. Het hoge scenario veronderstelt bredere inzet, maar telt dezelfde besparing niet nog eens als omzet of als vermeden externe kosten.

Deze scenario’s zeggen niets over een toekomstige modelbenchmark. Ze laten alleen zien hoeveel aantoonbare benutting nodig is. Wanneer de kwaliteit achterblijft, stijgt het aantal herstelpogingen en valt het netto voordeel lager uit. Wanneer een betere route werk in één keer accepteerbaar maakt, mag dat effect juist worden meegenomen.

Het sterkste tegenargument verdient een echte plaats

Het tegenargument is dat batchwerk vaak al asynchroon is. Dan kost wachten niets en is vrijwel iedere korting meegenomen. Dat klopt voor stabiele nachttaken. Bij urgente herstelruns, tijdzones en piekdagen blijft echter een normale route nodig, waardoor niet het hele volume voor de korting in aanmerking komt. Een goede vergelijking zet die kans niet weg als marketing. Zij vraagt alleen om dezelfde taak, dezelfde kwaliteitsgrens en dezelfde meetperiode. Anders worden snelheid, privacy of openheid wel genoemd, maar niet economisch bewezen.

Een benchmark kan daarbij helpen om kandidaten te selecteren, maar bewijst geen betrouwbaarheid in Nederlandse documenten, eigen code of een gereguleerd proces. Alleen een vaste evaluatieset met geslaagde en mislukte gevallen laat zien of de nieuwe route werkelijk minder werk vraagt.

Wat deze cijfers niet bewijzen

De bedragen hierboven zijn geen gemeten rendement van DeepSeek bij één specifieke onderneming. De officiële prijzen en productvoorwaarden zijn feiten op de peildatum; volume, uurwaarde, implementatiekosten en gebruik in 2027 tot en met 2029 zijn expliciete aannames. Een positief scenario bewijst dus alleen dat de rekensom kán sluiten wanneer de veronderstelde benutting werkelijk wordt gehaald.

Ook de omgekeerde conclusie vraagt voorzichtigheid. Een project onder de financiële drempel kan toch rationeel zijn wanneer het een harde privacy-eis, continuïteitsrisico of strategische afhankelijkheid vermindert. Dan moet die waarde apart worden benoemd en onderbouwd. Zij mag niet stilletjes boven op volledige tijdwinst worden gezet, want daarmee zou dezelfde verbetering twee keer in de businesscase terechtkomen.

Voor de vergelijking is daarom een nulmeting nodig. Noteer vóór de overstap hoeveel tijd de bestaande route vraagt, welk deel van de uitkomsten direct wordt geaccepteerd en hoeveel dossiers terugkomen voor correctie. Meet na de overstap exact dezelfde grootheden. Houd daarbij taakmix en kwaliteitsgrens gelijk, zodat een eenvoudiger maand niet per ongeluk als modelverbetering wordt geboekt. Zonder die basis wordt een dalende modelrekening gemakkelijk aangezien voor productiviteitswinst, terwijl medewerkers mogelijk meer tijd besteden aan controleren, wachten of het opnieuw formuleren van opdrachten.

Wat een bedrijf nu moet vastleggen

Verdeel werk eerst in urgent en uitstelbaar. Meet daarna welk deel werkelijk in het dalvenster wordt afgerond zonder extra handwerk. Een nominale korting is pas een besparing wanneer dezelfde taak, kwaliteit en deadline behouden blijven. De aanvullende productinformatie moet samen met de contractvoorwaarden worden bewaard op de datum waarop het besluit wordt genomen. Zo is later terug te vinden welke prijs, toegang en beperking bij de businesscase hoorden.

Praktisch betekent dit dat iedere productieflow een modelversie, regio, eigenaar, evaluatieset en terugvalroute krijgt. Meet per maand volume, cachetreffers, toolgebruik, wachttijd, correcties en acceptatie. Noteer ook wijzigingen in prompts en gekoppelde gegevens, omdat zij de uitkomst even sterk kunnen beïnvloeden als een nieuw model. Daarmee wordt een prijswijziging of modelwissel een herberekening in plaats van een verrassing.

Begin bovendien met een kleine groep taken die vaak genoeg voorkomt om te meten en begrensd genoeg is om fouten te onderzoeken. Bewaar afgewezen uitkomsten naast geslaagde voorbeelden. Juist die mislukkingen laten zien of een lagere prijs, hogere snelheid of ruimere context echt tot minder werk leidt, of alleen de kosten naar controle en herstel verschuift.

De conclusie volgt uit de gemeten uitkomst

De huidige stand maakt DeepSeek niet vanzelf goedkoop of duur. De gekozen invalshoek laat vooral zien waar een ogenschijnlijk kleine productvoorwaarde de hele rekening kan veranderen. Wie alleen het laagste tarief kiest, kan later betalen voor vertraging, migratie of controle. Wie zonder meting voor de duurste route kiest, koopt mogelijk capaciteit die niet wordt benut.

De redelijke conclusie is daarom om klein te beginnen, de volledige keten te meten en alleen op te schalen wanneer de omgekeerde drempel wordt gehaald. De uitkomst moet daarna minstens ieder kwartaal opnieuw worden getoetst. Opnieuw kijken wanneer DeepSeek het dalvenster, de prijs of de route van de legacy-modelnamen verandert en wanneer zoektools een groter deel van de rekening vormen. Tot dat bewijs er ligt, blijft het scenario een plan en geen gerealiseerde besparing.