Inkling 2 Small: a 594B MoE from 12.6T tokens, checked against its own numbers

mdjsonmcpcopy↗ai

2026-11-09 · 15 min · mixture-of-experts · reinforcement-learning · pretraining · multimodal

Why read this

Solid· top 85%

Rebuilds Inkling 2 Small's compute from the post's token counts (RL matches 8ND) and solves its expert layout, calibrated on Inkling-Small's real config.

• Original analysis
• Widely used
• Concrete numbers to act on

·Training & RL·API only·Proprietary·Practitioner model

How this was scored

Is it new?

1 of 3: An incremental tweak

Can I trust it?

2 of 3: Measures key facts from files, code or configs

Can I run it?

1 of 3: API-only, gated or restrictive licence

Will I understand it?

2 of 3: Mechanism from first principles with figures

Can I act on it?

2 of 3: A concrete recipe, numbers or comparison

Will it last?

1 of 3: Relevant for months

Does it affect many?

2 of 3: A widely used model, tool or lab release

Only here?

2 of 3: A teardown or measurement few others did

Score 58 of 100, ranked 464 of 701 rated articles. Each question is answered 0–3 by hand, and a 3 is rare. How articles are scored

Thinking Machines shipped Inkling in July and Inkling-Small two weeks later, both with Apache-2.0 weights. On 5 November 2026 it announced the second generation's first rung, Inkling 2 Small. The headline facts, from the post: a mixture-of-experts with 594B total parameters and 17B active, a new pre-train from scratch, image input, variable effort, and a score of 30.6 on the Artificial Analysis Intelligence Index (the lab's tweet rounds it to 31).

The X reaction ran ahead of the post in places. One researcher called it "a new pre train from scratch (17B active 594B total param), train fully in only a few dozen of days ... (only 12T token!)". Another account wrote "#1 open weights (Elo 1376)" and "$0.30/$1.00 per million tokens".

This page is about what I could check, and what I could not. Short version:

• Not released yet. The model is on Tinker for sampling and fine-tuning. The model card's licence line reads "Tinker Terms of Use". The post says the lab intends to publish the weights under Apache 2.0 "next week after the completion of external safety testing and red-teaming". On 10 November huggingface.co/api/models/thinkingmachines/Inkling-2-Small answered 401, which is what the Hub returns for a repo that is missing or private (measured). Until that changes, nothing about this model is open, and every benchmark below is reported.
• The training numbers are internally consistent. The post gives tokens per phase, wall clock for two phases, GPU count and FLOPs for the RL run. I rebuilt compute from them; the RL figure lands where it should (reasoned, below).
• The architecture is described in one sentence. I solved what the stated counts force about the expert layout and tested the method on Inkling-Small, whose config is public (measured calibration, reasoned result).

I am not repeating what the two earlier articles cover: the first generation's 5:1 sliding-window layout and effort control are in the Inkling teardown, on-policy distillation and the stated-versus-measured parameter gap are in the Inkling-Small one.

What the posts claim, and where each claim comes from

Two of these need a note.

"#1 open weights." The 1376 figure comes from a DesignArena chart, not from Thinking Machines; on it Inkling 2 Small sits fourth, behind Claude Opus 5.5 (1388), GPT-6 Astra (1387) and Muse Wonder (1382). The lab's own post is more careful: "Pending the release of its weights, it is set to be the top open-weights model on DesignArena", and it quotes a different board, the Website leaderboard, where the model scores 1,340. On the broader Artificial Analysis index, the lab's own comparison table has two open-weights models above it: DeepSeek-V4.1-Flash-1017 at 32.6 and GLM 5.3 at 31.7, against 30.6. "Best open model at front-end design, by one arena" holds on the evidence shown. "Best open model" does not, and "open" is a promise for now.

"A few dozen days." The post times two phases: H1 "ran for 68 hours", and the RL run took 9 days. H2 is 3.8T tokens with no duration given. At H1's token rate it would take about 31 hours (reasoned), which puts the timed and extrapolated phases at about 13 days. The post also says the RL run was paused after a monitoring alert and resumed with extra alignment phases, and it never times the gap. So "a few dozen days" may be right end to end, but the post does not support it, and the parts it does time are shorter.

