selorahomes/Selora-AI-14B

Selora AI 14B

A local assistant for Home Assistant, built on Qwen3-14B-Base. It turns plain requests into service calls, builds automations, answers questions about the home, asks when a request is ambiguous, and looks up documentation with citations — entirely on the hub. No cloud, no account, no telemetry.

This is the larger of the two Selora AI lines. The 1.7B line lives at selorahomes/Selora-AI and runs on far less memory. This model needs about 16 GB of RAM.

What it is

One shared base plus five small task adapters, served by llama.cpp with the adapter selected per request:

file	role	size
qwen3_14b_base.Q5_K_S.gguf	shared base, Qwen3-14B at Q5_K_S	10.3 GB
selora-command.lora.gguf	request → Home Assistant service calls	51 MB
selora-automation.lora.gguf	builds automations, including blueprint YAML	128 MB
selora-answer.lora.gguf	answers questions about the home's state	39 MB
selora-clarification.lora.gguf	asks when a request is genuinely ambiguous	26 MB
selora-utilities.lora.gguf	documentation lookup with source citations	51 MB
prompts/	the system prompt each adapter was trained against	—
selora-ollama.Q5_K_S.gguf	the Advanced tier: all five fused into one model	9.6 GB
ollama/Modelfile	template + system prompt for ollama create	—

Five specialists share one base, so the whole set costs 9.6 GB of memory rather than five separate models.

Requirements

memory	~16 GB total for the model, KV cache and Home Assistant together
serving	llama.cpp with LoRA support
quant	Q5_K_S (see below for why)

Running it

llama-server -m qwen3_14b_base.Q5_K_S.gguf \
  --lora selora-answer.lora.gguf \
  --lora selora-clarification.lora.gguf \
  --lora selora-automation.lora.gguf \
  --lora selora-utilities.lora.gguf \
  --lora selora-command.lora.gguf \
  -c 4096 -np 1

Adapter slot ids follow the order of the --lora flags. Resolve them by filename from /lora-adapters rather than assuming a fixed order.

Two ways to run it

llama.cpp — the default. One base plus five adapters, selected per request. Every number on this card below is this configuration unless marked otherwise.

Ollama — the Advanced tier. A single merged model, selora-ollama.Q5_K_S.gguf, with all five specialists fused into one set of weights and the routing decision made by the model itself. Simpler to deploy: one file, one ollama create.

ollama create selora-qwen:0.4.9 -f ollama/Modelfile

The merged model trails the five specialists on one surface, and the card says so plainly: when a request is ambiguous, it acts instead of asking about half the time (54.5% routing accuracy on clarification cases, against the clarification specialist asking reliably). On a Selora-authored 262-case behavioural set scored identically for both, the merged model reaches 69.5% against the specialists' 82.8%; 47 of its 80 misses are routing rather than content. It passes every pre-registered integration gate (18/18 turns through Home Assistant in the 15 GB sim, median 8.9 s, zero 500s), and multi-device commands actuate every target. Choose it for deployment simplicity; choose the adapters when asking-before-acting matters — locks and alarms in particular.

The Modelfile pins a chat template matching the training prompt byte-for-byte. Ollama renders the template embedded in the GGUF and ignores the Modelfile's own; the shipped GGUF carries the corrected one. Third-party benchmarks for this tier are in the table below, beside the specialists.

Why Q5_K_S

Measured with adapters, KV cache and Home Assistant running alongside, inside a 15 GB hub:

quant	base	total footprint	headroom
Q4_K_M	8.4 GB	~11.7 GB	documentation-lookup accuracy collapses 96% → 62%
Q5_K_S	9.6 GB	~12.9 GB	2.1 GB
Q6_K	11.3 GB	~14.6 GB	0.4 GB

Q6_K is a little more accurate on some suites. Q5_K_S is the one that leaves room for the KV cache to grow on a large home — Home Assistant's own analytics put the average install near 386 entities.

Verified through the real integration

