Nanbeige4.3-33B: 17 av 20 segrar, en 512K-kontext och inget oberoende testat

Klockan 02:49 UTC den 24 oktober 2026 blev ett Hugging Face-förvar med namnet Nanbeige/Nanbeige4.3-33B offentligt, fyra minuter efter bascheckpointen med samma namn. Inget lanseringsinlägg dök upp. Inget blogginlägg, inget leverantörsmeddelande, inget pressmeddelande – modellkortet är hela förstahandsdokumentationen för en släpp med öppna vikter på 33,1 miljarder parametrar vars huvudpåstående är att den slår Qwen3.8-27B på 18 av 20 benchmarks. Det påståendet är inte falskt. Det går heller inte att verifiera ännu, och bevakningen sedan dess har mest upprepat tabellen utan att läsa fotnoterna under den.

Så siffrorna säger två saker samtidigt. Nanbeige4.3-33Bligger först i 17 av de 20 raderna i sin egen tabell, och den slår Qwen3.8-27B i 18 av dem. Det är olika antal och båda är korrekta: de tre rader där den inte ligger först är SWE-Bench Pro, där Qwen3.8-27B vinner med 61,7 mot 60,3, GDPval, där Qwen3.8-27B vinner med 86,4 mot 84,8, och GPQA Diamond, där Gemma4-31B:s 91,3 slår båda. Att förlora två rader mot Qwen3.8-27B och en mot Gemma4-31B ger dig 18 av 20 mot Qwen-modellen och 17 av 20 mot fältet. De flesta genomgångar väljer en siffra och utelämnar den andra, vilket är en liten sak som säger dig hur noga resten har lästs.

Vad repositoriet fastställer, och vad det inte fastställer

Börja med det som kan verifieras genom att öppna filer snarare än att citera prosa, för klyftan mellan de två är själva poängen här.

• Bekräftat: vikterna finns. Fjorton safetensors-shardar med totalt 66 259 989 086 byte, bfloat16, i ett kodförråd skapat 02:49:18Z den 24 oktober 2026 och senast ändrat 11:11Z den 25 oktober. En separat bascheckpoint, Nanbeige4.3-33B-Base, skapades tre minuter tidigare kl. 02:46:52Z.

• Bekräftat: licensen är Apache 2.0, vilket anges i repots metadata och i kortets frontmatter. Det finns ingen fil med namnet LICENSE bland de åtta filerna som inte är vikter, vilket är en dokumentationslucka snarare än en juridisk sådan – metadatafältet är det som Hubben och de flesta skannrar läser.

• Bekräftat: arkitekturen är en vanlig Llama-stack, inte en blandning av experter och inte den loopade transformer-design som familjens små modeller använde. Mer om konfigurationen nedan.

• Bekräftat: det finns ingen leverantörshostad slutpunkt. Hubens mappning av inferensleverantör för detta repository är tom, och kortet erbjuder vLLM, SGLang och Transformers, i den andan: ta med egna GPU:er.

• Ej bekräftat: ingenting om hur den tränades. Inget antal förträningstoken, ingen datamix, ingen beräkningssiffra, inget recept för efterträning och inget avsnitt om begränsningar eller säkerhet. Kortets citatblock är fyra rader långt.

• Inte bekräftat: att något publicerat nummer är reproducerbart. Det finns ingen utvärderingsram i arkivet – inga skript, inga uppgiftskonfigurationer, inga loggar – och per den 26 oktober har ingen tredje part publicerat en poäng, ett arena-betyg eller en indexplacering för den här modellen.

• Ej bekräftat: att lanseringen skedde i smyg. Det gjorde den inte. Den var inte aviserad av labbet, vilket är en snävare och mer korrekt beskrivning: kortet är ett fullständigt lanseringsdokument med en benchmarktabell på tjugo rader, och aggregatorer plockade upp det inom en dag. Det som saknas är ett förstapartsinlägg som förklarar vad Nanbeige anser sig ha byggt.

Den distinktionen spelar roll för alla som ska avgöra vad de ska göra med lanseringen. Ett labb som inte säger något har inte sagt dig något om avsikt, stöd eller nästa kontrollpunkt. Ett labb som publicerar ett kort men inget inlägg har berättat mycket för dig om modellen och lämnat strategin implicit – och i det här fallet står strategin klart och tydligt i kortets andra stycke, när du väl lägger märke till den.

