Qwen3.8-27B Text+Video kommer till CPU: Vad SGLang:s torchcodec PR förändrar

Ett utkast till pull request i SGLang just nu har titeln “[CPU] Support Qwen3.8 text+video: adding torchcodec, ffmpeg and removing pin_memory.” Skalar man bort det tekniska, läses det som en färdplan: Qwen3.8-27B — Alibabas Apache-2.0-modell med 27 miljarder parametrar för vision och språk, som släpptes som öppen källkod för fem dagar sedan — håller på att integreras för att dess text+video-läge ska kunna köras på hårdvara utan GPU. Det är den första konkreta signalen på att den multimodala 27B-modellen får en riktig servingväg för CPU i en av de inferensruntimes som team faktiskt använder, och det spelar roll för alla som väntat på att kunna köra videoförståelse lokalt utan att köpa ett 48GB-kort.

Ingenting i den PR:en är sammanslaget ännu — det är ett utkast, CI är röd, och versionspinnarna ändras fortfarande. Men det är just därför det är värt att läsa noga. Modellen bakom den är verklig och släppt, serving-ekosystemet har redan kommit ikapp på GPU-sidan, och den här PR:n visar vart no-GPU-vägen leder. Här är vad ändringen faktiskt gör, varför videoinferens på CPU för en 27B-modell är en större sak än det låter, vad som är bekräftat om Qwen3.8-27B, och var du kan anropa den idag.

Modellen i ett stycke.

Qwen3.8-27B är den 27B-modell med öppna vikter i Qw​en 3.8-generationen: en tät vision-språkmodell med ~27,8B parametrar (64 lager, dold storlek 5 120) med ett dedikerat visionstorn, utgiven under Apache 2.0 på Hugging Face och ModelScope på kvällen den 14 augusti 2026 (Peking-tid). Den tar emot text, bilder och video och returnerar text — inbyggt, inte via en påskruvad adapter — med ett inbyggt kontextfönster på 262 144 tokens, utbyggbart till ungefär en miljon via YaRN. Licensen är den tillåtande: kommersiellt bruk, finjustering och vidaredistribution, ingen intäktströskel och inget separat kommersiellt avtal, till skillnad från flaggskeppsmodellens villkor.

Två arkitektoniska detaljer betyder mer för den som driftsätter än huvudspecifikationerna. Den första är hybrid attention: de flesta lager använder Gated DeltaNet linjär attention och endast en fjärdedel behåller en full KV-cache, så långkontextminnet är en bråkdel av vad en konventionell 64-lagers tät modell behöver — samma knep som gör ett 262K-fönster realistiskt i en enda konsument-GPU. Den andra är multi-token prediction (MTP), som levererar checkpointen med ett eget spekulativt avkodningshuvud och påtagligt snabbar upp avkodning när serveringsstacken använder det.

Det är också den videokapabla i familjen. Den flaggskeppsöppna checkpointen, Qwen3.8-2.4T-A95B, är i praktiken endast text i sin nedladdningsbara form, och det hostade Qwen3.8-Max API:et lägger till vision ovanpå dessa vikter. 27B är den vikt du faktiskt kan ladda ner och köra som hanterar text, bild och video direkt ur lådan – vilket är varför en CPU-sökväg för dess videoläge är värd att hålla ögonen på.

Vad SGLang PR faktiskt ändrar

