Some primitives in the library support input/output tensors with the INT8 (either signed or unsigned) data type. The primary goal is to support reduced precision inference on the compatible hardware.
Related materials:
The primary quantization model that the library assumes is the following:
\[ x_{f32}(:) = scale_{f32} \cdot (x_{int8}(:) - 0_{x\_int8}) \]
where \(scale_{f32}\) is somehow known in advance (typically, the process of obtaining these scale factors is called the calibration process). This might be counter-intuitive, but the library cannot compute any of the scale factors at run-time dynamically. Hence, the model is sometimes called a static quantization model. The main rationale to support only static quantization out-of-the-box is higher performance. Those who want to use dynamic quantization can do so in a few steps:
It is also worth mentioning that the library supports fixed zero position. For most of the primitives, real zero value is mapped to zero for quantized values; that is, \(0_{x\_int8} = 0\). For example, this is the only model that Convolution and Inner Product currently support. The RNN primitives have limited support of shifted zero (for details, refer to the corresponding section in RNN).
For the rest of this guide, we will assume that \(0_{x\_int8} = 0\).
This guide doesn't cover how the appropriate scaling factor can be found. Refer to the materials in the Introduction.
Let's consider a simple example: a convolution without bias. The tensors are represented as:
Here the \(src_{f32}, weights_{f32}, dst_{f32}\) are not computed at all, the whole work happens with INT8 tensors. As mentioned above, we also somehow know all the scaling factors: \(scale_{src}, scale_{weights}, scale_{dst}\).
So the task is to compute the \(dst_{int8}\) tensor.
Mathematically, the computations are pretty straightforward:
\[ dst_{int8}(:) = downconvert\_f32\_to\_int8( output\_scale \cdot conv_{s32}(src_{int8}, weights_{int8}) ), \]
where:
f32
value to s8
with potential saturation if the values are out of the range of the INT8 data type.Note that in order to perform the operation, one doesn't need to know the exact scaling factors for all the tensors; it is enough to know only the \(output\_scale\). The library utilizes this fact; a user needs to provide only this one extra parameter (see the Output Scaling Attribute section below) to perform the convolution.
Some of the primitives have limited support of multiple scales for a quantized tensor. The most popular use-case is a Convolution primitive that supports per-output-channel scaling factors for the weights, meaning that the actual convolution computations would need to scale different output channels differently. This is possible without significant performance drop because the per-output-channel re-quantization only required at the very end of the computations. It seems impossible to implement the same trick for the input channels, since that would require re-quantization for every input data point.
Assume we have (the scales are designated as \(\alpha\) to simplify reading):
Note that now the weights' scaling factor depends on the \(oc\).
To compute the \(dst_{int8}\) we need to perform the following:
\[ dst_{int8}(n, oc, oh, ow) = downconvert\_f32\_to\_int8( output\_scale(oc) \cdot conv_{s32}(src_{int8}, weights_{int8})|_{(n, oc, oh, ow)} ), \]
where now
It is worth mentioning that a user has to prepare quantized weights accordingly. For Intel MKL-DNN provides reorders that can perform per-channel scaling:
\[ weights_{int8}(oc, ic, kh, kw) = downconvert\_f32\_to\_int8( output\_scale(oc) \cdot weights_{f32}(oc, ic, kh, kw) ), \]
where:
The library API to support for INT8 was designed for the model described above. However, it doesn't require users to follow exactly this model. As long as users can fit their model into the given functionality everything should work fine. Having this in mind we tried to design a minimal and simple yet powerful enough quantization API.
The most common data type for data tensors during INT8 inference is mkldnn::memory::data_type::s8 and mkldnn::memory::data_type::u8. All the scaling factors related to tensors are not attached in any way to the Intel MKL-DNN memory objects and should be maintained by users.
The library essentially extends the ability of the primitives to scale the output before storing the result to the memory with the destination data type. That's exactly the minimum that we need to support INT8 inference (check the equations above–only \(output\_scale\) is non-standard).
The scaling happens in the single precision floating point data type (mkldnn::memory::data_type::f32). Before storing, the result is downconverted to the destination data type with saturation if required. The rounding happens according to the current HW setting (for instance, on CPU according to the MXCSR register).
The library uses Primitive Attributes API for setting the scaling factors for most of the primitives. The supporting attributes can be found in the documentation for each primitive. The unsupported cases are handled according to the attributes error handling section.
API:
The primitives do not support output scales if source (and weights) tensors are of the int8 data type. In other words, regular f32
convolution cannot scale the output result.
The parameters (C++ API for simplicity):
In the simplest case, when there is only one common scale the attribute changes the op behavior from
\[ dst(:) = Op(...) \]
to
\[ dst(:) = scale \cdot Op(...). \]
To support scales per one or several dimensions, users must set the appropriate mask.
Say the destination is \(D_0 \times ... \times D_{n-1}\) tensor and we want to have output scales per \(d_i\) dimension (where \(0 \le d_i < n\)).
Then the mask should be set to:
and the number of scales should be:
scales.size()
= \(\prod\limits_{d_i}D_{d_i}\).This example is complementary to the previous example (which should ideally be the first one). Let's say we want to have an INT8 convolution with per-output channel scaling.
In general, the post-ops are independent from the output scales. The output scales are applied to the result first; then post-ops will take effect.
For details, refer to the Tanh -> Sum -> ScaleShift example.
That has an implication on the scaling factors passed to the library, however. Consider the following example of a convolution with \(\tanh\) as a post-op:
\[ dst_{s8}(:) = \frac{1}{scale_{dst}} \cdot \tanh( scale_{src} \cdot scale_{weights} \cdot conv_{s32}(src_{s8}, wei_{s8}) ) \]
As you can see: