DeepSeek V4.1 Flash: den kinesiska AI:ns nya pris-prestandarevolution
Skriven av Gab
Innehåll
DeepSeek V4.1 Flash presenteras av @kimmonismus som en särskilt snabb vidareutveckling, sex veckor efter uppdateringen V4-Flash i juli. Hans inlägg återger de centrala siffrorna: en Causal Encoder Decoder-arkitektur, 552 miljarder MoE-parametrar, varav 8 miljarder är aktiva vid inmatning och 16 miljarder under generering, samt en KV-cache som har reducerats till en fjärdedel av HBM-minnet och en åttondel av SSD-lagringen jämfört med föregående generation. Han tillägger att DeepSeek numera skulle överträffa DeepSeek V4 Pro vad gäller kapacitet, kostnad och hastighet, och att trafiken för V4 Pro tillfälligt ska omdirigeras till V4.1 Flash från och med den 14 september.
Denna tolkning ligger överlag nära tillkännagivandet, men betonar främst lanseringstakten och produktlyftet. Den officiella tråden ger en mer fullständig bild: förbättringarna tillskrivs inte enbart arkitekturen, utan även nya metoder för förträning och en mer storskalig RL-efterträning. Framför allt är den mest praktiska förändringen bakom budskapet om en ”smartare, snabbare och effektivare” Flash-modell den minnesmängd som krävs för inferens med långa kontexter, en avgörande fråga för AI-agenter.
Grafen som delats av @kimmonismus visar dessutom en mindre entydig verklighet än marknadsföringsbudskapet: DeepSeek V4.1 Flash är konkurrenskraftig i flera utvärderingar, men dominerar inte konsekvent de ledande modellerna på Terminal-Bench.
Inlägget från @kimmonismus, som publicerades den 10 september, bygger uttryckligen på tråden från DeepSeeks officiella konto. Detta är viktigt: siffrorna, migreringen av endpoints och prestandalöftena kommer i första hand från modellens utvecklare, inte från analytikern som sammanfattade dem.
Här är källinlägget, publicerat av DeepSeek några timmar tidigare:
Den officiella tråden: en ny familj, inte bara en Flash-uppdatering
I sitt första inlägg presenterar @deepseek_ai V4.1 Flash som ”the smallest model in our new architecture family”, med inbyggd visuell förståelse. Positioneringen är tydlig: Flash är inte längre bara en lättviktsvariant, utan den första modellen i en familj utformad för hastighet, genomströmning och skalbarhet.
Den andra delen av tråden beskriver arkitekturen i detalj. DeepSeek V4.1 Flash bygger på en MoE-modell med 552 miljarder parametrar, men använder inte hela nätverket i varje steg. Enligt DeepSeek är endast 8 miljarder parametrar aktiva under bearbetningen av indata, och därefter 16 miljarder under genereringen.
Denna asymmetri utgör kärnan i Causal Encoder Decoder-arkitekturen. Bearbetningen av kontexten och produktionen av nya tokens har inte längre samma kostnad och använder inte exakt samma resurser. För användningsområden som kräver att en omfattande kontext läses innan ett relativt kort svar genereras kan denna uppdelning förbättra förhållandet mellan kostnad och prestanda.
Den officiella tabellen jämför V4.1 Flash med V4 Pro 0813, V4 Flash 0731 och flera konkurrenter. Den anger bland annat 30,0 på Terminal-Bench 3.0, 31,2 på Terminal-Bench 4.0 och 74,2 på DeepSWE v1.1 för V4.1 Flash.
Viktiga benchmarkresultat för DeepSeek V4.1 Flash
| Benchmark | Angivet resultat för V4.1 Flash | Tolkning |
|---|---|---|
| Terminal-Bench 3.0 | 30,0 | V4.1 Flash ligger före GLM 5.3 i den officiella tabellen. |
| Terminal-Bench 4.0 | 31,2 | Modellen ligger fortfarande efter GLM 5.3, som anges ha 37,9. |
| DeepSWE v1.1 | 74,2 | Resultat som DeepSeek lyfter fram för uppgifter inom programvaruutveckling. |
DeepSeek hävdar att deras nya förträningsmetoder, i kombination med en mer ambitiös RL-efterträning, placerar modellen före framstående system, däribland DeepSeek V4 Pro. Detta förtydligande är viktigt i förhållande till @kimmonismus sammanfattning: arkitekturen är central, men den förklarar inte ensam de resultat som görs anspråk på.
Den officiella formuleringen är avsiktligt enkel:
"Mindre KV-cache. Större besparingar." @deepseek_ai
Det mest konkreta löftet med V4.1 Flash är därför inte nödvändigtvis ett högre råresultat, utan en avsevärt lägre minneskostnad för långa och repetitiva arbetslaster.
DeepSeeks KV-cache, den verkliga hävstången för agenter
KV-cachen lagrar de representationer som behövs för att undvika att hela kontexten beräknas om för varje genererad token. Detta minne är avgörande för långa konversationer, agenter som anropar verktyg, arbetsflöden för kod, iterativa sökningar och system som bevarar en omfattande historik.
DeepSeek uppger att cachen i V4.1 Flash endast kräver:
- En fjärdedel av det HBM-minne som föregående generation krävde.
- En åttondel av det SSD-lagringsutrymme som tidigare behövdes.
- Cirka 890 byte per token i global cache, jämfört med 3 514 byte för V4 Flash enligt diagrammet som företaget publicerat.
Den officiella grafiken visar en dramatisk minskning sedan DeepSeek-V1: 389 120 byte per token för V1, 48 068 för V3.2, 3 514 för V4 Flash och slutligen 890 för V4.1 Flash.
För den som driver agenter kan denna förbättring vara mer betydelsefull än en marginell skillnad i ett benchmarktest. Cacheträffar utgör ofta en stor del av kostnaden när en agent regelbundet återanvänder en omfattande kontext. Genom att komprimera cachen minskar både belastningen på GPU-minnet och behovet av lagringskapacitet i stor skala.
Det är precis detta som @datachad lyfter fram i svaren på @kimmonismus inlägg:
"minskningen av KV-cachen till en fjärdedel av HBM-minnet är det som spelar roll för lokal inferens" @datachad
Iakttagelsen är riktig, men den behöver nyanseras. En mer kompakt DeepSeek KV-cache gör egenhosting av AI mer tillgänglig för infrastrukturer som redan har rätt utrustning. Den förvandlar däremot inte en MoE-modell med 552 miljarder parametrar till programvara som enkelt kan köras på en persondator.
DeepSeek medger detta indirekt när företaget självt talar om driftsättningar i en helt annan skala:
"Planerar ni en storskalig driftsättning med 2 000 GPU:er + ett lagringskluster? Låt oss prata." @deepseek_ai
Cachevinsten förbättrar tjänstens ekonomi avsevärt, men den undanröjer inte hårdvarutröskeln som modellens storlek medför.
Modellen och dess tekniska rapport finns tillgängliga via DeepSeek-V4.1-Flash-sidan på Hugging Face och den tekniska rapporten för DeepSeek V4.1. Materialet som finns tillgängligt i tråden gör det dock inte möjligt att bekräfta uppgifterna i ett svar från @UnslothAI om ”196B engram”. Denna uppgift bör därför inte betraktas som en verifierad specifikation utan en direkt genomgång av den tekniska rapporten.
En API-övergång som gör Flash till standardprodukten
Tillkännagivandet handlar inte bara om att marknadsföra en ny modell. Det innebär också en omorganisation av DeepSeeks produktutbud.
I den officiella tråden anges följande:
- V4 Flash och V4 Flash Vision Exp tas bort.
- De tidigare identifierarna
deepseek-v4-flashochdeepseek-v4-flash-vision-expomdirigeras tillfälligt till V4.1 Flash för att bevara kompatibiliteten. - Från och med den 14 september 2026 kl. 04:00 UTC kommer även förfrågningar avsedda för DeepSeek V4 Pro att dirigeras till V4.1 Flash.
- Detta ska fortsätta fram till lanseringen av V4.1 Pro.
- Förfrågningar som migreras från V4 Pro kommer att debiteras enligt priserna för V4.1 Flash.
Detta beslut går långt utöver en marknadsföringsmässig jämförelse. DeepSeek gör V4.1 Flash till sin huvudsakliga API-produkt redan innan V4.1 Pro lanseras. För team som redan använder API:et minskar migreringen risken för omedelbara avbrott. Den undanröjer dock inte behovet av att på nytt validera utdata, latens, verktygsanrop, inbyggt stöd för bildbehandling och modellens beteende i produktion.
@bygregorr sammanfattar problemet ur applikationsutvecklarnas perspektiv:
"Sex veckor mellan arkitekturfamiljer är en kort omställningstid för API-utvecklare." @bygregorr
DeepSeek svarar med tillfällig kompatibilitet och dirigering av de tidigare identifierarna. Det är en pragmatisk lösning för att säkerställa tjänstekontinuitet, men ingen garanti för fullständig funktionell likvärdighet. En agentbaserad applikation som är känslig för utdataformat, verktygsanrop eller resonemangspolicyer måste ändå testas på nytt.
DeepSeeks pristabell visar olika priser beroende på tidpunkt, per miljon tokens. Utanför högtrafik anges 0,003 dollar för indata med cache, 0,15 dollar för indata utan cache och 0,6 dollar för utdata. Under högtrafik stiger dessa belopp till 0,006, 0,3 respektive 1,2 dollar.
DeepSeek uppger att priserna under lågtrafik motsvarar 50 % av priserna under högtrafik. Denna prisstruktur gör flexibla arbetslaster ännu mer ekonomiskt attraktiva, särskilt batchbearbetning, automatiserade utvärderingar och asynkrona agentbaserade uppgifter.
Ett tredjepartsinlägg från @ns123abc, som nämns i den bredare diskussionen, uppger en körkostnad som är cirka 86 gånger lägre per miljon tokens och en genomströmning på 420 till 507 tokens per sekund. Dessa siffror kan bidra till diskussionen, men de förekommer inte i den officiella tråd som tillhandahållits. De bör därför betraktas som påståenden från tredje part, beroende på hårdvara, kontextlängd, kvantiseringsnivå och testad belastning, och inte som bekräftade uppgifter från DeepSeek.
Terminal-Bench: en påstådd dominans, men ingen universell dom
DeepSeek hävdar att ”tests by multiple parties” placerar V4.1 Flash före V4 Pro när det gäller prestanda, kostnad, hastighet och total körtid. Detta påstående kan stödja dess relativa positionering, men tråden dokumenterar inte protokollen, leverantörerna, inferensinställningarna eller den exakta sammansättningen av dessa tester tillräckligt utförligt.
Den huvudsakliga stötestenen gäller Terminal-Bench, ett benchmark som följs särskilt noga för att utvärdera agentbaserade funktioner för datoranvändning och programmering.
@Greg_GL_87 påpekar en uppenbar inkonsekvens mellan två versioner av utvärderingen:
"the table has it losing Terminal-Bench 4.0 to GLM 5.3, 31.2 vs 37.9, but winning 3.0. weird split for two versions of the same eval" @Greg_GL_87
Denna kritik fick inget svar i tråden. Den är specifik och viktig. Den officiella tabellen visar mycket riktigt 31,2 för V4.1 Flash i Terminal-Bench 4.0, medan @Greg_GL_87 jämför detta resultat med 37,9 för GLM 5.3. Samtidigt får V4.1 Flash 30,0 i Terminal-Bench 3.0 och ligger där före GLM 5.3.
En modell kan överträffa V4 Pro på flera indikatorer utan att vara det bästa valet för alla agentbaserade kodningsuppgifter. Utan ett detaljerat protokoll går det fortfarande inte att avgöra om skillnaden mellan Terminal-Bench 3.0 och 4.0 beror på uppgifterna, miljöerna, testparametrarna eller någon annan metodologisk faktor.
@kryptosopus framför en bredare invändning genom att jämföra V4.1 Flash med Claude Opus 5:
"Native vision baked into the smallest model but it still loses Terminal-Bench to Opus5 by 13 points. Flash is clearly the "cheap and fast" play, not the frontier one. The scaling line at the bottom is the real tell here" @kryptosopus
Denna tolkning motsäger inte helt DeepSeeks. V4.1 Flash kan vara bättre än DeepSeek V4 Pro enligt flera av de mått som företaget valt, samtidigt som den ligger efter Opus 5 i ett specifikt agentbaserat benchmark. Problemet uppstår när en relativ förbättring inom en produktserie omvandlas till ett påstående om överlägsenhet överlag.
Reaktioner: entusiasm för öppen källkod, produktmässig försiktighet och frågor om den framtida Pro-versionen
Svaren i den officiella tråden är överlag entusiastiska över modellens öppenhet och snabba integration. @MrAhmadAwais uppger exempelvis att V4.1 Flash redan finns tillgänglig i hans CommandCodeAI-erbjudande. @Presidentlin hyllar framför allt DeepSeeks bidrag till ekosystemet för öppen källkod:
"Thank you again for moving Open Source forward" "As always oblig" "How high will your ceiling go?!!" @Presidentlin
Svaret åtföljdes av en mangasida som gestaltar denna blandning av fascination och utmaning inför DeepSeeks höga lanseringstakt.
@ParthM1001 sammanfattar å sin sida stämningen med en kulinarisk metafor:
"The whale has cooked something beautiful again." @ParthM1001
Svaren på @kimmonismus inlägg fokuserar mer på produktseriens positionering. @elshayib_ anser att den tidigare Pro-versionen har förlorat sitt existensberättigande:
"V4 pro kinda irrelevant now" @elshayib_
@kimmonismus svarar:
"yeah, just waiting for another release of the pro version" @kimmonismus
Detta svar ligger i linje med det officiella tillkännagivandet: V4 Pro håller mycket riktigt på att tillfälligt fasas ut, men DeepSeek aviserar uttryckligen en framtida V4.1 Pro. Att dra slutsatsen att hela Pro-serien definitivt är överflödig går därför längre än vad de fastställda fakta medger.
Samma fråga dyker upp hos @RimasXYZ:
"om flash nu slår v4-pro när det gäller kapacitet, kostnad och hastighet, vad återstår då för v4.1-pro att vinna på?" @RimasXYZ
Tråden besvarar inte den frågan. Den lämnar definitionen av den framtida Pro-produkten helt öppen: högre kvalitet vid svåra uppgifter, förbättrad resonemangsförmåga, längre kontext, agentisk tillförlitlighet eller någon annan prestandaavvägning.
Causal Encoder Decoder-arkitektur: vad som förändras tekniskt
Reaktionen från @austinyuhao, ”välkommen tillbaka, encoder-decoder”, är kort men relevant. DeepSeek erbjuder inte bara komprimering av cacheminnet, utan återinför även en arkitektonisk uppdelning mellan den kausala kodningsvägen och avkodaren.
"välkommen tillbaka, encoder-decoder" @austinyuhao
Diagrammet som delades i svaret visar en Causal Encoder och en Decoder med tjugo lager vardera, vilket ger ett nätverk med totalt fyrtio lager. Det visar även komponenterna MoE, CSA2, SWA, Vision Encoder, Text Embedding, Engram, DSpark och Candidate Pool.
Denna struktur förklarar varför multimodal inferens och KV-cache hänger samman. DeepSeek strävar efter att erbjuda inbyggt stöd för bildbehandling och samtidigt hålla kostnaden på en rimlig nivå för långa sekvenser. Löftet är särskilt attraktivt för agenter som behöver läsa dokument, analysera gränssnitt, hantera kod och behålla ett beständigt arbetsminne.
Vanliga frågor om DeepSeek V4.1 Flash
Hur många parametrar är aktiva i DeepSeek V4.1 Flash?
DeepSeek uppger att det är en MoE-modell med 552 miljarder parametrar. Endast 8 miljarder parametrar uppges vara aktiva under bearbetningen av indata och därefter 16 miljarder under genereringen.
Varför är DeepSeeks KV-cache viktig för AI-agenter?
KV-cachen lagrar representationerna av den kontext som redan har bearbetats. Ett mer kompakt cacheminne minskar behovet av GPU-minne och lagringsutrymme, vilket kan sänka kostnaden för långa konversationer, agenter med verktygsanrop och arbetsflöden som ofta återanvänder samma kontext.
Vad händer med användarna av DeepSeek V4 Pro?
Från och med den 14 september 2026 kl. 04:00 UTC ska förfrågningar avsedda för DeepSeek V4 Pro tillfälligt omdirigeras till V4.1 Flash, fram till lanseringen av V4.1 Pro. Berörda team måste validera sina användningsfall i produktion på nytt, även om API-kompatibiliteten bibehålls under övergången.
Viktiga slutsatser
DeepSeek V4.1 Flash är inte bara ännu en snabb uppdatering. Tillkännagivandet kombinerar en ny asymmetrisk arkitektur, differentierad MoE-aktivering mellan indata och generering, kraftig komprimering av KV-cachen, aggressiv API-prissättning och en konkret migrering av trafik från V4 Pro.
För yrkesverksamma är konsekvenserna tydliga:
- Den mindre KV-cachen kan avsevärt sänka kostnaden för agenter med lång kontext.
- Egen drift av AI blir mer realistisk för operatörer som redan har omfattande infrastruktur.
- Omdirigeringen från V4 Pro till Flash kräver en fas med applikationsvalidering.
- De påstådda prestandafördelarna gentemot V4 Pro räcker inte för att fastställa överlägsenhet i alla agentiska benchmarktester.
- Terminal-Bench är fortfarande en punkt som kräver uppmärksamhet, särskilt med tanke på den skillnad mellan version 3.0 och 4.0 som @Greg_GL_87 har uppmärksammat.
Tråden lämnar därmed flera frågor obesvarade: vilka protokoll ligger till grund för ”tester av flera parter”, varför skiljer sig resultaten åt beroende på versionen av Terminal-Bench, vilken särskiljande roll kommer V4.1 Pro att få och vilken hårdvarukonfiguration gör egen drift praktiskt genomförbar?
Den rimligaste slutsatsen är också den mest användbara: V4.1 Flash verkar utgöra ett stort framsteg när det gäller effektivitet och driftsättning, men bevisar ännu inte att en Flash-modell har eliminerat de kompromisser som är typiska för frontiermodeller.