Limite 1B - Violetto: the throughput claim is in config.json, not the blog

Paradigma released Limite 1B - Violetto yesterday, and it comes with two different taglines. The GitHub README says "A model for high-frequency mathematical intelligence." The release blog says "high-throughput solutions of difficult mathematical problems" and, in its meta description, "high-throughput mathematical reasoning."

Neither page contains a tokens-per-second number, a latency figure, a batch size, a hardware target, or the word "milliseconds". I grepped both. The serving instructions are a vLLM plugin that requires tensor_parallel_size=1, and that is the whole of the deployment story.

So the interesting question is not whether the claim is true. It is whether the claim is attached to anything. It is — just not in the prose. config.json is unusually explicit for a model that had no technical report when I first wrote this, and one field in it does all the throughput work.

The stack, from the config

1,035,253,888 parameters, bf16, 2.07 GB on disk. 48 blocks, hidden 1280, intermediate 3328, 10 query heads over 2 KV heads at head_dim 128, Qwen's tokenizer (bos 151643, vocab padded to 151,680), tie_word_embeddings: true. Nothing surprising so far.

Then the rest of the file, which reads like a NanoGPT speedrun changelog rather than a model card:

{
  "global_every": 4,
  "global_layers": [3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47],
  "global_nope": true,
  "sliding_window": 1024,
  "sliding_window_convention": "k >= q - sliding_window, inclusive of the query token",
  "ve_layers": [1, 4, 7, 10, 13, 16, 19, 22, 25, 28, 31, 34, 37, 40, 43, 46],
  "ve_dim": 128,
  "mudd": true, "mudd_layers": [24, 47], "mudd_taps": 3,
  "mudd_tap_idx": { "24": [0, 12, 24], "47": [0, 23, 47] },
  "attn_gate_applied": "per_head_before_o_proj",
  "qk_norm": "rms_pre_rope",
  "rms_norm_has_weight": false,
  "attention_softmax_scale": 0.1,
  "rope_base_global": 1024.0,
  "rope_frac": 0.5,
  "softcap_logits": { "kind": "sigmoid", "a": 23.0, "b": 5.0, "c": 7.5 }
}

Four of these are worth stopping on, because the blog's one sentence about architecture — "strongly inspired by recent advancements made by the community on pre-training speedrun competitions" — is the only explanation on offer, and the fields say more than the sentence.

Value embeddings. model.value_embeds.weight is a second embedding table, 151,680 × 256, 38.8M parameters, injected at 16 of the 48 blocks. ve_stored_heads: 2 and ve_head_slice: "first_num_key_value_heads" mean it feeds the V path of the two KV heads directly from the token id, before QK-norm. This is the speedrun's U-net value-embedding trick, and it is 3.8% of the model spent on a lookup table that skips the residual stream entirely. (The report adds the part the config hid: a per-token, per-head gate decides how much of the lookup to mix in, read off just the first 12 channels of the residual stream.)

MuDD. Multi-way dynamic dense connections, at exactly two sites: block 24 taps the outputs of blocks 0, 12 and 24, and block 47 taps 0, 23 and 47. The parameters are trivial — mudd.dense1 is [32, 1280], dense2 is [48, 3, 32] — so this is a routing structure, not a capacity addition. Two deliberate long-range shortcuts at the half-way point and the exit.

Norms with no weight. rms_norm_has_weight: false throughout. Every RMSNorm is a pure normalisation with no learnable gain. That is a speedrun-derived simplification and it removes a hundred-odd thousand parameters, which is not the point; the point is that it removes a family of scale degrees of freedom that usually have to be tuned. The report shows they did not vanish entirely: each block scales its residual and its branch output with learned per-layer scalars, so the gain moved from inside the norm to the residual add.

