Skip to content

feat(quantization): support int8 with float8_e8m0fnu scales - #133

Open
dengqiaoyu wants to merge 3 commits into
apple:mainfrom
dengqiaoyu:feat/int8-e8m0-scale
Open

dengqiaoyu wants to merge 3 commits into
apple:mainfrom
dengqiaoyu:feat/int8-e8m0-scale

Conversation

@dengqiaoyu

@dengqiaoyu dengqiaoyu commented Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

Support int8 with float8_e8m0fnu scales (MXINT8) in QuantizationSpec.

  • int8 accepts an e8m0 scale at any granularity: scale = 2^(floor(log2(max_abs)) - 6).
  • e8m0 requires symmetric ZP (validate_symmetric_qscheme, validate_zp_qformulation).
  • Graph mode keeps the symmetric scheme where an op like relu or sigmoid would propose asymmetric.
  • finalize rejects CoreAI/CoreML export of int8 + e8m0 unless an activation export handler covers it.

@dengqiaoyu
dengqiaoyu requested a review from vineet-g October 9, 2026 21:55
dengqiaoyu added a commit to dengqiaoyu/coreai-optimization that referenced this pull request Oct 23, 2026
- Drop an op-intrinsic asymmetric qscheme in `_build_concrete_spec` when the reconciled group has a floating-point dtype or an e8m0 scale. The op-intrinsic gate only sees the producing op's own config, so `sigmoid -> Linear` with an e8m0 consumer reconciled to int8 + e8m0 + asymmetric and failed validation (FP8 hit the same crash). Settling it after reconciliation avoids a cycle with `InheritFields`, which copies the op's value verbatim.
- Re-raise the original exception from `prepare_qat_pt2e` with a note instead of rebuilding it via `type(e)(msg)`, which raised a `TypeError` for exceptions such as pydantic's `ValidationError` and hid the real error.
- Run `validate_scale_dtype` before the qscheme/qformulation validators so an unsupported dtype or scale dtype gets the scale_dtype error first, rather than a request to change a field that isn't the problem.
- Document int8 with e8m0 scales in the `QuantizationSpec` docstring: `target_max_pow2 = 6`, with OCP MXINT8's `2^-6` element factor folded into `scale`.
- Add the changelog fragment for apple#133.
)


@pytest.mark.parametrize("qparam_calculator_cls", ["default", "dynamic"])

@vineet-g vineet-g Oct 30, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add one more test for checking the clamping of MXINT8. Use x as torch.Tensor([[-3.99, 3.99]]).

scale = 2^(floor(log2(3.99)) - 6) = 2^-5; 3.99 / 2^-5 = 127.68
+127.68 rounds to 128 and clamps to 127; -127.68 rounds to -128, which int8 holds

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added!

