Model Gallery sizing ("YOUR HOST") ignores registered Distributed Mode nodes
メンテナーはふだん 1 日以内に返信
@modelpath-dev がすでに取り組んでいます。
2026年9月4日 から。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 55/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- go, postgres
調査の方向性
/app/models の Model Gallery のサイズチェックを追跡し、それらが /api/resources をどのように利用しているかを特定します。その経路を /api/nodes および既存の分散スケジューリングの動作と比較します。完了条件は、YOUR HOST パネルとモデルごとの適合インジケーターが Distributed Mode で登録済みノードの容量を使用し、複数ノードの場合でも可用性チェックが止まったままにならないことです。
索引モデルが issue の本文から書いたものです。
説明
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 vialocal-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.
- 主要言語
- Go
- スター
- 50k
- フォーク
- 4.6k
- 平均マージ
- 20時間 31分
- マージ済み PR（30日）
- 333
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
mudler/LocalAI のほかの issue
-
[Bug] Qwen3.8-27b Uncensored Fails to Download due to 404再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンbug unconfirmed
難易度 1/5 1時間未満 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
Realtime: ASR EOU language tags leak into the LLM conversation (unintended reply-language switching)対応中かも @nexxtmobile が 12 日前に担当しました。 オープンarea/api bug unconfirmed
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
Open Responses API doesn't accept "output_text" as an input Item再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンbug unconfirmed
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
mudler/LocalAI#12337 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Gallery model audio-cpp-sortformer-diarization fails to install: SHA mismatch, reproducible across retries再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
mudler/LocalAI#11995 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Agent pool Postgres DSN is logged in cleartext, including the password, while the auth DSN is redacted対応中かも @localai-org-maint-bot が 47 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
mudler/LocalAI#11991 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
[Bug]: Anthropic Responses converter forwards empty text blocks, upstream rejects with 400対応中かも @david-choi-querypie が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
area:web p3
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
Lets-Parley/Parley#912 ·
メンテナーはふだん 1 日以内に返信
-
bug observability
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
sagar2395/snowopslabs#164 ·
メンテナーはふだん 1 日以内に返信
-
enhancement help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
Git-Hospital/githealthcheck#61 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
afreidah/s3-orchestrator#1824 ·
メンテナーはふだん 1 日以内に返信