loras property

Initial LoRA adapters to load along with the model.

llama.cpp backends apply every adapter at its LoraAdapterConfig.scale, in list order, once the model and its context are created, as LlamaEngine.setLoraSource would; setLoraSource, removeLoraSource and clearLoras can change them afterwards. Each load applies the list again.

LlamaEngine resolves each LoraAdapterConfig.source before the model loads, as setLoraSource does, in list order, with the adapter's own LoraAdapterConfig.download. Without one, an adapter takes only the non-secret options of the load (the download of LlamaEngine.load and setModel): cache policy and directory, resume, retries and cancel token. The load's bearer token, headers and checksum never reach an adapter's host. Adapter downloads report no progress; a failed one fails the load before the model loads.

On WebGPU this needs bridge assets v0.1.54+ whose runtime LoRA API reports support. When an adapter cannot be applied the load fails, and a load through LlamaEngine leaves no model loaded. An unsupported adapter, such as an aLoRA adapter, or older bridge assets throw LlamaUnsupportedException naming the adapter; any other failure throws LlamaModelException, with the adapter and cause in its details.

Native LiteRT-LM supports one default-scale text LoRA adapter at model load; runtime adapter updates, stacking, custom scales, and LiteRT-LM web LoRA are unsupported. When the model's format, given or from a .litertlm extension, the native file header of a model without either, or the backend makes the load LiteRT-LM, adapters it cannot take throw LlamaUnsupportedException before any LoraAdapterConfig.source resolves or downloads: more than one, another scale, any with liteRtLmEmbeddingEngine, and on the Web any at all.