Skip to content

Add mxfp4_block_size parameter to f4f4bf16_grouped_mm for MXFP4_16 support (#496) - #496

Open
ghjeong12 wants to merge 1 commit into
meta-pytorch:mainfrom
ghjeong12:export-D101478667
Open

Add mxfp4_block_size parameter to f4f4bf16_grouped_mm for MXFP4_16 support (#496)#496
ghjeong12 wants to merge 1 commit into
meta-pytorch:mainfrom
ghjeong12:export-D101478667

Conversation

@ghjeong12

@ghjeong12 ghjeong12 commented Aug 21, 2026

Copy link
Copy Markdown

Summary:

f4f4bf16_grouped_mm hardcoded the MXFP4 scaling-block size to 32. This extends MXFP4 to support block size 16.

Adds an mxfp4_block_size parameter (default 32, so existing callers are
unchanged) threaded from the torch op down through the manifest into the kernel
instantiations, plus an MXFP4_16 quant-type tag alongside the existing NVFP4
and MXFP4.

The dispatch rule inside each instantiation is:

  • global_scale present -> NVFP4 (SfVecSize 16, E4M3 scales)
  • mxfp4_block_size == 16 -> MXFP4_16 (SfVecSize 16, E8M0 scales)
  • otherwise -> MXFP4 (SfVecSize 32, E8M0 scales)

MXFP4_16 reuses the NvF4 kernel schedule because it shares NVFP4's SfVecSize
of 16 and differs only in scale encoding (E8M0 vs E4M3), which is why this is a
schedule-selection change rather than a new kernel family.

Also widens starting_row_after_padding handling and the scale-layout helpers
to cover the 16-wide case.

Differential Revision: D101478667

@meta-cla meta-cla Bot added the cla signed label Aug 21, 2026
@meta-codesync

meta-codesync Bot commented Aug 21, 2026

Copy link
Copy Markdown

@ghjeong12 has exported this pull request. If you are a Meta employee, you can view the originating Diff in D101478667.

@meta-codesync meta-codesync Bot changed the title Add mxfp4_block_size parameter to f4f4bf16_grouped_mm for MXFP4_16 support Add mxfp4_block_size parameter to f4f4bf16_grouped_mm for MXFP4_16 support (#496) Aug 21, 2026
ghjeong12 added a commit to ghjeong12/MSLK that referenced this pull request Aug 21, 2026
…pport (meta-pytorch#496)

Summary:

`f4f4bf16_grouped_mm` hardcoded the MXFP4 scaling-block size to 32. This extends MXFP4 to support block size 16.

Adds an `mxfp4_block_size` parameter (default 32, so existing callers are
unchanged) threaded from the torch op down through the manifest into the kernel
instantiations, plus an `MXFP4_16` quant-type tag alongside the existing `NVFP4`
and `MXFP4`.

The dispatch rule inside each instantiation is:

- `global_scale` present -> `NVFP4` (SfVecSize 16, E4M3 scales)
- `mxfp4_block_size == 16` -> `MXFP4_16` (SfVecSize 16, E8M0 scales)
- otherwise -> `MXFP4` (SfVecSize 32, E8M0 scales)

`MXFP4_16` reuses the NvF4 kernel schedule because it shares NVFP4's SfVecSize
of 16 and differs only in scale encoding (E8M0 vs E4M3), which is why this is a
schedule-selection change rather than a new kernel family.

Also widens `starting_row_after_padding` handling and the scale-layout helpers
to cover the 16-wide case.

Differential Revision: D101478667
…pport (meta-pytorch#496)

Summary:

`f4f4bf16_grouped_mm` hardcoded the MXFP4 scaling-block size to 32. This extends MXFP4 to support block size 16.

Adds an `mxfp4_block_size` parameter (default 32, so existing callers are
unchanged) threaded from the torch op down through the manifest into the kernel
instantiations, plus an `MXFP4_16` quant-type tag alongside the existing `NVFP4`
and `MXFP4`.

The dispatch rule inside each instantiation is:

- `global_scale` present -> `NVFP4` (SfVecSize 16, E4M3 scales)
- `mxfp4_block_size == 16` -> `MXFP4_16` (SfVecSize 16, E8M0 scales)
- otherwise -> `MXFP4` (SfVecSize 32, E8M0 scales)

`MXFP4_16` reuses the NvF4 kernel schedule because it shares NVFP4's SfVecSize
of 16 and differs only in scale encoding (E8M0 vs E4M3), which is why this is a
schedule-selection change rather than a new kernel family.

Also widens `starting_row_after_padding` handling and the scale-layout helpers
to cover the 16-wide case.

Differential Revision: D101478667
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant