Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Model Gallery sizing ("YOUR HOST") ignores registered Distributed Mode nodes

Aperta
  • Qualcosa non va?
#11,814 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@modelpath-dev ci sta già lavorando.

Dal 4/9/2026.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, postgres
Ambito
api, distributed-systems, frontend

Direzione di ricerca

Traccia i controlli di dimensionamento di Model Gallery su /app/models e identifica come consumano /api/resources. Confronta questo percorso con /api/nodes e con il comportamento esistente della pianificazione distribuita; il lavoro è completato quando il pannello YOUR HOST e gli indicatori di compatibilità per modello usano la capacità dei nodi registrati in Distributed Mode, mentre i controlli di disponibilità non rimangono più bloccati con più nodi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area/p2p area/webui bug need-more-information waiting-from-reporter

Description

In Distributed Mode, the Model Gallery's "will this model fit" sizing check (the "YOUR HOST" panel and per-model fit indicators on /app/models) reads from /api/resources, which only reports the frontend's own local resources — not the aggregated/best-fit capacity of registered worker nodes from /api/nodes. This makes the Gallery sizing feature actively misleading (and in our case, useless) for any deployment where the frontend itself is a lightweight/non-compute host and real compute lives on registered distributed nodes.

Setup

  • v4.9.0, Distributed Mode enabled (LOCALAI_DISTRIBUTED=true, NATS + Postgres backing store, two nodes registered via local-ai worker --register-to)
  • Frontend runs on a small LXC container with 2GB RAM and no GPU — intentionally, it's meant to be a thin gateway
  • Two healthy compute nodes registered: one with an NVIDIA GPU (12GB VRAM), one Apple Silicon (16GB unified memory, capability: metal)

Evidence

GET /api/nodes correctly reports both real nodes:

[
  {"name":"AMXELA-Main","status":"healthy","gpu_vendor":"nvidia","total_vram":12884901888,"total_ram":67208949760,...},
  {"name":"MacBookAir.localdomain","status":"healthy","gpu_vendor":"apple","capability":"metal","total_vram":17179869184,"total_ram":17179869184,...}
]

But GET /api/resources (what the Gallery's "YOUR HOST" panel and sizing checks use) only ever reports the frontend's own tiny footprint, oblivious to any registered node:

{"aggregate":{"total_memory":2147483648,"used_memory":176013312,"free_memory":1971470336,"usage_percent":8.2,"gpu_count":0},"gpus":null,"ram":{"total":2147483648,...},"type":"ram",...}

Actual model scheduling/placement (via /api/node/register, NATS backend.install, and LOCALAI_MODEL_SCHEDULING node selectors) correctly uses the real node capacity from /api/nodes — we confirmed models schedule and run correctly on the appropriate node based on real hardware. So the underlying distributed capability-awareness works; it's specifically the Gallery UI's "will this fit" sizing feature that's still wired to the pre-distributed-mode single-host /api/resources data source and was never updated to consider the cluster.

Expected behavior

When Distributed Mode is enabled and nodes are registered, the Gallery's sizing/fit indicators should evaluate against the best-fit registered node's capacity (or an aggregate/max across nodes), not just the frontend host's own resources. As-is, on a thin-gateway deployment, the Gallery reports every model as basically not fitting anywhere, regardless of what real compute is actually available on the cluster.

Also observed (may be a separate/related issue)

The Gallery's model list gets stuck on "Checking availability..." indefinitely once 2 nodes are registered (worked fine, if inaccurately, with a single implicit host). Unconfirmed whether this is a performance issue from checking many gallery models against multiple nodes, or a separate bug — noting it here in case it's related to the same code path.

Lingua principale
Go
Stelle
50k
Fork
4.6k
Merge medio
21h 20m
PR unite (30g)
337

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mudler/LocalAI

Tutte le issue di mudler/LocalAI

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.