Low priority — no user impact (the omniswap pool resolves aliases and forwards correctly; only direct-to-node /models/unload by alias is affected). Filing to track, surfaced during the gems Pascal roll.
Observed
On llama-pascal (sm_61) built from ht 5adf3b6cd, a hot model loaded via the preset alias gemma-4-12b-256k (canonical id gemma-4-12B-it-qat-UD-Q4_K_XL):
GET /v1/models → lists gemma-4-12b-256k ✓POST /models/unload {"model":"gemma-4-12b-256k"} → 400 model is not found even while HOTPOST /models/unload {"model":"gemma-4-12B-it-qat-UD-Q4_K_XL"} (canonical) → 200 ✓
(repro by crystal-mom; pool end-to-end matrix is green: hot→200, cold→200 already_unloaded, unknown→400.)
Code analysis (at 5adf3b6cd)
This should work: server_models::get_meta (tools/server/server-models.cpp:634-646) resolves both the direct mapping key and aliases (inst.meta.aliases.count(name) at :641), and post_router_models_unload (:1511-1534) calls get_meta(name) then is_running(). #118 only changed the running/not-running branch, not name resolution. So a 400 means gemma-4-12b-256k is not registered as an alias of the loaded canonical instance at unload time.
Likely cause (UNCONFIRMED — needs a look at the node mapping table)
Current ht added a models-dir / HF catalog scan: native /v1/models now returns ~28 bare GGUF entries (LCO-Embedding, Nanbeige, gemma-4-31B/26B variants, mmproj-*, …), not just configured presets. Hypothesis: the scan registers the GGUF under its filename id and the preset’s alias = binding does not attach to (or is shadowed on) the loaded instance, so inst.meta.aliases lacks the alias when unload runs.
Asks
- Is the models-dir catalog scan intended to register bare GGUFs as first-class
/v1/models entries? (Harmless for pooled clients — peer models: allow-lists gate the union — but it changes native /v1/models semantics.)
- Ensure preset aliases attach to the loaded instance’s
meta.aliases so get_meta resolves them at unload (parity with /v1/models, which already lists the alias).
Related: #118 (idempotent unload), #66 (router models subsystem / per-device fit).
Low priority — no user impact (the omniswap pool resolves aliases and forwards correctly; only direct-to-node
/models/unloadby alias is affected). Filing to track, surfaced during the gems Pascal roll.Observed
On
llama-pascal(sm_61) built from ht5adf3b6cd, a hot model loaded via the preset aliasgemma-4-12b-256k(canonical idgemma-4-12B-it-qat-UD-Q4_K_XL):GET /v1/models→ listsgemma-4-12b-256k✓POST /models/unload {"model":"gemma-4-12b-256k"}→ 400model is not foundeven while HOTPOST /models/unload {"model":"gemma-4-12B-it-qat-UD-Q4_K_XL"}(canonical) → 200 ✓(repro by crystal-mom; pool end-to-end matrix is green: hot→200, cold→200
already_unloaded, unknown→400.)Code analysis (at
5adf3b6cd)This should work:
server_models::get_meta(tools/server/server-models.cpp:634-646) resolves both the direct mapping key and aliases (inst.meta.aliases.count(name)at :641), andpost_router_models_unload(:1511-1534) callsget_meta(name)thenis_running(). #118 only changed the running/not-running branch, not name resolution. So a 400 meansgemma-4-12b-256kis not registered as an alias of the loaded canonical instance at unload time.Likely cause (UNCONFIRMED — needs a look at the node mapping table)
Current ht added a models-dir / HF catalog scan: native
/v1/modelsnow returns ~28 bare GGUF entries (LCO-Embedding, Nanbeige, gemma-4-31B/26B variants, mmproj-*, …), not just configured presets. Hypothesis: the scan registers the GGUF under its filename id and the preset’salias =binding does not attach to (or is shadowed on) the loaded instance, soinst.meta.aliaseslacks the alias when unload runs.Asks
/v1/modelsentries? (Harmless for pooled clients — peermodels:allow-lists gate the union — but it changes native/v1/modelssemantics.)meta.aliasessoget_metaresolves them at unload (parity with/v1/models, which already lists the alias).Related: #118 (idempotent unload), #66 (router models subsystem / per-device fit).