Misc. bug: convert_lora_to_gguf.py error: AttributeError: 'LoraTorchTensor' object has no attribute 'contiguous'

[Lairs]

Name and Version

llama.cpp$ git reset --hard
HEAD is now at deee238 vulkan: add GATED_DELTA_NET op support (#20334)

Operating systems

Linux

Which llama.cpp modules do you know to be affected?

Documentation/Github

Command line

python convert_lora_to_gguf.py ./Solo_qwen35_lora/checkpoint-123 --outfile ./20260312_qwen3.5_lora.gguf --base ./base/Solo_qwen35 --outtype bf16

Problem description & steps to reproduce

We trained lora with qwen3.5, want to convert lora weight(safetensors), when we convert with the command, the error message is:
INFO:lora-to-gguf:Exporting model...
Traceback (most recent call last):
File "/home/user/llama.cpp/convert_lora_to_gguf.py", line 492, in
model_instance.write()
File "/home/user/llama.cpp/convert_hf_to_gguf.py", line 852, in write
self.prepare_tensors()
File "/home/user/llama.cpp/convert_hf_to_gguf.py", line 4512, in prepare_tensors
super().prepare_tensors()
File "/home/user/llama.cpp/convert_hf_to_gguf.py", line 718, in prepare_tensors
for new_name, data_torch in (self.modify_tensors(data_torch, name, bid)):
File "/home/user/llama.cpp/convert_lora_to_gguf.py", line 449, in modify_tensors
dest = list(super().modify_tensors(data_torch, name, bid))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/llama.cpp/convert_hf_to_gguf.py", line 4979, in modify_tensors
data_torch = self._reorder_v_heads(data_torch, 0, num_k_heads, num_v_per_k, 1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/llama.cpp/convert_hf_to_gguf.py", line 4952, in _reorder_v_heads
return tensor.permute(*perm).contiguous().reshape(*shape)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'LoraTorchTensor' object has no attribute 'contiguous'

we convert other model(qwen2.5, qwen3) before, it works fine, does anyone encounter same issue with qwen3.5 model?

First Bad Commit

No response

Relevant log output

No response

[CISC]

While adding contiguous support to LoraTorchTensor would fix conversion it looks like you have LoRA weights on ssm_conv1d, which does not support LoRA during inference...

[Lairs]

While adding contiguous support to LoraTorchTensor would fix conversion it looks like you have LoRA weights on ssm_conv1d, which does not support LoRA during inference...

Thanks for reply, when training qwen3.5, we install flash-linear-attention:v0.4.1, https://pypi.org/project/flash-linear-attention/
Following ssm_conv1d, I googled ssm_conv1d, the result is causal-conv1d, and flash-linear-attention mention about causal-conv1d in the github repo.

flash-linear-attention also released v0.4.2, we will update the package and try again, check convert_lora_to_gguf.py work or not.
if not work, we will uninstall flash-linear-attention and try again.

[Lairs]

Updates:
upgrade flash-linear-attention to v0.4.2, convert the lora check point, same error message: AttributeError: 'LoraTorchTensor' object has no attribute 'contiguous'
uninstall flash-linear-attention and start training, the training tool display message:

The fast path is not available because one of the required library is not installed. Falling back to torch implementation. To install follow https://github.com/fla-org/flash-linear-attention#installation and https://github.com/Dao-AILab/causal-conv1d

and the training time from 8 hours to 60 hours, and I tested the checkpoint, still get same error message: AttributeError: 'LoraTorchTensor' object has no attribute 'contiguous'

Based on the testing results above, it appears that AttributeError: 'LoraTorchTensor' object has no attribute 'contiguous' is not caused by the acceleration kits.
Instead, it suggests that the model architecture itself may contain certain layers that do not support LoRA inference.

Still looking for solution.

[Lairs]

Solved:
When we checking the lora checkpoint adapter_config.json, the target_modules is:

  "target_modules": [
    "out_proj",
    "up_proj",
    "in_proj_qkv",
    "qkv",
    "o_proj",
    "linear_fc1",
    "in_proj_a",
    "linear_fc2",
    "in_proj_z",
    "q_proj",
    "k_proj",
    "in_proj_b",
    "proj",
    "down_proj",
    "gate_proj",
    "v_proj"
  ]

but our training setting is:

lora_target_modules:
  - q_proj
  - k_proj
  - v_proj
  - o_proj
  - up_proj
  - down_proj
  - gate_proj
lora_target_linear: true

so we assume the lora_target_linear somehow automatically add the layers that LoRA not support even the layers are linear.
After testing different configs, the final config:

lora_target_modules:
  - q_proj
  - k_proj
  - v_proj
  - o_proj
  - up_proj
  - down_proj

The testing checkpoint can be converted to gguf by convert_lora_to_gguf.py, cheers!
We will proceed with training the LoRA.
While the actual inference performance is still pending verification, the functionality for converting safetensors to GGUF is now working correctly.

Thanks to @CISC for the valuable feedback.

[CISC]

I misread the log BTW, the triggering tensor was in_proj_qkv, so this should definitely be looked at on our side.

[CISC]

@Lairs Can you please try the linked PR (and undo your changes, sorry about that)?

[Lairs]

Apologies for the delayed response.

We haven't made any modifications to the llama.cpp repository; we are strictly using the convert_lora_to_gguf.py script for our GGUF conversions.
The fix was implemented by adjusting our training YAML configurations. By ensuring that the specific modules are not designated during the LoRA training process, the resulting LoRA config remains clean of unsupported modules.

We would also be very interested in seeing support for in_proj_qkv in future updates.

Thanks again for the assistance!

[CISC]

We would also be very interested in seeing support for in_proj_qkv in future updates.

As mentioned, the linked (and merged) PR should do exactly that.