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 orView on GitHub (pinned to 7a34a03db6)
Solutions
- Guard the call: if not layer.lora_enabled: layer.enable_lora(...).
- Move enable_lora into one-time model construction code so it is not re-run on resume.
- 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
- Make setup code idempotent: check lora_enabled first.
- Call enable_lora once at model construction, not inside the training loop.
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
- Lora is incompatible with kernel constraints. In order to en
- Cannot enable lora on a layer that isn't yet built.
- lora is already enabled. This can only be done once per laye
- lora is not currently supported with GPTQ quantization.
- Currently, `_float8_call` doesn't support LoRA
AI-assisted analysis of keras-team/keras@7a34a03db6 (2026-08-25).
Data as JSON: /api/errors/67fe565612800ba5.
Report an issue: GitHub.