DeepSeek V4.1 Flash: Kinas nye AI-revolusjon innen pris og ytelse
Skrevet av Gab
Innhold
DeepSeek V4.1 Flash presenteres av @kimmonismus som en spesielt rask videreutvikling, seks uker etter V4-Flash-oppdateringen i juli. Innlegget hans gjengir nøkkeltallene: en Causal Encoder Decoder-arkitektur, 552 milliarder MoE-parametere, hvorav 8 milliarder er aktive under inndatafasen og 16 milliarder under generering, samt en KV-cache som er redusert til en fjerdedel av HBM-minnet og en åttendedel av SSD-lagringen sammenlignet med forrige generasjon. Han legger til at DeepSeek nå skal være bedre enn DeepSeek V4 Pro når det gjelder kapasitet, kostnader og hastighet, og at trafikken til V4 Pro midlertidig skal rutes til V4.1 Flash fra 14. september.
Denne tolkningen er i hovedsak tro mot kunngjøringen, men den legger først og fremst vekt på lanseringstakten og produktforbedringen. Den offisielle tråden gir et mer fullstendig bilde: Forbedringene tilskrives ikke bare arkitekturen, men også nye metoder for forhåndstrening og RL-ettertrening gjennomført i større skala. Fremfor alt er den mest praktiske endringen bak omtalen av en Flash-modell som er «smartere, raskere og mer effektiv», knyttet til minnebehovet ved inferens over lange kontekster, et avgjørende tema for KI-agenter.
Grafen som @kimmonismus deler, viser dessuten en mindre entydig virkelighet enn markedsføringen antyder: DeepSeek V4.1 Flash er konkurransedyktig i flere evalueringer, men dominerer ikke konsekvent de ledende modellene i Terminal-Bench.
Innlegget fra @kimmonismus, publisert 10. september, bygger uttrykkelig på tråden fra den offisielle DeepSeek-kontoen. Dette er et viktig poeng: Tallene, migreringen av endepunktene og ytelsesløftene kommer først og fremst fra modellutvikleren, ikke fra analytikeren som har oppsummert dem.
Her er kildeinnlegget, publisert av DeepSeek noen timer tidligere:
Den offisielle tråden: en ny familie, ikke bare en Flash-oppdatering
I sitt første innlegg presenterer @deepseek_ai V4.1 Flash som «den minste modellen i vår nye arkitekturfamilie», med innebygd visuell forståelse. Posisjoneringen er tydelig: Flash er ikke lenger bare en lettvektsvariant, men den første modellen i en familie utviklet med tanke på hastighet, gjennomstrømning og skalering.
Den andre delen av tråden beskriver arkitekturen nærmere. DeepSeek V4.1 Flash er basert på en MoE med 552 milliarder parametere, men bruker ikke hele nettverket i hvert trinn. Ifølge DeepSeek er bare 8 milliarder parametere aktive under behandlingen av inndata, og deretter 16 milliarder under genereringen.
Denne asymmetrien utgjør kjernen i Causal Encoder Decoder-arkitekturen. Behandlingen av konteksten og produksjonen av nye tokener har ikke lenger samme kostnad og bruker heller ikke nøyaktig de samme ressursene. For bruksområder som krever at en omfattende kontekst leses før det genereres et relativt kort svar, kan dette skillet forbedre forholdet mellom kostnad og ytelse.
Den offisielle tabellen sammenligner V4.1 Flash med V4 Pro 0813, V4 Flash 0731 og flere konkurrenter. Den oppgir blant annet 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.
Viktige benchmarkresultater for DeepSeek V4.1 Flash
| Benchmark | Oppgitt poengsum for V4.1 Flash | Vurdering |
|---|---|---|
| Terminal-Bench 3.0 | 30,0 | V4.1 Flash ligger foran GLM 5.3 i den offisielle tabellen. |
| Terminal-Bench 4.0 | 31,2 | Modellen ligger fortsatt bak GLM 5.3, som er oppført med 37,9. |
| DeepSWE v1.1 | 74,2 | Resultat som DeepSeek fremhever for programvareutviklingsoppgaver. |
DeepSeek hevder at de nye metodene for forhåndstrening, kombinert med en mer ambisiøs RL-ettertrening, plasserer modellen foran ledende systemer, deriblant DeepSeek V4 Pro. Denne presiseringen er viktig sammenlignet med oppsummeringen fra @kimmonismus: Arkitekturen står sentralt, men den forklarer ikke alene resultatene som hevdes.
Den offisielle formuleringen er bevisst enkel:
"Mindre KV-cache. Større besparelser." @deepseek_ai
Det mest konkrete løftet med V4.1 Flash er derfor ikke nødvendigvis en høyere rå poengsum, men et betydelig lavere minneforbruk for lange og repetitive arbeidsbelastninger.
DeepSeeks KV-cache, den virkelige drivkraften for agenter
KV-cachen lagrer de nødvendige representasjonene for å unngå å beregne hele konteksten på nytt for hvert token som genereres. Dette minnet er avgjørende for lange samtaler, agenter som kaller verktøy, arbeidsflyter for kode, iterative søk og systemer som bevarer en omfattende historikk.
DeepSeek opplyser at cachen til V4.1 Flash nå bare krever:
- En fjerdedel av HBM-minnet som forrige generasjon krevde.
- En åttendedel av SSD-lagringen som tidligere var nødvendig.
- Omtrent 890 byte per token med samlet cache, mot 3 514 byte for V4 Flash ifølge grafen selskapet har publisert.
Den offisielle illustrasjonen viser en dramatisk nedgang siden DeepSeek-V1: 389 120 byte per token for V1, 48 068 for V3.2, 3 514 for V4 Flash og deretter 890 for V4.1 Flash.
For en agentoperatør kan denne forbedringen være viktigere enn en marginal forskjell i en benchmark. Cachetreff utgjør ofte en betydelig del av kostnadene når en agent ofte gjenbruker en omfattende kontekst. Komprimering av denne cachen reduserer både belastningen på GPU-minnet og lagringskapasiteten som kreves i stor skala.
Det er nettopp dette @datachad påpeker i svarene på innlegget fra @kimmonismus:
"reduksjonen av KV-cachen til en fjerdedel av HBM-minnet er det som betyr noe for lokal inferens" @datachad
Observasjonen er riktig, men må nyanseres. En mer kompakt DeepSeek KV-cache gjør selvhosting av KI mer tilgjengelig for infrastrukturer som allerede har nødvendig utstyr. Det gjør likevel ikke en MoE-modell med 552 milliarder parametere til programvare som er enkel å kjøre på en personlig datamaskin.
DeepSeek erkjenner dette indirekte når selskapet selv omtaler utrullinger i en helt annen skala:
"Planlegger du en storskala utrulling med 2 000 GPU-er + en lagringsklynge? La oss snakke sammen." @deepseek_ai
Cacheforbedringen gir langt bedre driftsøkonomi, men den fjerner ikke maskinvarebarrieren som følger av modellens størrelse.
Modellen og den tekniske rapporten er tilgjengelige via Hugging Face-siden for DeepSeek-V4.1-Flash og den tekniske rapporten for DeepSeek V4.1. Materialet som er tilgjengelig i tråden, gjør det imidlertid ikke mulig å bekrefte detaljene som @UnslothAI oppgir i et svar om «196B engram». Denne opplysningen bør derfor ikke behandles som en verifisert spesifikasjon uten at den tekniske rapporten leses direkte.
En API-overgang som gjør Flash til standardproduktet
Kunngjøringen begrenser seg ikke til å promotere en ny modell. Den omorganiserer også DeepSeek-sortimentet.
Den offisielle tråden opplyser at:
- V4 Flash og V4 Flash Vision Exp trekkes tilbake.
- De gamle identifikatorene
deepseek-v4-flashogdeepseek-v4-flash-vision-expomdirigeres midlertidig til V4.1 Flash for å bevare kompatibiliteten. - Fra og med 14. september 2026 kl. 04:00 UTC vil forespørsler til DeepSeek V4 Pro også bli rutet til V4.1 Flash.
- Denne ordningen skal vare frem til lanseringen av V4.1 Pro.
- Forespørsler som migreres fra V4 Pro, vil bli fakturert etter prisene for V4.1 Flash.
Denne beslutningen går langt utover en markedsføringsmessig sammenligning. DeepSeek gjør V4.1 Flash til sitt primære API-produkt allerede før V4.1 Pro lanseres. For team som allerede bruker API-et, reduserer migreringen risikoen for umiddelbare driftsavbrudd. Den fjerner imidlertid ikke behovet for å validere utdata, latens, verktøykall, innebygd bildebehandling og modellens oppførsel i produksjon på nytt.
@bygregorr oppsummerer problemet fra applikasjonsutviklernes ståsted:
"Seks uker mellom arkitekturfamilier er kort tid for API-utviklere." @bygregorr
DeepSeek svarer med midlertidig kompatibilitet og ruting av de gamle identifikatorene. Dette er en pragmatisk løsning for å sikre kontinuitet i tjenesten, men ingen garanti for full funksjonell ekvivalens. En agentbasert applikasjon som er følsom for utdataformater, verktøykall eller retningslinjer for resonnering, må likevel testes på nytt.
DeepSeeks pristabell viser ulike priser avhengig av tidspunktet på døgnet, per million tokens. Utenom topptid oppgis 0,003 dollar for inndata med cache, 0,15 dollar for inndata uten cache og 0,6 dollar for utdata. I topptiden øker disse beløpene til henholdsvis 0,006, 0,3 og 1,2 dollar.
DeepSeek presiserer at prisene utenom rushtid utgjør 50 % av prisene i rushtiden. Denne prismodellen gjør fleksible arbeidslaster enda mer økonomisk attraktive, særlig batchbehandling, automatiserte evalueringer og asynkrone agentbaserte oppgaver.
Et tredjepartsinnlegg fra @ns123abc, som nevnes i den bredere diskusjonen, viser til en kjøring som er omtrent 86 ganger billigere per million tokens, og en gjennomstrømning på 420 til 507 tokens per sekund. Disse tallene kan bidra til debatten, men de finnes ikke i den oppgitte offisielle tråden. De må derfor betraktes som tredjepartspåstander som avhenger av maskinvare, kontekstlengde, kvantiseringsnivå og den testede belastningen, og ikke som bekreftede data fra DeepSeek.
Terminal-Bench: varslet dominans, men ingen universell dom
DeepSeek hevder at «tester utført av flere parter» plasserer V4.1 Flash foran V4 Pro når det gjelder ytelse, kostnader, hastighet og samlet kjøretid. Denne påstanden kan underbygge modellens relative posisjonering, men tråden dokumenterer ikke testprotokollene, leverandørene, inferensinnstillingene eller den nøyaktige sammensetningen av disse testene tilstrekkelig.
Det viktigste stridspunktet gjelder Terminal-Bench, en benchmark som følges spesielt nøye for å evaluere agentbaserte ferdigheter innen datamaskinbruk og programmering.
@Greg_GL_87 påpeker en tilsynelatende uoverensstemmelse mellom to versjoner av evalueringen:
"tabellen viser at den taper Terminal-Bench 4.0 mot GLM 5.3, 31,2 mot 37,9, men vinner 3.0. merkelig sprik mellom to versjoner av samme evaluering" @Greg_GL_87
Denne kritikken fikk ikke noe svar i tråden. Den er presis og viktig. Den offisielle tabellen viser faktisk 31,2 for V4.1 Flash på Terminal-Bench 4.0, mens @Greg_GL_87 sammenligner denne poengsummen med 37,9 for GLM 5.3. Samtidig oppnår V4.1 Flash 30,0 på Terminal-Bench 3.0 og ligger der foran GLM 5.3.
En modell kan slå V4 Pro på flere måleparametere uten å være det beste valget for alle agentbaserte kodeoppgaver. Uten en detaljert protokoll er det fortsatt umulig å fastslå om forskjellen mellom Terminal-Bench 3.0 og 4.0 skyldes oppgavene, miljøene, testparameterne eller en annen metodisk faktor.
@kryptosopus fremsetter en bredere innvending ved å sammenligne V4.1 Flash med Claude Opus 5:
"Integrert visjon i den minste modellen, men den taper fortsatt Terminal-Bench mot Opus5 med 13 poeng. Flash er helt klart det «billige og raske» valget, ikke det mest avanserte. Skaleringslinjen nederst er det som virkelig avslører dette" @kryptosopus
Denne tolkningen motsier ikke DeepSeeks syn fullt ut. V4.1 Flash kan være bedre enn DeepSeek V4 Pro ifølge flere av måleparameterne selskapet har valgt, samtidig som den ligger bak Opus 5 på en bestemt agentbasert benchmark. Problemet oppstår når en relativ forbedring innenfor en produktserie gjøres om til en påstand om global overlegenhet.
Reaksjoner: entusiasme for åpen kildekode, produktmessig forsiktighet og spørsmål om den kommende Pro-versjonen
Svarene på den offisielle tråden er i stor grad entusiastiske når det gjelder modellens åpne tilgjengelighet og raske integrering. @MrAhmadAwais opplyser for eksempel at V4.1 Flash allerede er tilgjengelig i CommandCodeAI-tilbudet hans. @Presidentlin roser først og fremst DeepSeeks bidrag til økosystemet for åpen kildekode:
"Takk igjen for at dere driver åpen kildekode fremover" "Som alltid obligatorisk" "Hvor høyt er taket deres?!!" @Presidentlin
Svaret var ledsaget av en mangasstripe som visualiserer denne blandingen av fascinasjon og utfordring i møte med DeepSeeks lanseringstakt.
@ParthM1001 oppsummerer på sin side stemningen med en kulinarisk metafor:
"Hvalen har laget noe vakkert igjen." @ParthM1001
Svarene på innlegget fra @kimmonismus handler i større grad om posisjoneringen av produktserien. @elshayib_ mener at den tidligere Pro-versjonen har mistet sin relevans:
"V4 pro er på en måte irrelevant nå" @elshayib_
@kimmonismus svarer:
"ja, venter bare på en ny utgave av pro-versjonen" @kimmonismus
Dette svaret er i tråd med den offisielle kunngjøringen: V4 Pro er faktisk i ferd med å bli midlertidig trukket tilbake, men DeepSeek varsler uttrykkelig en kommende V4.1 Pro. Å konkludere med at hele Pro-serien definitivt er overflødig, går derfor lenger enn de etablerte faktaene tilsier.
Det samme spørsmålet dukker opp hos @RimasXYZ:
«Hvis Flash nå slår v4-pro på kapasitet, kostnad og hastighet, hva gjenstår det da for v4.1-pro å vinne på?» @RimasXYZ
Tråden gir ikke noe svar på dette spørsmålet. Den lar definisjonen av det fremtidige Pro-produktet stå åpen: bedre kvalitet på vanskelige oppgaver, styrkede resonneringsevner, lengre kontekst, agentisk pålitelighet eller et annet ytelseskompromiss.
Arkitektur med kausal enkoder-dekoder: Dette endres teknisk
Reaksjonen fra @austinyuhao, «velkommen tilbake, enkoder-dekoder», er kort, men relevant. DeepSeek foreslår ikke bare komprimering av hurtigbufferen, men gjeninnfører et arkitektonisk skille mellom den kausale enkodingsbanen og dekoderen.
«Velkommen tilbake, enkoder-dekoder» @austinyuhao
Diagrammet som deles i svaret, viser en Causal Encoder og en Decoder med tjue lag hver, i et nettverk med totalt førti lag. Det viser også komponentene MoE, CSA2, SWA, Vision Encoder, Text Embedding, Engram, DSpark og Candidate Pool.
Denne organiseringen forklarer hvorfor multimodal inferens og KV-hurtigbufferen henger sammen. DeepSeek ønsker å tilby innebygd støtte for synsdata, samtidig som kostnadene holdes på et rimelig nivå for lange sekvenser. Dette er spesielt attraktivt for agenter som må lese dokumenter, analysere grensesnitt, håndtere kode og opprettholde et vedvarende arbeidsminne.
Vanlige spørsmål om DeepSeek V4.1 Flash
Hvor mange parametere er aktive i DeepSeek V4.1 Flash?
DeepSeek annonserer en MoE-modell med 552 milliarder parametere. Bare 8 milliarder parametere skal være aktive under behandling av inndata, og deretter 16 milliarder under generering.
Hvorfor er DeepSeeks KV-hurtigbuffer viktig for KI-agenter?
KV-hurtigbufferen gjør det mulig å bevare representasjonene av konteksten som allerede er behandlet. En mer kompakt hurtigbuffer reduserer behovet for GPU-minne og lagringsplass, noe som kan senke kostnadene for lange samtaler, agenter med verktøykall og arbeidsflyter som ofte gjenbruker den samme konteksten.
Hva skjer med brukerne av DeepSeek V4 Pro?
Fra og med 14. september 2026 kl. 04:00 UTC må forespørsler til DeepSeek V4 Pro midlertidig rutes til V4.1 Flash, frem til lanseringen av V4.1 Pro. De berørte teamene må validere produksjonsbruken på nytt, selv om API-kompatibiliteten opprettholdes under overgangen.
Dette er det viktigste
DeepSeek V4.1 Flash er ikke bare enda en rask oppdatering. Kunngjøringen kombinerer en ny asymmetrisk arkitektur, differensiert MoE-aktivering for inndata og generering, kraftig komprimering av KV-hurtigbufferen, aggressive API-priser og en konkret migrering av trafikk fra V4 Pro.
For profesjonelle brukere er konsekvensene tydelige:
- En redusert KV-hurtigbuffer kan gi betydelig lavere kostnader for agenter med lang kontekst.
- Selvhosting av KI blir mer realistisk for operatører som allerede har omfattende infrastruktur.
- Omdirigeringen fra V4 Pro til Flash krever en fase med applikasjonsvalidering.
- Den oppgitte ytelsen sammenlignet med V4 Pro er ikke nok til å fastslå dominans på tvers av alle agentbaserte referansetester.
- Terminal-Bench er fortsatt et punkt som krever oppmerksomhet, særlig på grunn av avviket mellom versjon 3.0 og 4.0 som @Greg_GL_87 har påpekt.
Tråden lar dermed flere spørsmål stå ubesvart: Hvilke protokoller underbygger «tester utført av flere parter», hvorfor varierer resultatene mellom ulike versjoner av Terminal-Bench, hva blir den særskilte rollen til V4.1 Pro, og hvilken maskinvarekonfigurasjon gjør selvhosting praktisk i virkeligheten?
Den mest fornuftige konklusjonen er også den mest nyttige: V4.1 Flash ser ut til å være et stort fremskritt når det gjelder effektivitet og utrulling, men modellen beviser ennå ikke at en Flash-modell har eliminert kompromissene som kjennetegner frontier-modeller.