[feat] add MXFP8 support on H3

[Davids048]

Purpose

Add Blackwell MXFP8 inference for the two linear layers in every MiniMax-H3 transformer feed-forward network
(FFN). The FFN accepts BF16 hidden states, executes both matrix multiplications with MXFP8 values and E8M0
block scales, and returns BF16 hidden states.

Changes

• Add Blackwell MXFP8 inference for MiniMax-H3 FFN fc_in and fc_out layers. Weights are quantized after
  checkpoint loading and LoRA merging.
• Add support for MXFP8 quantization and configs.
• Simplify FastH3 inference entry points and add Nsight Systems profilers and NVTX ranges for MiniMax-H3.

The FFN dtype flow is:

BF16 hidden states
  -> fused MXFP8 quantization + scale swizzle
  -> MXFP8 fc_in GEMM
  -> BF16 packed SwiGLU input
  -> fused SwiGLU + MXFP8 quantization + scale swizzle
  -> MXFP8 fc_out GEMM
  -> BF16 FFN output

Enable the path with:

QuantizationConfig(transformer_quant="MXFP8")

Test Plan

Profile one 345-frame FastH3 generation after three warmup generations:

bash examples/inference/basic/basic_fasth3_simplified_profile.sh

The MXFP8 run used this command. The BF16 totals came from predecessor run 20260831T004438Z-4009913, which
used the same profile settings with transformer quantization disabled.

Profile configuration:

• 4 NVIDIA GB200 GPUs with sequence parallelism 4
• 1344x768, 345 frames, 24 frames per second
• FastH3 vsa-datafree LoRA, 5 scheduler points, seed 1000
• Video sparse attention at 90% sparsity with 64-token query/key tiles
• Video variational autoencoder compilation enabled; diffusion transformer compilation disabled
• 800 FFN NVTX ranges across four GPUs

Test Results

Summed GPU kernel time inside the same 800 FFN NVTX ranges:

FFN stage	BF16 total	MXFP8 total	Speedup
Input quantization	-	260.859 ms	-
fc_in	3,491.160 ms	1,902.536 ms	1.835x
SwiGLU + output quantization	373.079 ms	786.248 ms	0.475x
fc_out	1,852.935 ms	983.061 ms	1.885x
All FFN kernels	5,717.174 ms	3,932.703 ms	1.454x

MXFP8 reduces summed FFN kernel time by 31.21% in this profile. For the single measured generation in each
format, output-tensor production took 17.84 seconds with MXFP8 and 18.15 seconds with BF16. Including frame
postprocessing and media saving, elapsed latency was 19.33 seconds with MXFP8 and 19.53 seconds with BF16. One
measurement per format does not establish run-to-run variability. The run artifacts do not record a commit ID
or source hashes, so the exact profiled source snapshot is unverified.

Checklist

• I ran pre-commit run --all-files and fixed all issues
• I added or updated tests for my changes
• I updated documentation if needed
• I considered GPU memory impact of my changes

For model/pipeline changes:

• I verified SSIM regression tests pass
• The support matrix does not need an update because this PR adds a quantization path for MiniMax-H3.

[mergify]

This PR has merge conflicts with the base branch. Please rebase:

git fetch origin main
git rebase origin/main
# Resolve any conflicts, then:
git push --force-with-lease

[mergify]

Merge Protections

🔴 1 of 1 protections blocking · waiting on 🤖 CI

	Protection	Waiting on
🔴	PR merge requirements	🤖 CI

🔴 PR merge requirements

Waiting for

• check-success=fastcheck-passed
• check-success=full-suite-passed

This rule is failing.

• check-success=fastcheck-passed
• check-success=full-suite-passed
• #approved-reviews-by>=1
• check-success~=pre-commit
• title~=(?i)^\[(feat|feature|bugfix|fix|refactor|perf|ci|doc|docs|misc|chore|kernel|new.?model|skill|skills|infra)\]

[mergify]

Pre-commit checks failed

Hi @Davids048, the pre-commit checks have failed. To fix them locally:

# Install pre-commit if you haven't already
uv pip install pre-commit
pre-commit install

# Run all checks and auto-fix what's possible
pre-commit run --all-files

Common fixes:

• yapf: yapf -i <file> (formatting)
• ruff: ruff check --fix <file> (linting)
• codespell: codespell --write-changes <file> (spelling)