Measured through the Home Assistant integration in a 15 GB simulated hub at the shipping quant — not against the model in isolation.

turns passing	18 / 18
median response	6.2 s
single-device command, median	5.9 s
95th percentile	12.9 s
HTTP 500s	0
multi-device commands	every target actuated, 3/3 and 6/6
automations	created in Home Assistant, 3/3

Response time is dominated by prompt ingest, so it scales with how many entities a home exposes. The simulated home here is small (about 20 entities); a real home will be slower in proportion.

Third-party benchmarks

Measured on the exact weights in this repository, under each suite's own published protocol, temperature 0, on Apple Silicon (Metal) at the shipping quant. Each adapter is addressed by name from the server's /lora-adapters listing. The Ollama tier is measured separately below.

suite	score	n	what it measures
Allen assist	80.0%	95	a request becomes the right service call
Allen assist-mini	96.0%	50	same, smaller curated set
Allen questions	44.7%	38	answering questions about home state
Allen automations	3 of 4 scenarios	4 × 5	building a loadable automation
HA intents	90.3%	595	Home Assistant's own intent corpus, full set
HomeBench	30.2%	597	commands, exact match under upstream's scorer
acon96	56.7%	150	command dataset, scored by our shim

HomeBench by group, upstream scorer:

group	score	what it tests
normal_single	63.0%	one device, one operation
normal_multi	34.0%	several devices in one request
unexist_device	59.0%	refusing a device the home does not have
unexist_attribute	24.0%	refusing a setting a device does not have
mix_multi / error_multi	0.0%	several items where some do not exist

HomeBench multi-device, F1 partial credit (Selora-defined slice):

devices per request	F1
2	36.2
10	25.3

Reading the rows honestly.

HomeBench improved from 0.0% to 30.2% in this build by teaching the model the suite's output contract, which the training data had never contained — every prior output wrapped its operation in quotes the scorer could not read. Two gaps remain and are located: on requests naming several absent items the model refuses once rather than once per item, and "this device has no such setting" is read far worse than "no such device".

Allen automations is four scenarios, each sampled five times at temperature 0, so it moves in 25-point steps. Three pass. The one that fails does so on a single malformed key — a trigger's id: placed on an action step — which Home Assistant's loader rejects. Two earlier defects (a missing turn-off action; a double-wrapped blueprint input) were fixed in this build and are confirmed closed at the loader.

Allen questions is bounded by data, not capability: 17 of its 38 cases have answers that live only in entity attributes the model is never shown, so the achievable ceiling is about 55%. Of the 21 misses, 16 are the model declining.

acon96 has no published scoring harness, so that row is scored by our own translation and labelled as such.

Ollama tier, same suites

The merged model, measured the same way, beside the specialists:

suite	Ollama (merged)	llama.cpp (specialists)
Allen assist	72.6%	80.0%
Allen assist-mini	92.0%	96.0%
Allen questions	50.0%	44.7%
Allen automations	0 of 4	3 of 4
HA intents	84.9%	90.3%
HomeBench	0.0%	30.2%
acon96	54.7%	56.7%
HomeBench 2 devices, F1	30.3	36.2
HomeBench 10 devices, F1	14.9	25.3

Why the merged model trails. It was fused from the training corpus one generation before the command and automation fixes in this release, so it still carries the HomeBench quote-wrapping (99% of outputs) and the two blueprint defects the adapters no longer have — all four automation scenarios produced valid YAML that Home Assistant rejected on exactly those defects. The remaining gap on assist and intents is the act-vs-ask boundary: on HA intents, 63 of its 90 misses are the model asking a clarifying question where a command was wanted. No third-party suite here measures clarification or documentation lookup directly, so the table understates the difference on asking-before- acting, which is where the specialists are strongest.

One caveat on all of the above: measured on Metal. On one sampled case the same weights at the same quant produced a different numeric parameter on CPU than on Metal at temperature 0. The hub runs CPU.

Licence

Apache 2.0, inherited from Qwen3-14B-Base.