vh
91bda3c480
The box is physically at Fountain Valley, renamed, renumbered onto 10.251/16, and serving inference again. This lands the repo half of that. Host: hostname ana-ml2 -> fv-ml1, pinned to 10.251.50.54 by a dnsmasq reservation so the address the runbook, DNS and LiteLLM all assume is the address it actually has. Its headscale node is renamed too. The sweep ran from scripts/fv-ml1-rename-sweep.sh, whose allowlist is the reason this diff touches current-state files and not the record. Dated persistent-memory entries, archival-memory and incident notes still say ana-ml2 in 31 and 62 places respectively, because that is what the box was when those things happened. Rewriting them would make the history lie. LiteLLM was the load-bearing piece and needed more than the api_base sed the runbook describes. Twenty api_base entries repointed, but a grep-and-verify pass also caught a LIVE pass_through_endpoints target for the scalar-judge reward route still on the old address -- an api_base-only substitution would have left it dead. Four prose references describing current state were repointed as well; one historical note recording where a hand-test was run is deliberately left pointing at 10.250.50.54. Two facts in the server tables were wrong and are corrected here. The site is Fountain Valley, not Anaheim. And the box has FOUR RTX PRO 6000 Blackwell Max-Q, not two -- verified by nvidia-smi -L and independently by PCI enumeration of four GB202GL devices. That is 391 GB of VRAM rather than 196, which changes what fits on it. DNS: fv-ml1, fv-ml1-bmc and fv-gw added under the fv site via the piggyback approach, scriberr re-homed, and the ana-ml2 records removed. Applied to all three resolvers. The BMC record carries a warning that its 802.1q VLAN tag must stay disabled -- it shipped tagging VLAN 250 into an untagged port, which made it invisible to every network-side diagnostic and is the reason it appeared dead through several cable changes. Verified end to end: summarizer and sec both answer through the Anaheim gateway across the mesh to FV seats on different ports.
2.2 KiB
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.