Package: quanto
QuantoDISCLAIMER: This package is still an early prototype (pre-beta version), and not (yet) an HuggingFace product. Expect breaking changes and drastic modifications in scope and features.🤗 Quanto is a python quantization toolkit that provides several features that are either not supported or limited by the basepytorch quantization tools:all features are available in eager mode (works with non-traceable models),quantized models can be placed on any device (including CUDA and MPS),automatically inserts quantization and dequantization stubs,automatically inserts quantized functional operations,automatically inserts quantized modules (see below the list of supported modules),provides a seamless workflow from a float model to a dynamic to a static quantized model,supports quantized model serialization as astate_dict,uses integer matrix multiplications (mm) on CUDA devices,supports not only int8 weights, but also int2 and int4,supports not only int8 activations, but also float8.Features yet to be implemented:quantize clone (quantization happens in-place for now),dynamic activations smoothing,integer batched matrix multiplications (bmm) on CUDA devices,integer matrix multiplications for CPU and MPS devices,quantized operators fusion (mmfollowed by dequantization is the most common use case),compatibility withtorch compiler(aka dynamo).Quantized modulesThanks to a seamless propagation mechanism through quantized tensors, only a few modules working as quantized
tensors insertion points are actually required.The following modules can be quantized:Linear(QLinear).
Weights are always quantized, and biases are not quantized. Inputs and outputs can be quantized.Conv2d(QConv2D).
Weights are always quantized, and biases are not quantized. Inputs and outputs can be quantized.LayerNorm,
Weights and biases arenotquantized. Outputs can be quantized.Limitations and design choicesTensorsAt the heart of quanto is a Tensor subclass that corresponds to:the projection of a source Tensor into the optimal range for a given destination type,the mapping of projected values to the destination type.For floating-point destination types, the mapping is done by the native pytorch cast (i.e.Tensor.to()).For integer destination types, the mapping is a simple rounding operation (i.e.torch.round()).The goal of the projection is to increase the accuracy of the conversion by minimizing the number of:saturated values (i.e. mapped to the destination type min/max),zeroed values (because they are below the smallest number that can be represented by the destination type)The projection is symmetric (affine), i.e. it does not use a zero-point. This makes quantized Tensors
compatible with many operations.One of the benefits of using a lower-bitwidth representation is that you will be able to take advantage of accelerated operations
for the destination type, which is typically faster than their higher precision equivalents.The current implementation however falls back tofloat32operations for a lot of operations because of a lack of dedicated kernels
(onlyint8matrix multiplication is available).Note: integer operations cannot be performed infloat16as a fallback because this format is very bad at representingintegerand will likely lead to overflows in intermediate calculations.Quanto does not support the conversion of a Tensor using mixed destination types.ModulesQuanto provides a generic mechanism to replace torch modules by quanto modules that are able to process quanto tensors.Quanto modules dynamically convert their weights until a model is frozen, which slows down inference a bit but is
required if the model needs to be tuned.Biases are not converted because to preserve the accuracy of a typicaladdmmoperation, they must be converted with a
scale that is equal to the product of the input and weight scales, which leads to a ridiculously small scale, and conversely
requires a very high bitwidth to avoid clipping. Typically, withint8inputs and weights, biases would need to be quantized
with at least12bits, i.e. inint16. Since most biases are todayfloat16, this is a waste of time.Activations are dynamically quantized using static scales (defaults to the range[-1, 1]). The model needs to be calibrated to evaluate the best activation scales (using a momentum).PerformancesDISCLAIMER: These are preliminary observations gathered from a panel of models, and not an actual performance report.In terms of accuracy:models using only int8 weights do not seem to suffer any drop in accuracy,models using also int8 activations do suffer from moderate to severe accuracy drops,using float8 activations can help in getting a better accuracy.In terms of speed:models using int8 weights only are very slightly slower than the original float model due to the weight dequantization,models using int8 activations are slightly slower on CUDA devices,models using int8 activations are significantly slower on CPU and MPS devices, where fallbacks are triggered.models using float8 activations are significantly slower on CUDA devices, where fallbacks are triggered.The disk space and on-device memory to store weights is:equivalent for a model with dynamic weights (weights are stored with full precision and quantized dynamically),approximately divided by float bits / integer bits for a model with static weights.InstallationQuanto is available as a pip package.pipinstallquantoQuantization workflowQuanto does not make a clear distinction between dynamic and static quantization: models are always dynamically quantized,
but their weights can later be "frozen" to integer values.A typical quantization workflow would consist of the following steps:1. QuantizeThe first step converts a standard float model into a dynamically quantized model.quantize(model,weights=quanto.qint8,activations=quanto.qint8)At this stage, only the inference of the model is modified to dynamically quantize the weights.2. Calibrate (optional if activations are not quantized)Quanto supports a calibration mode that allows to record the activation ranges while passing representative samples through the quantized model.withcalibration(momentum=0.9):model(samples)This automatically activates the quantization of the activations in the quantized modules.3. Tune, aka Quantization-Aware-Training (optional)If the performance of the model degrades too much, one can tune it for a few epochs to recover the float model performance.model.train()forbatch_idx,(data,target)inenumerate(train_loader):data,target=data.to(device),target.to(device)optimizer.zero_grad()output=model(data).dequantize()loss=torch.nn.functional.nll_loss(output,target)loss.backward()optimizer.step()4. Freeze integer weightsWhen freezing a model, its float weights are replaced by quantized integer weights.freeze(model)Please refer to theexamplesfor instantiations of that workflow.Per-axis versus per-tensorActivations are always quantized per-tensor because most linear algebra operations in a model graph are not compatible with per-axis inputs: you simply cannot add numbers that are not expressed in the same base (you cannot add apples and oranges).Weights involved in matrix multiplications are, on the contrary, always quantized along their first axis, because all output features are evaluated independently from one another.The outputs of a quantized matrix multiplication will anyway always be dequantized, even if activations are quantized, because:the resulting integer values are expressed with a much higher bitwidth (typicallyint32) than the activation bitwidth (typicallyint8),they might be combined with afloatbias.Quantizing activations per-tensor can lead to serious quantization errors if the corresponding tensors contain large outlier values. Typically, this will lead to quantized tensors with most values set to zero (except the outliers).A possible solution to work around that issue is to 'smooth' the activations statically as illustrated bySmoothQuant. You can find a script to smooth some model architectures underexternal/smoothquant.A better option, often, is to represent activations usingfloat8instead ofint8.