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.
heretic2-charrp-reasoning — NVFP4 + native MTP reasoning seat (fv-ml1)
The char-rp-reasoning seat: NEO-CODE Heretic2 27B quantized to modelopt NVFP4
with a grafted BF16 MTP head, served by vLLM on fv-ml1 GPU0, port 8018.
Replaces the retired GGUF seat (llama-charrp-reasoning) at roughly 77 tok/s
(~1.3x) via qwen3_5_mtp speculative decode.
- Served model name:
char-rp-reasoning— the gateway alias consumers use - Endpoint:
http://10.251.50.54:8018(/docsfor the card link)
⚠️ It does not boot without the MTP workaround
vLLM 0.24.0 does not propagate modelopt's exclude_modules to the draft
model in a spec-decode config, so the BF16 MTP head gets quantized along with
everything else and the engine dies at load on a shape mismatch.
conf/mtp-workaround/sitecustomize.py is mounted at PYTHONPATH and patches
is_layer_skipped to force-skip mtp.*, keeping the head BF16. The mount and
the PYTHONPATH env are both load-bearing — remove either and the seat
crash-loops at startup with an error that looks like a bad quant rather than a
missing shim.
Canonical copy of the shim and the reasoning behind it live in
services/heretic2-nvfp4-quant/; the full build-and-serve recipe, including the
other landmines hit on the way, is in
docs/runbooks/heretic2-nvfp4-mtp-seat.md.
Read the runbook before changing anything here — this README is the pointer, not
the spec.
VRAM is the constraint, and it is shared
GPU0 also hosts vllm-aeon-gen (gen) and llama-charrp (char-rp). NVFP4
27B weights are ~26 GB plus KV, which is why --gpu-memory-utilization sits at
0.30 and --max-model-len at 32768 — the old GGUF seat managed 256K on
much lighter Q5 weights. Raising either without rebalancing GPU0 first will
OOM the neighbours, not just this container. Tunables are in .env; see
.env.example.
Deploy
scripts/deploy-stack.sh fv-ml1 heretic2-charrp-reasoning
ssh infra-ops@10.251.50.54 \
'cd /opt/docker/compose/heretic2-charrp-reasoning && sudo docker compose up -d'
First start is slow — the healthcheck allows a 600s start_period because
loading NVFP4 weights plus the draft head takes minutes.