Qwen3.8-Flash-Next lokalt: Vad 6 miljarder aktiva parametrar verkligen innebär för RAM, VRAM och NVMe

Nej, Qwen3.8-Flash-Next får inte plats i minnet som en 6B-modell bara för att ungefär 6B parametrar aktiveras per token. Qwen beskriver en huvudmodell med 125B parametrar och 6B aktiverade parametrar, plus 51B n-gram-inbäddningar och en MTP-komponent på ungefär 4B parametrar. Det officiella Qwen3.8-Flash-Next-arkivet är för närvarande cirka 360 GB i den utgivna BF16-versionen. Community-konverteringar till GGUF kan minska detta avsevärt, men de gör inte Flash-Next till en konventionell 6B-modell.

Det bästa sättet att tänka på lokal distribution är som en minneshierarki. VRAM avgör hur mycket av den snabba modellkörningen som kan ligga kvar på GPU:n. System-RAM ger kapacitet för komponenter som ligger på CPU:n eller har flyttats dit, inklusive den ovanligt stora n-gram-tabellen som Qwen uttryckligen har utformat för att köras från värdminnet. NVMe ger snabb lokal lagring och minnesmappat stöd för filer som närmar sig eller överstiger 100 GB, men ersätter inte RAM eller VRAM. Den verkliga frågan är därför vad siffran 6B aktiva parametrar avlastar från hårdvaran – och vad den inte gör.

Betyder 6B aktiva parametrar att Qwen3.8-Flash-Next bara behöver minne som en 6B-modell?

Nej. Aktiverade parametrar beskriver beräkningen per token, inte den totala mängden modellinformation som finns. Denna skillnad är särskilt viktig för Qwen3.8-Flash-Next eftersom skillnaden mellan antalet aktiva parametrar och antalet lagrade parametrar är ovanligt stor.

Enligt det officiella modellkortet för Qwen3.8-Flash-Next innehåller språkmodellen 125B parametrar, varav ungefär 6B aktiveras för varje token, samt 51B parametrar för n-gram-inbäddningar och cirka 4B parametrar kopplade till MTP. Den huvudsakliga MoE-modellen innehåller 512 dirigerade experter och väljer 10 dirigerade experter samt en gemensam expert för varje token.

Det ger tre olika siffror som inte bör blandas ihop:

Huvudpoängen är att inaktiva experter inte upphör att existera. Olika token kan routas till olika experter, så körningen behöver fortfarande åtkomst till den bredare viktpoolen, även om bara en liten andel deltar i framåtpasseringen för en viss token. Detta är samma grundläggande anledning till att andra stora MoE-modeller kan ha relativt låg aktiv beräkning men ändå mycket stora minnesavtryck, en skillnad som också är viktig i vår hårdvaruanalys av GLM-5.3-Flash för lokal körning.

Flash-Next tillför ytterligare en aspekt. Dess 51B stora n-gram-inbäddningstabell används inte som en vanlig viktningsmatris i ett tätt neuronnät. I Qwens officiella översikt över Flash-Next-arkitekturen förklarar teamet att platserna för n-gram-uppslag kan fastställas i förväg. Tabellen kan därför ligga i värdminnet och hämtas asynkront i förväg medan andra modellberäkningar körs.

Det är därför siffran 6B aktiva parametrar är betydelsefull, även om den inte anger ett minneskrav. Flash-Next är utformat för att separera modellkapacitet från beräkning per token mer aggressivt än en konventionell tät modell. För lokal inferens flyttar det hårdvarufrågan från en enda VRAM-siffra till hur effektivt VRAM, system-RAM och lagring kan samverka.

Hur stor blir Qwen3.8-Flash-Next efter kvantisering?

Den officiella BF16-versionen är cirka 360 GB, vilket omedelbart innebär att en helt resident okvantiserad distribution ligger utanför vanlig stationär maskinvara. Kvantisering förändrar situationen avsevärt.

Per den 1 september 2026 sträcker sig Unsloths aktuella Flash-Next-GGUF-byggen från extremt aggressiva versioner med få bitar till betydligt större varianter med hög kvalitet. Två användbara referenspunkter är UD-IQ4_XS-bygget på cirka 93,7 GB och UD-Q4_K_XL-bygget på cirka 111 GB.

Dessa GGUF-storlekar är community-konverteringar, inte officiella rekommendationer från Qwen om minsta RAM- eller VRAM-mängd. De är ändå användbara för kapacitetsplanering eftersom de visar problemets omfattning innan körtidsbuffertar, kontexttillstånd, bildbehandling, operativsystemet och andra program läggs till.

