What causes "Invalid LoRA multiplier '%s', skipping\n" in mudler/LocalAI?

Use a plain decimal multiplier in the tag, e.g.

Invalid LoRA multiplier '%s', skipping\n

Error message

Invalid LoRA multiplier '%s', skipping\n

What it means

Warning from the LoRA prompt parser: a <lora:name:multiplier> tag has a multiplier that std::stof cannot parse (non-numeric like 'strong' or '1,0'). The tag is removed from the prompt and skipped; all other tags continue to be processed. Note std::stof accepts partial prefixes, so '1.0abc' parses as 1.0 while 'abc' fails.

Source

Thrown at backend/go/stablediffusion-ggml/cpp/gosd.cpp:208

    static const std::regex re(R"(<lora:([^:>]+):([^>]+)>)");
    static const std::vector<std::string> valid_ext = {".pt", ".safetensors", ".gguf"};
    std::smatch m;

    std::string tmp = prompt;

    fprintf(stderr, "Parsing LoRAs from prompt: %s\n", prompt.c_str());

    while (std::regex_search(tmp, m, re)) {
        std::string raw_path = m[1].str();
        const std::string raw_mul = m[2].str();

        float mul = 0.f;
        try {
            mul = std::stof(raw_mul);
        } catch (...) {
            tmp = m.suffix().str();
            cleaned_prompt = std::regex_replace(cleaned_prompt, re, "", std::regex_constants::format_first_only);
            fprintf(stderr, "Invalid LoRA multiplier '%s', skipping\n", raw_mul.c_str());
            continue;
        }

        bool is_high_noise = false;
        static const std::string prefix = "|high_noise|";
        if (raw_path.rfind(prefix, 0) == 0) {
            raw_path.erase(0, prefix.size());
            is_high_noise = true;
        }

        std::filesystem::path final_path;
        if (is_absolute_path(raw_path)) {
            final_path = raw_path;
        } else {
            // Try name-based lookup first
            auto it = discovered_lora_map.find(raw_path);
            if (it != discovered_lora_map.end()) {
                final_path = it->second;

View on GitHub (pinned to 44413a9d06)

Solutions

Use a plain decimal multiplier in the tag, e.g. <lora:style:0.8>
Check for comma decimal separators and replace with a dot
Scan the prompt programmatically for <lora:...> tags and validate the multiplier before submitting

Example fix

// before
"a cat <lora:pixar:strong>" // multiplier skipped

// after
"a cat <lora:pixar:0.8>"

Defensive patterns

Strategy: validation

Validate before calling

// Go caller: validate multipliers before submitting the prompt
var loraTag = regexp.MustCompile(`<lora:([^:>]+):([^>]+)>`)
for _, m := range loraTag.FindAllStringSubmatch(prompt, -1) {
    if _, err := strconv.ParseFloat(m[2], 32); err != nil {
        return fmt.Errorf("invalid LoRA multiplier %q in tag %s", m[2], m[0])
    }
}

Prevention

Use plain dot-decimal multipliers like <lora:name:0.8>
Validate prompt tags server-side so bad multipliers are rejected loudly, not stripped silently

When it happens

Trigger: Prompts containing tags like <lora:style:high> or <lora:style:> variants where the second capture group is not a valid float start; locale issues where the comma is the decimal separator can also produce '1,0' which fails.

Common situations: Hand-edited or LLM-generated prompts with malformed multipliers; locales that write decimals with commas; copy-paste from web UIs that use different tag syntax.

Related errors

AI-assisted analysis of mudler/LocalAI@44413a9d06 (2026-08-15). Data as JSON: /api/errors/c8924c6bb422dfc5. Report an issue: GitHub.