Dion3: Full-Stack Orthogonal Updates
Abstract: The Muon optimizer incurs a significant overhead cost due to its cubic-time Newton-Schulz orthogonalization step. When weights are sharded, communication overhead compounds this computational cost, eroding the benefits of Muon in many settings. We present Dion3, a revision of Muon that targets this overhead at every level of the stack. Our Gram Newton-Schulz algorithm reduces the FLOP cost of orthogonalization, our CuteDSL kernels accelerate it by exploiting symmetry, and our megabatching strategy reduces communication overhead. Moreover, we propose a simple change to the update rule that cuts costs even further: selecting only a fraction of the momentum matrix's rows to orthogonalize at each step. This update rule improves on Dion (another "compressed" version of Muon), in both speed and performance. Overall, Dion3 matches or improves on the loss achieved by Muon but reduces optimizer step time by up to 6x. Dion3 is available via the dion package (https://github.com/microsoft/dion) as a drop-in replacement for Muon.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
Explain it Like I'm 14
1. What is this paper about?
This paper introduces Dion3, a new method for training LLMs more efficiently.
It improves an optimizer called Muon. An optimizer is like a coach for a machine-learning model: after the model makes a mistake, the optimizer helps adjust the model’s numbers so it performs better next time.
Muon can help models learn with fewer training steps than older methods such as AdamW. However, each Muon step is expensive, especially when:
- The model has very large weight matrices.
- The model is trained across many GPUs.
- The GPUs must communicate with one another.
The purpose of Dion3 is to keep Muon’s good learning behavior while making each training step much faster.
2. What questions does the research ask?
The paper mainly asks:
- How can Muon’s expensive matrix calculations be made faster?
- How can Muon work better when a model is split across many GPUs?
- Can only part of the information be processed at each step without harming learning?
- Can these improvements be combined into one practical optimizer?
The researchers want Dion3 to be useful for many different model sizes, computer systems, and ways of dividing work between GPUs.
3. How did the researchers approach the problem?
The researchers designed Dion3 as a combination of four improvements.
A faster way to orthogonalize matrices
Muon uses a process called orthogonalization. In simple terms, this reshapes the update to the model so that different directions are balanced instead of allowing a few directions to dominate.
Muon performs this using an iterative calculation called Newton–Schulz. An iterative calculation is like repeatedly adjusting an answer to make it more accurate. The problem is that the calculation can require a huge number of operations—especially for large matrices.
Dion3 introduces Gram Newton–Schulz. Instead of repeatedly working with the original large matrix, it first creates a smaller summary called a Gram matrix. This is similar to replacing a large, detailed map with a smaller map that preserves the important relationships between locations.
The new method:
- Creates a smaller matrix from the original one.
- Performs most of the calculations on this smaller matrix.
- Uses the result to produce the final update.
According to the paper, this gives the same mathematical result as standard Newton–Schulz, but with much less computation for many rectangular matrices.
Special GPU calculations
The smaller matrices used by Gram Newton–Schulz are symmetric. A symmetric matrix is the same when reflected across its diagonal, like a square pattern that looks identical in a mirror.
Because the top half is a copy of the bottom half, calculating both halves separately wastes time. The researchers created custom GPU programs using CuteDSL that:
- Calculate only one triangular half.
- Copy it to create the other half.
- Take better advantage of modern NVIDIA GPUs.
These programs are called kernels. A kernel is a small, specialized program that performs a particular calculation on a GPU.
Processing only some rows or columns
Dion3 also avoids processing the entire momentum matrix every time.
The momentum matrix stores information about recent gradients—roughly, the model’s recent history of which direction its parameters should move. Dion3 selects only some rows or columns of this matrix, usually the rows with the largest overall size.
For example, instead of processing all 100 rows, it might process only 25 or 12 rows at a time. The paper recommends selecting about one-quarter or one-eighth of the rows.
This is like editing only the most important pages of a book during each revision, rather than rereading the entire book every time.
Rows that are not selected are not simply forgotten. Dion3 uses error feedback, which keeps track of ignored information so that it can influence future updates. This gives neglected rows a chance to be selected later.
Reducing communication between GPUs
When a model is split across GPUs, the GPUs must exchange information. This communication can be slow, particularly when it happens in many small rounds.
Dion3 uses megabatching. Instead of sending many small groups of information one after another, it combines more work into larger groups. This is like sending one large delivery instead of making many small delivery trips.
The method also communicates only the selected rows or columns, reducing the total amount of information that must be moved between GPUs.
4. What did the researchers find?
The paper reports several important results.
Dion3 is much faster than Muon
The main result is that Dion3 can achieve similar or better training loss than Muon while making optimizer steps up to six times faster.
The paper’s example involves training a LLM with about 7 billion parameters on four GH200 GPUs. In that experiment:
- Muon’s optimizer step took about 26 times as long as AdamW’s.
- After adding the Dion3 improvements, the cost fell to about 4 times AdamW’s.
This does not necessarily mean the entire training process becomes six times faster, because the optimizer is only one part of training. The model still needs to perform forward and backward calculations. However, the optimizer’s large cost is greatly reduced.
Gram Newton–Schulz saves many calculations
For a typical rectangular matrix whose longer side is about four times the shorter side, the paper says Gram Newton–Schulz can save:
- About 55% of the operations compared with standard Newton–Schulz when symmetric calculations are already used.
- About 68% compared with a typical implementation that does not use symmetry.
The benefit is especially large when matrices are very rectangular rather than square.
The custom GPU kernels are effective
The researchers report that their symmetric matrix-multiplication kernels can be approximately twice as fast as standard cuBLAS kernels for sufficiently large matrices on Hopper and Blackwell GPUs.
cuBLAS is a highly optimized NVIDIA library for matrix calculations. Beating or improving on it for this special kind of calculation is significant because matrix multiplication is one of the most common and expensive operations in machine learning.
Processing fewer rows can preserve training quality
Dion3’s row-selection method changes the exact update made to the model. In theory, this could make training worse. However, the experiments described in the paper show that selecting only a fraction of the rows can still match or improve the final loss of Muon and related methods.
The error-feedback system is important because it prevents ignored information from disappearing permanently.
Stability required careful engineering
The researchers discovered that the simple version of Gram Newton–Schulz could become unstable when using lower-precision numbers, which GPUs often use for speed.
Small rounding errors could create impossible negative values in a matrix that should contain only nonnegative values. This could cause the calculation to fail or training to diverge.
To fix this, the researchers added a restart partway through the calculation. The restart recalculates an important matrix and removes much of the numerical error. They also made careful choices about number formats and GPU implementation.
5. Why are these findings important?
Training a LLM can require enormous amounts of computing power and time. If the optimizer wastes much of that time, researchers need more GPUs, more electricity, and more money.
Dion3 could help by:
- Making large-model training faster.
- Reducing the amount of communication needed between GPUs.
- Making Muon easier to use in different distributed-training setups.
- Allowing researchers to gain Muon’s learning advantages without paying as much of its computational cost.
- Making advanced optimizers more practical for models with very large or oddly shaped matrices.
The paper also provides open-source software packages, including dion and gram-newton-schulz, so other researchers can test and use the methods.
Simple conclusion
Muon can help LLMs learn efficiently, but its calculations are costly. Dion3 improves Muon at several levels: it uses a smaller mathematical problem, avoids repeated calculations, uses custom GPU code, processes only the most important parts of the update, and organizes GPU communication more efficiently.
The paper’s main message is that small improvements at many levels can combine into a large overall speedup. If the results continue to hold on larger and more varied models, Dion3 could make the training of future LLMs faster, cheaper, and easier to scale across many GPUs.
Knowledge Gaps
Conocimiento faltante, limitaciones y preguntas abiertas
- Validación empírica incompleta en modelos y escalas de frontera: aunque el artículo afirma aplicabilidad a múltiples tamaños, arquitecturas y estrategias de paralelismo, el texto proporcionado no demuestra sistemáticamente el comportamiento de Dion3 en modelos de cientos de miles de millones o billones de parámetros, ni en arquitecturas no basadas en Transformers.
- Cobertura limitada de hardware: las optimizaciones de CuteDSL se dirigen principalmente a GPUs NVIDIA Hopper y Blackwell; queda sin resolver si los beneficios se mantienen en arquitecturas NVIDIA anteriores, GPUs AMD, TPUs, aceleradores especializados u otros dispositivos.
- Dependencia no cuantificada de la selección de filas: no se establece cómo debe elegirse óptimamente la fracción según el tamaño de la matriz, la arquitectura, el nivel de ruido del gradiente, la fase del entrenamiento o el régimen de paralelismo.
- Ausencia de garantías teóricas para el muestreo de filas: el artículo muestra resultados experimentales favorables, pero no proporciona cotas de convergencia, error de aproximación o degradación de optimización para la selección de las filas con mayor norma .
- Comparación insuficiente entre estrategias de selección: se menciona que la selección aleatoria tiene un rendimiento cercano, pero no se realiza una comparación amplia con selección por norma , magnitud del gradiente, muestreo estratificado, selección basada en importancia o estrategias aprendidas.
- Efecto de la selección local frente a la global no resuelto: en configuraciones distribuidas se seleccionan las filas de mayor norma dentro de cada shard, aunque esto puede diferir de la selección global. No se cuantifica el impacto de esta discrepancia sobre la convergencia, la estabilidad y la calidad final.
- Interacción poco estudiada entre y el error feedback: el artículo adopta el mecanismo de Dion, pero no caracteriza cómo cambian la memoria del error, la frecuencia de actualización de filas poco activas y la estabilidad cuando es pequeño.
- Límites prácticos de la compresión: no se determina cuál es el valor mínimo de que permite conservar el rendimiento, ni si existe un umbral dependiente del modelo por debajo del cual Dion3 deja de ser competitivo con Muon, NorMuon o AdamW.
- Sensibilidad a hiperparámetros: falta un estudio sistemático de la sensibilidad de Dion3 a la tasa de aprendizaje, el coeficiente de momentum, , el weight decay, la inicialización y el número de iteraciones de Newton–Schulz.
- Ausencia de reglas de ajuste automático: el artículo recomienda o , pero no propone un procedimiento para adaptar automáticamente , la dirección de selección —filas o columnas— o el punto de reinicio durante el entrenamiento.
- Generalización limitada de la estabilización numérica: la estrategia de reinicio se diseña para un patrón específico de cinco iteraciones y una estimación concreta de autovalores espurios negativos. No se sabe cómo elegir robustamente el punto de reinicio para otros coeficientes, precisiones, números de iteraciones o distribuciones espectrales.
- Análisis numérico incompleto en precisiones modernas: se comparan principalmente
float16ybfloat16, pero no se estudian de forma exhaustiva formatos como FP8, TF32, FP4 u otros esquemas de cuantización relevantes para entrenamiento eficiente. - Impacto de la precisión mixta en el entrenamiento completo: aunque se identifican problemas de conversiones repetidas y se usan kernels personalizados, no se cuantifica cómo los errores acumulados de precisión afectan a entrenamientos largos, especialmente en modelos grandes y con gradientes mal condicionados.
- Falta de comparación con SVD o polar exacta bajo criterios de calidad: se afirma equivalencia matemática con Newton–Schulz estándar, pero no se mide de forma sistemática el error de Dion3 frente a la descomposición polar exacta ni se relaciona ese error con la pérdida y la generalización.
- Condiciones de estabilidad teórica no completamente establecidas: el análisis de la inestabilidad se centra en autovalores negativos introducidos al formar la matriz de Gram, pero quedan menos caracterizados otros errores, como pérdida de simetría, mal condicionamiento extremo, desbordamiento o cancelación numérica.
- Efectos sobre la generalización no explorados: las evaluaciones parecen centrarse principalmente en la pérdida de entrenamiento o validación; no se determina si la actualización parcial modifica sistemáticamente la generalización, la robustez o el comportamiento fuera de distribución.
- Evaluación limitada de tareas posteriores: no queda establecido si las mejoras observadas durante preentrenamiento se trasladan a ajuste fino, clasificación, razonamiento, recuperación, generación de código, visión o modelos multimodales.
- Falta de análisis en escenarios de entrenamiento inestables: no se examina Dion3 bajo lotes pequeños, datos ruidosos, gradientes escasos, entrenamiento con refuerzo, cambios de distribución o fases de aprendizaje con fuerte variación del gradiente.
- Comparaciones de rendimiento potencialmente incompletas: se reportan aceleraciones del paso del optimizador, pero no se separan siempre el tiempo de optimización, comunicación, memoria, sincronización y ejecución forward/backward en condiciones idénticas para todos los baselines.
- Ausencia de métricas completas de eficiencia: no se cuantifican de manera integral el consumo energético, la memoria máxima, la utilización de tensor cores, el coste de compilación, la ocupación de GPU ni el rendimiento por dólar o por unidad de energía.
- Dependencia de kernels y entornos concretos: el rendimiento de los kernels CuteDSL puede depender de versiones específicas de CUDA, PyTorch, compiladores y bibliotecas. No se estudia la reproducibilidad del speedup frente a cambios de software o configuraciones de lanzamiento.
- Escalabilidad de las ganancias con el tamaño de las matrices no completamente demostrada: los benchmarks de kernels no establecen si la ventaja se conserva para matrices muy pequeñas, muy grandes, con dimensiones no múltiplos de los tamaños de tile o con formas altamente asimétricas.
- Coste de los lanzamientos adicionales de kernels insuficientemente caracterizado: se menciona el uso de CUDA Graphs para mitigar el overhead, pero no se determina cuándo deja de ser eficaz ni cómo se comporta con formas dinámicas, secuencias variables o modelos con muchos tensores pequeños.
- Comunicación en topologías heterogéneas no evaluada: queda abierta la eficacia de la estrategia de megabatching en clusters con topologías no uniformes, múltiples niveles de interconexión, oversubscription, fallos de enlace o redes Ethernet frente a NVLink/InfiniBand.
- Interacción con otras formas de paralelismo poco explorada: aunque se mencionan FSDP, DDP y estrategias mixtas, faltan experimentos detallados con tensor parallelism, sequence parallelism, context parallelism, pipeline parallelism y expert parallelism combinados.
- Coste de sincronización y balance de carga no resuelto: la selección de filas y el agrupamiento de matrices pueden producir tamaños de trabajo desiguales entre dispositivos; no se cuantifica el impacto del desequilibrio ni se propone un mecanismo general de balanceo.
- Robustez ante matrices con dimensiones degeneradas: no se analiza suficientemente el comportamiento cuando las matrices son extremadamente rectangulares, casi de rango deficiente, muy pequeñas o tienen dimensiones que no se ajustan bien a los kernels implementados.
- Supuestos sobre la estructura de las capas no verificados ampliamente: las ventajas de Gram Newton–Schulz dependen de aspectos como y la distribución de formas matriciales; falta verificar si las tendencias arquitectónicas citadas se mantienen en una gama más amplia de modelos y diseños futuros.
- Interacción con weight tying y parámetros compartidos: no se estudia cómo manejar correctamente la selección parcial y el error feedback cuando una misma matriz o parámetro participa en varias partes del modelo.
- Aplicación a capas no matriciales insuficientemente abordada: no se explica en profundidad cómo se comporta Dion3 con convoluciones, embeddings, tensores de orden superior, normalizaciones, parámetros vectoriales o matrices con restricciones estructurales.
- Equivalencia con Muon en el caso solo es aproximada en precisión finita: aunque se reporta que las curvas coinciden, persisten diferencias de orden de operaciones, damping, normalización y kernels; no se cuantifica su impacto en entrenamientos largos o en condiciones numéricamente sensibles.
- Falta de ablaciones completas de cada componente a escala real: se necesitan experimentos factoriales que separen Gram Newton–Schulz, kernels simétricos, selección de filas, error feedback y megabatching, incluyendo sus interacciones en modelos grandes y no solo en benchmarks aislados.
- Comparación insuficiente con métodos alternativos de compresión: no se establece claramente cuándo Dion3 supera a Dion, Trion, MuonBP, métodos de ortogonalización por bloques, aproximaciones de bajo rango o técnicas de actualización dispersa bajo el mismo presupuesto computacional.
- Garantías sobre la calidad de optimización a largo plazo: los experimentos disponibles no determinan si las pequeñas diferencias por paso introducidas por la selección, la precisión finita y la aproximación polar se acumulan durante cientos de miles o millones de pasos.
- Reproducibilidad experimental incompleta: el texto no proporciona, en el fragmento disponible, todos los detalles necesarios sobre conjuntos de datos, calendarios de entrenamiento, semillas, hiperparámetros, versiones de software y configuración exacta del hardware.
- Estado “production-ready” no validado frente a fallos operativos: queda abierta la robustez del paquete ante reinicios, elasticidad del número de GPUs, recuperación de checkpoints, cambios de world size y reanudación de entrenamientos distribuidos.
- Implicaciones de memoria y almacenamiento no resueltas: no se analiza el coste adicional de mantener buffers de momentum, segundos momentos, residuos de error y estructuras auxiliares bajo distintos esquemas de sharding y checkpointing.
- Ausencia de análisis de seguridad o comportamiento adversarial del optimizador: no se estudia si la selección basada en normas puede amplificar patrones adversariales, favorecer sistemáticamente ciertos componentes del modelo o alterar la dinámica frente a datos contaminados.
Practical Applications
Immediate Applications
The paper’s main practical contribution is an open-source, drop-in implementation of a faster orthogonal optimizer for GPU-based distributed training. The following applications are therefore feasible with existing software and hardware, subject to validation on the target workload.
- Faster training of LLMs and transformer-based models — Industry / AI infrastructure
- Replace Muon or selected Muon variants with
dion, using Gram Newton–Schulz, symmetric GPU kernels, row/column subsampling, and megabatched communication. - The reported benefit is up to a reduction in optimizer-step time, with loss matching or improving on Muon in the evaluated settings.
- This can reduce wall-clock pretraining time, GPU-hours, and training cost for LLMs, mixture-of-experts models, and other transformer architectures.
- Dependencies: The largest gains require sufficiently large or rectangular matrices, supported NVIDIA Hopper or Blackwell GPUs, compatible distributed-training configurations, and workloads for which optimizer computation is a substantial fraction of total training time.
- Replace Muon or selected Muon variants with
- Drop-in acceleration for existing Muon or NorMuon training pipelines — Software engineering / ML platforms
- Use the
dionpackage as a replacement for existing Muon, NorMuon, or standard Newton–Schulz implementations. - Use
gram-newton-schulzindependently when the goal is only to accelerate orthogonalization while preserving the existing optimizer update rule. - This supports incremental adoption: teams can first substitute the orthogonalization routine, then enable Dion3 row selection and distributed megabatching.
- Dependencies: Existing code must expose compatible optimizer and parameter-sharding interfaces; numerical behavior should be checked because mixed-precision implementation details, fused updates, and normalization precision affect convergence.
- Use the
- More efficient fully sharded and distributed training — Cloud computing / HPC
- Apply megabatched all-to-all communication to reduce the number of communication rounds per optimizer step under FSDP2, DDP, and mixed-sharding strategies.
- Use row or column subsampling along the sharded dimension to reduce the amount of momentum data that must be gathered and scattered.
- This can improve GPU utilization and reduce communication bottlenecks in multi-GPU and multi-node training clusters.
- Dependencies: Benefits depend on interconnect topology, world size, tensor shapes, message sizes, and the quality of the framework’s collective-communication implementation. Global row selection may require additional synchronization and therefore reduce some gains.
- Acceleration of sparse mixture-of-experts training — Industry / Model architecture
- Use Dion3 for MoE models whose expert matrices are numerous, rectangular, or relatively small individually but collectively create substantial optimizer overhead.
- The method is particularly relevant where reduced forward/backward computation makes optimizer cost a larger share of total training time.
- Row selection can reduce orthogonalization cost without requiring a low-rank approximation procedure or power iteration.
- Dependencies: The recommended compression fractions, such as or , may not be optimal for every expert architecture. Quality must be evaluated for routing imbalance, expert sparsity, and highly heterogeneous parameter sizes.
- Efficient training of smaller models and fine-tuning workloads — Applied machine learning
- Use CUDA graph capture and replay in Dion3 to reduce kernel-launch overhead when training models too small to amortize the additional operations introduced by row selection.
- Potential users include researchers fine-tuning LLMs, vision transformers, recommendation models, and domain-specific transformers.
- Dependencies: At small scale, kernel-launch overhead can dominate arithmetic savings; actual speedups should be benchmarked against AdamW, Muon, and fused optimizer alternatives rather than assumed from large-model results.
- Reusable symmetric matrix-multiplication kernels — GPU software / Scientific computing
- Adapt the CuteDSL kernels for workloads involving symmetric products such as , , or .
- Potential uses include covariance estimation, kernel methods, Gram-matrix construction, covariance-based normalization, and selected numerical linear-algebra routines.
- The kernels can approximately halve unnecessary computation by calculating one triangle and copying it to the other, with reported speedups of roughly over cuBLAS for suitable matrix sizes on Hopper and Blackwell GPUs.
- Dependencies: The matrices must truly be symmetric or the computation must explicitly enforce symmetry. Performance is hardware-, size-, layout-, and precision-dependent; the kernels are not automatically superior for small or non-symmetric matrices.
- Efficient orthogonalization in research code and optimizer prototyping — Academia
- Researchers can use the open-source packages to compare Muon, NorMuon, Dion, Dion3, and alternative Newton–Schulz polynomial schedules under a common distributed backend.
- This lowers the implementation barrier for experiments involving spectral-norm optimization, orthogonalized updates, low-rank or block updates, and communication-aware optimizers.
- Dependencies: Reproducibility requires reporting hardware, matrix shapes, precision, compression fraction, sharding strategy, and kernel implementation, since these strongly influence measured performance.
- Reduced energy consumption for model training — Data centers / Sustainability
- If Dion3 achieves similar loss with lower optimizer-step time, organizations can use it to reduce energy consumed per training run or to complete more experiments within a fixed power budget.
- The same hardware could support more hyperparameter trials, ablations, or model iterations.
- Dependencies: Lower optimizer-step time does not necessarily imply proportional end-to-end energy savings. Forward and backward computation, idle periods, communication, and the energy cost of custom kernels must be measured at the full-training level.
Long-Term Applications
The following uses are plausible extensions of the paper’s methods, but require additional validation, broader hardware support, or research into optimization stability and generalization.
- General-purpose replacement for AdamW in frontier model pretraining — Industry / AI infrastructure
- Dion3 could become a standard optimizer for pretraining very large dense, MoE, multimodal, and reasoning models, particularly where Muon’s improved optimization efficiency is valuable but its orthogonalization overhead currently limits adoption.
- A mature implementation could expose automatic selection among AdamW, Muon, NorMuon, and Dion3 based on tensor aspect ratio, model size, and cluster topology.
- Dependencies: The paper demonstrates loss and timing improvements in selected settings, but broad replacement requires testing across datasets, architectures, training durations, scales, precision formats, and post-training objectives. Long-run stability and checkpoint compatibility also need evaluation.
- Adaptive compression schedules during training — Adaptive optimization / ML research
- The row-selection fraction could be adjusted dynamically according to training phase, gradient statistics, matrix aspect ratio, or communication congestion.
- For example, training could use a small during computationally expensive phases and increase during convergence-sensitive phases, or select rows based on residual momentum accumulated through error feedback.
- This could produce an optimizer that automatically trades off update fidelity against speed.
- Dependencies: Adaptive selection may introduce synchronization overhead, unstable update magnitudes, or additional hyperparameters. The paper establishes fixed-fraction strategies but does not fully establish optimal schedules.
- Hardware-portable orthogonal optimization — GPU, accelerator, and compiler ecosystems
- The Gram formulation could be implemented for AMD GPUs, TPUs, Intel accelerators, custom AI chips, and future GPU generations.
- Its concentration of work in small symmetric matrices may be suitable for accelerators with specialized matrix-multiplication or structured-linear-algebra units.
- Compiler libraries could automatically detect symmetric operations and generate triangular or symmetry-aware kernels.
- Dependencies: CuteDSL kernels are specifically targeted at NVIDIA Hopper and Blackwell architectures. Portability requires new kernels, supported collective operations, precision analysis, and benchmarking against vendor libraries.
- Communication-aware optimizers for exascale and geographically distributed training — HPC / Distributed systems
- Megabatching and compressed momentum exchange could be generalized to other optimizers and distributed algorithms in which many small tensors require repeated collectives.
- A communication scheduler could combine optimizer-state transfers across layers, overlap computation with communication, and select batch sizes based on network congestion.
- This may be useful for very large clusters, federated high-performance training, or multi-site model development.
- Dependencies: Larger communication batches may increase memory pressure and synchronization latency. The approach assumes that parameters can be safely grouped and that delayed or aggregated communication does not harm optimization.
- Orthogonalized optimization beyond transformers — Computer vision, recommendation, scientific ML
- Dion3 could be evaluated for convolutional layers, recurrent networks, graph neural networks, diffusion models, recommender systems, scientific surrogates, and reinforcement-learning policies.
- In these settings, the method may provide benefits wherever weight matrices have favorable rectangular shapes or where optimizer computation is a bottleneck.
- Dependencies: The paper focuses primarily on transformer-style matrix parameters. Convolutional and structured layers may require reshaping, block-wise updates, or new selection rules, and their optimization behavior may differ substantially.
- Robotics and embodied AI model training — Robotics
- More efficient distributed optimization could lower the cost of training multimodal policies, world models, robot-control transformers, and simulation-based agents.
- Faster optimization could enable more frequent retraining from new sensor data or simulation environments.
- Dependencies: The paper does not demonstrate online or safety-critical control. Before deployment in robotics, researchers would need to establish reliable convergence, robustness to nonstationary data, and predictable behavior under limited-data regimes.
- Energy-constrained and edge model training — Mobile, embedded, and edge computing
- A compressed orthogonal update could eventually support more sophisticated optimization on devices with limited compute, memory, or network bandwidth.
- Selective row updates and error feedback may reduce the cost of local training or adaptation in federated-learning systems.
- Dependencies: The current implementation targets high-end NVIDIA GPUs and distributed training. Edge deployment would require memory-efficient kernels, lower-precision stability guarantees, reduced synchronization requirements, and validation under heterogeneous client data.
- Compiler and framework-level automatic optimizer selection — ML systems
- Training frameworks could inspect tensor shapes and sharding layouts, then automatically choose standard Newton–Schulz, Gram Newton–Schulz, block orthogonalization, or Dion3 row selection.
- A runtime policy could optimize for end-to-end throughput by considering FLOPs, kernel-launch overhead, memory bandwidth, and interconnect utilization.
- Dependencies: Such automation requires reliable cost models and convergence predictors. A locally faster optimizer step may still reduce overall training efficiency if it requires more training steps or produces inferior final loss.
- Use of error feedback for structured update sparsification — Optimization research
- Dion3’s error-feedback mechanism could inspire sparse or selectively updated optimizers in which only important rows, columns, blocks, or experts are updated at each iteration.
- Similar techniques could be applied to communication compression, parameter-efficient training, or sparse adaptation.
- Dependencies: The current evidence supports selected row updates with specific momentum and normalization rules. Generalizing the method requires theoretical convergence analyses and experiments under adversarial sparsity, rapidly changing gradients, and nonconvex objectives.
- Numerically robust low-precision linear algebra workflows — Numerical computing
- The paper’s restart strategy and precision recommendations could inform other iterative matrix algorithms that operate on Gram matrices in float16 or bfloat16.
- Systems could monitor symmetry defects, negative eigenvalues, or condition-number estimates and trigger restarts or higher-precision recomputation automatically.
- Dependencies: The proposed stabilization addresses the observed Gram Newton–Schulz failure mode, but broader numerical guarantees across matrix spectra, scaling regimes, and hardware implementations remain to be established.
Glossary
The following is a list of advanced domain-specific terms found in the paper that may be unfamiliar to an undergraduate computer science student.
- All-to-all: A communication pattern in parallel computing where every processor sends distinct data to every other processor; it is frequently the bottleneck in distributed optimization. "We provide a full-stack solution that performs well across a wide range of model sizes, architectures, cluster sizes, and parallelism strategies... our megabatching strategy reduces communication overhead." (Note: Referenced in the context of: "We use all-to-all communication along the sharding dimension, with each device processing a different weight in parallel.")
- CuteDSL: A domain-specific language (DSL) used for writing high-performance GPU kernels, particularly for NVIDIA's Hopper and Blackwell architectures, that provides fine-grained control over thread-level memory access and register use. "Our CuteDSL kernels accelerate it by exploiting symmetry, and our megabatching strategy reduces communication overhead."
- Frobenius norm: A matrix norm defined as the square root of the sum of the absolute squares of its elements, often used to measure the magnitude of weight matrices or updates. "A final rescaling ensures that the overall magnitude of the update (as measured in the Frobenius norm) matches that of Muon."
- GEMM: An acronym for General Matrix-to-Matrix Multiplication, the fundamental operation used in deep learning for linear layers and optimization routines. "Each iteration has three steps. Each step contains a single matrix multiplication (, , ) costing, respectively, , , and FLOPs for a total cost of FLOPs... spread across 15 matrix-matrix multiplications (GEMMs)."
- Gram matrix: A matrix created by the inner product of a set of vectors (or a matrix multiplied by its transpose), which is always positive semi-definite and symmetric. "Gram Newton-Schulz, a mathematically equivalent reformulation of Newton-Schulz that iterates on the small symmetric Gram matrix and cuts the FLOP cost of each orthogonalization dramatically."
- Newton-Schulz: An iterative method used to compute matrix functions, specifically to approximate the inverse square root of a matrix or the polar decomposition, used here to orthogonalize weight updates. "The Muon optimizer incurs a significant overhead cost due to its cubic-time Newton-Schulz orthogonalization step."
- Polar decomposition: A matrix decomposition that factorizes a matrix into an orthogonal matrix and a symmetric positive semi-definite matrix; in optimization, this is used to "orthogonalize" updates to ensure they maintain specific spectral properties. "The key innovation is the operation... this operation—the 'orthogonalization step'—balances the spectrum of the update, ensuring that it has full numerical rank."
- Sharding: A technique for distributing large datasets or model parameters across multiple nodes or GPUs, commonly used in distributed training frameworks like FSDP (Fully Sharded Data Parallel). "When weights are sharded, communication overhead compounds this computational cost, eroding the benefits of Muon in many settings."
- Singular Value Decomposition (SVD): A mathematical factorization of a matrix into the product of three distinct matrices, revealing the geometric transformation, rotations, and scaling factors of the underlying linear operator. "If is the singular value decomposition (SVD) of a matrix, then ."
- Spectral norm: The largest singular value of a matrix, which provides a measure of the maximum "gain" or growth the matrix can impose on a vector. "The Muon optimizer... is best described as steepest-direction descent with respect to the spectral norm."
Collections
Sign up for free to add this paper to one or more collections.

