Inkling 2 Smalls vikter har släppts: 394 GB, Apache 2.0 och en nota i nodstorlek

Den första commiten med vikter i {{1}}Inkling 2 Small{{/1}}-arkivet är stämplad 19:53 UTC den 12 november 2026 – nio timmar innan detta skrevs. Fram till dess var modellen ett prisblad och en benchmarktabell: Thinking Machines Lab lanserade den den 5 november med stängda vikter, en Tinker-slutpunkt och en uttalad avsikt att publicera kontrollpunkterna under Apache 2.0 "nästa vecka". Själva modellen är därför åtta dagar gammal. Det nya är att du kan ladda ner den, och nedladdningen är inte en liten fil.

Två repositorier är offentliga. Den primära checkpointen är 393,5 GB fördelat på 36 filer, varav 24 är safetensors-shards. MXFP8-varianten är 622,8 GB. Båda deklareras som Apache 2.0 i modellkortets metadata. Det är hela tillkännagivandet så här långt – modellkortet, repositorierna och en uppdatering på ett stycke som bifogats lanseringsinlägget. Allt nedan är hämtat från dessa primärkällor plus de två cookbooks för servering som levererades tillsammans med dem, och det finns skäl att vara tydlig med det som fortfarande saknas: den externa säkerhetstestning som angavs som förutsättning för att öppna dessa vikter har inte publicerats.

Vad finns det egentligen i nedladdningen?

Börja med storleken, eftersom den är det första som avgör om den här modellen överhuvudtaget är tillgänglig för dig. Upplägget med blandad precision förklarar siffran nästan exakt, vilket är ett gott tecken på att de publicerade siffrorna stämmer överens med varandra snarare än är marknadsföringstext.

• Checkpoint-uppdelning – NVFP4-experter i lager 0 till 39, MXFP8-experter i lager 40 till 47, enligt SGLang-kokboken.

• Beräknad storlek – i genomsnitt 5,33 bitar per parameter över den uppdelningen på 40/48 och 8/48 ger 396 GB för 594B parametrar.

• Uppmätt storlek — 393,5 GB för det primära arkivet, inklusive tokenizer- och konfigurationsfiler.

• MXFP8-repositoriet — 622,8 GB, och safetensors-indexet räknar 612,4B lagrade parametrar jämfört med det primära repositoriets 383,1B, eftersom packning av expertvikter till fyra bitar minskar antalet räknade element snarare än modellen.

Den underliggande arkitekturen är en 48-lagers decoder-only-transformer med ett gles mixture-of-experts-frammatkopplingsblock: 384 routade experter, 8 aktiva per token, 4 608 i dold bredd, 48 attention-huvuden över 8 key-value-huvuden med 128 dimensioner vardera och ett ordförråd på 201 024 tokens. Attention är hybrid snarare än enhetlig – 40 av de 48 lagren använder ett glidande fönster på 1 024 tokens och endast 8 är globala, vilket är där långkontextbudgeten kommer ifrån. Visionstornet är en separat 23-lagers transformer med 1 024 i dold bredd och 16 huvuden, som läser 20×20-pixelplattor med en 2×2-sammanslagning, så varje bildtoken täcker ett 40×40-pixelområde; kortet efterfrågar bilder mellan 40 och 4 096 pixlar per sida.

Det finns också ett multi-token-förutsägelsehuvud påmonterat för spekulativ avkodning – fem lager, en blockstorlek på 8, en Markov-rank på 256 och mållager vid 5, 11, 17, 23, 29, 35, 41 och det sista blocket. Det är exakt de åtta globala attention-lagren, vilket är detaljen som avslöjar att draft-huvudet designades kring hybridstacken snarare än lades till i efterhand. Thinking Machines kallar den resulterande avkodaren för "DSpark".

En administrativ detalj för alla vars juridiska granskning kräver pappersarbete: licensen anges i modellkortets metadata som Apache 2.0 och kortet länkar till den standardiserade licenstexten, men det finns ingen LICENSE-, LICENSE.md-, LICENSE.txt- eller NOTICE-fil i arkivträdet. Alla fyra returnerar inget. Deklarationen är verklig och entydig; den artefakt som de flesta juridiska team förväntar sig att hitta finns inte där.

Hårdvarulistan, och var leverantören och kokboken går isär

Modellkortet anger ett VRAM-golv. Serveringsrecepten anger en topologi. De är inte samma siffra, och gapet mellan dem är det mest praktiska på den här sidan.

