Selora AI LLM — fused single-model build

Qwen3 1.7B fine-tuned for Home Assistant, with all five Selora specialists (command, automation, answer, clarification, utilities) merged into one model. For runtimes that cannot hot-swap LoRA adapters — Ollama being the common case.

The adapter bundle this is merged from lives in selorahomes/Selora-AI-LLM-1.7B: a shared quantized base plus five separate LoRA adapters, swapped per request. That is the reference deployment and the one the Home Assistant integration uses.

Which one do you want?

	This repo	Selora-AI-LLM-1.7B
Ships	One fused GGUF	Base GGUF + 5 LoRA adapters
Runtime	Ollama, llama.cpp — anything that loads a single GGUF	llama.cpp with `--lora`, vLLM with `--enable-lora`
Picks the response type	The model does, from the router prompt	The caller does, by activating one adapter
Accuracy	Not separately measured	Measured scores in `eval/baselines.json`

Merging trades accuracy for simplicity. Each adapter was trained against its own system prompt; the fused model is driven by a router prompt that asks it to choose a response type first, which is not a shape any adapter was trained on. If you can swap adapters, swap adapters.

This build has no benchmark numbers of its own. The suite's automations dataset is collected but never asserted on, so it cannot support a claim either way, and the other datasets are only run against the adapter bundle.

Quick start

ollama run hf.co/selorahomes/Selora-AI-LLM-1.7B-ollama:selora-ollama.Q6_K.gguf

The filename tag is deliberate. Hugging Face's Ollama integration selects Q4_K_M when present and otherwise picks a reasonable quant from the repo; naming the file removes the guess.

Or build it yourself from the Modelfile in this repo:

ollama create selora -f Modelfile
ollama run selora

The system, template and params files at the repo root configure the same thing for ollama run hf.co/… directly.

Prompt format

ChatML, with /no_think prefixed to the user turn to suppress Qwen3's reasoning block so the output is bare JSON. Inference must match training byte-for-byte; template in this repo is the authoritative form.

<|im_start|>system
{system}<|im_end|>
<|im_start|>user
/no_think {prompt}<|im_end|>
<|im_start|>assistant
<think>

</think>

The empty <think></think> block is part of the prompt, not the output. Training includes it (masked), so the template must emit it. Ollama renders the chat template embedded in the GGUF rather than template, and that one always emits it, with or without --think=false. Without it the model generates as though the JSON's opening {" had already been written and returns q=[...] instead of {"q":[...]}, which no parser accepts.

The user turn carries the AVAILABLE ENTITIES list, EXISTING AUTOMATIONS, and — for utilities questions — a RELEVANT DOCS block. The model replies with exactly one JSON object, of whichever of the five types it picked. Context is 4096 tokens.

Generation parameters

Set by params / the Modelfile:

temperature    0.0
repeat_penalty 1.0
repeat_last_n  256
num_ctx        4096
stop           <|im_end|>, <|endoftext|>

repeat_penalty stays at 1.0 on purpose. JSON output is mostly repeated structural tokens, and penalising them degrades schema fidelity.

Files

Artifact	Purpose
`selora-ollama.Q6_K.gguf`	The fused model
`Modelfile`	Ollama recipe (model + router prompt + params)
`system`	Router system prompt
`template`	Go chat template
`params`	Sampler settings
`manifest.json`	Version, checksum, provenance
`LICENSE` / `NOTICE`	Apache 2.0 text and the Qwen3 attribution

Modelfile, system, template and params are generated from the models repo — data-pipeline/prompts/router_system_prompt.txt is the source of truth for the system prompt. Don't edit them here; they are overwritten on every release.

Versioning

main is the latest release, and each release is also tagged v<x.y.z>. Versions track the adapter bundle in selorahomes/Selora-AI-LLM-1.7B: the same manifest.json version covers both, because both are built from one conversion run.

License

Apache 2.0, inheriting Qwen3-1.7B.