DeepSeeks API-prissætning i peak-time gør modelrouting til et planlægningsproblem

DeepSeeks V4 API-prissætning er flyttet fra et simpelt modeludvælgelsesspørgsmål til et timing-spørgsmål.

Virksomhedens officielle API-prissætningsside viser nu DeepSeek V4 Flash og DeepSeek V4 Pro med store kontekstvinduer med 1 million token, OpenAI-format og Antropisk-format-base-URL'er, og adskilt cache-billing-hit-input-kategorier og cache-miss-hit-kategorier. Rapporter samlet af Techmeme den 13. august sagde, at DeepSeek hævede priserne på V4-modeller og introducerede dynamisk peak/off-peak-fakturering, hvor den nye prissætning træder i kraft kl. 16:00 UTC den 16. august 2026.

Det gør ændringen til mere end en rutinemæssig opdatering af pristabel. For teams, der kører genfindingstunge agenter, kodningsassistenter med lang kontekst, batchanalysejob eller kundevendte AI-produkter, kan prisen på en DeepSeek-anmodning nu ikke kun afhænge af, hvilken model der vælges, men hvornår anmodningen sendes, og hvor meget af prompten, der kan betjenes fra cachen.

Hvad ændret i DeepSeek24's nuværende API-dokumentation

V4 Flash og V4 Pro som tilgængelige via API-formater i både OpenAI-stil og Antropisk stil. Det betyder noget, fordi mange udviklere allerede ruter DeepSeek sammen med andre udbydere gennem kompatibilitetslag i stedet for at skrive udbyderspecifik applikationskode.

Den bemærkelsesværdige faktureringsstruktur er adskillelsen mellem cache-hit input, cache-miss input og output. I praksis betyder det, at gentagne promptpræfikser, systeminstruktioner, værktøjsskemaer eller lange genanvendelige kontekstblokke kan have en anden omkostningsprofil end nyindsendt prompttekst. Dette var allerede en vigtig del af DeepSeek V4-Pro-omkostningshistorien. Det nye peak/off-peak-lag tilføjer endnu en variabel: Den samme arbejdsbelastning kan prissætte forskelligt afhængigt af, hvornår den kører.

Sekundær rapportering peger på en væsentlig prisstigning for V4-modeller og en dynamisk tidsplan, der begynder den 16. august. Nogle samfundsberegninger hævder meget store procentvise stigninger for specifikke cache-tunge sager, især hvor cache-hit-priserne ændrede sig kraftigt. Disse tal bør behandles med varsomhed, indtil de kontrolleres mod aktive fakturaer eller DeepSeeks aktuelle faktureringstabel. Rejseretningen er dog klar nok: API-forbrugere kan ikke længere kun evaluere DeepSeek V4 ud fra overskriftsmodelkapacitet og nominelle per-token-rater.

Hvorfor peak- og off-peak-priser er vigtige

Pic- og off-peak-priser er almindelige på infrastrukturmarkeder, men det er stadig et relativt nyt LLM-mønster. Det skaber incitamenter, som er velkendte for cloud- og datateams: flyt fleksibelt arbejde ud af dyre vinduer, reserver premium-tid til brugervendte anmodninger, og få batchjobs til at vente, når latenstiden ikke er kritisk.

For AI-applikationer har det flere praktiske effekter. En supportbot i realtid kan normalt ikke forsinke et kundesvar, indtil et billigere vindue. En natlig kodebaseanalysejob, dokumentberigelsespipeline eller evalueringskørsel kan ofte. Agentsystemer sidder et sted i midten: nogle værktøjsopkald er interaktive, mens andre kan sættes i kø, prøves igen eller planlægges.

Dette ændrer routingproblemet. En gateway, der vælger mellem modeller baseret på kvalitet, latency og tokenpris, skal nu overveje tid. Hvis DeepSeek V4 Pro er omkostningseffektiv uden for myldretiden, men dyr i myldretiden, kan en applikation foretrække en anden model i løbet af dagen og vende tilbage til DeepSeek senere. Hvis V4 Flash forbliver attraktiv til hurtige opgaver, men cacheøkonomien forværres for lange delte præfikser, skal selve promptarkitekturen muligvis gennemgås.