• NVFP4 som primär — minst 500 GB aggregerat VRAM; kortets exempel är 2× B300 eller 4× H200.

• MXFP8-variant — minst 800 GB; exempel är 4× B300 eller 8× H200.

• SGLang, topologi per GPU — GB200, GB300 och B300 vid TP 4 / EP 4; B200 vid TP 4 / EP 4, där TP 8 rekommenderas för KV-utrymme; H200 med NVFP4 vid TP 8 / EP 8; MI350X och MI355X vid TP 8 / EP 8; Vera Rubin vid TP 4 / EP 4; TPU7x vid 8 / 8 på en värd med fyra chip.

• MXFP8 på B200 eller GB200 — TP 8 / EP 8, ungefär 151 GB vikter per GPU.

• Begränsningen bakom allt detta — expertparallellism måste vara lika med tensorparallellism, eftersom NVFP4-expertaktiveringsskalor sträcker sig över varje experts hela indatabredd och inte kan shardas med tensorparallellism.

Så kortets 4× H200-exempel uppfyller golvet på 500 GB men är inte en topologi som kokboken validerar; H200 listas med 8-vägs. Lagrings- och minnesgolv säger om det får plats. De säger inte om det körs, och för denna checkpoint är den andra siffran dubbelt så stor som den första på den hårdvara de flesta har. Om du provisionerar bör du planera efter receptet, inte efter golvet.

AMD-sökvägen är två dagar gammal och har inte mergats

Radarn som fick upp den här artikeln fångade pull requesten för AMD-stöd snarare än viktutsläppet, och en ärlig beskrivning av den PR:en i sig är att det är motorarbete – den sorts sak som inte är någon nyhet. Det spelar roll här bara för att det landade samma vecka som checkpoints släpptes, och för att det är den andra kiselleverantören med en containeravbild.

Pull requesten lägger till gfx950-stöd för MI350X och MI355X, staplad på basporten för Inkling 2 Small. Vad den ändrar: ROCm-kärnorna ligger i separata *_hip.py-moduler som endast nås under HIP, CUDA- och NPU-sökvägarna är orörda, den enhetliga KV-poolen och full-graph-prefill blir standardvärden vid start, MegaMoE avvisas i stället för att försökas, och quick-reduce-kvantisering ignoreras om inte en miljöflagga tillåter det. gfx950 krävs om inte en andra miljövariabel åsidosätter det – vilket innebär att kort i MI300-klassen avvisas vid start, och PR-författaren säger att gfx942 "har inte körts".

Mätningarna i PR:en, som är författarens egna och inte granskade: 426 enhetstester godkända på en MI350X, 98,0 % på GSM8K-200 vid balanserad ansträngning och 97,5 % med DSpark vid en acceptanslängd på 4,04, samt tiden per utdatatoken vid 2 048 indata och 512 utdata på 5,15 ms balanserat mot 2,10 ms med DSpark. Det motsvarar ungefär 194 och 476 utdatatoken per sekund i en enda ström över åtta acceleratorer. Med AITer aktiverat ändras noggrannhetssiffrorna till 97,5 % och 96,5 %.

Statusen för PR:en är utkast. CI har inte körts på den – basjobbet är blockerat på grund av en saknad etikett och det finns ingen AMD-körning registrerad för commiten som granskas – och alla listade kodägare inväntar fortfarande granskning. Betrakta MI350X-stöd som något du kan bygga från källkod den här veckan, inte som något du kan köpa.

Att servera det innebär en dev image, inte en release

Båda de stora stackarna har stöd från dag ett, och ingen av dem har släppt det ännu. SGLang säger rakt ut att stödet ännu inte finns i någon release och hänvisar till dev-inkling-2-small-byggen, med separata images för Hopper och Blackwell, Vera Rubin, MI35x och TPU7x. vLLM kräver en nightly eller nyare, eller imagen vllm/vllm-openai:inkling-2-small. Det är normalt för en modell av den här storleken och så här ny, men det förändrar vad "stödd" betyder: du följer en branch, och en rebase kan bryta din driftsättning.

De operativa detaljerna som faktiskt kommer att ställa till problem:

• Kontext — vLLM:s TP 4-recept har ett tak på 262 144 token på en tray; det fullständiga fönstret på 1 048 576 token kräver TP 8 över två noder. Vid TP 4 kräver en enda förfrågan på 1 miljon token 64,47 GiB KV-cache, vilket är mer än vad en tray har kvar.

