[Xore]

Adds a dense decoder, split out of #1564 as requested. Rebuilt on current dev (4521832a).

What

c/llama.c — a conventional decoder with grouped-query attention and a grouped KV cache, supporting Llama 3.2. The tree is currently MoE-only, so this is a new capability rather than a port.

Also included:

• c/tools/convert_llama.py — safetensors to container converter
• c/tools/make_llama_oracle.py — oracle generator
• c/ref_llama.json — reference tokens for unsloth/Llama-3.2-1B@9535bd9b
• c/family_registry.py — dense-family support, reusing the existing FamilyDescriptor / FAMILIES extension points already in the tree
• engine/test registration in c/Makefile, the CI and release engine lists, and the family tuples in c/openai_server.py

Correctness

The oracle is generated independently with torch 2.14.1 / transformers 5.18.0 from the upstream checkpoint, and reproduces the committed reference exactly:

prompt_ids equal: True
generated_ids equal: True
full_ids equal: True

Against that reference, on the real unsloth/Llama-3.2-1B checkpoint:

CPU:    Matching tokens: 64/64   matmuls: gpu 0,    cpu 7232
CUDA:   Matching tokens: 64/64   matmuls: gpu 7232, cpu 0

The SERVE path is also exercised end to end (handshake, SUBMIT, DATA, DONE).

Tests

• make llama — clean, 0 warnings
• make llama CUDA=1 — clean, 0 warnings
• make test-c — full suite passes
• make test-python — 1921 tests, OK
• tests/test_llama_read_trust — new, passes
• tests/test_convert_llama.py — new
• segment conformance fixtures extended with llama

Notes

Deletions are limited to lines that have to grow: the engine lists in ci.yml/release.yml/Makefile, the family tuples in openai_server.py, the segment conformance manifest, and the "ten families" sentences in the five READMEs (now eleven). No upstream behaviour is removed.

This is the Llama portion of #1564. The rest is still being split out separately; this one stands alone.

[JustVugg]

Thanks for the work and for splitting it out of #1564. We are not going to take a dense Llama engine, and here is why.

colibri exists to run models that do not fit in memory, by streaming MoE experts from disk with a quantized trunk. This engine keeps every weight resident in f32, with no quantization and no streaming. Llama 3.2 1B is about 5 GB that way and 8B about 32 GB, and 70B cannot load at all, so it serves only small models that already run well everywhere. Each family also costs ongoing maintenance in CI, releases, the registry and five READMEs.

Two smaller points for the record:

• The tree is not MoE-only: dense models already run where it fits the design, for example Qwen3.8-27B on the qwen36 engine (qwen36: run dense checkpoints of the family (Qwen3.8-27B) #1777).
• The oracle compares against the real unsloth/Llama-3.2-1B checkpoint, which CI never downloads, so CI would not check this engine's numerics. Our families each carry a tiny fixture generated from the vendor code in CI.

The loader hardening idea from the same split is in #1824, and that one we would like to merge. Closing this one.