does lora_base have any effect?

[mlisovyi]

Looking at the code, it would seem, that the lora_base parameter is irnored, when the actual loading of the adapter from lora_path happens in

llama-cpp-python/llama_cpp/llama.py

Lines 424 to 427 in 1b1a320

	self._lora_adapter = llama_cpp.llama_adapter_lora_init(
	self._model.model,
	self.lora_path.encode("utf-8"),
	)

. Or do I overlood something?

[gyanu2507]

You are reading it right. In current llama.cpp, the adapter is applied to the model that is already loaded. There is no separate "here is the fp16 base GGUF for this LoRA" argument at apply time, so lora_base in the Python constructor is leftover and not passed into llama_adapter_lora_init.

Older llama.cpp had a flow where a LoRA was merged against a different base path. That is gone. Put the matching base in model_path and the adapter in lora_path (or Llama().load_lora). If the LoRA was trained on another base, it will load and produce garbage rather than error on lora_base.

If you need the old merge-against-this-file behavior, do it offline with llama-export-lora / the merge tools, then load the merged GGUF.