A pinned softmax scale. attention_softmax_scale: 0.1, not 1/sqrt(128) = 0.0884. Combined with rope_base_global: 1024.0 — three to four orders of magnitude below the 10⁶–10⁷ that a 131K-context model normally uses — and rope_frac: 0.5, so only half the head dimension is rotated at all, with the 12 global blocks using no positional encoding whatsoever. The positional scheme here is: local blocks get short-range RoPE on half their channels, global blocks get nothing and rely on the causal mask. It is the NoPE-plus-local-RoPE arrangement, committed to harder than most.

None of these four costs anything at inference. The fifth field does.

The only derivable throughput claim

36 of 48 blocks attend over 1,025 keys regardless of how long the sequence is. Only 12 grow.

The arithmetic is four numbers from config.json and nothing else. KV bytes per token per block = 2 (K and V) × num_key_value_heads (2) × head_dim (128) × 2 bytes = 1024 B. A global block at 131,072 tokens holds 134 MB; a windowed block stops at 1.05 MB. So the full 131K cache is 12 × 134 MB + 36 × 1.05 MB = 1.65 GB, against 6.44 GB if all 48 blocks were global. A factor of 3.91.

That is the mechanism behind "high-throughput", and it is worth saying plainly what kind of claim it is. It is not a speed claim — a windowed block and a global block cost roughly the same per token at short context. It is a concurrency claim: on one 80 GB accelerator with the 2.07 GB checkpoint resident and 4 GB set aside for activations and runtime, the 73.9 GB left over holds 44 simultaneous 131K-token sequences instead of 11. For a workload that is thousands of independent competition problems run in parallel, which is exactly what a maths model is for, that is the whole game.

It is also the ceiling, not a measurement. Nobody has published a real one.

The maths, and the one column that behaves differently

The headline is 94.01% on AIME 2026 at an estimated 1.71 × 10²¹ training FLOPs.

expand

The 6ND estimate is checkable. 6 × 1.035e9 × 275e9 = 1.71e21, so the x position implies about 275 billion training tokens — consistent with the blog's "less than 300B highly curated tokens", and a genuine 1–3 orders of magnitude below the models on the same dashed line. Sample efficiency is the real result here.

But read the axis footnote: "RL excluded; counted training stages vary by model." The blog credits its competition-level maths to "a mix of synthetic data generation, curated SFT and RL post-training", and the compute axis excludes the last of those for everyone.

When I first wrote this I called it a pre-training-efficiency chart wearing a capability headline. The report shows that was wrong: Limite's point counts pre-training, the distillation stage and the SFT stages, and leaves out only RL, which by my estimate is about 5% of the total. The footnote is fine as far as it goes. What it does not mention, the model Limite was distilled from, is the bigger gap, and the re-audit below goes through it.

expand

Rank Limite in its own table, column by column:

