[mxfp8 moe training] refactor all var names with suffix _mx to _data for clarity

[danielvegamyhre]

Stacked PRs:

• [mxfp8 moe training] add triton kernel for blocked swizzled 3d weight scales #2894
• [mxfp8 moe training] add per group blocked scale kernels #2886
• [mxfp8 moe training] add grouped gemm benchmark script #2882
• ->[mxfp8 moe training] refactor all var names with suffix _mx to _data for clarity #2879

---

[mxfp8 moe training] refactor all var names with suffix _mx to _fp8 for clarity

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/ao/2879

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Multiple CI trunk failures after landing https://github.com/pytorch/pytorch/pull/161002

✅ No Failures

As of commit fb1628c with merge base 15a6de6 ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[vkuzo]

sg, but if you're using A_scales I'd say the corresponding name is something like A_data, not A_fp8.

[danielvegamyhre]

sg, but if you're using A_scales I'd say the corresponding name is something like A_data, not A_fp8.

Yeah, hmm, scales and data are both different fp8 formats so I can see how this still could be unclear. The thing is, we already have A input tensor, so A_data vs A both sound like the same thing, and it gets confusing. I considered changing "A" to "A_hp" but A_hp vs A_data is still confusing. I figured "A" vs "A_fp8" was the clearest distinction, but A_hp vs A_data could also work I guess.

[vkuzo]

I'm not a fan of A_f8, this isn't going to scale to other dtypes. A_data is IMO better and more representative of the MX format being composed of raw data and scale.

[vkuzo]

stamping because prototype