Kortet kallar det för en lärare, och det ger hela releasen en ny inramning.

Nanbeige4.3-33B beskrivs som "flaggskeppslärarmodellen" för Nanbeige4.3-serien, byggd först så att labbet kan destillera agentiskt beteende till mindre modeller, "t.ex. för Nanbeige4.3-3B". Modellkortet anger "toppmodern agentisk prestanda bland öppna modeller i ~30B-parameterklassen" som målet och beskriver sedan omedelbart 33B som grunden för en destillationspipeline snarare än slutprodukten.

Läser man det bokstavligt är släppet en träningsartefakt som råkar vara leveransklar. Det är modellen man använder för att generera trajektorier för en 3B-student, och anledningen till att dess benchmarksvit är tung på långhorisontella agentuppgifter – Terminal-Bench, DeepSWE, JobBench, Toolathlon – är att det är de beteenden man vill överföra. Nanbeige4.3-3B har inte släppts. När den väl släpps kommer den att vara modellen som de flesta faktiskt kör, och den här 33B:n kommer att vara det som förklarar dess resultat.

Det finns en bieffekt som är värd att nämna: en lärarmodell är optimerad för att producera bra trajektorier inom en generös tokenbudget, inte för att vara billig vid inferens. Modellkortets rekommenderade inställningar bekräftar det – 65 536 max nya tokens för agentiskt arbete och 262 144 för resonemang och chatt, med tänkande på som standard. En modell som uppmanas att generera en kvarts miljon tokens är inte en modell man sätter bakom en chattruta utan en budget.

33B som konfigurationsfilen beskriver

Läs config.json och formen är konventionell på ett sätt som marknadsföringen inte är. Femtiotvå lager, dold storlek 7,168, 56 query-huvuden mot 8 key-value-huvuden – en grupperad query-kvot på 7:1 – huvuddimension 128, en FFN-bredd på 22,016 och en vokabulär på 166,912 token. RoPE-basen är 120,000,000 utan att någon skalning har tillämpats, och max_position_embeddings är satt till 524,288. transformers-versionen som stämplats i filen är 4.51.1.

Parametrantalet följer av de siffrorna. Attention-projektionerna uppgår till 117,4 miljoner parametrar per lager, den trelagers MLP:n till 473,4 miljoner, vilket ger 590,9 miljoner per block över 52 block: 30,7 miljarder. Två oberoende inbäddningsmatriser på 166 912 gånger 7 168 tillför 2,4 miljarder. Totalt blir det 33,1 miljarder, vilket är vad namnet lovar och vad 66,3 GB bfloat16 väger.

Mot den modell som den ägnar sin tabell åt att attackera är skillnaderna skarpare än poängen antyder.

• Storlek — 33,1B täta parametrar för Nanbeige4.3-33B jämfört med 27,78B täta parametrar för Qwen3.8-27B. Båda är täta modeller; ingen av dem är en blandning av experter.

• Modalitet — endast text, engelska och kinesiska, för Nanbeige4.3-33B jämfört med inbyggd inmatning av text, bild och video för Qwen3.8-27B. Om din pipeline läser skärmdumpar är jämförelsen över innan benchmarkarna ens har börjat.

• Uppmärksamhet — enhetlig full uppmärksamhet över 52 lager för Nanbeige4.3-33B jämfört med en hybridstack för Qwen3.8-27B, som kör 48 linjära gated DeltaNet-lager mot 16 lager med full uppmärksamhet i ett 3:1-mönster. Det är därför Qwen-modellen är billig vid lång kontext och den här inte är det.

• Kontext — 524 288 tokens inbyggt för Nanbeige4.3-33B jämfört med 262 144 inbyggt, utbyggbart till cirka 1M med YaRN, för Qwen3.8-27B.

• Licens — Apache 2.0 på båda, vilket tar bort det vanliga skälet att föredra den ena.

Skillnaden i uppmärksamhet är inte en fotnot. Det är hela anledningen till att nästa avsnitt finns.

