Deciding how to help non-expert humans engage with formal verification specifications seems like one of the more important non-verifiable UX problems facing the rise of formal verification. 🧵
Edward Z. Yang
Verified account This account is verified. Learn more@ezyang
I work on PyTorch at Meta. Chatty alt at @difficultyang.
1.7K Following 18K Followers 9.2K Posts
Latest posts 5
Earlier this year I had a kick where I was like "what if we FLEX EVERYTHING". This was mostly not actually a good idea but Driss made flex gemm actually work! Go check it out.
Gave a talk at PTC on flex_gemm which is a new gemm_epilogue API in pytorch built on Quack. I think its neat, not ground breaking but neat nonetheless :)View quoted post on X
github.com/drisspg/transf…
planning to bootstrap this and continue to add fun examples
Last year we were extremely worried about how to get cudagraphable, dropless mixture of experts. Dist_moe has essentially solved this for us, both internally and in OSS
We’re sharing Dist-MoE, open-source library from Meta SuperIntelligence Labs (MSL @AIatMeta ). Dist-MoE provides fused communication and compute kernels for BF16/MXFP8 training and inference, plus NVFP4 inference.View quoted post on X
✅ Fused communication and compute kernels
✅ Full CUDA graph support
✅ Dynamic activation packing across layers into a bounded buffer
✅ Dynamic, capacity-driven recompute
✅ Forward and backward kernels for BF16/MXFP8
✅ No shared-expert branch required
Some highlights from our GB300 NVL72 benchmarks:
• Up to 1.40× speedup over Mixture-of-Kittens (MoK) in our imbalanced, ten-layer MXFP8 training workload across 64 GPUs. Dist-MoE packed activation state across all ten layers with zero capacity-induced recompute.
• 3.09 useful PFLOP/s per GPU (3,090 TFLOP/s) for NVFP4 Mega inference across 16 GPUs.
• 1.86 useful PFLOP/s per GPU (1,856 TFLOP/s) for MXFP8 Staged training across 64 GPUs.
• 1.27 useful PFLOP/s per GPU (1,271 TFLOP/s) for BF16 training across 64 GPUs.
• Sub-linear scaling under imbalance: in NVFP4 inference across 16 GPUs, 8× the received rows on the busiest GPU required 4.82× the iteration time; about 40% lower iteration time per received row.
Full configurations, raw results, and measurement definitions are in the blog.
@levendlee and I also put together an interactive visual explainer covering token dispatch and combine, quantization, forward/backward kernels, activation packing, dynamic recompute, and memory planning.
Blog:
meta-pytorch.org/dist_moe/previ…
Repository:
github.com/meta-pytorch/d…
TorchTitan (@PyTorch ) integration:
github.com/pytorch/torcht…
If you work on MoE training, inference, or GPU kernels, take a look. We welcome feedback and contributions.
#PyTorch #MixtureOfExperts #MoE #OpenSource #TorchTitan #DistMoE
It is an incredibly pleasant feeling when Claude knows about variational types and will happily go implement them for you
Reminding myself that types are good even for things that are trivially testable cuz you don't have to remember to write those tests!