|
| 1 | +# The Comfy guide to Quantization |
| 2 | + |
| 3 | + |
| 4 | +## How does quantization work? |
| 5 | + |
| 6 | +Quantization aims to map a high-precision value x_f to a lower precision format with minimal loss in accuracy. These smaller formats then serve to reduce the models memory footprint and increase throughput by using specialized hardware. |
| 7 | + |
| 8 | +When simply converting a value from FP16 to FP8 using the round-nearest method we might hit two issues: |
| 9 | +- The dynamic range of FP16 (-65,504, 65,504) far exceeds FP8 formats like E4M3 (-448, 448) or E5M2 (-57,344, 57,344), potentially resulting in clipped values |
| 10 | +- The original values are concentrated in a small range (e.g. -1,1) leaving many FP8-bits "unused" |
| 11 | + |
| 12 | +By using a scaling factor, we aim to map these values into the quantized-dtype range, making use of the full spectrum. One of the easiest approaches, and common, is using per-tensor absolute-maximum scaling. |
| 13 | + |
| 14 | +``` |
| 15 | +absmax = max(abs(tensor)) |
| 16 | +scale = amax / max_dynamic_range_low_precision |
| 17 | +
|
| 18 | +# Quantization |
| 19 | +tensor_q = (tensor / scale).to(low_precision_dtype) |
| 20 | +
|
| 21 | +# De-Quantization |
| 22 | +tensor_dq = tensor_q.to(fp16) * scale |
| 23 | +
|
| 24 | +tensor_dq ~ tensor |
| 25 | +``` |
| 26 | + |
| 27 | +Given that additional information (scaling factor) is needed to "interpret" the quantized values, we describe those as derived datatypes. |
| 28 | + |
| 29 | + |
| 30 | +## Quantization in Comfy |
| 31 | + |
| 32 | +``` |
| 33 | +QuantizedTensor (torch.Tensor subclass) |
| 34 | + ↓ __torch_dispatch__ |
| 35 | +Two-Level Registry (generic + layout handlers) |
| 36 | + ↓ |
| 37 | +MixedPrecisionOps + Metadata Detection |
| 38 | +``` |
| 39 | + |
| 40 | +### Representation |
| 41 | + |
| 42 | +To represent these derived datatypes, ComfyUI uses a subclass of torch.Tensor to implements these using the `QuantizedTensor` class found in `comfy/quant_ops.py` |
| 43 | + |
| 44 | +A `Layout` class defines how a specific quantization format behaves: |
| 45 | +- Required parameters |
| 46 | +- Quantize method |
| 47 | +- De-Quantize method |
| 48 | + |
| 49 | +```python |
| 50 | +from comfy.quant_ops import QuantizedLayout |
| 51 | + |
| 52 | +class MyLayout(QuantizedLayout): |
| 53 | + @classmethod |
| 54 | + def quantize(cls, tensor, **kwargs): |
| 55 | + # Convert to quantized format |
| 56 | + qdata = ... |
| 57 | + params = {'scale': ..., 'orig_dtype': tensor.dtype} |
| 58 | + return qdata, params |
| 59 | + |
| 60 | + @staticmethod |
| 61 | + def dequantize(qdata, scale, orig_dtype, **kwargs): |
| 62 | + return qdata.to(orig_dtype) * scale |
| 63 | +``` |
| 64 | + |
| 65 | +To then run operations using these QuantizedTensors we use two registry systems to define supported operations. |
| 66 | +The first is a **generic registry** that handles operations common to all quantized formats (e.g., `.to()`, `.clone()`, `.reshape()`). |
| 67 | + |
| 68 | +The second registry is layout-specific and allows to implement fast-paths like nn.Linear. |
| 69 | +```python |
| 70 | +from comfy.quant_ops import register_layout_op |
| 71 | + |
| 72 | +@register_layout_op(torch.ops.aten.linear.default, MyLayout) |
| 73 | +def my_linear(func, args, kwargs): |
| 74 | + # Extract tensors, call optimized kernel |
| 75 | + ... |
| 76 | +``` |
| 77 | +When `torch.nn.functional.linear()` is called with QuantizedTensor arguments, `__torch_dispatch__` automatically routes to the registered implementation. |
| 78 | +For any unsupported operation, QuantizedTensor will fallback to call `dequantize` and dispatch using the high-precision implementation. |
| 79 | + |
| 80 | + |
| 81 | +### Mixed Precision |
| 82 | + |
| 83 | +The `MixedPrecisionOps` class (lines 542-648 in `comfy/ops.py`) enables per-layer quantization decisions, allowing different layers in a model to use different precisions. This is activated when a model config contains a `layer_quant_config` dictionary that specifies which layers should be quantized and how. |
| 84 | + |
| 85 | +**Architecture:** |
| 86 | + |
| 87 | +```python |
| 88 | +class MixedPrecisionOps(disable_weight_init): |
| 89 | + _layer_quant_config = {} # Maps layer names to quantization configs |
| 90 | + _compute_dtype = torch.bfloat16 # Default compute / dequantize precision |
| 91 | +``` |
| 92 | + |
| 93 | +**Key mechanism:** |
| 94 | + |
| 95 | +The custom `Linear._load_from_state_dict()` method inspects each layer during model loading: |
| 96 | +- If the layer name is **not** in `_layer_quant_config`: load weight as regular tensor in `_compute_dtype` |
| 97 | +- If the layer name **is** in `_layer_quant_config`: |
| 98 | + - Load weight as `QuantizedTensor` with the specified layout (e.g., `TensorCoreFP8Layout`) |
| 99 | + - Load associated quantization parameters (scales, block_size, etc.) |
| 100 | + |
| 101 | +**Why it's needed:** |
| 102 | + |
| 103 | +Not all layers tolerate quantization equally. Sensitive operations like final projections can be kept in higher precision, while compute-heavy matmuls are quantized. This provides most of the performance benefits while maintaining quality. |
| 104 | + |
| 105 | +The system is selected in `pick_operations()` when `model_config.layer_quant_config` is present, making it the highest-priority operation mode. |
| 106 | + |
| 107 | + |
| 108 | +## Checkpoint Format |
| 109 | + |
| 110 | +Quantized checkpoints are stored as standard safetensors files with quantized weight tensors and associated scaling parameters, plus a `_quantization_metadata` JSON entry describing the quantization scheme. |
| 111 | + |
| 112 | +The quantized checkpoint will contain the same layers as the original checkpoint but: |
| 113 | +- The weights are stored as quantized values, sometimes using a different storage datatype. E.g. uint8 container for fp8. |
| 114 | +- For each quantized weight a number of additional scaling parameters are stored alongside depending on the recipe. |
| 115 | +- We store a metadata.json in the metadata of the final safetensor containing the `_quantization_metadata` describing which layers are quantized and what layout has been used. |
| 116 | + |
| 117 | +### Scaling Parameters details |
| 118 | +We define 4 possible scaling parameters that should cover most recipes in the near-future: |
| 119 | +- **weight_scale**: quantization scalers for the weights |
| 120 | +- **weight_scale_2**: global scalers in the context of double scaling |
| 121 | +- **pre_quant_scale**: scalers used for smoothing salient weights |
| 122 | +- **input_scale**: quantization scalers for the activations |
| 123 | + |
| 124 | +| Format | Storage dtype | weight_scale | weight_scale_2 | pre_quant_scale | input_scale | |
| 125 | +|--------|---------------|--------------|----------------|-----------------|-------------| |
| 126 | +| float8_e4m3fn | float32 | float32 (scalar) | - | - | float32 (scalar) | |
| 127 | + |
| 128 | +You can find the defined formats in `comfy/quant_ops.py` (QUANT_ALGOS). |
| 129 | + |
| 130 | +### Quantization Metadata |
| 131 | + |
| 132 | +The metadata stored alongside the checkpoint contains: |
| 133 | +- **format_version**: String to define a version of the standard |
| 134 | +- **layers**: A dictionary mapping layer names to their quantization format. The format string maps to the definitions found in `QUANT_ALGOS`. |
| 135 | + |
| 136 | +Example: |
| 137 | +```json |
| 138 | +{ |
| 139 | + "_quantization_metadata": { |
| 140 | + "format_version": "1.0", |
| 141 | + "layers": { |
| 142 | + "model.layers.0.mlp.up_proj": "float8_e4m3fn", |
| 143 | + "model.layers.0.mlp.down_proj": "float8_e4m3fn", |
| 144 | + "model.layers.1.mlp.up_proj": "float8_e4m3fn" |
| 145 | + } |
| 146 | + } |
| 147 | +} |
| 148 | +``` |
| 149 | + |
| 150 | + |
| 151 | +## Creating Quantized Checkpoints |
| 152 | + |
| 153 | +To create compatible checkpoints, use any quantization tool provided the output follows the checkpoint format described above and uses a layout defined in `QUANT_ALGOS`. |
| 154 | + |
| 155 | +### Weight Quantization |
| 156 | + |
| 157 | +Weight quantization is straightforward - compute the scaling factor directly from the weight tensor using the absolute maximum method described earlier. Each layer's weights are quantized independently and stored with their corresponding `weight_scale` parameter. |
| 158 | + |
| 159 | +### Calibration (for Activation Quantization) |
| 160 | + |
| 161 | +Activation quantization (e.g., for FP8 Tensor Core operations) requires `input_scale` parameters that cannot be determined from static weights alone. Since activation values depend on actual inputs, we use **post-training calibration (PTQ)**: |
| 162 | + |
| 163 | +1. **Collect statistics**: Run inference on N representative samples |
| 164 | +2. **Track activations**: Record the absolute maximum (`amax`) of inputs to each quantized layer |
| 165 | +3. **Compute scales**: Derive `input_scale` from collected statistics |
| 166 | +4. **Store in checkpoint**: Save `input_scale` parameters alongside weights |
| 167 | + |
| 168 | +The calibration dataset should be representative of your target use case. For diffusion models, this typically means a diverse set of prompts and generation parameters. |
0 commit comments