512K är ett värde i en konfigurationsfil, inte en arbetskontext

Varje sammanfattning av den här utgåvan börjar med fönstret på en halv miljon token. Nästan ingen av dem gör beräkningen, och beräkningen är obarmhärtig.

Med 52 lager, 8 nyckel-värde-huvuden med 128 dimensioner och bfloat16-lagring kostar varje token i cachen 2 × 52 × 8 × 128 × 2 byte – 212 992 byte, eller 208 KiB. Tre konsekvenser följer direkt.

• Vid fulla 524 288 token är KV-cachen ensam 111,7 GB, ungefär 104 GiB. Det är mer än de 66,3 GB vikter, och det får inte plats på någon enskild accelerator som säljs idag.

Vid 131 072 tokens – en fjärdedel av det annonserade fönstret – är cachen 27,9 GB, ungefär 26 GiB. Lägg till vikterna och du är uppe i 92 GB före aktiveringar, vilket är anledningen till att kortets egna exempel använder fyrvägs tensorparallellism.

• Vid 32 768 tokens är cachen 6,98 GB, ungefär 6,5 GiB. Detta är siffran som spelar roll i praktiken, och det är den kontextlängd som communityns GGUF-repositoriums llama.cpp-exempel faktiskt ställer in.

Inget av detta gör 512K-påståendet ohederligt. Fönstret är nativt – inget YaRN, ingen skalningsfaktor, en rope-bas på 120 miljoner – och på en nod med fyra GPU:er och tillräckligt med minne kan du servera den. Det innebär att siffran i rubriken är ett tak som du inte kommer att nå på hårdvara du äger, och att den som citerar "512K-kontext" som köpskäl inte har räknat in cachen i priset. Jämför det med Qwen3.8-27B-designen, där tre fjärdedelar av lagren håller ett återkommande tillstånd av konstant storlek i stället för en växande cache, och gapet i kostnad per token för lång kontext är strukturellt snarare än en fråga om trimning.

Ytterligare en sak från konfigurationen, och det är den typ av detalj som kostar en eftermiddag: use_cache är satt till false, i både config.json och generation_config.json. Om du laddar modellen via modellkortets Transformers-utdrag och anropar generate utan att åsidosätta det, räknas prefixet om vid varje steg. vLLM- och SGLang-vägarna hanterar sin egen cache och påverkas inte. Om din första benchmarkkörning verkar oförklarligt långsam bör du kontrollera detta innan du skyller på vikterna.

Att läsa benchmarktabellen så som dess fotnoter uppmanar dig att göra

Tabellen är bättre dokumenterad än de flesta leverantörstabeller, och det är i dokumentationen som förbehållen finns. Tolv fotnoter ligger under tjugo rader, och de säger mer om jämförbarheten än poängen gör.

Terminal-Bench 2.1 kördes med Terminus 2. Terminal-Bench 4.0 och DeepSWE kördes med mini-swe-agent v2.4.6.

• NL2Repo kördes med Claude Code-harnesset; JobBench med Claude Code plus ett sökverktyg.

• SWE-Atlas-QnA-svar bedömdes mot 1 304 uppgiftsspecifika bedömningskriterier med GPT-6 Sol som domare vid medelhög resonemangsansträngning. En kriteriedomare är en andra modell i loopen, och det är inte modellen som testas.

• Toolathlon-Verified sätter ingen max_tokens-gräns för enskilda förfrågningar. Claw-Eval poängsätts endast på General-delmängden, 157 uppgifter med en enda tur. YC-bench behåller endast de tio senaste dialogturerna som historik före varje anrop. GDPval använder reviderade bedömningskriterier.

• Nanbeige4.3-33B utvärderades självt med preserve_thinking=true, vilket behåller tidigare assistentresonemang över turar. Kortet rekommenderar precis det för verktygsanvändning över flera turar, och precis motsatsen för vanlig chatt.

