Qwen 4: vLLM-PR:en "qwen4 fuse op" namngav arkitekturen – Apsara 2026 namngav familjen

En pull request med titeln "Add qwen4 fuse op" har legat öppen i vLLM-repositoriet sedan den 26 augusti, och under större delen av den månaden var den det närmaste en beskrivning av Alibabas nästa modellgeneration som existerade utanför företaget. Det förändrades den 22 september 2026, då Alibabas Qwen-chef Liu Da Yiheng använde öppningen av Apsara-konferensen i Hangzhou för att namnge familjen: Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus och Qwen 4 27B — nivån med öppna vikter, och den som världen för lokal inferens har väntat på. Två dagar senare, när konferensen hade stängt, satte företaget den familjen på en roadmap för första gången: Qwen 4 under träning, och en efterföljande linje — Qwen 4.5 och Qwen 5 — projicerad till 5 till 10 biljoner parametrar, en siffra som Alibaba Groups vd Eddie Wu angav på scen och som företaget sedan upprepade i sitt eget engelska pressmeddelande. Vad roadmappen inte är, två veckor senare, är ett schema. Den tidsangivelse som nu cirkulerar är ett fönster — oktober, eller början av november — och inget av det går tillbaka till något som Alibaba har publicerat. Företagets eget skriftliga material innehåller ingen månad, inget kvartal och inget datum; modellen har ingen identifierare, inget kontextfönster och inget pris; och det finns inget Qwen 4-repository i Qwen-organisationen på Hugging Face. Betrakta fönstret som en önskan snarare än en plan. Pull requesten — vllm-project/vllm#53909, fortfarande öppen, fortfarande inte mergad och fortfarande i väntan på granskning — innehåller varken releasedatum eller parameterantal. Den lägger till fristående Triton-kärnor för tre operatorfamiljer: HyperConnection, Qwen Sparse Attention (QSA) och PLE-tillståndsoperationer. Dess titel säger "qwen4", och dess operatorlista är en nästan exakt matchning mot arkitekturen som Alibaba levererade i de öppna vikterna av Qwen3.8-Flash-Next — en multimodell med mixture-of-experts, släppt den 26 augusti 2026, vars Hugging Face-kort lyder "A Preview of the Qwen4 Architecture". Qwen 4 själv är fortfarande inte släppt. Familjen har ett namn, en plats på en roadmap och ett ryktat fönster; kärnorna är fortfarande det enda som beskriver den.

Detta är en artikel om vad vi vet hittills, inte en lanseringsartikel. Aliba​ba har nu namngett familjen på en offentlig scen och placerat den på en företagsfärdplan, men att namnge är inte att leverera: det finns inget modellkort, inga vikter och inget API för någon Qwe​n 4-nivå, och varje arkitekturpåstående nedan kommer fortfarande från förhandsvisningen Qwen3.8-Flash-Next och de ingenjörsartefakter som omger den, snarare än från något Qwe​n 4-dokument. De hårda bevisen är den vLLM-pull request som fortfarande är under granskning, den släppta förhandsvisningsmodellen, en sglang-PR som lämnades in den 27 augusti och som lägger till inbyggt stöd för samma Qwe​n4-Exp-arkitekturkonfiguration, och posten qwen4_exp som sedan dess har landat i vLLMs eget modellregister på main – Qwen4ExpForCausalLM, Qwen4ExpForConditionalGeneration och Qwen4ExpMTP – tillsammans med det multimodala arbetet i Rust-frontend, som slogs samman den 1 september. Slutsatsen vi drar av dem – att operatorerna i PR:erna är den arkitektur som Aliba​ba förhandsvisade – är en tolkning av dessa bevis, och varje detalj nedan är märkt i enlighet med detta. Ett påstående här kommer inte alls från Alibaba: fönstret oktober till början av november kommer från ett watchlist-inlägg på X och de trackersidor som upprepade det under de senaste två veckorna, det är inte reproducerat, och det återges som community-sourcat varhelst det förekommer.

Vad Alibaba faktiskt sa den 22 september

