ONNX Runtime: cross-platform, high performance ML inferencing and training accelerator
Find a file
Adrian Lizarraga cdc5d72ba9
[QDQ Quant] Support mixed-precision integer quantization via overrides (#19925)
### Description
Adds support for specifying mixed precision QDQ models via tensor
quantization overrides.



### Motivation and Context
This PR implements an approach for supported "mixed precision" models.
The following figure demonstrates an example mixed precision model as
defined in this PR.


![image](https://github.com/microsoft/onnxruntime/assets/19691973/40ae3bf9-b21a-4ba5-a1cd-41c1e08c21e7)

A mixed precision QDQ model consists of regions with different
activation/weight quantization data types. The boundary between regions
converts between activation quantization data types (e.g., uint8 to
uint16) using a DQ to Q sequence.

The ability to specify regions with different quantization data types
enables exploring the tradeoffs between accuracy and latency. A higher
integer precision may improve accuracy at the expense of latency, so
selectively promoting certain regions to a higher precision can aid in
achieving a desirable balance in key metrics.

#### Current support
By default, the ORT quantizer supports specifying default activation and
weight quantization data types for the entire model. A recent PR added
support for specifying basic quantization overrides at the tensor level
via the `extra_options["TensorQuantOverrides"]` configuration:

```
TensorQuantOverrides = dictionary :
    Default is {}. Set tensor quantization overrides. The key is a tensor name and the value is a
    list of dictionaries. For per-tensor quantization, the list contains a single dictionary. For
    per-channel quantization, the list contains a dictionary for each channel in the tensor.
    Each dictionary contains optional overrides with the following keys and values.
           'quant_type' = QuantType : The tensor's quantization data type.
           'scale' =  Float         : The scale value to use. Must also specify `zero_point` if set.
           'zero_point' = Int       : The zero-point value to use. Must also specify `scale` is set.
           'symmetric' = Bool       : If the tensor should use symmetric quantization. Invalid if also
                                      set `scale` or `zero_point`.
           'reduce_range' = Bool    : If the quantization range should be reduced. Invalid if also
                                      set `scale` or `zero_point`.
           'rmax' = Float           : Override the maximum real tensor value in calibration data.
                                      Invalid if also set `scale` or `zero_point`.
           'rmin' = Float           : Override the minimum real tensor value in calibration data.
                                      Invalid if also set `scale` or `zero_point`.
```
The tensor-level overrides are currently used to override the
quantization type for weights/initializers or to set specific
scale/zero-point values for a tensor (e.g., QNN requires Sigmoid to use
a specific scale/zero-point at its output).

However, these overrides are not typically used to override activation
quantization types due in large part to operator data type constraints.
Consider, for example, that all inputs and outputs to an Add operator
must be of the same data type. Consequently, using tensor-level
overrides to promote the Add’s output to 16-bits would force the inputs
to also be overridden to 16-bit. In turn, this would have a cascading
effect on potentially the entire graph. The solution implemented by this
PR is to allow the specification of tensor boundaries where the
activation quantization data type changes.

#### The approach
The following figure shows a model with a region that has been promoted
to 16-bit from the default 8-bit activation type.


![image](https://github.com/microsoft/onnxruntime/assets/19691973/5998c301-ae20-4ac9-8a43-37f335cfcf8b)

Note the following observations:
- Op2’s output is consumed by Op4, Op7, and Op8. Op4 consumes the
converted u16 type, while Op7 and Op8 consume the original u8 type.
- Op3’s output is converted from u8 to u16. Op5 consumes the converted
u16 type.
 - Op4’s output is just u16 (not converted).
 - Op5’s output is converted from u16 to u8. Op6 consumes the u8 type.

The approach implemented by this PR uses the tensor-level quantization
overrides to specify a tensor’s quantization type at both the producer
and consumer ends. **The following shows the overrides necessary to
create this mixed precision QDQ model.**

```python3
overrides = {
  “Op2_out”: [{“quant_type”: QUInt8, “convert”: {“quant_type”: QUInt16, “recv_nodes”: {“Op4”}}}],
  “Op3_out”: [{“quant_type”: QUInt8, “convert”: {“quant_type”: QUInt16, “recv_nodes”: {“Op5”}}}],
  “Op4_out”: [{“quant_type”: QUInt16}],
  “Op5_out”: [{“quant_type”: QUInt16, “convert”: {“quant_type”: QUInt8, “recv_nodes”: {“Op6”}}}]
}
```
2024-03-23 11:05:08 -07:00
.config
.devcontainer
.gdn Update win-ci-pipeline.yml: enable xnnpack tests (#16244) 2023-06-14 19:12:42 -07:00
.github Use Java 11 to build project in the codeql pipeline (#19999) 2024-03-20 17:53:48 -07:00
.pipelines Upgrade the Windows SDK version that is used in WindowsAI Nuget Packaging pipeline (#19786) 2024-03-06 09:10:35 -08:00
.vscode disable gemm f16 on CPU (#19744) 2024-03-01 13:44:29 -08:00
cgmanifests turn on neural_speed by default (#19627) 2024-03-20 12:49:58 -07:00
cmake Make MS Debug engine SymInitialize() called as needed. (#20036) 2024-03-22 16:17:47 -07:00
csharp Update MAUI model tester tool to .net8 (#19907) 2024-03-14 15:19:19 +10:00
dockerfiles Ort openvino npu 1.17 master (#19966) 2024-03-21 18:44:00 -07:00
docs [MoE] Add TP and Mixtral MoE (#19945) 2024-03-19 21:28:15 -07:00
include/onnxruntime/core Implement CustomOp Output Type Inference function (#19906) 2024-03-18 10:28:39 -07:00
java [java] Adding ML program flag for CoreML (#19551) 2024-02-21 12:24:41 -08:00
js [js/webgpu] fix maxpool / fp16 (#19981) 2024-03-19 16:15:49 -07:00
objectivec [objc] Add check for ORTValue being a tensor in ORTValue methods that should only be used with tensors. (#19946) 2024-03-18 08:54:24 -07:00
onnxruntime [QDQ Quant] Support mixed-precision integer quantization via overrides (#19925) 2024-03-23 11:05:08 -07:00
orttraining Support model with multiple SCE loss nodes (#20016) 2024-03-22 10:28:44 -07:00
rust Fix rust compile issues and add GH action to run build validations and tests (#18346) 2023-11-09 04:26:02 -08:00
samples Removed all the deprecated python training code and related tests and utils (#18333) 2023-11-17 18:19:21 -08:00
tools Ort openvino npu 1.17 master (#19966) 2024-03-21 18:44:00 -07:00
winml Replace some old file system calls with C++17 std::filesystem APIs. (#19196) 2024-03-09 09:17:36 -08:00
.clang-format Prevent GSL_SUPPRESS arguments from being modified by clang-format (#17242) 2023-08-22 18:26:53 -07:00
.clang-tidy
.dockerignore
.gitattributes
.gitignore Build onnxruntime.dll as arm64x (#18633) 2023-12-06 16:49:00 -08:00
.gitmodules update to emsdk-3.1.51 (#18844) 2024-01-12 16:04:33 -08:00
.lintrunner.toml Adding cuda kernel (optimized for sm80) for block-wise 4b quantized float 16 GEMM. (#18619) 2024-03-05 09:37:45 -08:00
build.bat try to find patch.exe in git default installation folder (#17106) 2023-08-10 21:48:13 -07:00
build.sh Upgrade old Python version in packaging pipeline (#16667) 2023-07-17 08:24:47 -07:00
build_arm64x.bat remove unnecessary environment variable (#19166) 2024-01-16 16:24:37 -08:00
CITATION.cff Fix citation author name issue (#19597) 2024-02-22 17:03:56 -08:00
CODEOWNERS Add owners for public facing API files (#15288) 2023-03-30 17:16:15 -07:00
CONTRIBUTING.md Fix link to High Level Design (#11786) 2023-02-28 11:05:54 -08:00
lgtm.yml
LICENSE
NuGet.config
ort.wprp ORT ETW dynamic logging that improves ORT diagnosability & performance (#18882) 2024-01-11 12:43:27 -08:00
ORT_icon_for_light_bg.png
packages.config Update DirectML nuget version to 1.13.1 (#19122) 2024-01-15 19:04:41 -08:00
pyproject.toml Bump ruff to 0.3.2 and black to 24 (#19878) 2024-03-13 10:00:32 -07:00
README.md Update README.md (#18963) 2024-01-03 17:26:25 -08:00
requirements-dev.txt ONNX 1.15 integration (#17125) 2023-09-26 14:44:48 -07:00
requirements-doc.txt
requirements-lintrunner.txt Bump ruff to 0.3.2 and black to 24 (#19878) 2024-03-13 10:00:32 -07:00
requirements-training.txt ONNX 1.15 integration (#17125) 2023-09-26 14:44:48 -07:00
requirements.txt.in
SECURITY.md
setup.py Add cann_dependencies (#19929) 2024-03-15 20:28:43 -07:00
ThirdPartyNotices.txt Update ThirdPartyNotices.txt: Add Intel neural-speed (#19332) 2024-01-30 12:40:30 -08:00
VERSION_NUMBER [ORT 1.17.0 release] Bump up version to 1.18.0 (#19170) 2024-01-17 11:18:32 -08:00

ONNX Runtime is a cross-platform inference and training machine-learning accelerator.

ONNX Runtime inference can enable faster customer experiences and lower costs, supporting models from deep learning frameworks such as PyTorch and TensorFlow/Keras as well as classical machine learning libraries such as scikit-learn, LightGBM, XGBoost, etc. ONNX Runtime is compatible with different hardware, drivers, and operating systems, and provides optimal performance by leveraging hardware accelerators where applicable alongside graph optimizations and transforms. Learn more →

ONNX Runtime training can accelerate the model training time on multi-node NVIDIA GPUs for transformer models with a one-line addition for existing PyTorch training scripts. Learn more →

Get Started & Resources

Builtin Pipeline Status

System Inference Training
Windows Build Status
Build Status
Build Status
Linux Build Status
Build Status
Build Status
Build Status
Build Status
Build Status
Build Status
Build Status
Mac Build Status
Android Build Status
iOS Build Status
Web Build Status
Other Build Status

Third-party Pipeline Status

System Inference Training
Linux Build Status

Data/Telemetry

Windows distributions of this project may collect usage data and send it to Microsoft to help improve our products and services. See the privacy statement for more details.

Contributions and Feedback

We welcome contributions! Please see the contribution guidelines.

For feature requests or bug reports, please file a GitHub Issue.

For general discussion or questions, please use GitHub Discussions.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

License

This project is licensed under the MIT License.