Lästa tillsammans beskriver dessa anteckningar en svit byggd för att mäta agentbeteende över långa horisonter med generösa budgetar. Det är en försvarbar sak att mäta — det är vad modellen är till för — men det är också det scenario där valet av harness påverkar poängen mest. Den största skillnaden i tabellen, DeepSWE på 65,5 mot 42,5 för Qwen3.8-27B, är en spridning på 23 punkter i ett benchmark som drivs av ett agentscaffold. De minsta skillnaderna finns i raderna där scaffolden spelar minst roll: AIME 2026 på 95,2 mot 94,5, Tau3-Bench på 48,8 mot 48,5, EnterpriseOps-Gym på 41,0 mot 40,2.

Det mönstret är förenligt med två förklaringar. Antingen är modellen genuint mycket bättre på agentisk kodning än sina jämlikar, eller så är de agentiska raderna de där ett labb som finjusterar sin egen scaffold mot sin egen modell vinner mest. Inget i repositoriet skiljer mellan dem, och den ärliga hållningen tills någon kör om sviten är att båda är giltiga. De rader där modellen vinner med en poäng eller mindre — Tau3-Bench, EnterpriseOps-Gym, AIME, Claw-Eval med 78,3 mot 75,2 — är de som minst sannolikt överlever ett oberoende testramverk.

Det som inte finns, per den 26 oktober, är överhuvudtaget någon extern siffra. Ingen post i Artificial Analysis index, ingen arena-rating, ingen reproduktion av någon. Kortets egen AA-LCR-siffra på 84,0 är Nanbeige som kör ett Artificial Analysis-benchmark, inte Artificial Analysis som kör Nanbeige.

Det enda praktiska testet hittills, och vad det visar

En person har publicerat något från att faktiskt ha kört vikterna, och resultatet är värt att rapportera just för att det är tunt. En japansk utvecklare laddade den fullständiga bfloat16-checkpointen på en Colab A100 med 80 GB, med vanlig Transformers med automatisk dtype- och enhetsmappning, och uppmätte cirka 63 GB VRAM i användning. Det första svaret, begränsat till 1 024 nya tokens, tog ungefär elva sekunder. Ingen siffra för tokens per sekund angavs; intrycket var att en 33B tät modell i bfloat16 är långsam, vilket är vad aritmetiken förutsäger.

Tre prompter följdes. Jämförelsen 9.11 mot 9.8 blev rätt, med en tydlig decimalförklaring. En fråga om animefigurer gav subjektivt sett ett okej resultat men förvanskade namn. En fråga om Japans premiärminister gav ett felaktigt svar, ett påstått kunskapsavbrott i juni 2024 och ett hallucinerat namn. Engelskt tankekedja läckte före den avslutande think-taggen.

Tre informella promptar är inte en utvärdering och bör inte läsas som en. Vad de är är en datapunkt som stämmer överens med formen på leverantörstabellen: en modell hårt finjusterad för engelskt agentiskt arbete, två år efter vad gäller världskunskap och oanmärkningsvärd på ett andra språk. Kortet uppger engelska och kinesiska; ingen har heller publicerat ett test på kinesiska.

Där den kvantiserade versionen inte längre är samma modell

De flesta som kör detta kommer inte att köra 66 GB bfloat16. De kommer att köra en 4-bitars kvantisering på ett grafikkort, och kvantiseringsrapporterna som dök upp inom ett dygn efter lanseringen tyder på att det är ett större steg nedåt än vanligt.

Community-GGUF-förrådet publicerar KL-divergens och top-1-överensstämmelse gentemot bfloat16-modellen, mätt på en standardiserad textbänk, och dess egen README varnar för att modellen är "ovanligt känslig för kvantisering".

• Q8_0, 35,2 GB — KL 0,0032, 98,0 % top-1-överensstämmelse.

• Viktighetsmatris Q5_K_M, 24,7 GB — KL 0,0213, 94,7 % top-1.

• Viktighetsmatris Q4_K_M, 21,2 GB — KL 0,0380, 92,6 % top-1.

• Vanlig llama.cpp Q4_K_M, 20,1 GB — KL 0,0693, 89,9 % top-1. Samma bitbredd som raden ovan, nästan dubbelt så stor avvikelse.

• Viktighetsmatris IQ3_S, 17,1 GB – KL 0,1019, 87,5 % top-1. I README-filen anges att filer under 4 bitar tappar betydligt mer noggrannhet.