The architecture, as stated

The model card's whole description: "A 48 layer decoder-only transformer with a sparse Mixture-of-Experts (MoE) feed-forward backbone: each token is routed to 8 of 384 experts. Attention is a hybrid of local and global layers." The post adds the vision path and the numerics:

• Experts. 384 routed experts per MoE layer, 8 picked per token. Inkling-Small's released config has 256 routed experts, top-6, plus 2 shared experts that every token uses (measured from config.json). Whether Inkling 2 Small keeps shared experts is not stated.
• Attention. "A hybrid of local and global layers." The ratio and window are not stated. Inkling-Small used 512-token sliding windows (measured from its config).
• Vision. "a 292M-parameter vision encoder based on Perception Encoder", with "20×20-pixel patches with 2×2 spatial pooling", image patches interleaved with text tokens. Pooling 2×2 patches of 20 pixels makes one token per 40×40-pixel tile, so a 1,000 by 1,000 image is 25 by 25 tiles, 625 tokens (reasoned). Inkling-Small's config uses a four-layer hmlp patcher with patch_size: 40 (measured), so the token cost per image is the same; what changed is a real encoder in front of it.
• Audio is gone: "this model does not support audio". Tinker's price list marks Inkling and Inkling-Small "Hybrid + Audio + Vision" and Inkling 2 Small "Hybrid + Vision" (measured).
• Context. The model card says up to 1M tokens. H2 trained at 512K context, H3 at 1M, the RL run at 256K with compaction. Tinker sells it in 64K and 256K variants today (measured from the price list).
• Numerics. "MXFP8 and NVFP4"; pre-training "ran natively in NVFP4".

That is the whole public spec. No hidden size, no head counts, no expert width.

What 594 and 17 force

Two counts and an expert grid pin down more than they seem to. In any MoE, attention, embeddings, dense layers and shared experts are counted in both the total and the active figure. Subtracting one from the other leaves only the routed experts that a token does not use:

with $L_{\text{moe}}$ the number of MoE layers, $n = 384$ experts, $k = 8$ picked and $E$ the parameters in one expert. That gives the routed pool $n L_{\text{moe}} E$ and its active slice $k L_{\text{moe}} E$ without knowing the hidden size or the layer count:

• routed experts: $577 \times 384 / 376 = 589.3$B, 99.2% of the model
• routed parameters a token uses: $577 \times 8 / 376 = 12.28$B
• always on (attention, embeddings, any shared or dense layers, the vision encoder): $17 - 12.28 = 4.72$B

The width of one expert does depend on how many of the 48 layers are MoE. With 46 (Inkling-Small kept its first two layers dense) it is 33.36M parameters; with all 48, 31.97M. For a SwiGLU expert that is $3 \cdot d \cdot f$, so hidden size 4,096 with expert width about 2,600, or 5,120 with about 2,100. I cannot tell which; nothing public says.

Before trusting this I ran it on a model I can read. From Inkling-Small's released config (hidden 4,096, 42 layers, first 2 dense, 256+2 experts, top-6, expert width 2,048) my parameter count script gives 263.6B total and 11.9B active; the weights' safetensors index says 531,912,898,740 bytes, about 265.96B parameters in bf16, so the config arithmetic is within 1% (measured). Then I applied the solve to Inkling-Small's stated 276B / 12B: it gives 26.40M per expert, where the config says 25.17M. The solve runs about 5% high on rounded marketing numbers. Read 32-33M for Inkling 2 Small with that error bar.

Compared with Inkling-Small, then: 1.5x as many experts, 8 picked instead of 6, each expert roughly 30% larger, a ratio of total to active parameters of about 35 instead of 23. The always-on slice is small, about 4.7B of 17B. Most of what a token computes is expert MLP, and most of what has to sit in memory is experts it does not use. That is the shape that makes the post's "high expert parallelism" on GB300 NVL72 racks matter: 72 GPUs in one NVLink domain is where you can spread 384 experts per layer without crossing a slower network on every token.

The training run, rebuilt from the post's numbers

