Consolidate ZeroPointDomain.NONE & None zero point domains

[sanchitintel]

Summary

• Both ZeroPointDomain.NONE & None zero point domains were being used. The latter was being used for float8. This PR consolidates both & retains ZeroPointDomain.NONE
• Using ZeroPointDomain.NONE would now produce None for zero-point
• int8_dynamic_activation_int8_weight now uses ZeroPointDomain.NONE as weight zero point domain (as weight is quantized symmetrically to int8).

Some of the older changes in this PR (such as supporting torch.compile with optional zero_point) were rendered redundant by more recent changes in the main branch, so I removed them & modified the description accordingly. Thanks!

BC-breaking note:

A None value for zero_point_domain would no longer be accepted. Please use ZeroPointDomain.NONE instead.
A None zero-point would be generated if ZeroPointDomain.NONE would be used.

Before this PR:

None value of zero_point_domain was being used for quantization to float8 dtypes to indicate the absence of a zero-point.
ZeroPointDomain.NONE was being used for quantization to non-float8 dtypes to indicate the absence of a zero-point.
choose_qparams_affine returned a non-None zero-point for symmetric quantization.

After this PR lands:

ZeroPointDomain.NONE value for zero_point_domain should be used to denote the absence of a zero-point.
zero point in such cases would be None.

APIs affected:

For the following user-facing APIs, a None zero_point_domain can no longer be used with the following APIs (ZeroPointDomain.NONE should be used instead of None) -

torchao.quantization.quant_api.int4_weight_only

zero_point_domain is no longer optional for the following developer-facing APIs -

torchao.quantization.quant_primitives.choose_qparams_affine
torchao.quantization.quant_primitives.choose_qparams_affine_with_min_max
torchao.quantization.quant_primitives.fake_quantize_affine_cachemask
torchao.quantization.quant_primitives.quantize_affine
torchao.quantization.observer.AffineQuantizedObserverBase
torchao.dtypes.uintx.marlin_qqq_tensor.MarlinQQQTensor.from_hp_to_intx
torchao.dtypes.AffineQuantizedTensor.from_hp_to_intx
torchao.dtypes.AffineQuantizedTensor.from_hp_to_intx_static

For the following developer-facing APIs, a None zero_point_domain can no longer be used with the following APIs (ZeroPointDomain.NONE should be used instead of None) -

torchao.quantization.quant_primitives.fake_quantize_affine
torchao.quantization.quant_primitives.dequantize_affine
torchao.quantization.qat.FakeQuantizeConfig

For the following internal APIs (whose names begin with an underscore character), zero_point_domain can no longer be None (ZeroPointDomain.NONE should be used instead of None):

torchao.quantization.qat._ToAffineFakeQuantized

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 1 New Failure

As of commit cf90998 with merge base 47f96f1 ():

NEW FAILURE - The following job has failed:

• Run Float8 Tests / test (H100, linux.aws.h100, --pre torch torchvision torchaudio --index-url https://download.pytor... / linux-job (gh)
  RuntimeError: Command

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

[jerryzh168]

LGTM

[sanchitintel]

Thanks for reviewing, @jerryzh168! I'll fix the lint error once other CI checks would complete.

[sanchitintel]

The UTs that failed are failing because of some Inductor codegen issues that have since been fixed, but the CI jobs used PyTorch v2.4. I'll skip some of those UTs, so that they'd run with PyTorch v2.5 & beyond instead.

Thanks!

[jerryzh168]

for https://github.com/pytorch/ao/actions/runs/12760810579/job/35567540271?pr=1556 you can install pre-commit

pip install pre-commit

and run it:

pre-commit run

then it will run the formatting before every git commit

[jerryzh168]

is there a change of behavior when you change zero_point_domain for None to ZeroPointDomain.NONE?

[sanchitintel]

Yes, input_zero_point would now be None. So, instead of removing that line, I now added self.assertIsNone(input_zero_point). Thanks!

[jerryzh168]

I see, so what is the meaning of zero_point_domain == None before?

[sanchitintel]

Looks like some APIs/implementations were creating/expecting a None zero_point when zero_point_domain ZeroPointDomain.NONE or None was used, while choose_qparams_affine was not.

[sanchitintel]

Hi @jerryzh168, is it possible that some torchao users' code may be expecting a non-None zero_point with zero_point_domain ZeroPointDomain.NONE/None, making this change BC-breaking for them? Thanks!

[drisspg]

I think that most usages of this function are internal to torchao so that its okay to BC break, you can add the label just to be sure

[sanchitintel]

Thanks for your advice, @drisspg!
Could you please help add such a label as GitHub isn't displaying an option to me for adding it? Thanks!

[jerryzh168]

I added a bc-breaking label, please also write a bc-breaking note similar to #1049

[sanchitintel]

Thanks again, @jerryzh168! I added a note & rebased the PR.

[jerryzh168]

LGTM, please rebase and land