After fixing, commit and push the changes. The checks will re-run automatically.

For future commits, pre-commit will run automatically on changed files before each commit.

[mergify]

Pre-commit checks failed

Hi @Davids048, the pre-commit checks have failed. To fix them locally:

# Install pre-commit if you haven't already
uv pip install pre-commit
pre-commit install

# Run all checks and auto-fix what's possible
pre-commit run --all-files

Common fixes:

• yapf: yapf -i <file> (formatting)
• ruff: ruff check --fix <file> (linting)
• codespell: codespell --write-changes <file> (spelling)

After fixing, commit and push the changes. The checks will re-run automatically.

For future commits, pre-commit will run automatically on changed files before each commit.

[mergify]

Pre-commit checks failed

Hi @Davids048, the pre-commit checks have failed. To fix them locally:

# Install pre-commit if you haven't already
uv pip install pre-commit
pre-commit install

# Run all checks and auto-fix what's possible
pre-commit run --all-files

Common fixes:

• yapf: yapf -i <file> (formatting)
• ruff: ruff check --fix <file> (linting)
• codespell: codespell --write-changes <file> (spelling)

After fixing, commit and push the changes. The checks will re-run automatically.

For future commits, pre-commit will run automatically on changed files before each commit.

[mergify]

Pre-commit checks failed

Hi @Davids048, the pre-commit checks have failed. To fix them locally:

# Install pre-commit if you haven't already
uv pip install pre-commit
pre-commit install

# Run all checks and auto-fix what's possible
pre-commit run --all-files

Common fixes:

• yapf: yapf -i <file> (formatting)
• ruff: ruff check --fix <file> (linting)
• codespell: codespell --write-changes <file> (spelling)

After fixing, commit and push the changes. The checks will re-run automatically.

For future commits, pre-commit will run automatically on changed files before each commit.

[SolitaryThinker]

Rebased onto current origin/main to pick up the main-side FastH3 loader/CLI and unit-test fixes; no content changes (range-diff clean, with only the already-upstreamed h3-sequential-load hunk absorbed by main).

[mergify]

Pre-commit checks failed

Hi @Davids048, the pre-commit checks have failed. To fix them locally:

# Install pre-commit if you haven't already
uv pip install pre-commit
pre-commit install

# Run all checks and auto-fix what's possible
pre-commit run --all-files

Common fixes:

• yapf: yapf -i <file> (formatting)
• ruff: ruff check --fix <file> (linting)
• codespell: codespell --write-changes <file> (spelling)

After fixing, commit and push the changes. The checks will re-run automatically.

For future commits, pre-commit will run automatically on changed files before each commit.

[SolitaryThinker]

Requesting changes based on the implementation review; CI-only failures are intentionally omitted. The main blockers are distributed/FSDP correctness, LoRA lifecycle correctness, and missing non-skip MXFP8 parity. I also left a dependency-declaration comment. I reviewed the component, loader, LoRA integration, and quality/evidence lanes. Blackwell numerical validation could not be run in my local environment.

[mergify]

Pre-commit checks failed

Hi @Davids048, the pre-commit checks have failed. To fix them locally:

# Install pre-commit if you haven't already
uv pip install pre-commit
pre-commit install

# Run all checks and auto-fix what's possible
pre-commit run --all-files

Common fixes:

• yapf: yapf -i <file> (formatting)
• ruff: ruff check --fix <file> (linting)
• codespell: codespell --write-changes <file> (spelling)

After fixing, commit and push the changes. The checks will re-run automatically.

For future commits, pre-commit will run automatically on changed files before each commit.

[SolitaryThinker]

Re-reviewed the latest head against both origin/main and the prior reviewed commit. All four requested changes are addressed: the FastH3 extra directly pins Quack, unsupported FSDP-inference quantization is rejected before model construction, the packed-weight LoRA lifecycle is explicitly guarded with MXFP8 adapter changes requantized, and Blackwell numerical parity now covers activation/scales, fused SwiGLU, and the full H3 FFN. The author also reported a 4-pass GB200 run and 20 matched BF16/MXFP8 generations with no visible quality regression. No new blocking code findings. Per maintainer direction, CI status was not considered. I could not independently rerun Blackwell kernels locally; the MXFP8 sample attachment currently returns 404 and should be reattached for the record, but this is non-blocking given the recorded numerical and visual evidence.