fix(nevermore): repoint onto live aliases — its LLM pass had been dead 8 days

nevermore pinned LLAMA_SWAP_MODEL=granite-4.1-8b, an alias retired with the
granite seat on 2026-08-12. Every summarization call since then failed: 67
consecutive status=failure rows, 0 tokens, twice daily, entirely silently. The
briefing had been rendering with no LLM pass at all. Nothing alerts on
status=failure in the spend logs, so it took an unrelated question about
reranker VRAM to surface it.

It was also pinned to NEVERMORE_RERANK_MODEL=qwen3-reranker -- the incumbent
Brokkr R43 measured harming 80/90 fleet queries -- and was its ONLY caller,
while the production `reranker` alias sat at 0 calls for 4 days. The R43
cutover repointed the alias but never moved the consumer.

  nevermore/.env  LLAMA_SWAP_MODEL       granite-4.1-8b -> summarizer
                  NEVERMORE_RERANK_MODEL qwen3-reranker -> reranker
                  (server-only; .env is excluded from the mirror both ways)

Verified against nevermore's exact call shape: summarizer returns clean content
with 0 reasoning chars at temperature 0.2 / max_tokens 4000; reranker scores
0.95 on-topic vs ~1e-5 off-topic; embedding returns dim-1024.

Retired alongside it:

  vllm-rerank    :8002  Qwen3-Reranker-0.6B + the qwen3-reranker alias
  vllm-rerank-a4 :8014  gte-reranker-modernbert + its alias
  vllm-granite   :8004  Exited 8 days, dead service block