En 8-bitars MLX-konvertering rapporterar 98,6 % top-1 vid KL 0,015 och jämför en 4-bitars AWQ-väg vid 92,1 % top-1 med KL 0,181 – ett mycket brantare fall än importance-matrisens GGUF vid samma nominella bredd.

Den praktiska tolkningen: om du utvärderar den här modellen med 4-bit på ett enda 40- eller 48 GB-kort och den misslyckas med dina agentuppgifter, har du utvärderat en modell som stämmer överens med den publicerade på ungefär nio av tio tokens. I prosa är det osynligt. För verktygsanrop, där ett felformat argument avslutar turen, är en avvikelserate på 7 % en annan produkt. Om de agentiska påståendena är anledningen till att du är intresserad är det ärliga minimumet Q5 med en importance matrix, eller bfloat16 på hyrd hårdvara för utvärderingskörningen.

Vad det kostar att prova, och hur du kan prova det utan att satsa på det

Nanbeige har inte publicerat något pris, eftersom det inte finns något att prissätta: modellen är vikter, inte en tjänst, och Hub listar ingen inferensleverantör för den. Det lämnar tre vägar – fyra 80 GB-GPU:er för bfloat16, ett 48 GB-kort vid Q5, eller att vänta på att en leverantör listar den.

Som jämförelse är modellen som den påstår sig slå tillgänglig på begäran. Qwen3.8-27B körs på OrcaRouter för 0,33 dollar per miljon indatatokens och 2,40 dollar per miljon utdatatokens, med ett fönster på 262K och en p50-tid till första token på cirka 2,95 sekunder. En agentisk prompt på 65 536 tokens plus 8 000 tokens utdata kostar ungefär fyra cent. Det är siffran som en självhostad 33B måste slå, och den måste slå den samtidigt som den bär GPU-tomgångstid, kvantiseringsrisk och avsaknaden av en reservväg.

Vi hostar inte Nanbeige4.3-33B, och inget här bör tolkas som ett påstående om att vi gör det. Det vi kan göra är att göra jämförelsen billig i den andra riktningen: Orca Connect sätter din egen GPU bakom samma nyckel som den hostade katalogen, så en självhostad Nanbeige-endpoint och Qwen3.8-27B kan ligga bakom en enda endpoint och en enda routingregel medan du bestämmer dig. Dirigera en del av trafiken till den nya checkpointen, behåll den hostade modellen som fallback och låt förfrågningsloggarna – betyg, latens, kostnad per anrop – avgöra en diskussion som leverantörstabeller inte kan. Påslaget på 0 % spelar roll här på ett specifikt sätt: leverantörernas listpriser förs vidare oförändrade, så när en leverantör sänker ett pris förblir jämförelsen du satte upp förra veckan ärlig.

Vem bör agera på detta, och vem bör vänta?

Om du bygger en destillationspipeline är detta den mest intressanta öppna checkpointen den här månaden. En 33B dense-lärare med en tillåtande licens, dokumenterade samplingsinställningar och en benchmarksvit vald för att mäta exakt det beteende du vill överföra är en användbar tillgång, och det faktum att labbet säger att det först bygger en lärare är en signal om vart serien är på väg. Ladda ner den, kör din egen utvärdering och förvara kortets harness-anteckningar bredvid dina resultat.

Om du behöver en modell i produktion den här veckan, vänta. Det finns ingen oberoende poäng, ingen hostad slutpunkt, en praktisk rapport med tre prompter i, och en kvantiseringsprofil som försämras snabbare än vanligt vid de bitbredder som de flesta har råd med. Inget av detta är diskvalificerande – det är bara ännu inte bevis.

Om du behöver seende är jämförelsen redan avgjord: Qwen3.8-27B läser bilder och video, och den här modellen läser text på två språk.

Sakerna att hålla utkik efter är specifika. Nanbeige4.3-3B, destillationsmålet, som kommer att berätta för dig om läraren var värd att bygga. Den första oberoende körningen av Terminal-Bench 4.0, raden med det största gapet och den största scaffold-känsligheten. Och om en leverantör överhuvudtaget listar 33B — för i samma stund som någon gör det upphör 512K-kontexten att vara ett konfigurationsvärde och blir en rad på fakturan, och aritmetiken i den här artikeln blir någons faktura.