SkyRL Moved Mistral Large 4's AIME Score Eleven Points on Eight Nodes: What Day-0 RL on a 1T MoE Proves

Mistral Large 4 was announced as an API preview on 6 October 2026, and its weights only became downloadable at 14:51 UTC on 29 October — which makes the reinforcement-learning report published the same day notable for a reason its authors do not dwell on: before that afternoon, nobody outside Mistral had a fine-tuning result to publish. The note comes from the SkyRL team at NovaSky. Eight NVIDIA GB200 nodes, LoRA reinforcement learning on the NVFP4 checkpoint, vLLM serving the rollouts, and AIME 2024 average@8 climbing from about 64% to about 75% across 75 training steps. Eleven points on a benchmark usually settled in tenths is either the most useful day-zero result of the quarter or the least reproducible one, and the note as written does not tell you which.

What it does tell you is real, and it is worth separating from what it does not. The hardware is named. The checkpoint is named. The rollout engine is named. The training framework is named as one of two. What is missing is the reward function, the adapter rank, the evaluation harness and any learning curve — the four things another team would need to attempt the same run. So this is a recipe announcement with a headline number attached, not a reproduction package. Read it as the former and it is genuinely informative about what a trillion-parameter mixture of experts costs to post-train in late 2026. Read it as the latter and you will overrate one benchmark on one task.

What the SkyRL note actually says

The whole claim fits in five lines, so here it is without the framing:

• Hardware — 8 NVIDIA GB200 nodes, rented rather than owned, which at four GPUs per node is 32 Blackwell parts and roughly 6.1 TB of aggregate HBM at 192 GB per GPU.

• Checkpoint — the NVFP4 quantised sibling of the open release, 610.1 GB across 32 shards, not the 1,060.6 GB FP8 parent. That choice is the load-bearing one: it is what makes a 1T model fit on eight nodes with room left for activations, KV cache and two copies of the rollout engine's weights.

• Method — LoRA rather than full-parameter RL. Only the adapters receive gradients, so the optimizer state stays small and the frozen base can sit in its quantised form.

• Loop — vLLM generates the rollouts; FSDP2 or Megatron handles the training half. The note offers either, which tells you the training backend was still being swapped when the result was written up.

• Result — AIME 2024 average@8 from roughly 64% to roughly 75% in 75 training steps.

Nothing in that list is a specification of the run. There is no batch size, no sequence length, no learning rate, no group size for the policy gradient, no statement of what the reward was beyond the implicit "AIME answers are checkable". The 75-step figure is precise; almost everything needed to interpret it is not.

Why the node count is the headline, not the AIME score

A trillion parameters is a number that mostly functions as a deterrent. The FP8 checkpoint is 1.06 TB, which is fine if you have a datacentre and a problem if you have a rack. The NVFP4 checkpoint halves that to 610 GB, and 610 GB is a quantity you can distribute across eight nodes without sharding tricks that cost you more in communication than they save in memory.

That is why the interesting sentence in the note is not the one with the percentage in it. Hugging Face had already published a supervised fine-tuning recipe for this model — LoRA through TRL's SFT trainer, on a single node of eight B300 GPUs, on top of the FP8 weights. SFT on one node was therefore documented before the weights were a day old. What was not documented was reinforcement learning, and the reason is structural: RL needs an inference engine running alongside the trainer, generating rollouts fast enough that the GPU time spent training is not dwarfed by the GPU time spent sampling. SFT reads a fixed dataset. RL has to produce its own.

So the delta between the two published recipes is not eight nodes versus one. It is eight nodes plus a serving stack versus one node with no serving stack, for a task where the model has to attempt thirty problems eight times each before it learns anything. The rollout engine is the new cost centre, and naming vLLM as the generator is the part of the note that other teams can act on today.

The comparison everyone will make, and why it is unfair in both directions

Mistral ran its own RL on this model before shipping the weights, and the company has been specific about the shape of it: roughly three additional weeks after the 6 October preview, run on French compute the company describes in megawatts rather than GPUs — around 10 MW — with reporting elsewhere putting the wider RL infrastructure at the 3,000-GPU scale. The results it published from that run:

• Terminal-Bench 4.0 — 28.3% before the extra RL, 41% after.

• BrowseComp — 75% before, 84.5% after.

• B3 agent-security suite — 93.3% before, 97.1% after.

• Output length — about 30% fewer tokens per task after the RL, which matters more to a buyer than any of the accuracy rows.

Set that beside 64 to 75 on AIME and the temptation is to compute a ratio of GPU-hours per point. Resist it, because the two runs share almost no variables. Mistral's gain is on agentic terminal work and browsing, measured by a vendor with the reward design in-house and three weeks of wall clock. SkyRL's gain is on competition mathematics, measured by a partner with a rented cluster and a reward that a script can verify. A 13-point move on Terminal-Bench and an 11-point move on AIME are not the same achievement expressed in different units; they are different achievements that happen to be similar in size.

