keras-team/keras · error · ValueError

lora is already enabled. This can only be done once per laye

Error message

lora is already enabled. This can only be done once per layer.

What it means

EinsumDense.enable_lora() is intentionally one-shot: once lora_enabled is True it cannot be enabled again, because the LoRA A/B kernels and tracker state already exist. A second call raises this ValueError to prevent duplicating LoRA parameters.

Source

Thrown at keras/src/layers/core/einsum_dense.py:345

    def enable_lora(
        self,
        rank,
        lora_alpha=None,
        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 appropriate (unpacked) kernel shape for LoRA.
        if self.quantization_mode == "int4":
            # INT4 weights are stored in a flattened 2D layout that loses
            # the original N-dimensional structure required by the einsum
            # equation. We use `original_kernel_shape`` to ensure LoRA adapters
            # operate in the correct logical dimension space.
            kernel_shape_for_lora = tuple(self.original_kernel_shape)
        else:
            kernel_shape_for_lora = self.kernel.shape

        # LoRA weights should be float32 to avoid the risk of underflow or

View on GitHub (pinned to 7a34a03db6)

Solutions

  1. Guard the call: if not layer.lora_enabled: layer.enable_lora(...).
  2. Move enable_lora into one-time model construction code so it is not re-run on resume.
  3. If you intended a fresh LoRA, rebuild the layer/model instead of re-enabling on the existing one.

Example fix

# before
for epoch in range(epochs):
    layer.enable_lora(rank=8)  # second iteration raises

# after
if not layer.lora_enabled:
    layer.enable_lora(rank=8)
Defensive patterns

Strategy: type-guard

Validate before calling

if not layer.lora_enabled:
    layer.enable_lora(rank)

Type guard

def lora_ready(layer) -> bool:
    return layer.built and not layer.lora_enabled and layer.kernel_constraint is None

Prevention

When it happens

Trigger: Calling layer.enable_lora(...) twice on the same layer object; a training loop that re-runs a setup function each epoch or restart; re-invoking a LoRA-setup helper after resuming from a checkpoint that already had LoRA enabled.

Common situations: Notebook re-execution of a setup cell; idempotency-unaware training scripts that call enable_lora on every resume; a setup function called per-fold or per-run on the same layer.

Related errors


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