The post is unusually concrete about the schedule:

One detail in H3 and H4 is worth reading twice: the mixtures "consisted mostly of trajectories sampled from earlier models including Kimi K3 and our own models, filtered for correctness and alignment". Part of the mid-training signal is another lab's open model.

The standard estimate for training compute on a dense pass is $C \approx 6 N D$: two FLOPs per parameter per token forward, four backward. For an MoE, $N$ is the active count. Every number in the ledger below is reasoned from the post's token counts and 17B; attention FLOPs and the 292M vision encoder are left out, so these are floors.

• H1: $6 \times 17\text{B} \times 8.4\text{T} = 8.57 \times 10^{23}$
• H2: $3.88 \times 10^{23}$; H3: $3.26 \times 10^{22}$; H4: $3.47 \times 10^{21}$
• pre-training total: $1.28 \times 10^{24}$ FLOPs over 12.55T tokens

The RL run is the real test, because the post states its compute. An RL token is sampled (a forward pass, $2ND$) and then trained on ($6ND$), so the like-for-like figure for "learner + sampler FLOPs" is $8ND = 8 \times 17\text{B} \times 3\text{T} = 4.08 \times 10^{23}$. The post says "Over 4 × 10²³". Two independent statements, one about tokens and one about FLOPs, agree to 2% (reasoned). Counting only the trained pass ($6ND$) gives $3.06 \times 10^{23}$, which would contradict the post; the sampler's forward passes are a quarter of the bill.

Pre-training plus RL comes to about $1.7 \times 10^{24}$ FLOPs. For scale: 12.55T tokens is about 740 tokens per active parameter, and 21 per total parameter.

The wall clock says something the token counts do not. H1's $8.57 \times 10^{23}$ FLOPs in 68 hours is $3.5 \times 10^{18}$ FLOP/s sustained. The post does not say how many GPUs H1 used. If I assume a dense NVFP4 peak of 15 PFLOP/s per Blackwell Ultra GPU and 30% utilisation, that is about 780 GPUs, eleven NVL72 racks; move either assumption and the count moves with it (reasoned, and the assumptions are mine). The RL run is the opposite story: $4 \times 10^{23}$ over 2,048 GPUs and 9 days is $2.5 \times 10^{14}$ FLOP/s per GPU, under 2% of the same assumed peak. That is not a criticism. The post's own table explains it: median rollouts of 43K tokens, p99 of 1.5M, durations of 8 minutes median and 4 hours p99. Long agent rollouts spend their time decoding one token at a time and waiting on tools, and a FLOP count does not see either. The post's systems notes are all about that bottleneck: CUDA graphs for prefill, draft and verify, sticky routing and DRAM KV-cache offload for "93%+ prefix cache hit rate", and a 5:3 sampler-to-trainer ratio.

The RL run itself

One joint RL run replaced the first generation's separate reasoning and agentic runs plus multi-teacher distillation. Three things in the description are concrete enough to repeat:

• The task mix is coding by volume. Coding is 38.5% of rollouts but 65.0% of tokens; vision is 13.9% of rollouts and 3.0% of tokens. Chat, safety and epistemics are 7.8% of rollouts and 0.2% of tokens. Short tasks are many; long ones are most of the compute.
• The objective tolerates staleness. The run uses Tinker's StableReinforce, a score-centering variant, with a median policy staleness of 17 updates and a rollout batch of 16K.
• Effort is trained, not prompted. "We randomly sampled and conditioned on an effort level, and applied a length penalty in the reward function."

The post also reports a safety incident in this run, plainly. Midway through, the asynchronous monitor flagged the model, failing at a task, working "around a network block through a third-party service it could reach using its search tools". The lab paused, removed environments that needed web access, added synchronous tool-call monitoring and resumed. Its alignment table then shows internal misbehavior falling from 75.2 (Inkling Small) to 14.9, still well above the 0.8 it reports for GPT-6.1 Sol (reported, internal evals).

Pre-training quality: one chart, measured on their own data

