DeepSeek V4.1 Flash: den nye pris-ydelsesrevolution inden for kinesisk AI
Skrevet af Gab
Indhold
DeepSeek V4.1 Flash præsenteres af @kimmonismus som en særligt hurtig videreudvikling, seks uger efter V4-Flash-opdateringen fra juli. Hans opslag gengiver de centrale tal: en Causal Encoder Decoder-arkitektur, 552 milliarder MoE-parametre, hvoraf 8 milliarder er aktive ved input og 16 milliarder under genereringen, samt en KV-cache, der er reduceret til en fjerdedel af HBM-forbruget og en ottendedel af SSD-lagerforbruget sammenlignet med den forrige generation. Han tilføjer, at DeepSeek nu skulle være bedre end DeepSeek V4 Pro med hensyn til kapacitet, omkostninger og hastighed, og at trafikken til V4 Pro midlertidigt skal omdirigeres til V4.1 Flash fra den 14. september.
Denne fortolkning er overordnet set tro mod annonceringen, men den lægger især vægt på udgivelsestempoet og produktspringet. Den officielle tråd giver et mere komplet billede: Gevinsterne tilskrives ikke kun arkitekturen, men også nye metoder til prætræning og en RL-eftertræning, der er gennemført i større skala. Frem for alt vedrører den mest operationelle ændring bag omtalen af en Flash-model, der er »mere intelligent, hurtigere og mere effektiv«, den hukommelse, der kræves til inferens over lange kontekster, hvilket er afgørende for AI-agenter.
Grafen, som @kimmonismus har delt, viser desuden en mindre entydig virkelighed end marketingfortællingen: DeepSeek V4.1 Flash er konkurrencedygtig i flere evalueringer, men dominerer ikke konsekvent de førende modeller på Terminal-Bench.
Opslaget fra @kimmonismus, som blev offentliggjort den 10. september, bygger udtrykkeligt på tråden fra DeepSeeks officielle konto. Dette er vigtigt: Tallene, migreringen af endpoints og løfterne om ydeevne stammer først og fremmest fra modeludvikleren og ikke fra analytikeren, der har sammenfattet dem.
Her er kildeopslaget, som DeepSeek offentliggjorde nogle timer tidligere:
Den officielle tråd: en ny familie, ikke blot en Flash-opdatering
I sit første opslag præsenterer @deepseek_ai V4.1 Flash som »den mindste model i vores nye arkitekturfamilie« med indbygget visuel forståelse. Positioneringen er tydelig: Flash er ikke længere blot en lettere variant, men den første model i en familie, der er udviklet med fokus på hastighed, gennemløb og skalering.
Anden del af tråden beskriver arkitekturen nærmere. DeepSeek V4.1 Flash er baseret på en MoE med 552 milliarder parametre, men aktiverer ikke hele netværket ved hvert trin. Ifølge DeepSeek er kun 8 milliarder parametre aktive under behandlingen af inputtet, og derefter 16 milliarder under genereringen.
Denne asymmetri udgør kernen i Causal Encoder Decoder-arkitekturen. Behandlingen af konteksten og produktionen af nye tokens har ikke længere samme omkostning og benytter ikke helt de samme ressourcer. Til anvendelser, der kræver læsning af en omfattende kontekst, før der genereres et relativt kort svar, kan denne opdeling forbedre forholdet mellem omkostninger og ydeevne.
Den officielle tabel sammenligner V4.1 Flash med V4 Pro 0813, V4 Flash 0731 og flere konkurrenter. Den angiver blandt andet 30,0 på Terminal-Bench 3.0, 31,2 på Terminal-Bench 4.0 og 74,2 på DeepSWE v1.1 for V4.1 Flash.
Vigtige benchmarks for DeepSeek V4.1 Flash
| Benchmark | Annonceret score for V4.1 Flash | Vurdering |
|---|---|---|
| Terminal-Bench 3.0 | 30,0 | V4.1 Flash ligger foran GLM 5.3 i den officielle tabel. |
| Terminal-Bench 4.0 | 31,2 | Modellen ligger fortsat efter GLM 5.3, der er angivet til 37,9. |
| DeepSWE v1.1 | 74,2 | Resultat, som DeepSeek fremhæver for softwareudviklingsopgaver. |
DeepSeek hævder, at virksomhedens nye prætræningsmetoder kombineret med en mere ambitiøs RL-eftertræning placerer modellen foran førende systemer, herunder DeepSeek V4 Pro. Denne præcisering er vigtig i forhold til @kimmonismus' opsummering: Arkitekturen er central, men den kan ikke alene forklare de hævdede resultater.
Den officielle formulering er bevidst enkel:
"Mindre KV-cache. Større besparelser." @deepseek_ai
Det mest konkrete løfte ved V4.1 Flash er derfor ikke nødvendigvis en højere rå score, men et markant lavere hukommelsesforbrug ved lange og gentagne arbejdsbelastninger.
DeepSeeks KV-cache, den egentlige løftestang for agenter
KV-cachen gemmer de nødvendige repræsentationer for at undgå at genberegne hele konteksten for hvert genereret token. Denne hukommelse er afgørende for lange samtaler, agenter, der kalder værktøjer, kodeworkflows, iterative søgninger og systemer, der bevarer en omfattende historik.
DeepSeek oplyser, at cachen i V4.1 Flash nu kun kræver:
- En fjerdedel af den HBM, som den forrige generation krævede.
- En ottendedel af den SSD-lagerplads, der tidligere var nødvendig.
- Omkring 890 byte pr. token i samlet cache sammenlignet med 3.514 byte for V4 Flash ifølge den graf, virksomheden har offentliggjort.
Den officielle visualisering viser et dramatisk fald siden DeepSeek-V1: 389.120 byte pr. token for V1, 48.068 for V3.2, 3.514 for V4 Flash og derefter 890 for V4.1 Flash.
For en agentoperatør kan denne forbedring være mere afgørende end en marginal forskel i en benchmark. Cache hits udgør ofte en betydelig del af regningen, når en agent hyppigt genbruger en omfattende kontekst. Komprimering af denne cache reducerer både presset på GPU-hukommelsen og den nødvendige lagerkapacitet i stor skala.
Det er netop dette, @datachad fremhæver i svarene på @kimmonismus' opslag:
"reduktionen af KV-cachen til en fjerdedel af HBM er det, der betyder noget for lokal inferens" @datachad
Observationen er korrekt, men den kræver nuancering. En mere kompakt DeepSeek KV-cache gør selvhosting af AI mere tilgængelig for infrastrukturer, der allerede har det nødvendige udstyr. Det gør dog ikke en MoE-model med 552 milliarder parametre til software, der er nem at køre på en personlig computer.
DeepSeek anerkender indirekte dette, når virksomheden selv omtaler implementeringer i en helt anden skala:
"Planlægger du en storstilet implementering med 2.000 GPU'er + en lagerklynge? Lad os tale sammen." @deepseek_ai
Cacheforbedringen giver en markant bedre driftsøkonomi, men den fjerner ikke den hardwaremæssige barriere, der skyldes modellens størrelse.
Modellen og dens tekniske rapport er tilgængelige via DeepSeek-V4.1-Flash-siden på Hugging Face og den tekniske rapport om DeepSeek V4.1. Det tilgængelige materiale i tråden gør det dog ikke muligt at bekræfte detaljerne i et svar fra @UnslothAI om »196B engram«. Denne oplysning bør derfor ikke behandles som en verificeret specifikation uden direkte gennemgang af den tekniske rapport.
En API-overgang, der gør Flash til standardproduktet
Annonceringen begrænser sig ikke til at promovere en ny model. Den omstrukturerer også DeepSeeks produktudvalg.
Den officielle tråd oplyser, at:
- V4 Flash og V4 Flash Vision Exp udfases.
- De tidligere identifikatorer
deepseek-v4-flashogdeepseek-v4-flash-vision-expomdirigeres midlertidigt til V4.1 Flash for at bevare kompatibiliteten. - Fra den 14. september 2026 kl. 04.00 UTC vil forespørgsler til DeepSeek V4 Pro også blive dirigeret til V4.1 Flash.
- Denne ordning skal fortsætte indtil lanceringen af V4.1 Pro.
- Forespørgsler, der migreres fra V4 Pro, faktureres efter priserne for V4.1 Flash.
Denne beslutning rækker langt ud over en reklamemæssig sammenligning. DeepSeek gør V4.1 Flash til sit primære API-produkt, allerede inden V4.1 Pro lanceres. For teams, der allerede bruger API'et, reducerer migreringen risikoen for en umiddelbar driftsforstyrrelse. Den fjerner dog ikke behovet for at validere output, latenstid, værktøjskald, integreret vision og modellens adfærd i produktion på ny.
@bygregorr opsummerer problemet fra applikationsudviklernes perspektiv:
"Seks uger mellem arkitekturfamilier er en kort overgangsperiode for API-udviklere." @bygregorr
DeepSeek reagerer med midlertidig kompatibilitet og routing af de tidligere identifikatorer. Det er en pragmatisk løsning med hensyn til driftskontinuitet, men ikke en garanti for fuldstændig funktionel ækvivalens. En agentbaseret applikation, der er følsom over for outputformater, værktøjskald eller ræsonneringspolitikker, skal stadig testes igen.
DeepSeeks pristabel viser forskellige priser afhængigt af tidspunktet, pr. million tokens. Uden for spidsbelastningsperioder angiver den 0,003 dollar for input med cache, 0,15 dollar for input uden cache og 0,6 dollar for output. I spidsbelastningsperioder stiger beløbene til henholdsvis 0,006, 0,3 og 1,2 dollar.
DeepSeek præciserer, at priserne uden for spidsbelastning udgør 50 % af priserne i spidsbelastningsperioder. Denne prismodel gør fleksible workloads endnu mere økonomisk attraktive, især batchbehandling, automatiserede evalueringer og asynkrone agentbaserede opgaver.
Et tredjepartsopslag fra @ns123abc, som nævnes i den bredere diskussion, omtaler en kørsel, der er cirka 86 gange billigere pr. million tokens, og en hastighed på 420 til 507 tokens pr. sekund. Disse tal kan bidrage til debatten, men de fremgår ikke af den officielle tråd, der er angivet her. De bør derfor betragtes som tredjepartspåstande, der afhænger af hardware, kontekstlængde, kvantiseringsniveau og den testede belastning, og ikke som bekræftede data fra DeepSeek.
Terminal-Bench: annonceret dominans, men ikke en universel dom
DeepSeek hævder, at »tests by multiple parties« placerer V4.1 Flash foran V4 Pro med hensyn til ydeevne, omkostninger, hastighed og samlet kørselstid. Denne påstand kan understøtte modellens komparative positionering, men tråden dokumenterer ikke testprotokollerne, udbyderne, inferensindstillingerne eller den præcise sammensætning af disse tests tilstrækkeligt.
Det største stridspunkt vedrører Terminal-Bench, en benchmark, der følges særligt tæt for at evaluere agentbaserede færdigheder inden for computerbrug og programmering.
@Greg_GL_87 påpeger en tilsyneladende uoverensstemmelse mellem to versioner af evalueringen:
"tabellen viser, at den taber Terminal-Bench 4.0 til GLM 5.3 med 31,2 mod 37,9, men vinder 3.0. mærkelig forskel mellem to versioner af den samme evaluering" @Greg_GL_87
Denne kritik fik ikke noget svar i tråden. Den er præcis og vigtig. Den officielle tabel viser ganske rigtigt 31,2 for V4.1 Flash i Terminal-Bench 4.0, mens @Greg_GL_87 sammenligner dette resultat med GLM 5.3's 37,9. Samtidig opnår V4.1 Flash 30,0 i Terminal-Bench 3.0 og ligger her foran GLM 5.3.
En model kan slå V4 Pro på flere parametre uden at være det bedste valg til alle agentbaserede kodeopgaver. Uden en detaljeret protokol er det fortsat umuligt at afgøre, om forskellen mellem Terminal-Bench 3.0 og 4.0 skyldes opgaverne, miljøerne, testparametrene eller en anden metodisk faktor.
@kryptosopus fremsætter en bredere indvending ved at sammenligne V4.1 Flash med Claude Opus 5:
"Indbygget vision i den mindste model, men den taber stadig Terminal-Bench til Opus5 med 13 point. Flash er tydeligvis det »billige og hurtige« valg, ikke frontlinjemodellen. Skaleringslinjen nederst er det, der virkelig afslører det" @kryptosopus
Denne fortolkning modsiger ikke fuldstændigt DeepSeeks. V4.1 Flash kan være bedre end DeepSeek V4 Pro ifølge flere af virksomhedens valgte målepunkter og samtidig ligge efter Opus 5 i en bestemt agentbaseret benchmark. Problemet opstår, når en relativ forbedring inden for en produktserie omdannes til en påstand om generel overlegenhed.
Reaktioner: begejstring for open source, produktmæssig forsigtighed og spørgsmål om den kommende Pro-version
Svarene på den officielle tråd er overvejende begejstrede for modellens åbenhed og hurtige integration. @MrAhmadAwais oplyser eksempelvis, at V4.1 Flash allerede er tilgængelig i hans CommandCodeAI-tilbud. @Presidentlin roser især DeepSeeks bidrag til open source-økosystemet:
"Endnu en gang tak for at bringe Open Source fremad" "Som altid oblig" "Hvor højt går jeres loft?!!" @Presidentlin
Svaret var ledsaget af en mangastribe, som illustrerer denne blanding af fascination og udfordring over for DeepSeeks tempo.
@ParthM1001 opsummerer på sin side stemningen med en kulinarisk metafor:
"Hvalen har endnu en gang tilberedt noget smukt." @ParthM1001
Svarene på @kimmonismus' opslag fokuserer i højere grad på produktseriens positionering. @elshayib_ mener, at den tidligere Pro-version har mistet sin relevans:
"V4 pro er lidt irrelevant nu" @elshayib_
@kimmonismus svarer:
"ja, venter bare på endnu en udgivelse af pro-versionen" @kimmonismus
Dette svar stemmer overens med den officielle meddelelse: V4 Pro er ganske rigtigt ved at blive udfaset midlertidigt, men DeepSeek annoncerer udtrykkeligt en kommende V4.1 Pro. At konkludere, at hele Pro-serien definitivt er overflødig, går derfor videre end de fastslåede fakta.
Det samme spørgsmål dukker op hos @RimasXYZ:
"Hvis Flash nu slår V4 Pro på kapacitet, pris og hastighed, hvad er der så tilbage for V4.1 Pro at vinde på?" @RimasXYZ
Tråden besvarer ikke dette spørgsmål. Den lader definitionen af det kommende Pro-produkt stå helt åben: højere kvalitet på vanskelige opgaver, forbedrede ræsonnementsevner, længere kontekst, agentisk pålidelighed eller et andet kompromis mellem forskellige ydeevneparametre.
Causal Encoder Decoder-arkitekturen: Hvad ændrer sig teknisk?
Reaktionen fra @austinyuhao, »velkommen tilbage, encoder-decoder«, er kort, men relevant. DeepSeek tilbyder ikke blot cachekomprimering, men genindfører en arkitektonisk opdeling mellem den kausale kodningsvej og dekoderen.
"velkommen tilbage, encoder-decoder" @austinyuhao
Diagrammet, der deles i svaret, viser en Causal Encoder og en Decoder med hver tyve lag, hvilket giver et samlet netværk på fyrre lag. Det viser også komponenterne MoE, CSA2, SWA, Vision Encoder, Text Embedding, Engram, DSpark og Candidate Pool.
Denne organisering forklarer, hvorfor multimodal inferens og KV-cache hænger sammen. DeepSeek forsøger at understøtte vision direkte og samtidig holde omkostningerne på et rimeligt niveau ved lange sekvenser. Løftet er særligt attraktivt for agenter, der skal læse dokumenter, analysere brugergrænseflader, arbejde med kode og bevare en vedvarende arbejdshukommelse.
FAQ om DeepSeek V4.1 Flash
Hvor mange parametre er aktive i DeepSeek V4.1 Flash?
DeepSeek annoncerer en MoE-model med 552 milliarder parametre. Kun 8 milliarder parametre skulle være aktive under behandlingen af inputtet og derefter 16 milliarder under genereringen.
Hvorfor er DeepSeeks KV-cache vigtig for AI-agenter?
En KV-cache gør det muligt at bevare repræsentationerne af den kontekst, der allerede er behandlet. En mere kompakt cache reducerer behovet for GPU-hukommelse og lagerplads, hvilket kan sænke omkostningerne ved lange samtaler, agenter med værktøjskald og workflows, der ofte genbruger den samme kontekst.
Hvad sker der for brugerne af DeepSeek V4 Pro?
Fra den 14. september 2026 kl. 04.00 UTC skal forespørgsler til DeepSeek V4 Pro midlertidigt omdirigeres til V4.1 Flash, indtil V4.1 Pro lanceres. De berørte teams skal validere deres anvendelser i produktion på ny, selv om API-kompatibiliteten opretholdes under overgangen.
Det vigtigste at huske
DeepSeek V4.1 Flash er ikke blot endnu en hurtig opdatering. Annonceringen kombinerer en ny asymmetrisk arkitektur, differentieret MoE-aktivering mellem input og generering, en kraftig komprimering af KV-cachen, aggressive API-priser og en konkret migrering af trafik fra V4 Pro.
For professionelle er konsekvenserne tydelige:
- Den reducerede KV-cache kan sænke omkostningerne væsentligt for agenter med lang kontekst.
- Selvhosting af AI bliver mere realistisk for operatører, der allerede råder over en omfattende infrastruktur.
- Omdirigeringen fra V4 Pro til Flash kræver en fase med validering af applikationerne.
- De hævdede præstationsforbedringer i forhold til V4 Pro er ikke tilstrækkelige til at fastslå en førerposition på tværs af alle agentiske benchmarks.
- Terminal-Bench er fortsat et opmærksomhedspunkt, især på grund af den forskel mellem version 3.0 og 4.0, som @Greg_GL_87 har påpeget.
Tråden efterlader derfor flere åbne spørgsmål: Hvilke protokoller ligger til grund for »test udført af flere parter«, hvorfor varierer resultaterne afhængigt af versionen af Terminal-Bench, hvilken særlig rolle får V4.1 Pro, og hvilken hardwarekonfiguration gør i praksis selvhosting realistisk?
Den mest rimelige konklusion er også den mest nyttige: V4.1 Flash ser ud til at være et stort fremskridt inden for effektivitet og implementering, men det beviser endnu ikke, at en Flash-model har elimineret de kompromiser, der kendetegner frontier-modeller.