keras-team/keras · error · NotImplementedError

lora is not currently supported with GPTQ quantization.

Error message

lora is not currently supported with GPTQ quantization.

What it means

enable_lora() does not support GPTQ-quantized layers: GPTQ stores a packed int4 kernel whose dimensions don't match the float kernel LoRA needs, so the LoRA A-matrix cannot be sized against it. NotImplementedError fires before any LoRA state is created.

Source

Thrown at keras/src/layers/core/dense.py:273

        a_initializer="he_uniform",
        b_initializer="zeros",
    ):
        if self.kernel_constraint:
            raise ValueError(
                "Lora is incompatible with kernel constraints. "
                "In order to enable lora on this layer, remove the "
                "`kernel_constraint` argument."
            )
        if not self.built:
            raise ValueError(
                "Cannot enable lora on a layer that isn't yet built."
            )
        if self.lora_enabled:
            raise ValueError(
                "lora is already enabled. This can only be done once per layer."
            )
        if self.quantization_mode == "gptq":
            raise NotImplementedError(
                "lora is not currently supported with GPTQ quantization."
            )
        self._tracker.unlock()
        # Determine the correct input dimension for the LoRA A matrix. When
        # the layer has been int4-quantized, `self._kernel` stores a *packed*
        # representation whose first dimension is `ceil(input_dim/2)`. We
        # saved the true, *unpacked* input dimension in `self._orig_input_dim`
        # during quantization. Use it if available; otherwise fall back to the
        # first dimension of `self.kernel`.
        if self.quantization_mode == "int4" and hasattr(
            self, "_orig_input_dim"
        ):
            input_dim_for_lora = self._orig_input_dim
        else:
            input_dim_for_lora = self.kernel.shape[0]

        # LoRA weights should be float32 to avoid the risk of underflow or
        # overflow during fine-tuning.

View on GitHub (pinned to 7a34a03db6)

Solutions

Skip GPTQ layers during injection: if layer.quantization_mode == 'gptq': continue.
Use int8 or unquantized layers for LoRA fine-tuning instead of GPTQ.
Check layer.quantization_mode in your LoRA utility before calling enable_lora.

Example fix

# before
for layer in model.layers:
    layer.enable_lora(8)  # raises NotImplementedError on gptq layers

# after
for layer in model.layers:
    if getattr(layer, 'quantization_mode', None) != 'gptq':
        layer.enable_lora(8)

Defensive patterns

Strategy: validation

Validate before calling

for layer in model.layers:
    if getattr(layer, 'quantization_mode', None) == 'gptq':
        continue
    layer.enable_lora(rank)

Type guard

def lora_supported(layer) -> bool:
    return getattr(layer, 'quantization_mode', None) != 'gptq'

Try / catch

try:
    layer.enable_lora(rank)
except NotImplementedError:
    pass  # unsupported quantization; skip layer

Prevention

Filter by quantization_mode before enable_lora
Prefer int8 or unquantized layers for LoRA

When it happens

Trigger: Calling enable_lora() on a Dense layer whose quantization_config uses mode='gptq' — e.g. LoRA-injecting a model quantized for GPTQ.

Common situations: QLoRA-style workflows where developers quantize with GPTQ then try to add LoRA; blanket enable_lora loops that don't check quantization_mode.

Related errors

AI-assisted analysis of keras-team/keras@7a34a03db6 (2026-08-25). Data as JSON: /api/errors/ae7d19d24e94e1c7. Report an issue: GitHub.