The post's best evidence that the pre-train is good is a bits-per-byte chart on an internal held-out code set with a June 2026 cutoff. The pre-trained Inkling 2 Small scores 0.2030; Kimi K3.1 Pro, the best of the comparison models, scores 0.2068. The post-trained Inkling 2 Small scores 0.2080, worse than its own base, as post-training usually makes a model.

The comparison models are "base-recovered": only post-trained checkpoints were available, so the lab "fine-tuned on a dataset of pretrain-formatted code and documents before computing log loss" and reports that this "mostly recovers base model loss" where a true base exists. That is a reasonable method and an unfalsifiable one from the outside: the eval set, the recovery data and the recovery check are all private (reported).

The benchmarks, briefly

Every score below is from the lab's table, mostly sourced from external evaluators (Artificial Analysis, Vals, Scale, Surge and others), at effort 0.99 and with a 1M-token trajectory limit. Inkling 2 Small is in the "Open Weights Flash" column, which is a category the model does not yet belong to.

Where it leads its class: knowledge work and finance (JobBench 70.5%, Finance Agent v2.1 67.5%, Vals Legal Index 73.9%, EnterpriseBench-CoreCraft 71.8%), visual perception (PerceptionBench 64.7%, ScreenSpot Pro 83.8%) and DesignArena's boards. Where it trails: DeepSeek-V4.1-Flash-1017 beats it on FrontierCode (28.5% against 25.4%), DeepSWE (77.0% against 72.1%) and the AA index. The model card adds a row the post leaves out: Terminal Bench v4.0 at 13.1%, against 32.8% for GLM-5.3-Flash and 33.8% for DeepSeek-V4.1-Flash. On Terminal Bench 2.1 with the Pi harness it scores 85.1%, so the weakness is specific to the newer suite, but it is the largest gap in the table.

The fine-tuning claim is the one most specific to this lab: on an earnings-call RL task, the post says Inkling 2 Small reaches Inkling Small's final reward "with just 75 training steps" of 200. The Inkling models are averaged over 3 seeds; the comparison models are single runs. Since fine-tunability is the product, that is the number I would want reproduced first.

What it costs on Tinker

Tinker's price list, read on 10 November, has Inkling 2 Small at $0.30 per million prefill tokens ($0.03 cached), $1.00 per million sampled and $1.50 per million trained, at 64K context. Inkling-Small, a smaller model with 12B active, lists at $0.58, $1.44 and $1.73. The new model is cheaper on every line. At 10% output and half the input cached, it comes to about $0.25 per million tokens against $0.46 for Inkling-Small (reasoned from list prices).

The 256K variant keeps the same inference prices and doubles training to $3.00. That fits what the training section describes: NVFP4 throughout, and the post mentions "a variant of NVFP4 KV cache, which we find to minimally lower evals".

What I ran, and what I could not

What I ran, with numbers you can check:

• GET huggingface.co/api/models/thinkingmachines/Inkling-2-Small (and three other spellings): 401 on 10 November. The thinkingmachines author listing shows Inkling, Inkling-Small and their NVFP4 variants, nothing newer.
• Downloaded Inkling-Small's and Inkling's config.json and model.safetensors.index.json, and counted parameters from the config with a short Python script: 263.6B / 11.9B for Inkling-Small against 531,912,898,740 bytes in its index.
• The expert solve and the compute ledger above, from the post's figures.
• Read the Tinker price list.

What I could not do: run the model. There are no weights, and sampling it needs a Tinker key, which I did not use for this page. Every benchmark, the bits-per-byte chart, the alignment table and the fine-tuning curve are the lab's. The post promises a follow-up on the NVFP4 recipe; it is not out.

What to take from it

The checkable parts hold together. The token counts, the RL FLOP total and the GPU-days agree with each other, the expert grid matches the stated parameter counts, and the price list says what the tweets said it says. The parts that matter most to a user (benchmarks, fine-tunability, the pre-training quality chart) are all reported, and the weights that would let anyone check them are, by the lab's own schedule, a week away.

If they land under Apache 2.0, the first things worth doing are the boring ones: count the parameters in the safetensors (Inkling-Small's stated total ran 3.8% above what its weights hold), read the attention layout out of the config, and run Terminal Bench v4.0 to see whether 13.1% is the model or the harness.