Microsoft AI's lab notes on MAI-Base-2 lead with scale: a mixture-of-experts base model with 80 billion active and 2.8 trillion total parameters, pre-trained on 16,000 GB200 GPUs over 38 days in August and September 2026. The number worth reading twice is smaller. The run averaged 21% model FLOPs utilisation (MFU) and 89% goodput, the fraction of wall-clock time in which training actually progressed. Frontier pre-training posts usually publish neither. A utilisation figure without its denominator is a mood; with the denominator attached it becomes something an outside team can argue with.
The 21% is normalised against 2.5 PFLOPS, GB200's theoretical BF16 peak, and it excludes FLOPs for rematerialisation and for the optimizer. Both exclusions cut the same way: the numerator counts model FLOPs while the hardware is also doing recomputation and Newton–Schulz iterations. The post is explicit about this, which is better than most, but the size of the omitted work is not stated. Until it is, 21% is a ceiling on hardware utilisation rather than a measurement of it, and comparing it with a lab that counts recomputation in its numerator would be comparing two different quantities.
The goodput figure interacts with it multiplicatively. Eighty-nine per cent of 38 days is roughly 33.8 days of actual progress. That reads as a rounding error until it is priced across a fleet: 11% of 16,000 GPUs over 38 days is about 67,000 GPU-days of non-progress if the loss were spread evenly, which it never is, since real interruptions cluster into restarts. Publishing goodput at all is the unusual part. It separates two things benchmark tables routinely conflate, namely how good the recipe is and whether the cluster stayed up, and it is the reason the MFU number can be interpreted as an algorithmic result rather than a statement about a machine that happened to keep running.
The efficiency claim is the one that travels: 4.2–12.3x more pre-training FLOPs-efficient than DeepSeek-V4-Pro-Base, shortened to 4–12x in the opening. The method is to fit, for each of four held-out evaluations, an independent scaling law of bits-per-byte against training FLOPs, then estimate how much compute a model on Microsoft's ladder would need to match the reference's BPB, and divide. The post states plainly that MAI-Base-2's final performance is included in those fits, so the matching point falls inside the fitted range rather than beyond it. That removes the worst failure mode of this genre, extrapolating past the last data point. It does not make the estimate independent, because the fit is constrained by the very checkpoint being reported and every rung of the ladder shares one recipe, so any recipe-specific curvature in the loss curve is present both in the fit and in the answer.
The width of the interval is the more informative detail. Four independent fits yielding 4.2x to 12.3x means the number depends heavily on which evaluation is read. Reporting the range rather than a point estimate is the honest choice, but it also means the low end barely constrains anything: a 4x claim and a 12x claim are different statements, and the post does not say which evaluation produced which end of the range.
The reference point also needs care. DeepSeek-V4-Pro-Base is described as the only released base pre-training checkpoint above one trillion parameters, and as trained on significantly fewer FLOPs than MAI-Base-2. So the claim is that Microsoft's recipe reaches the reference model's loss at lower compute, which is the correct shape for a recipe claim. What it cannot separate is where the advantage comes from, since data pipelines, MoE and optimizer changes, and vision pre-training all moved at once. The 6.3–12.7x improvement over MAI-Base-1 has the same property.
The most transferable method in the post is not the efficiency number but a technique called source scaling.
Scaling ladders hold tokens per active parameter constant and vary size, with each rung defined by its layer count alone. The problem is repetition: a 50-trillion-token run may loop some sources eight times, and a five-trillion-token rung trained on the full mixture would see almost no repetition, which changes regularisation behaviour and lets small-scale experiments favour configurations that overfit at scale. Source scaling restricts the unique samples available at small rungs so that each dataset repeats the same number of times it would in the full run, holding the ratio of unique data to parameters fixed. The blind spot is symmetrical: at small rungs, matched repetition is bought with reduced diversity, so any interaction between data diversity and scale is invisible to a ladder built this way. The recipe's transfer is validated with one scale-dependent variable held artificially constant.
The engineering account is where the post earns its credibility, and it is specific. MoE in every layer had a consistent FLOPs advantage over alternating dense and MoE layers, but every-other-layer was wall-clock optimal for MAI-Base-1; two implementation problems, memory fragmentation from dynamic routing under extreme expert imbalance and per-expert overhead from finer-grained experts, held MoE layer MFU at 24%. Fixing them took it to 35% and made every-layer MoE the wall-clock choice. That is the paper's cleanest demonstration of why it tracks two efficiency metrics: the better architecture was already known to be better, and only the implementation made it affordable. Dropless routing is handled by giving each expert a fixed token capacity and processing overflow in additional rounds, borrowing unused capacity inside an expert group, with capacity sized so steady state needs one round; memory stays static under arbitrary imbalance, and tokens are never dropped because their experiments found dropping degraded quality. Muon needed the full weight matrix for Newton–Schulz orthogonalisation, which conflicts with sharding momentum across the data-parallel dimension, so the momentum is resharded during the optimizer step, cast to BF16, exchanged in shape-batched all-to-alls, orthogonalised locally and returned; after tuning, Muon accounted for 2.1% (165 ms) of mean iteration time against an estimated 55 ms floor, with the gap attributed to stragglers, kernel dispatch, load imbalance and resharding copies. Activation gradient clipping is the item most likely to be copied elsewhere: clipping activation gradients at selected points instead of the batch-global weight-gradient norm prevents one outlier example from scaling down an entire batch, its benefit grew with scale where most changes give a roughly constant gain, and it doubled as a data diagnostic when a clipped example traced back to a license header truncated mid-sentence in a code pull request, exposing a preprocessing bug.
What is absent matters for anyone trying to reuse the numbers. There is no absolute FLOP count, no sequence length, no batch size, no tokens-per-second throughput, no per-evaluation BPB deltas in text, and no post-training results. The open-weight comparisons also mix base and post-trained checkpoints, which the post flags for Kimi K3, Qwen3.8-2.4T-A95B and MiMo-V2.6-Pro-RL. Without absolute FLOPs or throughput, 21% MFU cannot be converted into cost per token, and 89% goodput cannot be converted into calendar time per unit of progress.
The contribution worth taking from this release is the denominator. Utilisation, goodput and an explicit statement of what the fit contains are three disclosures that most frontier announcements omit, and together they make the efficiency claim falsifiable in principle. Turning it into effective cost per trained token at a stated quality still needs the absolute compute figure and the throughput that 21% implies. Those are the next two numbers to ask for.