For teams, der bruger en AI API-gateway, er den mest nyttige funktion muligvis ikke en anden modelskift. Det kan være politik: send interaktive anmodninger med det samme, sæt ikke-hastende job i kø, advar, når en anmodning kommer ind i et højere omkostningsvindue, eller anvend budgetter på teamniveau, før en batchkørsel begynder. Det er direkte relevant for Model Gate-lignende infrastruktur, fordi ensartet fakturering, brugsanalyse og routingkontroller bliver mere værdifulde, når udbyderpriserne er dynamiske frem for statiske.

Hvem er mest eksponeret

Den største påvirkning vil sandsynligvis falde på udviklere og virksomheder i store mængder med forudsigelige arbejdsbelastninger. Forbrugerchatprodukter, kodningsagentplatforme, forskningsværktøjer, datarensningstjenester og interne automatiseringsteams kan alle sende et stort antal lignende anmodninger. Disse systemer drager ofte fordel af hurtig cachelagring, men de er også følsomme over for små ændringer pr. token ganget over millioner eller milliarder af tokens.

Teams, der bruger DeepSeek gennem OpenAI-kompatible grænseflader, bør ikke antage, at kompatibilitet beskytter dem mod faktureringsændringer. Anmodningen ser måske bekendt ud, men fakturaen følger stadig DeepSeeks modelspecifikke prissætningsregler.Adgang i antropisk format skaber det samme problem fra den anden retning: lettere integration fjerner ikke behovet for at forstå udbyderens faktureringskategorier.

Udviklere, der vedligeholder prisberegnere, forhandler-dashboards eller interne tilbageførselsværktøjer, bør opdatere antagelserne hurtigt. Hvis pristabellen i et produkt stadig behandler DeepSeek V4 som en enkelt flad pris pr. token, kan den undervurdere eller overvurdere reelt forbrug. Det kan forvrænge kundemargener, teambudgetter og modelvalgsbeslutninger.

Indkøbs- og økonomiteam bør også være opmærksomme. Dynamisk API-prissætning gør månedlige prognoser sværere. En arbejdsbyrde, der var overkommelig i test, kan opføre sig anderledes i produktionen, hvis brugertrafikken koncentreres i spidsbelastningsvinduer. Den samme risiko gælder for demoer, evaler og agentbenchmarks: En modelsammenligning, der køres på et tidspunkt af dagen, repræsenterer muligvis ikke økonomien ved at køre den samme arbejdsgang kontinuerligt.

Hvad teams skal gøre nu

Det umiddelbare skridt er at adskille teknisk migration fra finansiel validering. Der er muligvis ingen kodeændring påkrævet, hvis applikationer allerede kalder DeepSeek V4 Flash eller V4 Pro gennem understøttede API-formater. Men faktureringsantagelser, advarsler og dashboards har brug for en gennemgang.

Ingeniørteams bør identificere, hvilke DeepSeek-arbejdsbelastninger, der er interaktive, og hvilke der kan udskydes. Batch-opsummering, indlejring af tilstødende berigelse, analyse af depoter, generering af syntetiske data og evalueringspakker er kandidater til planlægning uden for spidsbelastningsperioder, hvis produktkrav tillader det. Agentframeworks bør ikke kun logge token-antal og model-id'er, men også anmode om tid, cache-hit-adfærd og outputvolumen.

Teams bør også gentjekke prompt-cache-strategi. Hvis genanvendelige kontekstblokke stadig er billigere end ikke-cachelagret input, forbliver caching værdifuld. Hvis cache-hit-priser er steget væsentligt for en specifik model og tidsvindue, kan det være værd at forkorte systemprompter, opdele arbejdsgange eller sammenligne en anden udbyder for gentagne opgaver med lang kontekst.

Det, der stadig er usikkert, er den nøjagtige prispåvirkning for hver arbejdsbyrde. DeepSeeks officielle dokumentation bekræfter modelformaterne, kontekstvinduet og faktureringskategorierne, der er synlige på prissiden, mens sekundære rapporter beskriver den 16. august peak/off-peak aktivering og prisstigninger. Det præcise omkostningsdelta afhænger af den aktuelle live-tabel, tidsanmodninger, der sendes, cache-adfærd og outputlængde.

Den bredere lektion er mindre usikker. LLM-priser er ved at blive operationelle. Modelvalg, anmodningstiming, cachedesign og budgetpolitik er nu forbundet. For udviklere og virksomheder er AI API-omkostningskontrol ikke længere kun en regnearksøvelse efter implementering; det er en del af, hvordan produktions-AI-systemer skal dirigeres.