Pull requesten (sgl-project/sglang #35492) är smal och lättläst. Dess egen beskrivning: ”Detta PR är för att stödja Qw​en3.8 text+video, genom att lägga till torchcodec, ffmpeg och ta bort pin_memory.” I praktiken är det tre åtgärder.

• torchcodec — PyTorchs ffmpeg-baserade videodekodningsbibliotek — läggs till i stacken, så att videoramar för Qw​en3.8 text+video kan avkodas och förbehandlas på värdens CPU. PR:n pinnar torchcodec 0.12.0 mot torch 2.12 och noterar att ffmpeg måste hållas under version 9.

• pin_memory tas bort från den multimodala sökvägen. pin_memory är en GPU-överföringsoptimering som låser värdbuffertar för snabb asynkron kopiering till en enhet; att ta bort den på en CPU-only-sökväg är tecknet på att målhårdvaran inte har någon diskret accelerator i databanan.

• Reproduktionskommandot startar den faktiska modellen — Qwen/Qwen3.8-27B — via sglang.launch_server på CPU med text+video-ingångsvägen aktiverad.

Läs statusetiketterna innan du bygger något på det: PR:n är ett utkast, båda CI-körningarna misslyckas, och den väntar fortfarande på granskning från SGLangs kodägare i dag. Det är en riktning, inte en release. Den viktiga kontexten är att SGLang redan betjänar Qwen3.8-27B på GPU — kokboken täcker H200, RTX PRO 6000, RTX 5090 och DGX Spark, med en dedikerad lmsysorg/sglang:qwen38-27b-image — så text+video-vägen på CPU är den genuint nya delen.

Varför CPU text+video spelar större roll än det låter

Alibaba positionerade 27B för edge-AI från första dagen — MediaTek anpassade den till Dimensity-mobilkretsar och C-X1-fordonscockpiten samma dag som vikterna släpptes. Historien om lokal driftsättning förstärkte det: en Q4_K_M-kvantifiering är ungefär 17,1 GB, vilket passar i ett 24 GB konsument-GPU eller en Apple Silicon Mac med 32 GB enhetligt minne. Det enda den historien inte kunde göra var video på en maskin utan GPU alls. Det är den lucka som denna PR åtgärdar.

En CPU-text+video-väg gör videoförståelse driftsättningsbar på vanliga CPU-maskiner — virtuella maskiner, små servrar, lokala rackenheter, edge-gateways — där arbetsbelastningen är asynkron och genomströmning betyder mer än latens. Videobeskrivning, innehållsmoderering, dokument- och diagramtolkning, offline-sökning över inspelningar: dessa är precis de batchjobb som inte behöver en GPU, och idag förutsätter de ändå en sådan för alla VLM:er med videoinmatning.

Den ärliga avvägningen är att Qwen3.8-27B är en modell med 27 miljarder parametrar och ingen CPU-väg gör en 27B snabb. Förvänta dig ensiffriga tokens per sekund på en rejäl server av AVX-klass med videorutor i kontexten — gångbart för batchjobb och jobb över natten, inte för interaktiv chatt över video. Poängen med CPU-vägen är att alternativet överhuvudtaget finns: en driftsättning utan GPU kan köra samma modells videoläge istället för att falla ner till en mindre visionsmodell eller skicka varje bildruta till en moln-GPU.

Var Qwen3.8-27B körs idag

Ekosystemet kom ikapp modellen snabbt. På self-host-sidan har du llama.cpp och LM Studio med GGUF-paket ner till en ungefär 10,7 GB 2-bitars kvantisering, Ollama för en one-liner, och vLLM och SGLang för ordentlig servering. Det mesta av det är text eller bild idag; videovägen på CPU är den del som fortfarande byggs.

Om du hellre inte vill köra en 27B själv, så finns den värdbaserade rutten redan: OrcaRouter serverar qwen/qwen3.8-27b med text-, bild- och videoinmatning, ett kontextfönster på 262 144 token och textutmatning, till $0.33 per miljon inmatade token och $2.40 per miljon utmatade token. Den ligger bakom samma OpenAI-kompatibla endpoint som alla andra modeller på plattformen — en API-nyckel, inget andra avtal — och plattformens automatiska failover och routing-DSL gäller för de 200+ modellerna på den nyckeln. En modell som är fem dagar gammal med en oprövad CPU-väg är ett typexempel på routing i stället för hårdkoppling: du kan testa Qwen3.8-27B på verkliga arbetsbelastningar bakom en rutt utan att satsa hela din anropsväg på en enda serverstack, och växla mellan självhostade och värdbaserade versioner utan att ändra kod.

Siffrorna — leverantörsrapporterade, och värda att kontrollera

Varje rubriksiffra nedan är Alibabas egen, från modellkortet och lanseringsmaterialet. Modellen är fem dagar gammal och oberoende återgivning börjar bara dyka upp, så behandla dessa som påståenden med en tydlig riktning snarare än som utfall. För en 27B är kodnings- och agentpoängen det som fångar uppmärksamheten:

• SWE-bench Pro — 61,7 (rapporterat av Alibaba; dess egen tabell visar Claude Opus 4.6 Max på 53,4)

• Terminal-Bench 2.1 — 73.0 (agentisk terminalkodning)

• OSWorld-Verified — 84.3 (uppgifter för datoranvändningsagenter)

• AndroidWorld — 81.9

• DeepSWE 1.1 — 42,2, ungefär tredubblad jämfört med den tidigare öppna 27B:s 13,3.

På visionssidan — den sida som den här artikeln egentligen handlar om — rapporterar Alibaba VideoMME 87.0 för videoförståelse och MathVision 90.0 för visuellt resonemang utan verktyg. Artificial Analysis:s tidiga bedömning placerar modellen på 52 på dess Intelligence Index och 51 på dess Agentic Index, konkurrenskraftig med mycket större stängda modeller vid vissa resonemangsinställningar; det är fortfarande tidiga poäng för en modell som bara är fem dagar gammal.

En sak som är oproportionerligt viktig för den som kör modellen lokalt eller på CPU är resonemangsvredet. Qwen3.8-27B kommer med tankeläget på och en inställning för reasoning_effort per begäran (låg / medel / xhigh). Standardinställningen xhigh överanalyserar rejält: den numera berömda första körningen av 17GB GGUF tog cirka 21 minuter och 22 000 resonemangstokens att rita en enkel bild. Särskilt på CPU bör du ställa in reasoning_effort medvetet – skillnaden mellan interaktivt och oanvändbart är en enda parameter.

Vad du ska titta på

Tre saker talar om för dig huruvida CPU-sökvägen blir verklig:

• Huruvida PR #35492 sammanfogas. Det är ett utkast med röd CI idag. En sammanslagen, grön version som landar i en release är den punkt där CPU-text+video-vägen blir körbar för oss andra.

• Oberoende benchmarks. Siffrorna 61.7 SWE-bench Pro och 87.0 VideoMME är rapporterade av leverantören. Körningar av LMArena och Artificial Analysis under de närmaste veckorna kommer att visa hur mycket som överlever utanför Alibabas egen testmiljö.

• Huruvida en hostad 1M-kontextversion materialiseras. Nativ 262K är redan mycket; ett multimodalt läge med en miljon token är där hybrid-attentionens cachebesparingar betalar sig.

För närvarande är beslutet enkelt. Om du har hårdvaran körs modellen idag med 17GB Q4 GGUF tillsammans med SGLang eller llama.cpp, och CPU-text+video-PR visar vart den GPU-lösa vägen är på väg. Om du inte har det kan Qwen3.8-27B anropas via OrcaRouter för $0.33 per miljon input-tokens och $2.40 per miljon output-tokens bakom en enda nyckel. Oavsett vilket är den video-kapabla öppna 27B-modellen den mest intressanta modellen att följa i Qw​en 3.8-generationen — och den är fem dagar gammal.