• Spekulativ avkodning – SGLang verifierar 8 token per steg med det medföljande DSpark-huvudet; vLLMs motsvarighet anger 7 spekulativa token med probabilistisk draftning. Receptet varnar för att acceptansen sjunker 15 till 25 % vid temperatur 1.0 om du draftar girigt.

• Parsers – resonemang använder inkling, verktygsanrop använder inkling2, och SGLang väljer båda automatiskt när inget är inställt. vLLMs verktygsanropsparser är opt-in och receptet säger att verktygsanrop inte har benchmarkats end-to-end, bara enhetstestats.

• Prefill/decode-disaggregering – endast validerad som 1P1D på en GB300-tray med fyra GPU:er, NVFP4, utan MegaMoE, med den statiska minnesfraktionen tvingad ner till 0,86 eftersom det automatiska värdet 0,963 orsakade minnesbrist. Uppdelningen passar inte för MXFP8-checkpointen.

• Encoder-disaggregering – ännu inte i avbildningarna, och språkservern stannar om ingen frisk encoder kan nås.

• Minnesutrymme — på 192 GB B200- eller GB200-enheter vid TP 4 är KV-kapaciteten ungefär en tredjedel av vad en GB300-tray ger dig, vilket är den verkliga begränsningen för samtidighet med långa kontexter snarare än den fönsterstorlek som anges på kortet.

Det finns också en communityrapport på själva modellkortet, från de första timmarna efter uppladdningen, med titeln "Hopper-kort är för närvarande inte kompatibla med vllm-avbildningen". Inget svar från en maintainer syns, och jag kunde inte reproducera det, så behandla det som en varningsflagga snarare än ett fynd, och kontrollera innan du driftsätter en Hopper-nod. På SGLang-sidan listas H200 med 8-vägs, så Hopper-vägen är inte stängd — det är bara inte den väg som vLLMs recept beskriver.

Vad självhosting kostar, och varför svaret sällan är priset

Anledningen till att ladda ner 394 GB är kontroll, inte enhetsekonomi, och räkneexemplet gör det snabbt tydligt.

På Tinker prissätts modellen till $0,30 per miljon indatatokens, $0,03 per miljon cachade indata och $1,00 per miljon utdata, vid 256K kontext. Artificial Analysis mäter 84 utdatatokens per sekund och 67,71 sekunder till första token i svaret, till $1,18 per index task och 29,6 minuter per uppgift, mot 154M utdatatokens över hela sviten och en jämförbar median på 89,8M. Det tokenantalet är det som avslöjar det: det här är en modell som tänker länge innan den svarar, och till listpriset för utdata producerar en enda ström som körs för fullt i en timme cirka 302 000 tokens, eller ungefär trettio cent utdata. För att slå en nod som kostar en dollar i timmen behöver du hålla ungefär fyra strömmar sysselsatta; för att slå en nod som kostar tjugo dollar i timmen behöver du sextiosex. Väldigt få utvärderingsarbetslaster, och ännu färre agentiska sådana, upprätthåller den graden av samtidighet mot en modell med 67 sekunders tid till första token.

Vad du i stället får genom att äga vikterna: hela 1M-fönstret på dina egna villkor i stället för på Tinkers 256K-servingnivå, ingen betaväntelista före produktion, finjustering på din egen stack, data som aldrig lämnar ditt nätverk och eval-svep som inte mäts per token. Vad du ger upp: en fungerande releasebuild, den åttavägs-topologi du måste köpa i stället för att hyra, och en serving-stack som du nu underhåller.

Det är den ärliga formen av beslutet, och det är också där ett routningslager passar in utan att behöva låtsas att det är värd för något det inte är. Inkling 2 Small finns inte i OrcaRouters katalog – vi kontrollerade den live modellistan den här veckan och det finns ingen inkling-post bland de 215 – så API-vägen för den här modellen förblir Thinking Machines egen Tinker-plattform och, enligt lanseringsuppdateringen, flera tredjepartsleverantörer för inferens. Vad mer än 200 modeller bakom en enda nyckel ger dig är en fallback: du kan köra självhost-experimentet på en enda nod och behålla produktionen på modeller som vi faktiskt routar, med automatisk failover om experimentet kraschar, och på de modeller vi routar förs leverantörens listpris vidare oförändrat. När en andra och tredje värd tar upp dessa checkpoints upphör failover-delen att vara teoretisk – och leverantörsinlåsningen, som är huvudargumentet för att ladda ner 394 GB från första början, blir svagare.

Var den sitter nu när den är öppen