The fair reading is narrower and more useful: three weeks of RL at datacentre scale moved Mistral's terminal score by thirteen points, and a few hours of LoRA RL at eight-node scale moved a partner's maths score by eleven. Both numbers say the same thing — this checkpoint responds to reinforcement learning readily — and neither says anything about the other.

What 64 to 75 on AIME 2024 does and does not prove

Start with the arithmetic, because it is the one part of this that can be checked without a GPU. AIME 2024 is thirty problems. Average@8 means eight sampled attempts per problem, so the reported figure rests on 240 completions. The sampling error on a proportion near 70% at that sample size is a few percentage points, which puts an eleven-point move comfortably outside noise. If the two figures came from the same harness, the improvement is real on that task.

That is the strongest thing that can be said, and it is worth saying clearly because most day-zero claims are not even this good. Now the limits:

• There is no Mistral-published AIME score for this model. The 64% baseline is SkyRL's own measurement of the base checkpoint on its own harness, so the delta is internally consistent but externally unanchored — you cannot check it against a vendor figure because no vendor figure exists.

• Average@8 is not pass@1. Eight attempts per problem flatters any model with a wide sampling distribution, and the gap between the two metrics is routinely five to fifteen points on competition maths. The number that decides whether you would deploy the model is the one attempt you give it in production.

• AIME 2024 is two and a half years old and among the most heavily represented maths sets in post-training data. A 2026 model scoring well on it is evidence of a trainable checkpoint, not a verdict on reasoning. Nothing in the note reports a held-out or newer evaluation.

• One task, one run, one reward. RL on verifiable maths is the easiest case there is: the reward needs no judge, no rubric and no human. The result is a statement about how far this model moves under the cheapest possible RL signal, which is genuinely the right first experiment and also the least transferable one.

What you would need to reproduce it, and what the licence allows

The practical shopping list, reconstructed from the note rather than published by it:

• The NVFP4 checkpoint — 610 GB, 32 shards, ungated, downloadable today without a Hugging Face account gate.

• Roughly 32 Blackwell-class GPUs across eight nodes, plus the interconnect to keep the adapter synchronisation from eating the step time.

• A vLLM build with a working NVFP4 path for this architecture. The model card recommends vLLM with an official container and a tensor-parallel size of eight, and notes an embedded speculative-decoding head the vendor claims is worth up to 1.9× throughput — that head is not what an RL loop needs, but the container is.

• An adapter rank and a reward you will have to choose yourself, because the note does not say.

The licence question resolves more cleanly than the technical one. Mistral released this under the Mistral Ecosystem Open-Weight License, a modified MIT text that permits commercial use, fine-tuning and derivatives, and requires a separate commercial licence only for operating a model-as-a-service business on top of it. Internal fine-tuning, a private adapter, an evaluation run on rented nodes — all of that sits inside the grant. Standing up a per-token API and selling access to your fine-tune does not. If your plan is the first, the licence is not your problem. If it is the second, it is the whole problem, and no amount of AIME improvement changes it.

The half of the loop that gets expensive later

AIME is the cheap case for a reason worth spelling out. The reward is an answer string that a script compares. There is no judge, no rubric, no second model in the loop, so the marginal cost of a rollout is inference and nothing else. Move the same recipe to agentic tasks, open-ended writing, or anything graded by preference, and the reward becomes a model call — issued at rollout scale, thousands of times per step, for the entire run. That is a different procurement problem from training compute, and it is the one most teams discover after they have booked the GPUs.

Mistral Large 4 itself is not a model we serve, so this piece is not a route to it — self-hosting it means the Hugging Face repository and the vendor's own API. What is routable is the other half of the loop. If your verifier is a judge model rather than a script, it has to survive being called at rollout volume: one endpoint over 200+ models, provider list price passed through with no markup on top, and failover when a single judge endpoint rate-limits in the middle of a training step. The models you would actually use as judges are listed, with context and price, in the OrcaRouter model catalogue. The point is not that routing makes RL cheap. It is that the reward signal is the part of an RL run you cannot schedule around, so it is the part worth putting behind a stable interface.

What to watch next

Three things would turn this from a promising note into a result. The SkyRL team publishing the adapter rank, the reward definition and a learning curve, which would let another group attempt the same run rather than admire it. A second task, ideally one whose reward is not a string comparison, which would show whether the effect survives contact with a judge. And an independent AIME or harder-maths evaluation of the released checkpoint, because the 64% floor is currently the partner's own measurement and the only way to retire that caveat is for someone else to measure it.

Until then, the honest summary is short. The weights are one day old, a partner moved a maths benchmark eleven points on eight rented nodes with a LoRA adapter, and nobody has yet reproduced it. That is more than most open-weight releases offer in their first week, and less than the headline implies.