dengqiaoyu added a commit to dengqiaoyu/coreai-optimization that referenced this pull request Oct 30, 2026
- Drop an op-intrinsic asymmetric qscheme in `_build_concrete_spec` when the reconciled group has a floating-point dtype or an e8m0 scale. The op-intrinsic gate only sees the producing op's own config, so `sigmoid -> Linear` with an e8m0 consumer reconciled to int8 + e8m0 + asymmetric and failed validation (FP8 hit the same crash). Settling it after reconciliation avoids a cycle with `InheritFields`, which copies the op's value verbatim.
- Re-raise the original exception from `prepare_qat_pt2e` with a note instead of rebuilding it via `type(e)(msg)`, which raised a `TypeError` for exceptions such as pydantic's `ValidationError` and hid the real error.
- Run `validate_scale_dtype` before the qscheme/qformulation validators so an unsupported dtype or scale dtype gets the scale_dtype error first, rather than a request to change a field that isn't the problem.
- Document int8 with e8m0 scales in the `QuantizationSpec` docstring: `target_max_pow2 = 6`, with OCP MXINT8's `2^-6` element factor folded into `scale`.
- Add the changelog fragment for apple#133.
@dengqiaoyu
dengqiaoyu force-pushed the feat/int8-e8m0-scale branch from c5d2a00 to d8f07e5 Compare October 30, 2026 21:22
@dengqiaoyu
dengqiaoyu enabled auto-merge (squash) October 30, 2026 21:59
dengqiaoyu added a commit to dengqiaoyu/coreai-optimization that referenced this pull request Nov 3, 2026
- Drop an op-intrinsic asymmetric qscheme in `_build_concrete_spec` when the reconciled group has a floating-point dtype or an e8m0 scale. The op-intrinsic gate only sees the producing op's own config, so `sigmoid -> Linear` with an e8m0 consumer reconciled to int8 + e8m0 + asymmetric and failed validation (FP8 hit the same crash). Settling it after reconciliation avoids a cycle with `InheritFields`, which copies the op's value verbatim.
- Re-raise the original exception from `prepare_qat_pt2e` with a note instead of rebuilding it via `type(e)(msg)`, which raised a `TypeError` for exceptions such as pydantic's `ValidationError` and hid the real error.
- Run `validate_scale_dtype` before the qscheme/qformulation validators so an unsupported dtype or scale dtype gets the scale_dtype error first, rather than a request to change a field that isn't the problem.
- Document int8 with e8m0 scales in the `QuantizationSpec` docstring: `target_max_pow2 = 6`, with OCP MXINT8's `2^-6` element factor folded into `scale`.
- Add the changelog fragment for apple#133.
@dengqiaoyu
dengqiaoyu force-pushed the feat/int8-e8m0-scale branch from d8f07e5 to 7c0540d Compare November 3, 2026 17:47
- `QuantizationSpec` accepts `dtype=torch.int8` with `scale_dtype=torch.float8_e8m0fnu` at any granularity (`E8M0_TARGET_MAX_POW2[torch.int8] = 6`), so int8 power-of-2 block scales work in torch fake quantization.
- For integer dtypes the e8m0 qparams path returns a zero `zero_point` and `minval = -max_abs`, which the integer fake-quant path requires; FP4/FP8 still get `None`.
- An e8m0 scale requires `qscheme="symmetric"` and `qformulation="zp"` (enforced by the existing FP qscheme/qformulation validators), and graph-mode op-intrinsic overrides such as `relu` no longer propose an asymmetric scheme for it.
- `Quantizer.finalize` rejects CoreAI/CoreML export of integer quantization with e8m0 scales unless a registered activation export handler covers the module; `ExportBackend._TORCH` is unaffected.
- Integer palettization `lut_qspec` rejects an e8m0 scale, keeping LUT behavior unchanged.
- Drop an op-intrinsic asymmetric qscheme in `_build_concrete_spec` when the reconciled group has a floating-point dtype or an e8m0 scale. The op-intrinsic gate only sees the producing op's own config, so `sigmoid -> Linear` with an e8m0 consumer reconciled to int8 + e8m0 + asymmetric and failed validation (FP8 hit the same crash). Settling it after reconciliation avoids a cycle with `InheritFields`, which copies the op's value verbatim.
- Re-raise the original exception from `prepare_qat_pt2e` with a note instead of rebuilding it via `type(e)(msg)`, which raised a `TypeError` for exceptions such as pydantic's `ValidationError` and hid the real error.
- Run `validate_scale_dtype` before the qscheme/qformulation validators so an unsupported dtype or scale dtype gets the scale_dtype error first, rather than a request to change a field that isn't the problem.
- Document int8 with e8m0 scales in the `QuantizationSpec` docstring: `target_max_pow2 = 6`, with OCP MXINT8's `2^-6` element factor folded into `scale`.
- Add the changelog fragment for apple#133.
… clamping

- Rename `validate_qscheme_for_fp_quant` to `validate_symmetric_qscheme` and `validate_qformulation_for_fp_quant` to `validate_zp_qformulation`: both also guard int8 with an e8m0 scale, not just FP quantization.
- Comment why the int8 e8m0 qparams path returns a zero point and a minval: the integer fake-quant path needs both, and e8m0 allows only symmetric ZP.
- Add a test that an e8m0 scale can push the int8 block max past 127, which clamps, while -128 stays representable.
@dengqiaoyu
dengqiaoyu force-pushed the feat/int8-e8m0-scale branch from 7c0540d to 760f7bf Compare November 3, 2026 22:07

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants