Every fv-ml1 link on the Homepage dashboard was broken. Measured against the
live dashboard API before the fix: 16 entries pointing at the dead 10.250.50.54
and zero at the live 10.251.50.54, covering gen, M.O.G.-SEC, Scriberr, Embed,
Rerank, Reward, Coder, Dockge and six dormant seats.
The miss was structural, not careless. fv-ml1-rename-sweep.sh works from an
allowlist assembled from files that mention the HOST, and a homepage.href label
mentions only an IP -- so every stack whose sole stale reference was a label
fell outside it. The allowlist now covers those 24 files, and records how to
derive the list next time (grep the old address, subtract history) rather than
enumerating from memory.
History is still untouched, and the exclusions are now written down with the
reason each one keeps the old address: recorded benchmark results, whose
base_url is part of a measurement's provenance; the one LiteLLM comment
preserving a retired hand-test endpoint; and the cutover runbooks, where the old
address is the subject matter.
Two bugs found while applying it, both fixed here:
- deploy-stack.sh rejected any stack name containing a dot, so qwen3.5-122b,
qwopus3.5-122b and mistral-medium-3.5 could not be deployed by the script at
all. The check exists to stop path traversal, which means rejecting ".." and
"/" -- not every dot. Traversal is now rejected explicitly and tested.
- stacks/scriberr/.env.example allowed CORS only from the dead IP and from
scriberr.ana.internal, which no longer resolves; the box is at the fv site
and DNS already carries scriberr.fv.internal. The live .env had both stale
origins, i.e. an allowlist with nothing reachable in it.
Host side, applied separately: canonical pushed for the 16 stacks whose only
difference from the host was this renumber, and an in-place address-only fix for
the nine whose host copy has genuinely drifted or has no canonical copy, so that
drift survives for a deliberate reconciliation instead of being clobbered. Every
compose.yaml on fv-ml1 now reads 10.251.50.54. The labels themselves only take
effect at container creation, so the running containers still need recreating.
selene — RETIRED 2026-08-23
AtlaAI Selene 1 Mini (Llama 3.1 8B, dynamic FP8), served on ana-ml2 GPU 1 at
:8011 as selene-1-mini-8b. An LLM-as-judge: it scored and critiqued other
models' output rather than generating for users (hallucination /
RAG-faithfulness checks, Worldtree's Domari and selene-judgment roles).
The seat is down and the compose file is kept for reference only. It is not
deployed. stacks-mirror/ will no longer show it on the host.
Why it was retired
Benchmarked head-to-head against gen (qwen3.8-27b-uncensored, ana-ml2 GPU 0
:8015) on selene's own job — 24 designed judge items with checkable
ground truth, pairwise and absolute-scoring modes, 3 repeats each, run on two
prompt templates. 288 calls total, all free local.
| template | selene | gen |
|---|---|---|
| neutral JSON prompt | 20/24 (83%) | 23/24 (96%) |
| Selene's native Atla template | 21/24 (88%) | 22/24 (92%) |
gen won on both templates, and selene's best score sat below gen's worst. Selene was given its own fine-tuned prompt format as a fairness check — it gained one point, not the three it needed.
The decisive defect: selene cannot emit "tie." On both tie items, on both
templates, it forced a winner (0/2 each time). gen returned tie correctly on
the JSON template. For eval work, close pairs are precisely the case that
matters; a judge that manufactures a preference on every equivalent pair is
producing noise exactly where it is most trusted.
Other findings:
- Calibration. gen used the full 1–5 range decisively (1s for bad answers, 5s for good). Selene clustered at 2s and 4s, compressing the scale.
- Stability at temperature 0. Selene had 2 unstable items on the JSON template; gen had 0. They swapped on the native template (gen 4, selene 0) — longer free-text reasoning costs determinism.
- Latency was selene's only win — roughly 3× faster (0.23s vs 0.40s median on JSON). Unexercised: it served ~60 calls/day with zero queueing across five weeks of uptime.
- Shared blind spot. Both preferred a response containing an arithmetic error on the JSON template. gen caught it on the reasoning-first template. Neither is trustworthy for numerically-checkable judgments without a prompt that forces reasoning before the verdict.
Best measured configuration overall: gen + the neutral JSON prompt —
23/24, zero instability, ties handled correctly.
What happened to the names
chat-judge → repointed to gen. It is a role alias, and ADR-0012 is
explicit that consumers bind the capability, not a concrete model. Sampler
profile copied from image-judge (temperature 0, top_p 1.0, top_k 1,
thinking off) so the served config matches the benchmarked condition.
selene-1-mini-8b → removed outright. It 404s by design. It was NOT
aliased to gen. A served-name is a contract about what the model is;
answering it with a different model hides a material change behind a stable
string, and the caller has no way to know. Failing loud forces a conscious
migration. Operator ruling, 2026-08-23:
never repoint a named model at a different model's endpoint — that is intentionally misleading
Direct precedent on this gateway: qwen-image-bench / image-judge had their
dedicated backend retired 2026-07-15 to reclaim GPU 1 VRAM and were repointed
to gen as role aliases. Counter-example worth remembering: when
qwen3-reranker was retired, nevermore was pinned to it by name and the
cutover moved the reranker alias but never moved nevermore — which is why
name-pinned consumers get notified explicitly rather than assumed covered.
Reclaimed
GPU 1 free: 1,818 MiB → 19,450 MiB
17.2 GiB, on a card that had under 2 GiB of headroom. gen was already
running on GPU 0, so the judge role moved onto an existing seat rather than
allocating anything new.
To bring it back
compose.yaml and the host .env are intact. GPU 1 must have ~17 GiB free
(SELENE_GPU_MEM_UTIL=0.17); re-add the selene-1-mini-8b entry to the
LiteLLM config under its own true name, never as an alias for something
else.