Propose to remove WPT conformance tests with negative scale of dequantizeLinear and quantizeLinear operator

[BruceDai]

According to Quantize ONNX Models, there's below message

scale is a positive real number used to map the floating point numbers to a quantization space.

And we also investigate current LLM Quantize Models, there's no case of using negative scale for quantizeLinear operator.

So I propose to remove those WPT conformance tests with negative scale.

@fdwr @huningxin @reillyeon Any suggestions? Thanks!

[fdwr]

I guess we need to answer a few questions:

• Are they mathematically valid?
• Are they found in the wild?
• Do all backends support them?

Are they mathematically valid?

Yes, and it's elegant for an operator's output to be equivalent to that operator's decomposition (and useful for conformance testing and a ground truth).

Are they found in the wild?

Evidently they can appear in generated models (microsoft/onnxruntime-genai#1051):

When quantizing to INT4 precision, the model builder assumes that the scales are symmetric. When is_symmetric = True, the scales can be positive or negative.

So positive and negatives scales could be meaningful in certain contexts, such as symmetric quantization around zero or when modeling signed data distributions. Granted, ONNX says they should be positive, but the fact remains that they can be emitted and successfully execute with some ORT EP's.

Do all backends support them?

• ORT, from the above Phi-3 mini issue fails with some execution providers, whereas others work correctly like the DML EP. OpenVINO EP?
• CoreML rejects negative scale values ((de)quantization behaviors on CoreML #822). If CoreML just removed the validation and permitted them through, it would probably compute the correct result.
• TF accepts negative scales fine (see below).

Verdict

Positive and negatives scales are evidently useful in certain contexts, but also they're not widely supported by all the backends which WebNN targets, requiring either we:

• leave them as implementation defined. We can't really validate negative scales ahead of time because we'd have to inspect every scale value in the uploaded GPU resource, and we can't prevent them from reaching backends unless we relu them.
• decompose the dequantizeLinear call if a backend/EP doesn't support negative values, but that slows performance compared to the built-in operator to always decompose just because there might be some negative values.

So from the math viability/consistency and utility perspective, I favor supporting them, but from the performance and rarity perspective, I favor not supporting them (and possibly even forcibly relu'ing the scale tensors if backends would fail execution during dispatch). ⚖️ Maybe we can support them officially later when/if more backends do.

Reference

# Negative scale via inverted min/max.
import tensorflow as tf

input     = tf.constant([[1,2],[3,4]], dtype=tf.quint8)
min_range = tf.constant(3, dtype=tf.float32)
max_range = tf.constant(1, dtype=tf.float32)
output = tf.quantization.dequantize(
    input,
    min_range,
    max_range,
    mode='MIN_COMBINED',
    name=None,
    axis=None,
    narrow_range=False,
    dtype=tf.dtypes.float32
)

print("value:", output)
print("shape:", output.shape)

[reillyeon]

It's also important to note that CoreML requires quantization parameters to be known at compile time and it sounds like while OpenVINO might handle the case of a non-constant scale it might fail to compile if it is constant and negative. There's a separate discussion about whether to express requirements that an input be constant in opSupportLimits or always decompose the operator in that case.