Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#11,814 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@modelpath-dev ya está trabajando en esto.

Desde el 4/9/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, postgres
Área
api, distributed-systems, frontend

Línea de trabajo

Rastrea las comprobaciones de dimensionamiento de Model Gallery en /app/models e identifica cómo consumen /api/resources. Compara esa ruta con /api/nodes y con el comportamiento existente de planificación distribuida; se considera terminado cuando el panel YOUR HOST y los indicadores de ajuste de cada modelo usan la capacidad de los nodos registrados en Distributed Mode, mientras que las comprobaciones de disponibilidad ya no se quedan bloqueadas con varios nodos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
50k
Forks
4.6k
Merge medio
20 h 40 min
PR fusionados (30 d)
341

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de mudler/LocalAI

Todos los issues de mudler/LocalAI

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.