En modellfil på exempelvis 94 GB innebär inte att en dator med exakt 96 GB kombinerat minne kommer att ge en bekväm installation. Körtidsmiljön behöver fortfarande arbetsutrymme, och hur mycket extra minne som krävs varierar beroende på kontextlängd, backend, cacheformat, strategi för GPU-avlastning och samtidighet.

Hur mycket VRAM behöver Qwen3.8-Flash-Next?

Det finns inget användbart enda ”minsta VRAM”-värde för Flash-Next, eftersom lokal inferens kan variera från nästan helt CPU-baserad körning till en modell som är fördelad över en eller flera GPU:er. VRAM avgör främst hur stor del av inferensarbetsbelastningen med hög bandbredd som kan ligga kvar på GPU:n och därmed hur snabbt systemet kan köras.

Ett konsument-GPU-kort på 24 eller 32 GB kan inte på egen hand rymma en aktuell fyrabitars-GGUF på 94–111 GB. Det gör inte nödvändigtvis GPU:n oanvändbar. En körmiljö som stöder partiell GPU-avlastning kan behålla utvalda tensorer eller lager i VRAM medan system-RAM innehåller resten.

Aktuella alternativ för modellinläsning i llama.cpp omfattar placering av GPU-lager, explicit val av enhet, tensoröverskrivningar och CPU-MoE-kontroller. Det innebär att ”kan min GPU köra den?” och ”kan min GPU rymma hela modellen?” är olika frågor.

Prestandaskillnaden mellan dessa konfigurationer kan vara enorm, även när modellen tekniskt sett laddas i varje konfiguration. GPU:ns minnesbandbredd är dramatiskt högre än den vanliga systemminnesbandbredden, och att flytta en stor del av den aktiva beräkningen tillbaka till CPU:n kan förvandla en annars imponerande lokal modell till något som lämpar sig bättre för experiment än för interaktivt agentarbete.

För Flash-Next bör VRAM därför betraktas som en prestandaallokering, inte som ett binärt kompatibilitetsvärde.

Hur mycket RAM behöver Qwen3.8-Flash-Next för CPU–GPU-avlastning?

Systemminnet är utan tvekan viktigare för Flash-Next än rubriken ”6B aktiv” antyder. En dator med ett konsument-GPU men mycket lite RAM har ingen användbar plats för den stora mängd modellstatus som inte får plats i VRAM.

N-graminbäddningen gör detta särskilt intressant. Qwen säger att tabellen på 51B kan placeras i värdminnet eftersom åtkomsterna är deterministiska och kan förhämtas. När Flash-Next-implementeringen slogs samman med llama.cpp den 27 augusti beskrev implementeringsanteckningarna n-graminbäddningstabellen per lager som ungefär 97,7 GiB i BF16 och hanterade uppslagningen av dess rader från värdsidan.

Det betyder inte att varje lokal distribution permanent behöver ytterligare 97,7 GiB okvantiserat ovanpå en kvantiserad GGUF. Kvantisering och representation under körning spelar roll. Det visar däremot varför arkitekturen utformades kring heterogent minne, i stället för att anta att varje parameter måste förbli i GPU-minnet.

För praktisk GGUF-inferens bör systemminnet planeras utifrån den faktiska kvantiserade modellstorleken plus utrymme för operativsystemet och körningen. Med en kvantisering på cirka 94 GB är 128 GB RAM ett rimligt mål för experiment, men det är inte generöst när operativsystem, kontext, buffertar och GPU-värdens allokeringsbeteende räknas in. Ett system med 192 GB eller 256 GB ger en betydligt säkrare marginal för seriös hybridinferens.

Detta är ett av de tydligaste exemplen på varför minnet i lokal AI håller på att bli en hierarki i stället för en enda VRAM-specifikation. GPU-minnet hanterar det arbete som är mest känsligt för bandbredd, värdminnet utökar modellkapaciteten och lagringen tillhandahåller beständiga modelldata under båda.

Kan avlastning till NVMe-SSD göra Qwen3.8-Flash-Next praktisk?

NVMe kan göra en överdimensionerad modell enklare att lagra och läsa in, men det omvandlar inte SSD-kapacitet till snabbt inferensminne. Den skillnaden blir viktigare när lokala modeller passerar 100 GB.

En snabb NVMe-enhet är användbar för att lagra flera GGUF-varianter, läsa in en stor modell utan att vänta på långsammare nätverks- eller hårddisklagring och stödja minneskarta modellåtkomst. llama.cpp använder minneskartläggning som ett läge för modellinläsning, vilket gör att modellsidor kan mappas från en fil i stället för att hela filen måste kopieras till en separat RAM-allokering vid start.

Dokumentationen om minnesinläsning i llama.cpp förklarar dock också varför detta inte bör tolkas som kostnadsfri avlastning till disk. Om arbetsmodellen överskrider det tillgängliga RAM-minnet kan sidutväxling och upprepad åtkomst till lagringen försämra prestandan. Minneslåsning finns just eftersom det kan vara viktigt att hålla ofta använda modellsidor kvar i RAM.

