chore(vllm): retire LFM2.5-2.6B permanently; audit finds nevermore on the harmful reranker
Operator directive: lfm2.5-2.6b goes down permanently.
- stacks/vllm/compose.yaml vllm-lfm25 service removed (replaced by a
tombstone comment), pushed live to ana-ml2
- ana-ml2 container docker rm -f'd, 8,721 MiB freed on GPU1
(95,388 -> 86,667 of 97,887)
- litellm config lfm2.5-2.6b alias deleted, live + canonical,
28 -> 27 models
It was an EVAL-ONLY bake-off seat against granite-4.1-8b that never received
the operator ruling it was pending; the comparator was retired from the roster
on 2026-08-15; it was deliberately never wired into any default or fallback
routing chain; and spend logs show 0 calls in the 4-day window to 2026-08-21.
Weights stay in the shared HF cache -- nothing deleted from disk.
The gateway restart that makes the alias deletion take effect is HELD so it can
batch with a pending reranker change. Until then the name is still routable
in-memory and will error against a dead backend.
Auditing the three reranker seats while answering "why do we have three" turned
up a real problem. The design is one production, one rollback, one fallback --
but the traffic is backwards:
:8013 A3 bge-v2-m3 PRODUCTION, backs `reranker` 0 calls / 4 days
:8002 Qwen3-Reranker RETIRED incumbent, rollback only 7 calls, 12-hourly
:8014 A4 gte-modernbert "fallback" no alias at all
nevermore is hard-wired to the incumbent by name (NEVERMORE_RERANK_MODEL=
qwen3-reranker), so the R43 cutover never moved it -- the cutover repointed the
`reranker` alias and correctly left `qwen3-reranker` naming the Qwen model.
Brokkr R43 measured that model harming 80/90 fleet queries, so nevermore's
twice-daily rerank pass is likely degrading its own briefing.
Fix is one line in nevermore's .env plus a nevermore restart, and it must land
before :8002 is retired. Recorded in persistent-memory with the A4 alias also
noted as absent (global CLAUDE.md names reranker-a4-gte-modernbert; it does not
exist).
This commit is contained in:
+11
-2
@@ -134,10 +134,17 @@ _As of 2026-08-20 23:30 — **the Heretic-300 session** (see the 🔴 entry abov
|
||||
|
||||
- **🟢 LITELLM — upgraded v1.91.0→v1.97.0, spend-log DB purged 6GB→16MB + CAPPED (2026-08-17).** `store_prompts_in_spend_logs:false` + `maximum_spend_logs_retention_period:7d`. ⚠ **1.8GB pre-upgrade pg_dump still on ana-docker `/opt/docker/compose/litellm/` — deletable now the upgrade is proven** (operator was going to call it). Commit `01b5ad9`.
|
||||
|
||||
- **⚠️ GPU zero-sum (both cards ~94–95/97.9 GB).** GPU0: gen + meromero. GPU1: fablefusion + utility cluster. Any util bump on either seat of a shared card must be checked against the co-tenant (starved meromero into a crash-loop once at 0.45). **⚠️ BOOT ORDER IS PART OF THE STATE (2026-08-20).** `--gpu-memory-utilization` sets the target as a fraction of **TOTAL** VRAM, but vLLM **refuses to start unless that whole target is FREE right now** — so at ~96.4/97.9 GB the GPU0 pair coexists *only* in the order it was originally brought up. **Restore/reboot order: `vllm-meromero-rp` to `healthy` FIRST, then `vllm-gen`** — meromero (0.52 = 49.38 GiB) is the one that cannot fit in the remainder. "First" means **observed healthy**, not a `sleep`: a 10s gap against a 2–3 min weight load cost a 7-restart crash-loop. Verify a restore against **KV-pool size** (`GPU KV cache size` / `Maximum concurrency` in the container log), not `nvidia-smi` used-MiB — the latter swings ~7 GB on allocator slack with identical serving capacity. Baselines: gen ≈14.36 GiB / 403k tok / 1.54× (h300 build: 401,550 tok / 1.53×); meromero 542,202 tok. **📊 MEASURED VRAM CENSUS 2026-08-20 23:20** (nvidia-smi PID→container, not util-fraction guesses) — **GPU0 92,572/97,887 MiB (94.6%), 5.2 GB free:** meromero 50,072 + gen 42,500. **GPU1 95,388/97,887 MiB (97.4%), 2.4 GB free:** fablefusion-probe **43,452** + selene 16,870 + reward 9,512 + lfm25 8,772 + coder 6,158 + rerank 3,586 + embed 3,304 + rerank-a3 2,314 + rerank-a4 1,420. Fleet 96.0% committed — **there is no room for a probe seat on either card without stopping something.** ⚠ **fablefusion is the single biggest reclaimable block (43.4 GB) and is nearly idle** — LiteLLM spend logs show `char-rp-probe` at **4 calls, last 2026-08-19 08:52**, vs `char-rp` (meromero) at 129 calls, last 2026-08-20 15:28.
|
||||
- **⚠️ GPU zero-sum (both cards ~94–95/97.9 GB).** GPU0: gen + meromero. GPU1: fablefusion + utility cluster. Any util bump on either seat of a shared card must be checked against the co-tenant (starved meromero into a crash-loop once at 0.45). **⚠️ BOOT ORDER IS PART OF THE STATE (2026-08-20).** `--gpu-memory-utilization` sets the target as a fraction of **TOTAL** VRAM, but vLLM **refuses to start unless that whole target is FREE right now** — so at ~96.4/97.9 GB the GPU0 pair coexists *only* in the order it was originally brought up. **Restore/reboot order: `vllm-meromero-rp` to `healthy` FIRST, then `vllm-gen`** — meromero (0.52 = 49.38 GiB) is the one that cannot fit in the remainder. "First" means **observed healthy**, not a `sleep`: a 10s gap against a 2–3 min weight load cost a 7-restart crash-loop. Verify a restore against **KV-pool size** (`GPU KV cache size` / `Maximum concurrency` in the container log), not `nvidia-smi` used-MiB — the latter swings ~7 GB on allocator slack with identical serving capacity. Baselines: gen ≈14.36 GiB / 403k tok / 1.54× (h300 build: 401,550 tok / 1.53×); meromero 542,202 tok. **📊 MEASURED VRAM CENSUS 2026-08-20 23:20** (nvidia-smi PID→container, not util-fraction guesses) — **GPU0 92,572/97,887 MiB (94.6%), 5.2 GB free:** meromero 50,072 + gen 42,500. **GPU1 86,667/97,887 MiB (88.5%), 11.0 GB free** *(after the lfm25 retirement below; was 95,388/2.4 GB)*: fablefusion-probe **43,452** + selene 16,870 + reward 9,512 + coder 6,158 + rerank 3,586 + embed 3,304 + rerank-a3 2,314 + rerank-a4 1,420. **Still no room for a ~22 GB PPL probe seat on either card without stopping something.** ⚠ **fablefusion is the single biggest reclaimable block (43.4 GB) and is nearly idle** — LiteLLM spend logs show `char-rp-probe` at **4 calls, last 2026-08-19 08:52**, vs `char-rp` (meromero) at 129 calls, last 2026-08-20 15:28.
|
||||
|
||||
- **FLEET RERANKER** = A3 (bge-reranker-v2-m3) PROD ana-ml2 GPU1 :8013. Passive watch; levers = A4 :8014 / util / 2nd replica; incumbent :8002 warm. `docs/pfi/reranker-selection-ledger.md`.
|
||||
|
||||
- **🔴 RERANKER FLEET AUDIT 2026-08-20 — the R43 cutover is only half-landed; `nevermore` is still running on the reranker Brokkr measured as HARMFUL.** Three reranker seats are up, and the usage is backwards from the design:
|
||||
- `:8013` **A3 bge-reranker-v2-m3 — PRODUCTION**, backs the `reranker` alias. **0 calls** in the 4-day spend window to 2026-08-21. 2,314 MiB.
|
||||
- `:8002` **Qwen3-Reranker-0.6B — the RETIRED incumbent**, kept warm only as a rollback path. **STILL SERVING LIVE TRAFFIC: 7 calls, 12-hourly at 03:00/15:00**, most recently 2026-08-21T03:00:31, all from api_key `dc0af5ba431b…`. 3,586 MiB.
|
||||
- `:8014` **A4 gte-reranker-modernbert — "throughput fallback"**, but it has **NO LiteLLM alias at all** (config has only `qwen3-reranker` and `reranker`; the `reranker-a4-gte-modernbert` name in global `CLAUDE.md` is **STALE — it does not exist**). Unreachable through the gateway; 1,420 MiB serving nobody.
|
||||
- **Root cause of the live-traffic finding:** `nevermore` is hard-wired to the incumbent **by name** — `/opt/docker/compose/nevermore/.env` has `NEVERMORE_RERANK_MODEL=qwen3-reranker` (+ `NEVERMORE_EMBED_MODEL=qwen3-embedding`, which is fine, that's the live embedder) pointed at the gateway. The R43 cutover repointed the `reranker` alias but **deliberately left `qwen3-reranker` naming the Qwen model** (correct under the no-false-aliases rule) — so nevermore never moved. Brokkr R43 measured that model **harming 80/90 fleet queries** (no-reranker beat it 89/90 vs 56/90), so nevermore's twice-daily rerank pass is very likely degrading its own briefing.
|
||||
- **Fix is one line in nevermore's `.env`** (`NEVERMORE_RERANK_MODEL=reranker`) + a nevermore restart — NOT a gateway restart. Do that BEFORE retiring `:8002`, or nevermore's rerank pass breaks. **Then** `:8002` and `:8014` are both genuinely free to retire (~5.0 GB).
|
||||
|
||||
- **EVIDENCE HOLD (partial):** WT #394 FILE half STILL STANDS — do NOT delete on-disk gen dirs (`fiction/rex390-dcc`, `rex392-dcc`, `b59c147c5ce0`); rex393-fiction-* + r42-gate-* KEEP.
|
||||
|
||||
- **🔴 NH3/AT&T IPv6 PD is a HARD `/64` — TESTED ON THE WIRE 2026-08-19, not inferred.** AT&T support (Christopher, `prov-dns@att.com`) said "I do not believe att will do that" and punted to consumer sales — **and he was right, though his team is DNS provisioning and the answer was a guess.** Verified empirically: the NH3 UDM solicited DHCPv6-PD at **/48, /56 AND /60** and AT&T returned **the same single `/64` (`2600:1700:b25:c11f::/64`) every time**. So it is NOT "nobody ever asked" — the request was made three ways and the server answers `/64` regardless. **How it was proven:** the PD is invisible until a LAN claims it, so `nh3-iot` (the only NH3 VLAN with **0 clients**) was temporarily set `ipv6_interface_type: pd`; then `ipv6_pd_prefixid` was set to 0, 15 and 16 — **all three returned the identical `c11f` prefix**, which is the signature of a single delegated `/64` (with any larger block the prefix-id moves the LAN within it). ⚠ **Do NOT read the WAN address vs LAN prefix gap as evidence of block size** — WAN is `c110`, delegated is `c11f`, and I initially misread that spread as a `/60`; AT&T just assigns the two from different places in their pool. **NH3 UDM was fully restored** (nh3-iot back to `none`, WAN back to `pd_size=64`); rollback artifacts at `nh3-dev:~/backups/nh3-udm/`. **THE ASK FOR AT&T BUSINESS** (this is business fiber at a commercial park — the residential org cannot change it, and 800-288-2020 is the wrong number): *"circuit solicits DHCPv6-PD at /48, /56 and /60; server returns a single /64 in all three cases; please increase the delegation size on the provisioning profile"* — a claim they can verify against their own DHCPv6 logs. **ROOT CAUSE FOUND 2026-08-19 — it is the BGW, not AT&T, and EIGHT /64s are actually available.** The CPE is a **BGW210-700, firmware 4.28.7**,management reachable at **`http://192.168.1.254`** (v4 is already IP-passthrough — the UDM holds public `70.230.226.88` directly — but passthrough covers v4 ONLY; v6 always terminates on the BGW). Its `/cgi-bin/lanstatistics.ha` and `/cgi-bin/broadbandstatistics.ha` are readable unauthenticated and give the whole picture: BGW WAN v6 = `2001:506:70b2:8958::1`, **BGW LAN v6 = `2600:1700:b25:c110::/64` (it keeps this for itself)**, delegated to the UDM = `2600:1700:b25:c11f::/64`. **So AT&T DOES hand the BGW a `/60`** (`c110`-`c11f`); the BGW keeps `c110`-`c117` and re-delegates **up to EIGHT individual `/64`s on `c118`-`c11f`**, top-down. Our UDM got `c11f` = delegation #8. **The other seven are sitting unclaimed** — not withheld by AT&T, just never solicited, because **UniFi exposes only a single `wan_dhcpv6_pd_size` integer and no 'number of prefixes' field**, so it asks once. The documented workaround is `dhclient -6 -P -P -P...` (one `-P` per prefix), which UniFi cannot express. ⇒ **An AT&T ticket CANNOT fix this** — it is CPE firmware behaviour, so Christopher's 'att won't do that' was accidentally right. Real options: (a) accept one `/64`; (b) **full BGW bypass via wpa_supplicant/EAP-TLS on the UDM** (documented working on UDM Pro; extract the BGW's 802.1X certs, authenticate to AT&T directly, negotiate the whole `/60` yourself) — ⚠ modifies NH3's ONLY uplink and must survive UDM firmware updates, so it needs a planned window with physical access, NOT an ad-hoc change. **⏳ PARKED pending the Device Access Code:** `reclaim-nh3-s-7-unclaimed-ipv6-64s-from-the` on the henge. Operator will fetch the BGW210 Device Access Code (12 digits, on the unit's label) next time he is at the NH3 office and **vault it — suggested path `unifi/bgw210-nh3-device-access-code` — after which this is drivable remotely.** First stop is `http://192.168.1.254/cgi-bin/ip6lan.ha` (**confirmed to exist, currently redirects to Login**); check for a delegation size/count control, a v6 pass-through/bridge option, or a way to stop the BGW reserving `c110`-`c117`. If the UI can do it, that is a SUPPORTED fix and the wpa_supplicant bypass is unnecessary. Other settings pages behind the same login: `ippass.ha` (how v4 passthrough was set up), `dhcpserver.ha`, `firewall.ha`, `broadbandconfig.ha`, `packetfilter.ha`, `remoteaccess.ha`, `restart.ha`. Consequence if left alone: **NH3 has ONE v6 segment**, vs ESH's `/56` (256), which makes NH3 the prefix-constrained site in any fleet v6 design.
|
||||
@@ -165,7 +172,9 @@ _As of 2026-08-20 23:30 — **the Heretic-300 session** (see the 🔴 entry abov
|
||||
⚠ **Never set the ZFS cachefile on one pool.** The runbook's `zpool set cachefile=… nvme` was a trap: populating a cache flips the host from import-by-scan to import-by-cache, so a cache holding only `nvme` leaves `ssd`+`tank` unimported and empties every CT 103 export. Set on all three 2026-08-18, verified in the 11,976-byte cache.
|
||||
⚠ **Migrate FIRST, patch after** — a signed kernel would land in `/boot` on the 1.3 GB root. ⚠ **CT 103 `esh-nas` (10.0.50.50) runs on this host and serves `hard` NFS to esh-docker-vm and esh-pve — quiesce both before any reboot** or you wedge esh-docker-vm into D-state. Off-box at `nh3-dev:~/backups/esh-pve-nas/`: DOM image `dom-sdq-20260818.img.zst` (2.38 GiB, crash-consistent), clean `bootchain-20260818.tar.gz`, config snapshot `…20260818T051*.tar.gz`. Runbook `docs/runbooks/esh-pve-nas-boot-migration.md`; detail → `persistent-memory.d/2026-08-17-esh-pve-nas-dom.md`.
|
||||
|
||||
- **OPEN FOLLOW-UPS (parked):** move gen seat off pinned-nightly to stable once #51113 ships; Lobe one-time TTS UI pass; delete the 1.8GB litellm dump; `harden-esh-docker-vm` (park id 28, PROMOTED — Tier-1 done, `/mnt/books` stays hard w/ watchdog); chatterbox-fast build-context divergence; #363 research-wing ingest (no deadline); optionally attach our MTP reproducer to vllm#47087 (needs a GitHub identity — operator's call).
|
||||
- **⚪ LFM2.5-2.6B RETIRED PERMANENTLY 2026-08-20 (operator directive).** `vllm-lfm25` (:8021, GPU1) removed: service deleted from `stacks/vllm/compose.yaml` + pushed live (backup `compose.yaml.bak-pre-lfm25-retire-20260820`), container `docker rm -f`'d, `lfm2.5-2.6b` alias deleted from the LiteLLM config (live + canonical; backup `config.yaml.bak-pre-lfm25-retire-20260820`, 28→27 models). **Freed 8,721 MiB on GPU1.** Justification: it was an EVAL-ONLY bake-off seat vs `granite-4.1-8b` (brokkr R-target 2026-08-10) that never received the operator ruling it was pending; the comparator was retired from the roster 2026-08-15; it was deliberately never in any default/fallback routing chain; and spend logs showed **0 calls in the 4-day window**. Weights remain in the shared HF cache — nothing deleted from disk. ⚠ **The gateway restart that makes the alias-deletion take effect was HELD** so it could batch with a reranker change — until `docker restart litellm` runs, `lfm2.5-2.6b` is still routable in-memory and will error against a dead backend. ⚠ `vllm-granite` is **still a defined service** in `stacks/vllm/compose.yaml` though the model was retired 2026-08-12 — dead config, 0 VRAM (stopped), worth the same cleanup pass.
|
||||
|
||||
- **OPEN FOLLOW-UPS (parked):** repoint `nevermore` off the retired reranker (see the 🔴 reranker audit) then retire `:8002`/`:8014`; delete the dead `vllm-granite` service block; move gen seat off pinned-nightly to stable once #51113 ships; Lobe one-time TTS UI pass; delete the 1.8GB litellm dump; `harden-esh-docker-vm` (park id 28, PROMOTED — Tier-1 done, `/mnt/books` stays hard w/ watchdog); chatterbox-fast build-context divergence; #363 research-wing ingest (no deadline); optionally attach our MTP reproducer to vllm#47087 (needs a GitHub identity — operator's call).
|
||||
|
||||
- **althing monitor** ARMED (handle `infra-ops`). ⚠️ Re-arm ONLY after a real FIRE (rc0), never after a plain operator turn (bounces rc3); spawn `althing-wake-listener` as its OWN `run_in_background` task, never chained with `&` (orphans it — hit this twice 2026-08-17, `stop-monitor` reclaims).
|
||||
|
||||
|
||||
@@ -513,22 +513,12 @@ model_list:
|
||||
# model names. Removed so unknown models now fail loudly (404). Re-add an
|
||||
# explicit per-model entry if a swappable zoo ever returns. ---
|
||||
|
||||
# --- lfm2.5-2.6b -> LiquidAI LFM2.5-2.6B (ana-ml2 GPU1 :8021, vLLM). NON-PROD bake-off
|
||||
# vs granite-4.1-8b (brokkr R-target 2026-08-10). LFM Open License v1.0 (<USD 10M-rev
|
||||
# commercial) - EVAL-ONLY pending operator ruling; NOT in any default/fallback chain.
|
||||
# Reasoning model served raw (no vLLM reasoning-parser) so content is non-empty.
|
||||
# Vendor sampling (temp 0.1 / top_k 50 / rep_pen 1.1) baked as the alias default. ---
|
||||
- model_name: lfm2.5-2.6b
|
||||
litellm_params:
|
||||
model: hosted_vllm/lfm2.5-2.6b
|
||||
api_base: http://10.250.50.54:8021/v1
|
||||
api_key: os.environ/VLLM_API_KEY
|
||||
temperature: 0.1
|
||||
extra_body:
|
||||
top_k: 50
|
||||
repetition_penalty: 1.1
|
||||
model_info:
|
||||
mode: chat
|
||||
# --- lfm2.5-2.6b -> RETIRED PERMANENTLY 2026-08-20 (operator directive). The
|
||||
# LiquidAI LFM2.5-2.6B seat (ana-ml2 GPU1 :8021) was an EVAL-ONLY bake-off
|
||||
# against granite-4.1-8b that never got its operator ruling; its comparator
|
||||
# was retired 2026-08-15 and spend logs showed 0 calls in the 4 days to
|
||||
# 2026-08-21. Container removed, service deleted from stacks/vllm. The alias
|
||||
# is deleted rather than repointed so the name 404s cleanly. ---
|
||||
|
||||
general_settings:
|
||||
master_key: os.environ/LITELLM_MASTER_KEY
|
||||
|
||||
@@ -342,78 +342,15 @@ services:
|
||||
- homepage.description=Qwen2.5-Coder-1.5B FIM code-completion (ana-ml2, Zed edit-predictions)
|
||||
- homepage.href=http://10.250.50.54:${CODER_PORT}/docs
|
||||
|
||||
vllm-lfm25:
|
||||
image: vllm/vllm-openai:${VLLM_VERSION}
|
||||
container_name: vllm-lfm25
|
||||
restart: unless-stopped
|
||||
ipc: host
|
||||
ports:
|
||||
- "${LFM25_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:
|
||||
# LiquidAI/LFM2.5-2.6B (BF16, Lfm2ForCausalLM). NON-PRODUCTION bake-off alias
|
||||
# vs granite-4.1-8b on structured extraction / classification / tool-call
|
||||
# formatting (brokkr R-target, 2026-08-10). LFM Open License v1.0 (<USD 10M-rev
|
||||
# commercial, not OSI) — EVAL-ONLY pending an operator ruling on production; NOT
|
||||
# wired into any default/fallback routing chain. Reasoning model: the chat
|
||||
# template opens <think>; deliberately NO --reasoning-parser, so the full
|
||||
# generation (thinking + answer) lands in `content` non-empty — brokkr's explicit
|
||||
# requirement (an empty content with the answer stranded in reasoning_content
|
||||
# reads as a degenerate model). Vendor sampling (temp 0.1 / top_k 50 / rep_pen 1.1)
|
||||
# is the LiteLLM alias default, not a launch arg.
|
||||
- ${LFM25_MODEL}
|
||||
- --served-model-name
|
||||
- ${LFM25_SERVED_NAME}
|
||||
- --host
|
||||
- 0.0.0.0
|
||||
- --port
|
||||
- "8000"
|
||||
- --gpu-memory-utilization
|
||||
- ${LFM25_GPU_MEM_UTIL}
|
||||
- --max-model-len
|
||||
- ${LFM25_MAX_MODEL_LEN}
|
||||
- --max-num-seqs
|
||||
- ${LFM25_MAX_NUM_SEQS}
|
||||
- --dtype
|
||||
- auto
|
||||
- --kv-cache-dtype
|
||||
- ${LFM25_KV_CACHE_DTYPE}
|
||||
- --enable-prefix-caching
|
||||
# Split the <think> reasoning (delimited by </think>; the opening tag is
|
||||
# injected by the chat template into the prompt) into reasoning_content, so
|
||||
# `content` is the clean post-</think> answer — scoreable JSON for brokkr's
|
||||
# structured-extraction bake-off (raw-served, reasoning prepended, is not).
|
||||
- --reasoning-parser
|
||||
- deepseek_r1
|
||||
deploy:
|
||||
resources:
|
||||
reservations:
|
||||
devices:
|
||||
- driver: nvidia
|
||||
device_ids:
|
||||
- "${LFM25_GPU_ID}"
|
||||
capabilities:
|
||||
- gpu
|
||||
healthcheck:
|
||||
test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
|
||||
interval: 30s
|
||||
timeout: 10s
|
||||
retries: 3
|
||||
start_period: 300s
|
||||
networks:
|
||||
- tnet
|
||||
labels:
|
||||
- homepage.group=AI - Inference
|
||||
- homepage.name=vLLM LFM2.5-2.6B (bake-off)
|
||||
- homepage.icon=mdi-flask-outline
|
||||
- homepage.description=LiquidAI LFM2.5-2.6B non-prod bake-off vs granite (ana-ml2)
|
||||
- homepage.href=http://10.250.50.54:${LFM25_PORT}/docs
|
||||
# vllm-lfm25 (LiquidAI/LFM2.5-2.6B, :8021) — RETIRED PERMANENTLY 2026-08-20 by
|
||||
# operator directive. It was an EVAL-ONLY bake-off seat against granite-4.1-8b
|
||||
# (brokkr R-target, 2026-08-10) that never received the operator ruling it was
|
||||
# pending. Its comparator is gone (granite retired from the roster 2026-08-15),
|
||||
# it was deliberately never wired into any default/fallback routing chain, and
|
||||
# LiteLLM spend logs showed 0 calls in the 4-day window ending 2026-08-21.
|
||||
# Freed 8,772 MiB on ana-ml2 GPU1. The `lfm2.5-2.6b` gateway alias was removed
|
||||
# in the same pass so the name 404s cleanly rather than erroring against a dead
|
||||
# backend. Weights remain in the shared HF cache; nothing was deleted from disk.
|
||||
|
||||
networks:
|
||||
tnet:
|
||||
|
||||
Reference in New Issue
Block a user