Research
When Does Muon Actually Win? A Paired Data-, Time-, and Tuning-Budget Benchmark
Overview Research area: Machine learning optimization and training-efficiency benchmarking, specifically comparing the Muon optimizer with AdamW. Technical level: Intermediate. Readers should be comfo

- arXiv
- 2610.21555
- Published
- 2026-10-15
- Authors
- Mushir Akhtar, Hazem N. Nounou, Majdi Mansouri, Mohamed N. Nounou
AI summary
Overview
Research area: Machine learning optimization and training-efficiency benchmarking, specifically comparing the Muon optimizer with AdamW.
Technical level: Intermediate. Readers should be comfortable with optimizers, validation loss, hyperparameter tuning, and training budgets.
Scope: The paper benchmarks a reference single-device Muon implementation against AdamW under matched data, time, and tuning budgets on small causal language models and vision transformers.
What This Paper Is About
Muon has been promoted for its data efficiency, but it is unclear whether that advantage holds when data, wall-clock time, and tuning effort are explicitly controlled. The paper asks when Muon actually wins by comparing it with AdamW under a common evaluation protocol rather than relying on raw loss alone. It separates data efficiency from time-normalized performance and tuning-budget sensitivity.
Key Contributions
- A paired benchmark of Muon versus AdamW across 17.7M- and 33.6M-parameter causal language models and 2.70M-parameter vision transformers on a single A100 GPU.
- A common development protocol using a 23-candidate budget, five matched seeds, full validation trajectories, optimizer-step timing, and a frozen one-shot test.
- An evaluation of three budget dimensions together: equal-data performance, time-normalized performance, and expected regret under restricted tuning access.
- A characterization of where Muon’s advantages appear and where AdamW remains stronger, with explicit caveats about model size and reference kernels.
Main Findings
- Equal-data validation efficiency: Muon reduces validation-loss area under the curve by 3.25–22.44% at equal data.
- Test-loss consistency: Muon lowers test loss in all 20 primary pairs.
- Time-normalized trade-off: On vision tasks, Muon improves time-normalized loss area by 19.68–22.31%; on language tasks, AdamW is better by 3.38–6.96%.
- Optimizer overhead: The full Muon optimizer call, including auxiliary AdamW updates, consumes 56.1–69.6% of training time, compared with 6.1–9.1% for the AdamW baseline.
- Tuning-budget sensitivity: Muon has higher expected regret when access to the candidate pools is restricted.
- Scope limitation: The results characterize small models with reference kernels; the wall-clock ordering does not establish a ranking for larger models or optimized implementations.
Methodology in Plain English
The researchers trained small causal language models and vision transformers on a single A100 GPU and compared a reference Muon implementation with AdamW. They used the same 23-candidate development budget to select configurations, then evaluated the selected configurations with five matched seeds, full validation-loss trajectories, optimizer-step timing, and a frozen one-shot test. This paired setup lets them compare equal-data behavior, time-normalized behavior, and sensitivity to tuning restrictions. The abstract does not provide details about the datasets, candidate pools, or exact training schedules.
Why This Matters
The paper matters because optimizer claims can change depending on whether one controls for data, wall-clock time, and tuning effort. Its results suggest that Muon’s equal-data gains do not automatically translate into wall-clock wins, especially on language tasks and with the reference implementation tested.
Real-world applications:
- Selecting optimizers for small language-model or vision-model training under compute constraints.
- Planning training pipelines where optimizer overhead affects throughput and cost.
- Designing hyperparameter-tuning budgets when only a limited candidate pool can be explored.
- Building reproducible optimizer benchmarks that separate algorithmic gains from implementation overhead.
Industry relevance: Training time and tuning cost are major operational expenses. The paper’s distinction between data efficiency, time-normalized performance, and tuning regret is directly relevant to teams deciding whether an optimizer is worth deploying in practice.
Future Directions
- Test whether the observed ordering holds for larger models and longer training runs.
- Compare optimized Muon kernels against optimized AdamW implementations to isolate algorithmic gains from implementation overhead.
- Extend the budget-aware benchmark to more architectures, modalities, and datasets.
- Study how candidate-pool design and restricted tuning access affect optimizer regret and selection.
Target Audience
Machine learning researchers studying optimizer design, practitioners choosing between Muon and AdamW, benchmark methodologists, and engineers responsible for training efficiency and hyperparameter-tuning budgets.
Authors’ abstract
Muon's gains in data efficiency motivate evaluating its performance under explicit data, time, and tuning budgets. On a single A100 GPU, we compare a reference single-device Muon implementation with AdamW across 17.7M- and 33.6M-parameter causal language models and 2.70M-parameter vision transformers. A common 23-candidate development budget selects configurations evaluated with five matched seeds, full validation trajectories, optimizer-step timing, and a frozen one-shot test. Muon reduces validation-loss area under the curve by 3.25--22.44\% at equal data and lowers test loss in all 20 primary pairs. In this configuration, Muon improves time-normalized loss area} by 19.68--22.31\% on vision, while AdamW is better by 3.38--6.96\% on language. The full Muon optimizer call, including auxiliary AdamW updates, consumes 56.1--69.6\% of training time, compared with 6.1--9.1\% for the AdamW baseline. Muon also has higher expected regret under restricted access to these candidate pools. These results characterize small models with reference kernels; their wall-clock ordering does not establish a ranking for larger models or optimized implementations.