En användbar tumregel är: NVMe kan göra en överdimensionerad modell möjlig att läsa in; det gör den inte automatiskt interaktiv.

Detta förklarar också varför lagringsarkitekturen blir allt viktigare för lokal AI, även när själva lagringsenheten inte utför inferens. Modeller, bildresurser, RAG-index, datamängder, agentarbetsytor och flera kvantiserade kontrollpunkter kan lätt ta upp hundratals gigabyte. Snabb lokal lagring blir en del av AI-systemet, men den tillhör fortfarande en annan nivå än minnet som matar den aktiva beräkningen.

Hur förändrar 262K-kontext minneskravet?

Qwen3.8-Flash-Next har inbyggt stöd för en kontextlängd på 262 144 token, som kan utökas mot en miljon token med YaRN. Det betyder inte att alla lokala distributioner bör konfigurera maximal kontext som standard.

Modellen använder en hybridarkitektur i stället för konventionell fullständig uppmärksamhet i varje lager. Gated DeltaNet komprimerar historiken, medan Qwen Sparse Attention använder ett index för att välja relevanta kontextblock. Detta är särskilt avsett att minska den beräknings- och minnesbelastning som långa sekvenser medför.

Lång kontext är fortfarande inte gratis. Körminnet kan omfatta återkommande tillstånd, cacheminnen för gles uppmärksamhet, indexeringstillstånd, tillfälliga beräkningsbuffertar, bildinmatning, batchningsöverflöd och backend-specifika allokeringar. Den exakta minneskurvan beror därför på inferensmotorn och kan inte beskrivas enbart utifrån GGUF-filens storlek.

Det finns också en skillnad mellan modellens arkitektoniska kontextgräns och hur mogen körmiljöns aktuella implementation är. Den 1 september 2026 hade llama.cpp-stödet för den nya arkitekturen bara funnits i några dagar. Ett aktuellt CUDA-problem med 262K-kontext rapporterar ett fel vid start av kärnan vid exakt 262 144 token, medan 261 888 token fungerar på testsystemet. Rapporten identifierar detta som en kärnbegränsning snarare än VRAM-brist.

Det specifika problemet kan åtgärdas snabbt, men det illustrerar en bredare poäng: 262K är en egenskap hos modellen, inte en garanti för att alla aktuella GPU:er och inferensbakändar kan använda hela fönstret effektivt i dag.

För lokal distribution bör du börja med den kontextlängd som arbetsbelastningen faktiskt behöver. En kodsession, dokumentanalys eller privat RAG-arbetsflöde som ryms inom 16K, 32K eller 64K blir inte bättre bara för att körmiljön reserverar hundratusentals token.

Vilken hårdvara kan faktiskt köra Qwen3.8-Flash-Next lokalt?

Det mest användbara hårdvarusvaret beror på vad ”köra” innebär. Att läsa in en kraftigt kvantiserad modell och generera token är ett mål. Att upprätthålla interaktiv prestanda, stor kontext, bildinmatning och agentarbetsbelastningar är ett betydligt svårare mål.

Tabellen nedan är därför en planeringsguide baserad på aktuella modell- och GGUF-storlekar – inte en officiell rekommendation av Qwen-hårdvara.

Den viktigaste skiljelinjen är inte en specifik GPU-modell. Det handlar om huruvida maskinen har tillräckligt med samlad snabb minneskapacitet för att hålla lagringsväxling utanför den kritiska sökvägen för genereringen.

Ett grafikkort med 24 GB, ihopkopplat med 192 GB snabbt systemminne, kan vara ett mer trovärdigt Flash-Next-experiment än ett grafikkort med 24 GB ihopkopplat med bara 32 eller 64 GB RAM. Omvänt gör en stor mängd RAM inte CPU-tung inferens likvärdig med att köra samma tensorer i GPU-minne med hög bandbredd.

För de flesta vanliga datoranvändare som är intresserade av Qwen3.8-familjen snarare än just den här arkitekturen är Qwen3.8-27B det mer konventionella lokala alternativet. Flash-Next är mest meningsfull för användare som medvetet vill experimentera med en mycket större gles modell, heterogent minne, en arkitektur med lång kontext eller den teknik som Qwen säger ger en förhandsvisning av Qwen4:s riktning.

Är Qwen3.8-Flash-Next värd att köra lokalt?

Ja, för rätt arbetsstation och av rätt anledning – men inte för att ”6B aktiva” plötsligt får en utgåva med omkring 180 miljarder parametrar att bete sig som en liten skrivbordsmodell.

