DeepSeek V4.1 Flash vs GLM-5.2: Två MIT-modeller, ett tråkigt svar

DeepSeek V4.1 Flash och GLM-5.2 är samma typ av objekt, och det är den delen som de flesta jämförelser hoppar över. Båda är mixture-of-experts-modeller, båda släpps under MIT med nedladdningsbara vikter, båda tar en miljon tokens i kontext, och båda är tillgängliga via ett hostat API från en leverantör som inte tränade dem. GLM-5.2 kom först och var vid sin release den högst poängsatta modellen med öppna vikter på Artificial Analysis Index med 51. DeepSeek V4.1 Flash kom den 10 september 2026 som den mindre, nyare och billigare modellen i DeepSeeks nya arkitekturfamilj. Jämförelsen som spelar roll mellan dem är inte vilken som är smartare. Det är vilken du kan köra, och till vilken kostnad, för det arbete du faktiskt har.

Det de har gemensamt, vilket är det mesta av det

Börja med överlappningen, eftersom den eliminerar de flesta av de vanliga besluts kriterierna. Om du väljer mellan en öppen modell och en sluten väger du in inlåsning, du väger in möjligheten att finjustera, du väger in huruvida leverantören kan ändra villkoren för dig. Inget av det gäller här. Både DeepSeek V4.1 Flash och GLM-5.2 är MIT-licensierade med vikter som du kan hämta och köra själv. Båda tar 1M tokens indata. Båda är MoE-arkitekturer, vilket innebär att båda är billiga att köra i förhållande till sitt totala antal parametrar, eftersom bara en bråkdel av vikterna aktiveras per token.

Så jämförelsen är inte öppen kontra sluten, och den är inte lång kontext kontra kort. Det är en uppsättning på fyra eller fem siffror, och siffrorna pekar i en riktning när det gäller kostnad och i den andra riktningen när det gäller mognad.

Där de faktiskt skiljer sig åt

• Pris per 1M tokens — DeepSeek V4.1 Flash $0.15 in / $0.60 ut off-peak jämfört med GLM-5.2 $1.40 in / $4.40 ut. Det är drygt 9 gånger inputpriset och drygt 7 gånger outputpriset.

• Cachad indata — V4.1 Flash $0,003 per 1M under lågtrafik jämfört med GLM-5.2 $0,26 per 1M. Nästan 90 gånger, på den radpost som dominerar en agentloops räkning.

• Parametrar — V4.1 Flash 552B totalt med 8B aktiva vid indata och 16B vid utdata jämfört med GLM-5.2 som har ungefär 745B totalt med cirka 40B aktiva. GLM-5.2 aktiverar ungefär två och en halv gång så många parametrar per token.

• Maximal utdata — V4.1 Flash 384K tokens jämfört med GLM-5.2 128K tokens. Tre gånger så högt tak.

• Kontextfönster — 1M tokens vardera. Nivå.

• Oberoende indexpoäng — GLM-5.2 har en poäng på 51 på Artificial Analysis Index, den högsta bland alla modeller med öppna vikter vid dess lansering. DeepSeek V4.1 Flash har ännu inte något publicerat indexvärde.

• Observerad latens till första token — V4.1 Flash 2,63 s vid p50 och 9,05 s vid p95 jämfört med GLM-5.2 2,36 s vid p50 och 10,00 s vid p95, enligt OrcaRouters egen telemetri över 7 dagar. Medianerna ligger på samma nivå. Svansarna gör det inte.

Prisriktningen och mognadsriktningen är motsatta. GLM-5.2 är modellen med det oberoende betyget och den längre historiken. DeepSeek V4.1 Flash är modellen med billigare tokens, en niondel av indatapriset och tre gånger så högt utdatatak. Det finns ingen tolkning av den här listan där en modell helt enkelt dominerar.

Svansen är den underskattade linjen

De flesta jämförelser av modeller med öppna vikter inleds med indexpoängen. Latens-telemetrin förtjänar i stället uppmärksamhet, men inte av den anledning du skulle förvänta dig: medianerna ligger på samma nivå. GLM-5.2:s p50-tid till första token är 2,36 s mot V4.1 Flashs 2,63 s, vilket inte är en skillnad, det är brus i ett delat nätverk. Den som citerar en fördel för första token för den billigare modellen läser fel percentil.

p95 är där de två går isär, och riktningen är den motsatta mot vad prisskillnaden skulle antyda. GLM-5.2:s värsta väntetid är 10,00 s; V4.1 Flash:s är 9,05 s. Det spelar större roll än en median gör, eftersom de förfrågningar en användare lägger märke till är de långsamma. Ett verktyg som vanligtvis är omedelbart och ibland stannar i tio sekunder framstår som opålitligt på ett sätt som ett verktyg som alltid tar tre sekunder inte gör, och i en agentloop som skickar ut tio anrop per tur är p95 det tal som avgör om turen slutförs inom en persons tålamod. GLM-5.2:s svans är inte en defekt; det är en större modell som aktiverar ungefär 40 miljarder parametrar per token, och det kostar vad det kostar. Men det är anledningen till att modellen passar asynkront arbete – en kö, ett batchjobb, en bakgrundsagent som ingen tittar på – bättre än den passar ett gränssnitt för förfrågan och svar.

Ingen av modellerna publicerar någon genomströmningssiffra på de sidor vi kan se, vilket är värt att säga rakt ut i stället för att fylla i. Tid till första token är den enda latensdimension där dessa två kan jämföras på gemensamma data, och i den dimensionen är den ärliga tolkningen att de ligger lika vid medianen och nära varandra i svansen.

Vad ett indexvärde avgör och inte avgör

