Meta Published the Waste Ledger — Two of Four Levers Port to You
The interesting disclosure is not the utilization number but the ranking of where the FLOPs went missing, and exactly one item on that list is free of a quality argument.
The detail worth internalizing even if you never run several thousand GPUs
Meta shards two parameter populations under two different regimes: 2D FSDP plus Expert Parallelism for dense parameters, and Fully Sharded 2D Model Parallelism for trillions of sparse embedding parameters. Both are mapped topology-aware onto a multi-tiered fabric with SM-free collectives. The transferable finding is narrower than the architecture diagram suggests: one uniform parallelism strategy across a model with a huge embedding table and a modest dense trunk leaves throughput on the floor. At this scale the jobs are comms-bound, not FLOPs-bound, and adding GPUs to a comms-bound job buys more all-reduce, not more steps per second.
Portability, ranked
| Lever | Reported gain | Ports to a normal stack? | Quality risk |
|---|---|---|---|
| Jagged Flash Attention | Removes up to 50% padding waste | High — varlen/nested-tensor kernels are widely available | None. Skipping arithmetic on zeros is exact. |
| BlockAttention | O(L²) → O(L) | Medium — custom kernel or linear-attention substitute | Real; no full-attention control reported |
| MXFP8 in attention + MLP | Speed gain, no CTR/CVR regression claimed | Medium — needs FP8 hardware and paired runs | Medium; zero ablation, no per-slice breakdown |
| Topology-aware 5D parallelism | Enabled the 4x FLOPs scaling | Low — assumes Meta's fabric | Low risk, high reproduction cost |
Where the disclosure thins
No baseline MFU is stated. The ~10–12% prior is an inference from "2x to 20–25%", not a number Meta published. The 4x FLOPs scaling is entangled with the efficiency work, so any model-quality improvement cannot be attributed between more compute and better utilization. Correlated, plausibly causal, not established. And "no CTR/CVR regression" from MXFP8 arrives with no confidence intervals and no slice-level breakdown. The thing that claim doesn't tell you is where the errors went, because low precision fails first on rare slices and on probability calibration, and neither shows up in an aggregate conversion rate.
Meta stated on the record that the honest ceiling for sparse recommenders is low. That is negotiating leverage in your next hardware request, not an excuse.
What to do with it
The cheapest measurement available is the padding ratio. Take one real batch from the highest-cost sequence model in production and compute sum(true_seq_lens) / (batch_size × max_len). Under 0.6 means up to half the attention FLOPs are multiplying zeros. The fix is a varlen kernel, with no quality conversation attached, which is rare enough in this field to be worth doing first. MFU belongs on the training dashboard next to loss and AUC, because without a baseline there is no arguing for or against more GPUs.
Before any linear-attention migration, run a truncation-depth ablation on user-history length: sweep 64 / 256 / 1024 with full attention and plot the AUC curve. BlockAttention's value is entirely conditional on longer history carrying signal in your domain, which is a research-leaderboard property, not a production one. If the curve flattens at 256, O(L) attention buys approximation risk and nothing else. For MXFP8, gate on paired runs with identical seeds and data order, scoring log-loss and expected calibration error across at least five traffic slices including the lowest-volume decile.
What to do
Compute the padding ratio on one real batch from your two highest-cost sequence models this week, and swap in a varlen/nested-tensor attention kernel wherever it falls below 0.6.
Add MFU and sequence-padding ratio to the training dashboard alongside loss and AUC for every ranking model by end of month.
Run a 64/256/1024 truncation-depth ablation on user-history length before funding any linear-attention or BlockAttention port this quarter.