Flash-Next är särskilt intressant om du har 128–256 GB systemminne eller enhetligt minne, meningsfull GPU-acceleration, snabb NVMe-lagring och ett skäl att experimentera med stora lokala arbetslaster för kodning, multimodalt innehåll, kontorsarbete eller agenter. Arkitekturen är ovanligt relevant för lokal AI eftersom den medvetet separerar parametrar som beräknas ofta från stora kapacitetsorienterade strukturer som kan ligga utanför GPU-minnet.

Den passar betydligt sämre för en vanlig dator med 32–64 GB RAM, där planen bygger på att operativsystemet hela tiden hämtar saknade modellsidor från SSD:n. En sådan maskin kan visa att modellen tekniskt sett går att starta, men ”laddas utan problem” och ”körs på ett användbart sätt” är två olika måttstockar.

Den viktigaste lärdomen sträcker sig längre än den här modellen. Lokal AI-hårdvara handlar allt mindre om att fråga efter ett enda minimikrav på VRAM och allt mer om att utforma en hierarki: VRAM för beräkningar med hög hastighet, RAM för lättillgänglig modellkapacitet och NVMe för beständig lokal lagring av modeller och data. Qwen3.8-Flash-Next gör den övergången ovanligt tydlig.

Vanliga frågor: Lokala maskinvarukrav för Qwen3.8-Flash-Next

Kan Qwen3.8-Flash-Next köras på ett RTX 4090- eller RTX 5090-kort?

Ja, de GPU:erna kan ingå i en hybridbaserad lokal driftsättning, men varken ett RTX 4090-kort med 24 GB eller ett RTX 5090-kort med 32 GB kan rymma ett aktuellt GGUF-bygge av Flash-Next på ungefär 94–111 GB med fyra bitar helt i VRAM. Du behöver betydande mängder system-RAM samt avlastning till CPU och GPU. GPU:n kan fortfarande accelerera den del av modellen som placeras där, så detta är mycket annorlunda än att säga att korten inte kan användas.

Kan Qwen3.8-Flash-Next köras med 64 GB RAM?

64 GB system-RAM understiger storleken på de minsta aktuella praktiskt användbara GGUF-byggena med ungefär fyra bitar. Minnesmappning kan göra det möjligt att komma åt delar av en för stor fil från lagringen, men upprepad växling mellan minne och lagring kommer sannolikt att göra inferensen långsam och instabil vid interaktiv användning. För en seriös lokal driftsättning bör 64 GB inte betraktas som ett praktiskt mål.

Räcker 128 GB RAM för Qwen3.8-Flash-Next?

128 GB är en rimlig utgångspunkt för ett av de mindre GGUF-byggena med ungefär fyra bitar, i kombination med GPU-offload och ett försiktigt kontextfönster. Det är inte en bekväm rekommendation för alla situationer. En modell på ungefär 94 GB lämnar betydligt mindre än 34 GB för operativsystemet, runtime-buffertar, kontexttillstånd, bildbehandling och andra tjänster, så 192 GB eller mer ger avsevärt bättre marginaler.

Kan Qwen3.8-Flash-Next köras helt från en NVMe-SSD?

En runtime kan minnesmappa modellfiler som lagras på NVMe, och operativsystemet kan hämta sidor när de behövs. Det motsvarar inte att köra modellen ”från SSD” med RAM- eller GPU-hastigheter. NVMe är utmärkt för lagring och inläsning av modeller, men om man kontinuerligt förlitar sig på den eftersom det fysiska minnet är slut kan genereringsprestandan försämras dramatiskt.

Betyder 6B aktiva parametrar att Qwen3.8-Flash-Next är lika snabb som en 6B-modell?

Nej. Siffran 6B beskriver det ungefärliga antalet aktiverade parametrar i huvudmodellen för varje token. Flash-Next har fortfarande en mycket större arkitektur, routningslogik, minnestrafik, n-gram-uppslagning, tillstånd för gles uppmärksamhet och annat arbete under körning. Färre aktiverade parametrar kan minska beräkningarna avsevärt, men gör inte hela systemet likvärdigt med en tät 6B-modell.

Kan Ollama eller llama.cpp köra Qwen3.8-Flash-Next lokalt?

Stöd för Qwen3.8-Flash-Next i llama.cpp qwen4exp arkitekturen slogs ihop till master den 27 augusti 2026, en dag efter modellsläppet. Aktuella community-baserade GGUF-arkiv tillhandahåller också byggen avsedda för lokala inferensarbetsflöden baserade på llama.cpp. Eftersom implementationen fortfarande är mycket ny bör du kontrollera aktuella runtime-versioner och modellinstruktioner innan du antar att alla GPU-backend, kontextlängder, visionsvägar eller offload-konfigurationer är lika mogna.