Poängen ändrades inte när vikterna släpptes; det som ändrades är att den nu tillhör en topplista som den tidigare uteslöts från. På Artificial Analysiss rankning för öppna vikter är Inkling 2 Small fyra av 28 med ett Intelligence Index på 31, mot en median på 24 för jämförelsegruppen.

• Kimi K3.1 Pro — 46.

• DeepSeek V4.1 Flash 1017 vid maximal ansträngning — 33.

• GLM-5.3 med maximal ansträngning — 32.

• Inkling 2 Small — 31.

• MiMo-V2.6-Pro och Ling 3.1 Flash 1019 — 30 styck vardera.

• Mistral Large 4 med hög ansträngning — 26.

• Qwen3.8 27B vid xhigh – 20.

Den intressanta kolumnen i den listan är inte toppen. Alla modeller ovanför Inkling 2 Small kommer från ett kinesiskt labb, och den bästa modellen med öppna vikter från ett icke-kinesiskt labb var Mistral Large 4 på 26. Att öppna dessa vikter minskar den specifika klyftan från tjugo poäng till femton och flyttar toppen av den icke-kinesiska kolumnen. Det rör inte frontlinjen: den bästa öppna modellen ligger femton poäng före, och slutna modeller ligger ännu längre bort.

Leverantörens egen utvärderingstabell är längre och mer smickrande, och varje siffra i den kördes av Thinking Machines på deras egen testrigg med hög ansträngning – utan att ha reproducerats och därför ett tak snarare än en förväntan. Raderna som spelar roll för agentiskt arbete: SWE-bench Pro v2 Hard 86,3 %, DeepSWE v1.1 72,1 %, Vibe Code Bench v1.1 81,6 %, BrowseComp 90,2 % och DeepSearchQA 90,9 %, båda med kompaktering, MCP Atlas 85,4 % full och 85,0 % public, HLE 44,1 % endast text, FrontierCode v2.0 25,4 %. Raden som pekar i motsatt riktning är Terminal Bench Science på 5,7 %, vilket är lågt i absoluta tal och förenligt med profilen med lång horisont och lång betänketid snarare än ett påstående om bred förmåga. Leverantören anger 30,6 för Intelligence Index, medan den live-uppdaterade resultattavlan visar 31 – en skillnad mellan ögonblicksbilder, inte en tvist.

Vad skulle förändra den här bedömningen?

Tre saker, i ordning efter hur mycket de spelar roll.

Säkerhetsprocessen som skulle ha utgjort en grind för den här lanseringen har inte publicerats. Thinking Machines juluppdatering om en säker väg till öppna vikter beskriver fyra externa organisationer som utför testning före driftsättning av första generationens Inkling, och lanseringsinlägget den 5 november knöt den här versionen till "extern säkerhetstestning och red-teaming". Uppdateringen den 12 november som meddelar vikterna innehåller en mening och en länk – till Hugging Face-repositoriet – och inga utvärderingsresultat, inga red team-fynd och ingen revidering av de tidigare villkoren. Det betyder inte att testningen inte ägde rum. Det betyder att en läsare inte kan kontrollera det, och en organisation med en inköpspolicy som efterfrågar underlaget kommer inte att hitta det här.

Stöd i klass med en släppt version skulle förändra vilka som kan ta till sig det. Just nu är valet en dev-gren i SGLang, en nightly i vLLM, eller att bygga AMD-vägen från källkoden utifrån ett ej sammanslaget utkast. I samma stund som stödet landar i en taggad release blir modellen ett driftsättningsbeslut snarare än ett ingenjörsprojekt, och åttavägs-topologin upphör att vara en forskningsuppsättning.

Oberoende reproduktion med standardinställningar skulle visa vad 31 är värt i praktiken. De agentiska raderna är de man bör hålla koll på – SWE-bench Pro på 86,3 och DeepSWE på 72,1 är starka påståenden för en modell med 17B aktiva parametrar, och de producerades vid maximal ansträngning. Tredjepartskörningar vid standardansträngning hamnar alltid lägre. Frågan är hur mycket lägre, och ingen utanför Thinking Machines har svarat på det ännu.

Tills åtminstone en av dem har landat är den korrekta beskrivningen av Inkling 2 Small ovanligt precis: en Apache 2.0-checkpoint som du kan ladda ner idag, som ingen lanserad serving-stack stöder, vars starkaste påståenden kommer från labbet som skapade den, och vars licensgrind öppnades utan pappersarbetet som skulle ha föregått den. Det är en riktig lansering och en riktig lucka, och luckan är den del som är värd att bevaka.