Aliba​ba visade en förhandsvisning av Qwe​n 4-familjen vid öppningen av sin Apsara-konferens (Yunqi), som hölls i Hangzhou från 22 september till 24 september 2026, med Qwe​n-ledaren Liu Da Yiheng på scen. Fyra nivåer namngavs vid öppningen, utifrån den struktur som 3.8-generationen redan hade etablerat:

• Qwe​n 4 Max — flaggskeppsnivån, och den som ställs mot toppmodellen från varje annat frontier-labb.

• Qwen 4 Flash — nivån för hög genomströmning, avsedd för latenskänsligt arbete i hög volym snarare än maximal resonemangsförmåga.

• Qwe​n 4 Plus — den balanserade mellannivån.

• Qwe​n 4 27B — nivån med öppna vikter: storleksklassen som Qwe​n tidigare har släppt öppna vikter i, och den som det skrivs om som alternativet för lokal körning.

27B-posten är den konkreta delen av tillkännagivandet, och det är vad källsignalen bakom den här artikeln reagerade på. I 3.8-generationen var 27B-nivån släppet med öppna vikter som konverterades till MLX, kvantiserades till NVFP4 och finjusterades inom dagar efter lansering, så en namngiven Qwen 4 27B ger det nedströms ekosystemet ett mål igen. Det är ett mål och inte en lansering, och distinktionen är värd att hålla fast vid: Alibaba har inte publicerat någon parameteruppdelning, ingen licens, inget kontextfönster och inget datum för den, och nivånamnet säger inte ens om den är dense eller mixture-of-experts. Allt som gjorde den tidigare 27B-nivån körbar – storleksklassen, fokuset på en enskild maskin – ärvs från produktlinjens historia, inte specificerat för den här modellen.

Det konferensen inte levererade är just det en läsare kan planera efter. Alibabas uttalade hållning – leverantörsramverk, framförd på scen och rapporterad av flera oberoende medier snarare än oberoende verifierad – är att Qwen 4 bygger på en ny generationens arkitektur, att den är under träning och att den kommer "snart". Ingen nivå har något kontextfönster, något pris, någon modalitetslista eller någon publicerad poäng. Det enda daterade inslaget på konferensen var en nästa generationens videomodell planerad till november. En siffra från samma scen måste hållas i sin egen fil: ambitionen om 5 till 10 biljoner parametrar hör till tidsramen för Qwen 4.5 och Qwen 5, inte till Qwen 4 – inget parameterantal angavs för någon Qwen 4-nivå. Den siffran är inte längre en läcka eller ett cirkulerande påstående: den finns i Alibabas eget engelskspråkiga pressmeddelande, tillskriven vd:n Eddie Wus keynote, och den anges som en prognos utan datum och utan arkitektur bakom sig – företagsuttalad, och fortfarande inte reproducerad.

Så namngivningen ändrade familjens status, inte bevisläget. Allt nedan är fortfarande serveringslagrets redogörelse för vad den här arkitekturen är – och eftersom tillkännagivandet inte tillför några egna specifikationer, förblir den redogörelsen mer detaljerad än något som Aliba​ba har publicerat.

Vad "qwen4 fuse op"-PR:en egentligen är

Pull request #53909 i vllm-project/vllm är öppen, från en bidragsgivares fork, och väntar fortfarande på granskning från kodägare — automatisk granskning inaktiverades just för att den kom från en fork. Det är ett litet arbete i kernelform:

• Tre HyperConnection-kärnor – en grupperad Ge​ma RMSNorm, en gate-reducering och en injektionskombination.

• Tre QSA-kärnor plus tre leverantörsbaslinje-wrappers för jämförelse.

• Gather- och maskerade scatter-kärnor för PLE-tillstånd.

• Tretton godkända tester som täcker dtype- och shape-skydd, pagineringsmetadata, cacheplatser, MRoPE-layout, strided tillstånd, null- och duplicerade index samt deterministisk körning.

Två detaljer spelar roll utöver op-listan. För det första är implementeringen fail-closed: host guards kastar fel i stället för att falla tillbaka till en generisk Torch-beräkningsväg, eftersom ett tyst felaktigt värde i en attention-kernel är värre än ett hårt fel. För det andra är namnklyvningen – titeln säger "qwen4" medan beskrivningen namnger Qwen3.8-Flash-Next – i sig en signal. vLLM-sidan behandlar förhandsvisningsmodellen som den första instansen av qwen4-linjen och bygger kernels under familjenamnet som kommer att täcka vad som än kommer efter det.