Six of the seven columns are competition-format short-answer maths — AIME, HMMT, BeyondAIME, an olympiad shortlist — and Limite is first, third, third, fourth, fifth and sixth on them, against models up to 730 times its size. That is a real result and the BeyondAIME number in particular (74.25 against MUSE-Glimmer-30B's 70.00, which the blog names) is not a rounding artefact.

The seventh column is ArXivMath May 2026, and Limite is 7th of 12 at 25.08 — behind VibeThinker-3B (29.77), Qwen3.5-9B (31.64), Gemma-4-31B-IT (35.78) and a long way behind GLM 5.2 (56.67). It is also behind Qwen3.5-4B (26.33), a model it beats by four points on AIME 2026.

That inversion is the most informative thing in the table. On every benchmark whose format is "produce a boxed integer", the 1B is top-six. On the one benchmark whose format is not, the ordering reverts to something much closer to parameter count. Paradigma does not hide this — the column is right there in their own table, and the blog is unusually frank about the model's limits elsewhere, printing four worked examples of Violetto reinterpreting "What is photosynthesis?" as a cell-division recurrence and "What causes the seasons?" as a calendar arithmetic problem. A model described as "as lightly instruction-tuned as possible, to challenge the assumption that models need to be embedded in an assistant persona" is going to do that, and saying so with receipts is the right call.

It does mean the honest summary is narrower than "mathematical intelligence." This is a competition-problem solver. MiniCPM5-2B appears in the same table two rows down, and the comparison holds up: 90.21 to Limite's 94.01 on AIME 2026, at twice the parameters — but 21.80 to Limite's 25.08 on ArXivMath, a much smaller gap.

What is actually released

Four repositories under paradigma-inc: limite-1b-violetto (the RL'd model), limite-1b-base, limite-1b-base-soup and limite-1b-value-model — the training-time value model, which is an unusual and useful thing to release. The serving code is Apache-2.0, as are all four model repos: at launch the two base checkpoints carried no licence tag on the Hub, and on 7 October both show license:apache-2.0. The base and Violetto configs are byte-identical apart from the weights, so the post-training changed no architecture.

At launch the technical report was "to be released soon", and the RL recipe and the eval harness were missing with it. The report has since filled in the recipe, and the eval harness now ships as limite-evals/ in the GitHub repo. Two things are still missing: the training data, and any performance measurement at all. For a model whose name is "high-frequency", the last omission is the one to fix first, and it is an afternoon's work: vllm bench serve against the plugin at a few concurrencies, on a named card, with the prompt distribution the model is for.

The report, two weeks later

Paradigma published the technical report on 6 October: 37 pages, eight authors, a PDF and a thread summarising it. I read it looking for three things. Does it confirm what I inferred from the config? What does the recipe look like once it is written down? And does the headline chart hold up now that every stage is on the table?

Mostly yes, a lot, and less well than I expected, for a reason the chart's footnote never mentions.

What the config got right, and what it could not see

expand

The layer pattern, the window, the positional scheme and the MUDD taps are exactly what the config said: three local blocks then one global, window 1,024, partial RoPE on 64 of the 128 head dimensions at base 1024, NoPE on the global blocks, mixing sites at 24 and 47 that read the embedding, a mid-stack state and the current input. The report states the motive I had to infer: "This hybrid pattern reduces KV-cache requirements while retaining regular access to the full context." So the 3.91× arithmetic above is the design intent, not a side effect.

Two things the config named but I did not explain. attn_gate_applied: per_head_before_o_proj is gated attention: each head's output is multiplied by a sigmoid gate computed from the first 128 channels of the normalised residual. And before that gate sits Exclusive Self-Attention, which subtracts a learned fraction of each head's output along the direction of its own value vector. My reading of why: a token attending heavily to itself mostly copies its own value back, which the residual stream already carries, so removing that component pushes the head to bring in something else. Every one of these extras reads a slice of the residual (12 channels for the value-embedding gate, 128 for the output gate) rather than all 1,280, and the report says why: additions are kept "sparse in depth, width, or both" so training throughput stays close to a plain Transformer.

The MUDD mixer is the one piece Paradigma clearly adapted rather than lifted. The original MUDDFormer mixes every earlier layer into every layer. Here a small MLP with a shared 32-wide first layer produces three weights per token, for two mixtures (the attention input and the residual), at just two sites, initialised so the mixer is the identity, and the report gives the trade it bought: "This sparse formulation increases step time by only 2.3% while retaining most of the gain observed with the full MUDD formulation", and it "performed comparably" to Hyper-Connections and Attention Residuals at their scale. No ablation table backs either sentence, so that is a claim, but it is the right kind of claim for a speedrun-flavoured design: a measured cost against a stated benefit.

Two facts change how I read the rest. The model is deliberately deep for its size, 48 layers at width 1,280, on the hypothesis that hard maths "benefits from a larger number of sequential operations." And pre-training ran at a context of only 8,192 tokens; 131K arrived during post-training. That makes the positional choices look less like taste and more like a plan. A local block's RoPE never sees a distance past 1,024, so nothing about it changes when the sequence gets longer, and a NoPE global block has no frequencies to stretch. A model built this way can be extended from 8K to 131K without touching its positional encoding, which is what they did. The pinned 0.1 softmax scale is the one config field the report never mentions.

Then there is a sentence in the RL section that supports my reading of "high-throughput" better than anything in the blog: "the 48-layer architecture also gives a relatively high per-token latency despite its small parameter count." The conclusion repeats it: the deep architecture "can limit decoding speed and the model has not been fully optimized for inference." Depth costs latency, the window buys concurrency, and "high-throughput" means many problems at once, not any one of them quickly. There is still no throughput number anywhere in the report.

Pre-training: a speedrun optimiser at full length

The pre-training run is small and fast. 6 nodes of 8×H100, about 449k steps at a batch of 524k tokens, which multiplies out to 235B tokens; the report says 236B in one place and 237B in the abstract. Using the same 6ND rule as the chart, that is about 1.47 × 10²¹ FLOPs. At an assumed 40% of the H100's dense bf16 peak, 48 GPUs get through that in under a day. The thread says the whole project, "from the very first experiments", took six weeks, so the final run was a small slice of the effort.

The optimiser is straight from the speedrun lineage the site has covered in Muon: orthogonalizing the update for hidden layers and the nanoGPT speedrun frontier. NorMuon on every hidden matrix, which is Muon plus a per-neuron second-moment rescale after orthogonalisation; Polar Express coefficients in place of Newton–Schulz, five iterations; Nesterov momentum warmed from 0.85 to 0.95; and cautious weight decay, which only decays a weight where the update is already pushing it towards zero, at 1.2 times the squared learning rate. Everything else (embeddings, the value-embedding table, the scalars, gates, XSA coefficients, MUDD weights) goes to AdamW, which steps only every second iteration. Peak learning rate for the matrices is 0.018, and the schedule is warmup, a long flat phase and a linear decay over the last 20%. The report says the run "remained stable for approximately 450k training steps, with no major events such as large loss spikes."

The data is maths-first by construction: 46% problem–solution pairs, 19% synthetic textbook-style documents, 35% filtered web of which about 40% is synthetic rewrites. They filtered by sampling each source and asking an LLM to judge error rates, re-deriving reference answers for the Q&A part. The pool is 346B tokens, of which the run consumed 236B. Decontamination was lexical then semantic, against every benchmark in the report.

After pre-training they "souped" the base: three short continuations on a 6B-token high-quality mixture with different seeds and learning rates, averaged uniformly. On MATH-500 with a thinking prompt the soup scores 80.2 against 71.6 to 74.6 for the three runs it averages and 59.2 for the starting checkpoint. It is the first of four soups in the pipeline, which brings me to the figure people reacted to.

Post-training: distil, prefer, RL, patch, soup, repeat

expand

The reaction that went round, "I was not emotionally ready for this graph", was attached to this figure, not to the compute chart. I understand it. Nine boxes and three bowls is a lot of plumbing for a 1B model, and every bowl is a weight average that someone decided was better than either checkpoint going into it.

The first stage does most of the work. Distillation is teacher-forced and logit-level: for 5.5 million solutions written by VibeThinker-3B, about 26B target tokens, the student is trained against the teacher's top 32 log-probabilities at every position. The filtering is careful. A trace is kept only if it reaches the gold answer; traces where the teacher gives up are dropped by matching phrases like "given the time constraints" and "I'll just go with"; rejected traces go to a judge that sees the problem without the gold answer, which wins back tokens worth 18% of the corpus. The last five distillation checkpoints are averaged.

Then a short DPO pass, 140 updates of 128 pairs, on the maths subset of the OLMo team's preference data, where the chosen answer is from Qwen3-32B and the rejected one from Qwen3-0.6B. They average the log-ratio per token rather than summing it, so the preference signal does not reward longer or shorter answers for their length.

The RL is where Paradigma has opinions. They run DPPO with learning rates of 1 to 2 × 10⁻⁵, ten to twenty times the usual, and squeeze 7 to 19 optimiser updates out of every batch of rollouts. Instead of PPO's ratio clipping, DPPO masks a token only when its probability under the current policy has moved by more than 0.15 from the policy that generated it and the update would push it further. Groups where all eight rollouts pass, or all fail, are discarded because they carry no signal. Rollouts are collected as whole cohorts rather than streamed in as they finish, because streaming would favour short answers and easy problems. The report is candid that this regime is fragile: both of the first two runs climbed and then collapsed, and the shipped checkpoints are the ones picked before the fall.

expand

The first run is kept at update 213 of roughly 300; the second at 179, after its learning rate was doubled partway through because reward was rising too slowly. The report counts 461 actor updates across the three runs; the three kept checkpoints, 213, 179 and 59, add up to 451, so I assume the other ten were thrown away. Either way it is a few hundred updates where large runs take thousands. When reward stopped improving, they did not push RL harder. They ran two short SFT stages on synthetic problems aimed at the areas where the checkpoint was weakest, with solutions from Qwen3.8 models, and averaged each SFT result with the checkpoint before it so the new skills did not wash out what RL had taught. These stages also stretched the context from 65K to 131K. The final RL run starts from that soup and adds a critic.

expand

The critic argument is the most interesting few pages of the report. With a 0/1 reward on the final answer and no discounting, every token in a rollout gets the same group-relative advantage, so a 40,000-token solution that went wrong at one step is pushed down uniformly. A value model, initialised from the actor with a scalar head, can say where the expected reward dropped. They warm it for 501 updates with the actor frozen, then train it twice per actor step during RL 3. The GAE λ is set to 0.5 to the power 1/L, with L the rollout length, so the credit that reaches the first token is the same half whether the solution is 10,000 tokens or 100,000. It is a neat fix for a problem that only exists at these lengths. RL 3 improves the model "substantially within 59 actor updates", and the report attributes this to the critic together with the stronger SFT starting point, "rather than to the critic alone." There is no critic-off run to separate them, and Paradigma says so.

The RL problems come from two generators. An LLM writes a problem, a program that solves it and a claimed answer, and the problem is kept only if re-running the program reproduces the answer. A CPU-side procedural generator renders templated problem families with varied wording, tuned so brute-force enumeration does not work. Both are filtered to problems the current checkpoint solves about half the time, the band where a group of eight rollouts actually disagrees.

expand

Which stage bought what

The report gives a score for every benchmark after every stage, and an appendix gives the same checkpoints evaluated again at a single context length. Those two tables do not tell the same story, which is why the widget below shows both.

Table 5, the one in the body, evaluates the first four stages with a 61,440-token answer cap and the last two with 126,976. Read that way, RL 1 looks like the big step: +3.96 on AIME 2026, +13.03 on BeyondAIME. Appendix G re-runs the early checkpoints with the full 131K budget, and the picture moves. The DPO checkpoint, given room to finish, already scores 91.25 on AIME 2026, against 83.54 under the short cap. Its answers were the longest of any stage, 32,800 tokens on average, so the short cap was cutting it off. At the full budget RL 1 lowers AIME 2026 to 88.54 and RL 2 lowers it again to 86.98, while mean answer length falls from 32,800 to 18,376.

So the first two RL runs bought brevity. Brevity is worth having, because under the 61,440-token cap they trained with, shorter is more often finished, and the cheaper rollouts made the rest of the pipeline affordable. But from the DPO checkpoint at 131K to the final model, AIME 2026 rises 2.76 points. The large late gains on the hard columns (APEX Shortlist from 30.12 to 50.80, HMMT February 2026 from 72.16 to 83.62) come from the SFT-and-soup step and the critic run, with answer lengths growing back to 75,007 tokens on the APEX Shortlist. One caveat from the report itself: the 65K and 131K evaluations "used different concurrency settings," so small differences between the two tables are not all signal.

ArXivMath barely moves at all. From the DPO checkpoint at 131K (24.69) to the final model (25.08) it gains 0.39 points, while every competition column gains between 2.76 and 16.29. The release table had already shown Limite seventh of twelve there. The stage table shows that nothing in post-training after DPO touched it. Paradigma's own introduction concedes the model "may struggle with knowledge of the literature," and this is what that looks like in numbers.

The chart again, with the recipe in hand

Appendix F finally pins the compute axis down. For Limite, 6ND "counts pretraining, offline distillation and SFT, and excludes RL." That reconciles with what I backed out of the x-position earlier: 1.71 × 10²¹ over 6 × 1.035B parameters is about 275B tokens, and 236B of pre-training plus 26B of distillation targets leaves about 13B for the soup mixture and the two short SFTs. The report never prints the sum, but the pieces fit, and they fit the thread's "less than 300B training tokens (including post-training)."

How much does leaving RL out move the dot? The report gives enough to estimate it. Up to the checkpoints they kept, RL 1 generated about 21 cohorts of 704 problems × 8 rollouts, RL 2 about 20 cohorts at its 9 updates per cohort, and RL 3 about 15 cohorts of 256 × 8: roughly 260,000 rollouts. At about 25,000 tokens each for the first two runs and 45,000 for the third (Table 6's answer lengths at those stages) it comes to around 7B generated tokens. Generating, training on every one of them, and a generous allowance for the critic comes to under 10²⁰ FLOPs, about 5% of the plotted figure. Double it for long-context attention and it is still a tenth, which moves the dot 0.04 of a decade on a log axis. I raised this as a falsifier when the chart came out; the answer is that the RL exclusion is harmless.

The omission that is not harmless is the teacher. Distillation is where the base model's 16.88 on AIME 2026 (few-shot with a thinking prompt and an 8K answer budget, so not strictly comparable) becomes 81.67, and those 26B target tokens were written by VibeThinker-3B. Limite's x-position charges it for reading them, at 1B-parameter cost. It does not charge anything for the 3B model that had to exist to write them, and that model sits on the same chart at about 10²³ FLOPs, with a footnote saying only its "Coder training stage" was counted. In Table 7, VibeThinker-3B scores 93.85 on AIME 2026 and Limite 94.01, each with a standard error of about half a point. To its credit, the PDF version of the table bolds both, as its caption's overlap rule requires. On the chart, the student sits nearly two orders of magnitude to the left of its own teacher at the same height, and the picture reads as two independent ways of reaching 94%.

Other comparisons on the chart run the opposite way. VibeThinker-3B's point counts only one stage and MiniCPM5-2B's only its 1T-token mid-training, so both are under-counted; the Qwen3.5 points assume Qwen3's 36T tokens. Those choices flatter the competitors, not Limite. The scores are mixed-source too: Qwen3.5 and Nemotron 3 Super from MathArena, the two NVIDIA Nemotron models from NVIDIA, and Qwen3.5-4B's AIME 2026 is "IRT-estimated." Appendix F says "evaluation setups differ across these sources." None of that is hidden, but none of it is on the chart.

My verdict: the sample-efficiency result is real. Distillation is a legitimate technique, and the recipe after it plainly adds capability: Limite beats its teacher by 4.64 points on HMMT February 2026, 4.39 on the APEX Shortlist and 3.12 on HMMT 2025. A 1B reaching 94% on a 2026 competition is remarkable whatever it cost. But "one to three orders of magnitude below the models that match it" should read "below the models that match it, one of which taught it."

The eval suite they released

The thread says "we also release the entire eval suite," and it is a serious piece of work: a limite-evals/ package in the GitHub repo that pins every dataset revision and every reference model to a 40-character Hub commit, records template hashes and sampling settings in a manifest, and refuses to compare runs whose manifests disagree. Every completion is scored on a ladder: the official grader's exact rule, a strict boxed-answer rule, a lenient one and a permissive one, so a format change cannot pass itself off as a capability change. It is the eval tooling I would want from every release.

I read it for the three fairness questions that matter on this table. The first is token budgets. The default completion budget is the model's own native context minus a 4,096-token prompt reserve (cli.py, token_budget). VibeThinker-3B and MiniCPM5-2B both declare 131,072 in their Hub configs, the same as Limite, so they got the same 126,976-token ceiling; Qwen3.5-9B and Gemma-4-31B declare 262,144 and got more room, not less. Gemma, MUSE-Glimmer and Qwen3.6 are sampled at their own published temperature of 1.0; the rest at the harness default of 0.6, which is also Limite's. I found nothing in the budgets that tilts the table towards Limite.

The second is statistical resolution. Every score is pass@1 averaged over 32 samples, and Table 10's standard errors (0.54 for Limite on AIME 2026) measure sampling noise on a fixed problem set. They do not measure the fact that AIME 2026 is 30 problems: 94.01 versus 93.85 is a twentieth of one problem. Spread over a different 30 problems of the same difficulty, a 94% solver's score would move by about four points. Read the top of the AIME columns as a tie, which is what the bolding says.

The third is contamination. The report says pre-training data was decontaminated lexically and semantically against every benchmark, and the same procedure was applied to all post-training data. The corpus has a knowledge cutoff "around the final months of 2025," with "a small fraction" of web text into early 2026. The evaluator's own comment on HMMT February 2026 says it was held "after the training cutoff of every checkpoint currently under evaluation," which is true of the pre-training corpus. It is less obviously true of post-training: the distillation teacher was released in June 2026 and the SFT teachers in August, both after AIME 2026 and HMMT February 2026 were public. Their solutions went into Limite. Decontamination of the problems is the right defence, and I have no evidence of a leak, but a teacher that has seen a competition can distil its fluency on that competition's style even when the exact problems are filtered out. ArXivMath, the freshest set, is where Limite does worst, which fits a model whose strength is the competition format rather than leakage.

And one gap. The released suite, math-extended, contains AIME 2024, 2025 and 2026, MATH-500, GSM8K, HMMT February 2025 and 2026, OlympiadBench, BeyondAIME and the APEX Shortlist. ArXivMath is not in it. The report explains that MathArena's grader gave both false positives and false negatives on ArXivMath, so Paradigma scored it with Math-Verify instead, and that scorer is not what shipped. So the one headline column you cannot rerun with their tool is the one where Limite trails. That cuts against them rather than for them, since it is their weakest number, but "the entire eval suite" is six of the seven benchmarks. The suite also carries a caveat I liked: four of the APEX Shortlist's 47 problems are AIME 2025 and HMMT 2025 problems, and the code records that as a known double-count rather than trimming the set.

What I would still ask for

The report answers most of what I asked for in September. What it does not give is still what I asked for first: a serving measurement. The eval harness runs 320 concurrent requests per vLLM replica by default, and a comment in its launcher notes that "the scarce resource is KV cache, not parameter memory." It is the concurrency argument from the top of this article, written by the people who built the model. Put a tokens-per-second number next to it.

The other thing I would want is a critic-off run of RL 3. The value-model machinery is the most reusable idea in the report, the value checkpoint is released, and right now its contribution and the SFT soup's are counted together.

How I checked

The first version (22 September) read config.json and the safetensors header from the Hugging Face repo, grepped the rendered blog and the GitHub README for throughput terms, and transcribed the release table. The KV-cache figures are arithmetic on four config fields.

For the update I read the technical report PDF in full (37 pages, dated October 2026) and took its figures from the PDF itself, cropped and flattened onto white. I read the author thread and the quoted reaction through the fxtwitter mirror; the "graph" in that reaction is the report's post-training pipeline figure. I shallow-cloned paradigma-inc/limite-violetto at commit 7ddad34 and read the evaluator rather than running it: the suite list in suites.py, the token budget in cli.py, the reference-model pins and decoding defaults in reference_models.py, the concurrency default in runner.py and the launcher comment in serve.py. The native context lengths of VibeThinker-3B, MiniCPM5-2B, Qwen3.5-9B and Gemma-4-31B come from their Hub configs, and the base-checkpoint licence tags from the Hub API, both on 7 October.

Two numbers are my estimates rather than the report's. The RL compute assumes the cohort counts read off Figures 9 to 11 at the kept checkpoints and answer lengths taken from Table 6; it ignores rollouts generated after those checkpoints. The "under a day" for pre-training assumes 40% of the H100's dense bf16 peak, which the report does not state. I did not run the model, the evaluator or a serving benchmark.