and vllm-rerank-a3 was promoted from a throwaway `docker run` into this stack
(the selection ledger's own open follow-up). Healthy in 55s. It keeps the
bake-off arm name so the ledger, memory and R43 record stay valid.

VLLM_VERSION is pinned latest -> v0.24.0. Every service in the stack shares that
one variable, so a bare `compose up -d` could have silently upgraded all of
them at once; both tags resolved to the same local image (4091d5593f77), so the
pin changed nothing at runtime.

GPU1 is down to 81,448 of 97,887 MiB -- 13.9 GB reclaimed tonight.

Correction: an earlier claim that A4 had no gateway alias was wrong. It did.
LiteLLM serves both config-defined and DB-defined models -- live showed 32
against config.yaml's 26 -- and grepping the file cannot see the difference.
/v1/models and /model/info (which flags db_model) are the ground truth. DB
models delete hot via POST /model/delete with no restart.

Left alone: reranker-a3-bge-v2-m3, a zero-call duplicate of `reranker` on the
same backend. It is Brokkr's cutover-verification handle -- redundant rather
than broken, and another agent's tooling is not mine to delete unilaterally.

stacks/vllm/compose.yaml

@@ -83,9 +83,27 @@ services:
       - homepage.description=Qwen3 Embedding via vLLM (ana-ml2)
       - homepage.href=http://10.250.50.54:${EMBED_PORT}/docs
 
-  vllm-rerank:
+  # THE fleet reranker. Backs the LiteLLM `reranker` alias, which is what every
+  # consumer should name — never the model, never a bake-off arm name.
+  #
+  # It won the Brokkr R43 bake-off (docs/pfi/reranker-selection-ledger.md) and
+  # replaced Qwen3-Reranker-0.6B, which was measured HARMING 80/90 fleet queries
+  # (no-reranker beat it 89/90 vs 56/90). The R42 v13 acceptance gate went
+  # 56/90 -> 90/90 on the cutover, its first-ever PASS.
+  #
+  # Promoted from a throwaway `docker run` to this service 2026-08-20 (the
+  # ledger's own open follow-up). It carried the bake-off's arm name from the
+  # start and KEEPS it: the ledger, persistent-memory and the R43 record all say
+  # `vllm-rerank-a3`, and renaming for tidiness would orphan every one of those
+  # references. The name carries its provenance.
+  #
+  # Retired alongside this promotion: `vllm-rerank` (Qwen3-Reranker-0.6B, :8002 —
+  # the rollback path, kept warm 13 days) and `vllm-rerank-a4`
+  # (gte-reranker-modernbert, :8014 — a documented throughput fallback that was
+  # never given a gateway alias, so it was unreachable the whole time).
+  vllm-rerank-a3:
     image: vllm/vllm-openai:${VLLM_VERSION}
-    container_name: vllm-rerank
+    container_name: vllm-rerank-a3
     restart: unless-stopped
     ipc: host
     ports:
@@ -103,8 +121,9 @@ services:
       - ${RERANK_MODEL}
       - --runner
       - pooling
-      - --hf-overrides
-      - '{"architectures":["Qwen3ForSequenceClassification"],"classifier_from_token":["no","yes"],"is_original_qwen3_reranker":true}'
+      # No --hf-overrides here. The Qwen reranker needed one to be coerced into a
+      # sequence-classification head; bge-reranker-v2-m3 is natively a
+      # cross-encoder and vLLM resolves it directly.
       - --host
       - 0.0.0.0
       - --port
@@ -134,9 +153,9 @@ services:
       - tnet
     labels:
       - homepage.group=AI - Eval & Retrieval
-      - homepage.name=vLLM Rerank (Qwen3)
+      - homepage.name=vLLM Rerank (bge-v2-m3)
       - homepage.icon=mdi-sort-variant
-      - homepage.description=Qwen3 Reranker via vLLM (ana-ml2)
+      - homepage.description=BAAI bge-reranker-v2-m3 — the fleet reranker, backs the `reranker` alias (ana-ml2)
       - homepage.href=http://10.250.50.54:${RERANK_PORT}/docs
 
   vllm-reward:
@@ -197,86 +216,24 @@ services:
       - homepage.description=Skywork-Reward-V2 8B classifier via vLLM (ana-ml2)
       - homepage.href=http://10.250.50.54:${REWARD_PORT}/docs
 
-  # Granite 4.1 8B (FP8) — production summarizer (replaced phi4-mini
-  # 2026-06-05, which had superseded the llama-swap granite-4-small pin).
-  # Generative chat model (OpenAI /v1/chat/completions), so NO --runner
-  # pooling. FP8 on RTX PRO 6000 Blackwell (cc 12.0): near-lossless, ~1.2x, ~6 GB.
-  vllm-granite:
-    image: vllm/vllm-openai:${VLLM_VERSION}
-    container_name: vllm-granite
-    restart: unless-stopped
-    ipc: host
-    ports:
-      - "${GRANITE_PORT}:8000"
-    volumes:
-      - /tank/aimodels/huggingface:/hfcache
-    environment:
-      - HF_HOME=/hfcache
-      - HF_HUB_CACHE=/hfcache/hub
-      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN:-}
-      - VLLM_API_KEY=${API_KEY:-}
-    command:
-      # Production summarizer (replaced phi4-mini 2026-06-05). Default = official
-      # IBM pre-quantized FP8 (compressed-tensors), loaded directly; FP8 is native
-      # on the RTX PRO 6000 Blackwell (cc 12.0). Fallback to vLLM-native dynamic FP8 from
-      # BF16: GRANITE_MODEL=ibm-granite/granite-4.1-8b + GRANITE_QUANT=fp8.
-      - ${GRANITE_MODEL}
-      - --served-model-name
-      - ${GRANITE_SERVED_NAME}
-      - --quantization
-      - ${GRANITE_QUANT}
-      - --host
-      - 0.0.0.0
-      - --port
-      - "8000"
-      - --gpu-memory-utilization
-      - ${GRANITE_GPU_MEM_UTIL}
-      - --max-model-len
-      - ${GRANITE_MAX_MODEL_LEN}
-      # Very high so the KV pool (not the seq cap) is the only concurrency bound —
-      # granite is the fleet fan-out summarizer/classifier (many concurrent SHORT
-      # calls). vLLM's default resolves to 128, capping below the KV bound
-      # (~192 @ 1K-tok); 1024 unblocks it (VRAM-neutral — KV pool is util-bound).
-      - --max-num-seqs
-      - ${GRANITE_MAX_NUM_SEQS}
-      - --dtype
-      - auto
-      # CUDA graphs ENABLED (no --enforce-eager) for decode throughput. Made
-      # room 2026-06-05 by right-sizing the embed/rerank/reward trio's KV pools
-      # (they were over-provisioned at 5.9x/2.0x/3.9x concurrency); GPU 1 now has
-      # ~17 GB free after granite, so graph-capture buffers fit. If the trio
-      # ever grows back, granite may need --enforce-eager again on this card.
-      # FP8 KV cache — halves KV memory; near-lossless on Blackwell (cc 12.0).
-      - --kv-cache-dtype
-      - ${GRANITE_KV_CACHE_DTYPE}
-      # Prefix caching pinned EXPLICIT (vLLM v1 defaults it on, but pin so a
-      # version flip can't silently disable it). Benched 2026-06-13: ~6.5x faster
-      # TTFT (45ms vs 292ms) on a shared ~4.5k-token summarizer template; soft/
-      # evictable KV, neutral when prefixes don't repeat — pure win for granite.
-      - --enable-prefix-caching
-    deploy:
-      resources:
-        reservations:
-          devices:
-            - driver: nvidia
-              device_ids:
-                - "${GRANITE_GPU_ID}"
-              capabilities:
-                - gpu
-    healthcheck:
-      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
-      interval: 30s
-      timeout: 10s
-      retries: 3
-      start_period: 180s
-    networks:
-      - tnet
-    labels:
-      - homepage.group=AI - Inference
-      - homepage.name=vLLM Granite 4.1 8B (summarizer)
-      - homepage.icon=mdi-text-box-outline
-      - homepage.description=Granite 4.1 8B FP8 via vLLM (ana-ml2)
-      - homepage.href=http://10.250.50.54:${GRANITE_PORT}/docs
+  # vllm-granite (ibm-granite/granite-4.1-8b-fp8, :8004) — RETIRED 2026-08-12,
+  # service block removed 2026-08-20. It was the fleet summarizer until the
+  # `summarizer` and `classifier` aliases were repointed at the gen seat; the
+  # container was stopped then and sat Exited for 8 days while this block still
+  # claimed it as production.
+  #
+  # ⚠️ Retiring the SEAT did not retire its CONSUMERS, and nobody checked. The
+  # `granite-4.1-8b` gateway alias was deleted at the same time, but `nevermore`
+  # was still pinned to that alias by name — so its LLM summarization pass failed
+  # 67 consecutive times over 8 days, 0 tokens, entirely silently, because a
+  # failed gateway call still returns 200-shaped spend-log rows and nothing
+  # alerts on status=failure. Found 2026-08-20 only because someone asked an
+  # unrelated question about reranker VRAM.
+  #
+  # The rule this earns: RETIRING A MODEL IS A TWO-SIDED OPERATION. Grep every
+  # consumer's config for the alias BEFORE deleting it, and prefer that consumers
+  # pin stable ALIASES (`summarizer`) over model names (`granite-4.1-8b`) so the
+  # gateway can repoint them without anyone editing a downstream .env.
 
   vllm-coder:
     image: vllm/vllm-openai:${VLLM_VERSION}