För kontext kring vad en "fuse op" är: en inferensmotor kör normalt en modells graf med en kernel-lansering per operation, och varje lansering medför overhead – minnesrundturer mellan kärnor, dispatch-kostnad. Att fusionera flera elementvisa operationer och tillståndsoperationer till en enda kärna minskar den overheaden, och det är precis där en ny arkitekturs kostnad och latens vinns eller förloras. En modell byggd på operatorer som inte har någon fusionerad implementering någonstans kommer att vara långsam och minneshungrig oavsett hur smart träningen är; den första motorn som fusionerar dem väl sätter modellens verkliga pris.

Att läsa kärnnamnen som en ritning

Ingen av dessa operatorer finns i standard-transformer-opsetet, vilket är anledningen till att de överhuvudtaget behöver nya kärnor — och var och en motsvarar en specifik del av arkitekturen som Aliba​ba förhandsvisade i Qwen3.8-Flash-Next:

• HyperConnection → gated residualanslutningar. Den enskilda residualströmmen breddas till fyra parallella grenar med elementvis dynamisk gating, vilket låter modellen avgöra hur mycket den ska läsa från och skriva till varje gren; residualtillståndet kan lagras i FP8 för att minska minnestrafiken.

• QSA → Qwen Sparse Attention. En lättviktig indexerare komprimerar nycklar till mikroblock med en komprimeringsgrad på 4, poängsätter dem och behåller de 512 bästa blocken – ungefär 2 051 logiska tokenpositioner – medan den slutliga softmaxen och värdeaggregeringen fortfarande körs på de ursprungliga, okomprimerade K/V. Tolv av de 48 lagren är QSA; de övriga 36 är GDN-lager med linjär attention som har ett återkommande tillstånd av fast storlek och ingen växande KV-cache.

• PLE-tillståndsoperationer → n-gramminne. Uppslagstabellen med 51 miljarder parametrar – "Per-Layer Embeddings" i SGLang-artikeln – hash-adresseras utifrån den aktuella token plus de två eller tre föregående token, och hämtar 16 rader per token. Dess positioner kan förberäknas, så den kan ligga i värdminnet och förhämtas asynkront i stället för att ta upp GPU-VRAM.

• MoE-kroppen som kärnorna sitter i: 125B parametrar totalt med ungefär 6B aktiva per token – under 5 % aktivering – dirigerade över 512 experter med top-10-routing.

Två förbehåll gör att detta förblir ärligt. För det första är arkitekturen ovan hämtad från modellkortet för Qwen3.8-Flash-Next och community-teardowns, inte från något Qwe​n 4-dokument — det är bevis om familjen, inte en specifikation av familjen. För det andra ändrar inget av detta det centrala faktumet: Qwe​n 4 finns inte i någon katalog.