GLM-5.2:s 51 på Artificial Analysis Index är en verklig, oberoende framtagen siffra och det starkaste enskilda argumentet för modellen. Den är också en sammansatt storhet: ett enda tal som aggregerar flera utvärderingsset, vilket gör den till en bra sammanfattning av allmän förmåga och en dålig förutsägelse av prestanda på en specifik uppgift. En modell som får 51 och en modell utan publicerad poäng är inte samma sak som en modell som får 51 och en modell som får 40.

Den ärliga hållningen till DeepSeek V4.1 Flash är att dess oberoende underlag är tunt, och orsaken är åldern. Den har varit allmänt tillgänglig i tolv dagar. Den enda färska tredjepartsutvärderingen där den förekommer – Agents on Rails agentiska kodningstavla publicerad den 21 september 2026 – placerade den på 17 % vid maximal insats, i mitten av fältet, över GLM-5.3 Flash på 15 % och under Gemini 3.8 Flash på 23 %. Det är en enda tavla som mäter en enda snäv sak, och den ersätter inte en Index-poäng. Den som hävdar att V4.1 Flash slår GLM-5.2 i kapacitet just nu extrapolerar från arkitektur och pris, och rapporterar inte en mätning.

Argumentet för vardera, klart uttryckt

DeepSeek V4.1 Flash är modellen att välja när arbetsbelastningen har hög volym, är latenskänslig eller utdatatung. En niondel av indatapriset och ungefär en nittiondel av priset för cacheläsning är en strukturell fördel i en agentloop som läser om kontexten varje tur, och ett utdatatak på 384K är en annan kategori av artefakt än 128K. Om din uppgift är klassificering, extrahering, lång strukturerad generering eller den högvolymiga utföraren i en agentpipeline, är kostnadsskillnaden inte marginell — den är skillnaden mellan en livskraftig pipeline och en icke livskraftig.

GLM-5.2 är modellen att ta till när du behöver en publicerad, oberoende verifierad förmågesiffra för att motivera ett beslut, eller när arbetet är asynkront och en väntetid på tio sekunder i värsta fall är osynlig. Det är det mogna valet: poängen finns, beteendet är dokumenterat, modellen har varit i produktion tillräckligt länge för att andra ska ha hunnit hitta dess gränser. Det ligger ett verkligt värde i det, och det fångas inte av en priskolumn.

Där ingendera är uppenbart rätt — en allmän assistent som hanterar blandad trafik — är det användbara draget inte att välja. Det är att skicka merparten av trafiken till den billiga modellen och hålla den dyra till de förfrågningar som behöver den.

Köra båda som ett system

Eftersom båda modellerna har öppna vikter och båda är värdbaserade är split-and-route-mönstret ovanligt billigt att sätta upp här, och det är här OrcaRouters routningslager förtjänar sin plats i stället för att vara ett påklistrat säljargument. Båda modellerna ligger bakom en enda nyckel, så routningsbeslutet är konfiguration i stället för en andra integration: en regel som skickar korta förfrågningar med hög volym till DeepSeek V4.1 Flash och långa asynkrona jobb till GLM-5.2 är några rader i stället för en gren i din applikationskod.

Två egenskaper hos plattformen är särskilt viktiga för den här kombinationen. OrcaRouter förmedlar leverantörernas listpriser vidare med 0 % påslag, så siffrorna ovan är leverantörernas egna priser och DeepSeeks peak-schema gäller exakt som DeepSeek definierar det — peak är 01:00–04:00 och 06:00–10:00 UTC på vardagar, med helger helt off-peak, vilket är ett schemaläggningsbeslut som är värt att fatta uttryckligen för en så billig modell. Och routing-DSL:en kan komponera flera modeller till ett anrop, vilket är det naturliga sättet att använda två modeller med öppna vikter vars styrkor inte överlappar: den billiga producerar, den starkare granskar, och anroparen ser ett enda svar. Automatisk failover ligger bakom båda vägarna, vilket spelar roll när en av de två modellerna är tolv dagar gammal och dess beteende på dina data ännu inte är känt.

Anledningen till att detta är rätt form snarare än en kompromiss är att de två modellerna skiljer sig åt längs axlar som inte konkurrerar. Den ena är snabb och billig; den andra är poängsatt och långsam. En pipeline som använder båda är inte en hedge, den matchar instrument mot uppgifter.

Vad du ska titta på

• En publicerad siffra från Artificial Analysis Index för DeepSeek V4.1 Flash. Tills den finns är kapacitetsjämförelsen mellan dessa två modeller ett argument, inte en mätning – och det är den enda bevisningen som skulle avgöra saken.

• Huruvida GLM-5.2:s latensprofil förbättras. Dess p95 på 10,00 s är det tal som mest sannolikt kommer att ändras när hostingleverantörer optimerar, och det är för närvarande den största enskilda uppmätta skillnaden mellan de två modellerna – en väntetid i svansen, inte ett pris.

• Huruvida DeepSeeks schema för högtrafik ändras. För en modell på 0,15 USD per miljon indatatokens är högtrafikmultiplikatorn den största enskilda variabeln i kostnadsmodellen.

Tills det första av dessa landar är den korrekta sammanfattningen: DeepSeek V4.1 Flash är ungefär nio gånger billigare på indata och nästan nittio gånger billigare på cachad indata än GLM-5.2, och den har tre gånger så högt utdatatak; GLM-5.2 är modellen med den oberoende poängen och den längre historiken, och dess median för första token ligger i nivå med den billigare modellens, även om dess värsta fall inte gör det. Båda är MIT. Båda är en nyckel bort. Välj efter arbetsbelastning, inte efter vinnare.