DeepSeek-AI har udgivet en preview-version af DeepSeek-V4-serien. Serien består af to Mixture-of-Experts-modeller, DeepSeek-V4-Pro og DeepSeek-V4-Flash, og begge understøtter nativt et kontekstvindue på én million tokens. MarkTechPost angiver, at DeepSeek-V4-Pro har 1,6 billioner parametre i alt og aktiverer 49 milliarder parametre per token, mens DeepSeek-V4-Flash har 284 milliarder parametre i alt og aktiverer 13 milliarder parametre per token. Checkpoints for Pro, Pro-Base, Flash og Flash-Base ligger ifølge samme kilde offentligt på Hugging Face.
Det er den slags tal, der hurtigt bliver til ren pral i AI-land. Men her er der faktisk en mere interessant historie under motorhjelmen. DeepSeek prøver ikke kun at sige “vores model er større”. De prøver at gøre ekstrem lang kontekst mindre upraktisk ved inferens, og det er en vigtig forskel.
Det nye er ikke bare størrelsen
DeepSeek-V4-Pro blev ifølge de tilgængelige oplysninger prætrænet på 33 billioner tokens, mens Flash blev prætrænet på 32 billioner. Det er voldsomt, ja. Men nyheden ligger et andet sted, nemlig i arkitekturen bag den lange kontekst og i forsøget på at gøre én million tokens brugbart uden at regningen eksploderer helt ud af vinduet.
Det problem er velkendt. Standard attention i transformere vokser kvadratisk med sekvenslængden, så når konteksten bliver meget længere, stiger både beregning og hukommelsesforbrug hårdt. Ved én million tokens bliver det hurtigt så dyrt, at man ikke bare kan løse det ved at hælde mere hardware på. Der skal ændringer til i selve måden modellen læser på.
DeepSeek beskriver fire centrale greb i V4: en hybrid attention-arkitektur, et nyt residual-design, en anden optimizer og FP4 quantization-aware training. Det sidste er teknisk, og vi gider ikke gå helt ned i hver skrue her. Pointen er bare, at de ikke kun har skiftet én komponent ud og kaldt det en ny generation.
CSA og HCA er den egentlige historie
Kernen er en hybrid attention-mekanisme, der kombinerer Compressed Sparse Attention, CSA, og Heavily Compressed Attention, HCA, på tværs af transformerlag. Det lyder tørt. Men det er i praksis et forsøg på at få modellen til at huske mere selektivt, i stedet for at læse alt lige grundigt hele tiden.
CSA fungerer ved, at Key-Value-cachen for hver blok af m tokens komprimeres til én post med en lært token-kompressor. Derefter bruger modellen sparse attention, så hver query kun kigger på top-k udvalgte komprimerede KV-poster. Lightning Indexer står for den udvælgelse ved at score queries mod de komprimerede KV-blokke. Det er ret elegant på papiret.
Både CSA og HCA har også en sliding-window attention-gren, der dækker de seneste tokens for lokal afhængighedsmodellering. Det er vigtigt. Ellers ville modellen risikere at blive for optaget af komprimerede oversigter og miste grebet om det nære tekstforløb, altså det der lige blev sagt for få linjer siden.
Hård komprimering er smart, men ikke gratis
HCA er den mere aggressive variant. Her samles Key-Value-poster fra større tokenblokke i en enkelt komprimeret post. De blokke er væsentligt større end i CSA. Hvor CSA stadig prøver at vælge selektivt mellem komprimerede bidder, går HCA hårdere til værks og reducerer simpelthen mængden af materiale, der skal holdes styr på.
Oversat til almindeligt arbejdssprog: modellen forsøger at have et indeks over arkivet, ikke kun et fotografisk minde om alt. Det kan være præcis det, der gør lange dokumentforløb mere realistiske i praksis. Men et indeks kan også pege forkert. Og hvis komprimering eller routing misser det ene afsnit, der faktisk betyder noget, så hjælper det ikke meget, at resten af svaret lyder selvsikkert.
Det er også derfor, én million tokens ikke automatisk betyder bedre svar. Mere kontekst kan lige så godt blive til mere støj. Vi har set nok AI-opsætninger til at vide, at store inputflader ser flotte ud i en demo, men mandag morgen handler det om svartid, stabilitet og om modellen stadig kan finde den ene detalje, ingen må overse.
Hvor det kan blive relevant i praksis
Hvis DeepSeek har fat i noget her, så er det især i tunge dokumentflows. Juridiske sager, compliance-materiale, teknisk dokumentation, forskningsopsamlinger og store supportbiblioteker er oplagte steder at kigge. I de miljøer går meget ofte tabt, når man splitter materialet aggressivt op i små bidder og håber, at retrieval limer det sammen igen.
Det samme gælder større kodebaser. En model med meget lang kontekst kan i princippet arbejde mere direkte på tværs af kode, dokumentation og fejlspor i samme arbejdsgang. Det er interessant. Men kun hvis latency og omkostning holder, og kun hvis kvaliteten ikke falder, når modellen begynder at komprimere hårdt længere tilbage i forløbet.
Her bliver tradeoffet ret jordnært. Lang kontekst ændrer ikke behovet for retrieval, caching eller evaluering. Den flytter bare grænsen for, hvornår det giver mening at proppe mere direkte ind i modellen, og hvornår det stadig er smartere at hente præcist det rigtige frem. Den forskel opdager man først, når man sidder med workflowet i hænderne.
Det åbne spørgsmål er drift, ikke slides
Der er en grund til, at preview-status betyder noget. De tilgængelige kilder er gode på modeldesign, parametre og de overordnede arkitekturvalg. De er langt mindre konkrete om real-world latency, hardwarekrav, performance under belastning og hvor robust modellen er over meget lange forløb. Det er ikke en lille detalje. Det er i virkeligheden hovedregningen.
For tekniske ledere og produktfolk er de oplagte spørgsmål derfor ret enkle. Hvor mange GPU-ressourcer kræver det her i praksis. Hvad sker der med svartider, når mange brugere rammer systemet samtidig. Hvordan observerer man fejl, hvis modellen både router og komprimerer information undervejs. Og hvornår skal der være en fallback, hvis lang kontekst bliver for dyr eller for langsom.
Den del bliver ofte glemt i lanceringer. Ikke fordi den er uinteressant, tværtimod, men fordi den er mindre sexet end benchmark-grafik. Hos os er det tit dér projekter enten bliver nyttige eller bare bliver endnu en dyr prototype med flotte screenshots.
Pris og licens kan presse markedet, men med forbehold
VentureBeat rapporterer, at DeepSeek-V4 er tilgængelig gratis under MIT-licens. Mediet skriver også, at modellen nærmer sig, eller på nogle benchmarks overgår, førende lukkede modeller til cirka en sjettedel af API-omkostningen. Det er potentielt en stor historie i sig selv, især hvis open source-modeller igen begynder at presse de lukkede spillere på både pris og ydeevne.
Men attributionen betyder noget her. De oplysninger kommer fra VentureBeat som sekundær kilde, og vi har ikke i det fremlagte materiale selvstændige benchmark-tabeller eller en uafhængig omkostningsanalyse, der lukker diskussionen. Så ja, interessant. Men ikke noget man bør læse som en endelig dom over markedet endnu.
Samlet set ligner DeepSeek-V4 et reelt teknologisk skridt, ikke bare endnu et stort tal i en pressehistorie. Den vigtige test bliver bare ikke, om modellen kan holde én million tokens i en demo. Den bliver, om den kan gøre det med ordentlig pris, ordentlig svartid og ordentlig pålidelighed, når data er rodede og brugerne er helt almindelige mennesker.