En separat bevislinje är visionsvägen, värd att hålla åtskild från kärntolkningen ovan. Oberoende av varje operatormappning listar vLLM:s egen modellregistrering på main en qwen4_exp-post — Qwen4ExpForConditionalGeneration — registrerad som en multimodal modell med ett Qwen3-VL-visionstorn och en Qwen3VLMultiModalProcessor. Rust-frontend-PR:en (#54813) som kopplar in den konfigurationen i motorns multimodala crate, kodvägen som omvandlar bildindata till tokens, mergades den 1 september 2026 — ett starkare påstående än att samma PR är öppen, eftersom den multimodala vägen för qwen4 finns i motorn snarare än i någons fork. Det är fortfarande ingen release: modellen som registreringsposten beskriver har inga vikter och inget API. Men det är den första bekräftelsen på ingenjörsnivå att nästa Qwen-generation tar emot bildindata, och etiketten "multimodal" på arkitekturen är inte längre bara en rad på modellkortet för förhandsversionen.

Varför arkitekturen förändrar kostnadsbilden

Om Qwen 4 släpps på den här arkitekturen ser ekonomin annorlunda ut än för en standard-dense – eller till och med en vanlig MoE – transformer, och den skillnaden är anledningen till att kernel-arbetet är värt att bevaka.

• Uppdelning av minne och beräkning. Minnets kostnad följer de totala parametrarna – alla 125B måste vara residenta för att kunna betjäna modellen. Beräkningskostnaden följer de aktiva parametrarna – endast ~6B körs per framåtpassning. Den separationen är vad som gör att en "125B"-modell kan betjäna till kostnaden för en mycket mindre.

• KV-cachen slutar växa i de flesta lager. Med 36 av 48 lager som använder återkommande tillstånds-attention med fast storlek begränsas den växande nyckel-/värde-cachen till 12 lager. Vid en inbyggd kontext på 262K token – 1M via YaRN – är det en stor del av varför betjäning av långa kontexter alls blir överkomlig.

• Den stora tabellen kan avlastas. N-gram-tabellen är den enskilt största minneskonsumenten med 51B parametrar, och den behöver inte ligga på GPU:n. SGLangs day-0-arbete mätte hur avlastning av BF16-tabellen till pinnat värdminne frigjorde cirka 23 GiB per GPU på H200 och ökade den allokerade KV-kapaciteten med ungefär 78 % – med bit-identiska utdata. På vLLM-sidan landade samma avlastning i etapper i stället för i en enda PR: den ursprungliga support-PR:en (#53899) stängdes utan att mergas den 21 september, medan själva funktionen kom in genom separata mergar – #54371, UVA-baserad PLE-avlastning med Engram-tensorparallelism, den 9 september, och en ROCm-väg (#57497) den 25 september.

Ingen av dessa siffror har ännu oberoende granskats — påståendena om 7,6×/4,9× snabbhetsökning för lång kontext, avkodningssiffran 540 tok/s från SGLang-inlägget, påståendet om träningskostnaden på "1/9 av Qwen3.7-Plus" — och de bör läsas som leverantörs- eller community-rapporterade tills ett neutralt index reproducerar dem.

Kapplöpningen om att servera det

Båda de stora motorerna har qwen4-arbete på gång — SGLang publicerade day-0-stöd inom några dagar efter förhandsvisningen den 26 augusti, och arbetet på båda sidor har fortsatt att staplas på sedan dess, från konfigurationsregistrering till kernel- och minnesengineering.

• SGLang publicerade ett dag-0-inlägg den 26 augusti i ett samarbete mellan SGLang, Aliba​ba, NVIDIA och AMD, där de släppte en NVFP4-checkpoint och hävdade 540 tokens/s vid avkodning på TP4 med B200 och spekulativ avkodning.

• Den 27 augusti lade en sglang-PR (#36585) till inbyggt stöd för Qwe​n4-Exp i själva motorn — den registrerade konfigurationen Qwen4ExpForConditionalGeneration och en textmodell byggd av samma GatedResidual-, Gated DeltaNet-, Qwe​n sparse attention-, PLE- och MoE-delar. Den är inte mergad: PR:en kommer från en bidragsgivare som inte är maintainer, arbetet tillskrivs en autonom agent vid namn Argus, och den är fortfarande öppen och väntar på granskning. Dess ankare är dock oberoende kontrollerbart — Qwen3.8-Flash-Nexts egen konfiguration deklarerar model_type=qwen4_exp, och referensimplementationen finns nu i huggingface/transformers under models/qwen4_exp.

• Den 8 september öppnades ett utkast till sglang-PR (#38492) mot qwen4-main-squashed, en sglang-gren dedikerad till Qwen4/Flash-Next-linjen, och den här är inte registrering. Den portar RecoverSSM — en återhämtningsväg för accepterat tillstånd som först byggdes för Qwen3.8-Flash-Next på SM120 — för arkitekturens verifiering av multi-token-prediction (MTP). MTP-utkast passerar genom Gated DeltaNet-lagrens rekursiva tillstånd med fast storlek, och i stället för att hålla varje mellanliggande spekulativt tillstånd i minnet medan ett utkast verifieras, rekonstruerar motorn det accepterade tillståndet från det committeda tillståndet och det accepterade token-prefixet. Läget är opt-in (en flagga --gdn-mtp-cache-mode none; nuvarande full-cache-beteende förblir standard), och det är tidigt även med den här historiens mått: ett utkast som senast ändrades den 14 september, vars nuvarande head fortfarande misslyckas med nio av sina kontroller, med författarens egen checklista öppen innan det kan markeras som redo för granskning. Riktningen är poängen — sglang utvecklar Qwen4-serveringsvägen, inte bara registrerar dess konfiguration.

• vLLM:s qwen4-linje har gått från tre öppna PR:er till en blandad historik under veckorna sedan den här artikeln först publicerades. Rust-frontendens multimodala PR (#54813) mergades den 1 september. PLE-offload-arbetet mergades i två delar – #54371 den 9 september och #57497 den 25 september – medan den ursprungliga PLE-offload-PR:en (#53899) stängdes utan att ha mergats den 21 september. Konfigurationen har sedan dess förts uppströms: #57387, som byter qwen4_exp-konfigurationen och processorn till uppströmsimplementationerna i Transformers, mergades den 2 oktober. Det som fortfarande är öppet är fuse-op-PR:en som är ämnet för den här artikeln (#53909) – tillsammans med en QSA ring-buffer-buggfix som lämnades in den 1 oktober (#59528) och en SM86-genomgång (Ampere) av n-gram-tabellen med 51 miljarder parametrar, öppen sedan den 26 september (#58856), vilket är den typ av arbete man gör när en modell är något som folk försöker köra på äldre hårdvara snarare än något som ingen har kört. Själva qwen4_exp-konfigurationen är registrerad i vLLM som multimodal: ett Qwen3-VL-visionstorn parat med Qwen4-Exp-textmodellen.

Det här är ett race med ett verkligt pris. Den motor som bäst fusionerar de nya operatorerna sätter det serverade priset för Qwen4-generationen, eftersom kärneffektivitet – inte rå parameterantal – är vad en hybrid-attention-modells tokenkostnad består av.

Vad finns faktiskt ute i dag: Qwen3.8-Flash-Next vs Qwen 4

Det är värt att vara precis när det gäller de två sakerna i den här berättelsen, eftersom namngivningen gör en stor del av jobbet.

• Qwen3.8-Flash-Next har släppts. Öppna vikter finns på Hugging Face och ModelScope under licensen qwen-community-1.0, i standard- och FP8-varianter; modellkortet fastställer specifikationerna — 125B MoE, ~6B aktiva, 51B n-gram-tabell, 262K kontext, multimodal. Det är arkitekturförhandsvisningen, inte flaggskeppet.

• Qwen3.8-Flash är den serverade produktionsvarianten som Alibaba annonserade tillsammans med den, listad på Qwen Cloud till ¥1 per miljon indatatokens och ¥3 per miljon utdatatokens (ungefär $0,16 / $0,47), med en standardkontext på 1M tokens och inbyggda verktyg. Leverantörsrapporterade priser, ännu inte i något oberoende index.

• Qwe​n 4 är inte ute. Aliba​ba namngav alla fyra nivåer den 22 september 2026 och sade att familjen är under träning och kommer snart — det första officiella beskedet om tidsplanen, och fortfarande inte ett schema. Inget datum, inget kort och inga vikter för någon nivå. Fönstret som cirkulerar nu är oktober till början av november, och det kommer från bevakningslistetrådar och trackersidor snarare än från Aliba​ba: träningsstatusen är företagsangiven, tidsangivelsen kommer från communityn. Septemberfönstret som cirkulerade i en läckt färdplan från juli är förbrukat, vilket i sig är ett svar.

• Qwe​n 4 27B-nivån är den man bör hålla ögonen på av en anledning som inte har med benchmarks att göra: det är den enda nivån i familjen med en dokumenterad historia av att släppa öppna vikter, och en annonserad 27B är det som lokala inferensstackar planerar utifrån — vilket är varför avsaknaden av storleksuppdelning, licens och datum spelar större roll här än de gör för flaggskeppet.

Förhandsvisningens benchmarktabell – DeepSWE 1.1 på 58,7, SWE-bench Pro på 62,5, LiveCodeBench v6 på 91,9 – är leverantörsrapporterad på modellkortet och har inte oberoende reproducerats. Planera utifrån arkitekturen; betrakta poängen som ett löfte, inte en mätning.

Vad en utvecklare bör göra nu

Ingenting i din nuvarande stack förändras i dag: Qwe​n 4 går inte att anropa någonstans — Apsara namngav nivåerna och satte familjen på en färdplan, och levererade inget av det — och i skrivande stund finns de öppna vikterna för Qwen3.8-Flash-Next fortfarande inte med på vår egen modelllista heller — det närmaste vi tillhandahåller i dag är den Qwen3.8 Flash-variant vi serverar till $0.15/$0.47 per miljon tokens och Qwen3.8 27B-rutten för öppna vikter till $0.33/$2.40, vilket är det närmaste man kommer en lokalt körbar Qwe​n i katalogen medan efterträdargenerationen fortfarande bara är ett rykte. Färdplansraden är det enda som är värt att läsa två gånger, eftersom det är första gången Aliba​ba har satt en efterträdargeneration på pränt: om Qwe​n 4.5 och Qwe​n 5 verkligen landar i intervallet 5–10 biljoner parametrar, spelar nivån du har råd att självhosta i den generationen större roll, inte mindre. Om du vill känna på arkitekturen innan familjen släpps, är de ärliga vägarna att hämta vikterna själv eller vänta på att förhandsvisningen landar bakom ett API. För den som planerar kring 27B-nivån gäller samma sak, med ett tillägg: den är värd att följa just för att den är den nivå som mest sannolikt kan köras utan ett API, och den är för närvarande den minst specificerade av de fyra.

När Qwen3.8-Flash-Next eller en Qwen 4-modell väl dyker upp i en leverantörskatalog är byteskostnaden på OrcaRouter i stort sett noll: ett API för 200+ modeller, leverantörens listpris vidareförmedlat med 0 % påslag, och en leverantörsprissänkning går live hos oss samma dag. Samma endpoint och nyckel som du redan använder för Qwen3.8 Max – kan anropas idag som qwen/qwen3.8-max till $2.00/$6.00 per miljon tokens, listpris vidareförmedlat – är samma endpoint som ett anrop till Qwen 4 kommer att använda.

För en obeprövad arkitektur är automatisk failover rätt första steg: routa en del av trafiken till den nya modellen med en failover till Qwen3.8 Max (eller vilken modell arbetsbelastningen faktiskt behöver), och låt din egen trafik avgöra om förhandsversionen lever upp till modellkortet — en ändring i routing-DSL, inte en omskrivning.

Vad vi tittar på

• Huruvida fuse-op-kärnorna slås samman (#53909), nu den sista av vLLM:s ursprungliga tre qwen4-PR:er som fortfarande är öppen — arbetet med multimodal front-end och PLE-offload har redan landat, och konfigurationen har gått uppströms. På sglang-sidan är både native-support-PR:en och RecoverSSM-utkastet fortfarande öppna. En sammanslagen kärnuppsättning är den starkaste signalen hittills om att qwen4-linjen finns på båda körtidsmiljöernas kortsiktiga färdplaner.

• Huruvida qwen4-main-squashed befästs som sglangs Qwen4-huvudlinje — en integrationsgren som kernel- och minnesarbete fortsätter att landa på utgör ett starkare åtagande än en enskild bidragsgivares PR, och det är värt att hålla koll på vad som händer med den när flaggskeppet har ett datum.

• Om vision-vägen överlever fram till släppet – posten i det multimodala registret för qwen4_exp och Rust-frontendintegrationen är den första tydliga signalen om att flaggskeppet levererar bildinmatning, och båda finns nu i vLLM:s huvudlinjekod i stället för i en fork. Den öppna frågan är om den levererade modellen behåller visionstornet.

• De första oberoende siffrorna om Qwen3.8-Flash-Next, vilket blir det första testet av huruvida arkitekturens kostnadspåståenden håller utanför leverantören.

• Ett datum eller ett kort för Qwe​n 4 i sig. Familjen har nu namn, en nivålista, en träningsstatus och en plats på en publicerad färdplan, och inget av dem är ett schema. Fönstret som cirkulerar i communityn är oktober till början av november; färdplanen som Aliba​ba publicerade på Apsara innehåller inga datum alls, och inget Qwe​n 4-repositorium har dykt upp på Hugging Face. Nästa verkliga signal är den första med ett datum kopplat till sig – ett modellkort, en API-identifierare eller vikter.

• Särskilt Qwe n 4 27B-nivån — huruvida den släpps med öppna vikter enligt Qwen3.8-27B-mönstret, under vilken licens, och hur snabbt ekosystemet för konvertering och finjustering följer efter.

• Licensen för familjen — huruvida Qwe​n 4 upprepar Qwen3.8 Max-mönstret med öppna vikter under en användningsbegränsad licens, eller öppnar upp ytterligare.

• Kapplöpningen om serverat pris på förhandsvisningen, som kommer att berätta för oss vad den hybrida arkitekturens tokens faktiskt kostar i produktion.

Vanliga frågor

När kommer Qwe​n 4 ut? Det finns fortfarande inget datum, och det finns nu två officiella uttalanden om tidpunkten i stället för ett. Aliba​ba Groups vd Eddie Wu bekräftade på Apsara den 22 september 2026 att Qwe​n 4 är under träning och att en efterföljande serie – Qwe​n 4.5 och Qwe​n 5 – beräknas ligga på 5 till 10 biljoner parametrar; Aliba​bas engelska pressmeddelande upprepar båda. Inget av uttalandena innehåller någon tidsplan. Tre påståenden om tidsramar har cirkulerat och inget av dem kommer från Aliba​ba: juliläckan om färdplanen som förde fram ett fönster i september 2026, vilket har passerat utan en lansering; och fönstret från oktober till början av november som nu cirkulerar i bevakningsinlägg och spårningssidor, vilket är en tolkning av labbets utgivningstakt snarare än ett uttalande från labbet. Lanseringen av Qwen3.8-Flash-Next den 26 augusti är uttryckligen en förhandsvisning av arkitekturen, inte flaggskeppet.

Är Qwe‍n 4 samma modell som Qwen3.8-Flash-Next? Nej. Qwen3.8-Flash-Next är en släppt modell med öppna vikter vars modellkort kallar den "En förhandsvisning av Qwen4-arkitekturen". Qwe‍n 4 är den ännu inte släppta familjen som Aliba‍ba namngav den 22 september — fyra nivåer, inga publicerade specifikationer — och arkitekturen är gemensam medan produkten inte är det.

Kan jag använda Qwe​n 4 idag? Nej – ingenting dirigeras till en modell som inte har några vikter och inget API, och tillkännagivandet den 22 september ändrade inte det. Det närmaste du faktiskt kan komma åt är de öppna vikterna för Qwen3.8-Flash-Next som släpptes den 26 augusti, eller Qwen3.8 Max-API:et, live på OrcaRouter för $2.00/$6.00 per miljon tokens.

Kärnan är budskapet — och tillkännagivandet den 22 september, trots all tid på scenen, skrev inte över det. vLLM lägger inte granskningscykler på att bygga Triton-kärnor för operatorfamiljer som det förväntar sig att överge, och Aliba​ba publicerar inte heller en arkitekturförhandsvisning som det förväntar sig att överge. Mellan den fortfarande öppna PR:en "qwen4 fuse op", förhandsvisningen av Qwen3.8-Flash-Next som släpptes den 26 augusti, posten qwen4_exp som nu finns i vLLM:s huvudregister med sin konfiguration uppströmsförd och sin multimodala integration mergad, PLE-offload-arbetet som landade på både CUDA och ROCm i september, och en utkast-PR för sglang som öppnades den 8 september och fortfarande finjusterar SM120-minne för linjens multi-token-prediction-väg, är formen på nästa Qwe​n-generation inte längre ett rykte — den är skriven i kärnorna och minnesvägarna som två körtider bygger för den. Det Apsara lade till är ett namn för varje nivå, en träningsstatus och ett parameterband för generationen efter den. Det som communityn har lagt till sedan dess är ett fönster snarare än ett faktum: oktober till början av november, från samma trådar på bevakningslistan. Aliba​ba har inte publicerat något av dem. Planera för arkitekturen; satsa inte på datumen.