Onboards Anbeeld's llama.cpp fork (beellama.cpp) as a registry engine
with two single-card DFlash composes, both experimental pending a
published Docker image:
- beellama/dflash Qwen3.6-27B Q5_K_S + Anbeeld DFlash-IQ4_XS,
q5_0/q4_1 KV, 102K ctx, port 8060
- beellama/gemma-dflash Gemma-4-31B Q4_K_S + Anbeeld DFlash-IQ4_XS,
q5_0/q4_1 KV, 102K ctx, port 8061
Composes reference the locally-built ${BEELLAMA_IMAGE:-beellama-cpp:local}
(entrypoint /app/llama-server) — upstream ships no pullable image, so
they ship as Status: Experimental and surface as (NA: experimental) in
--list (launch is --force-gated). Configs follow the fork's quickstart
docs (Qwen "Precision combo", Gemma "Balanced combo"), deviating only on
the stack-wide --reasoning off default.
Catalog wiring: engine profile beellama-local.yml; two DFlash GGUF
drafters (anbeeld-qwen-dflash, anbeeld-gemma-dflash); compose_registry.py
entries with kvcalc_key="SKIP" (llama.cpp-family, like ik-llama);
weights-map entries (target + draft GGUFs) on both models; q4_1 added to
rtx-3090 supported KV; INFERENCE_ENGINES + UPSTREAM notes; test counts
bumped (engines 8->9, drafters 6->8, registry 45->47, disk 46->48).
Default-resolver invariant preserved: beellama is #1 in
ENGINE_PREFERENCE[single], but its (NA) status + no DEFAULTS row means
the resolver skips it, so qwen3.6-27b single still resolves to
ik-llama/iq4ks-mtp (asserted by test-model-default-resolver.sh). It
auto-promotes only when a published image lands and the composes flip to
production. Full catalog suite green (only the pre-existing
test-submit-bench.sh fixture failure remains).
Co-authored-by: noonghunna <[email protected]>
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
Follow-up to #235 — the PRISM/APEX presets exercised (model, engine, KV)
combos the profile catalog didn't know about, reddening test-profiles-compat
and test-diagnose-profile (caught by the pre-tag FULL-suite run, which the
narrower #235 gate subset had missed).
- engines/llama-cpp-mainline.yml: supported_model_families += qwen3-next-moe
(the 35b-a3b APEX MoE; llama.cpp serves the MoE GGUF — the family list was
just incomplete). Fixes constraint C10 for the 3 APEX entries.
- hardware/*.yml (all 9): supported_kv_formats += q5_0, q8_0 — the llama.cpp
KV quants the engine already lists but no hardware profile did, so the q8_0
presets (prism-pro-dq-dual-vision, apex-mtp-compact-long, apex-mtp-quality-dual)
failed C5 "kv not supported by hardware". q5_0/q8_0 are software KV quants
that work on any CUDA card (laurimyllari runs q8_0 on a 4090).
- patches.yml: register the APEX chat-template (apex-qwen-chat-template) with a
symmetric-protocol drift_guard — resolves the orphan #235 introduced into
test-patch-attribution.
Validation: test-profiles-compat + test-diagnose-profile PASS. APEX patch-
attribution orphan resolved (only the 2 PRE-EXISTING sglang orphans remain =
the v0.8.5 baseline). Full suite 29/34; the 5 remaining fails are all
pre-existing-at-v0.8.5 or test-isolation, NONE from the v0.8.5..master range:
generate-compose (pre-existing), setup-picker (mock 5090 rig), submit-bench
(0 fixtures), loop-input (test-hwdetect .pull-captures cross-contamination —
passes in isolation). Leak-clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
