Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Local node's GPU/CPU/memory enrichment is never refreshed after startup

未关闭
#4 1 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 2 天内回复

@ckelseynv 已经在做这个了。

开始于 2026年9月11日。

  • #5 来自 @canja006 —— 未关闭

评估

这个 Issue 还没有评估数据。

描述

The discovery directory's enrichment for the local node is captured once and then frozen. Peers converge; self does not.

What I measured

Ubuntu node with an RTX 3060, paired with a macOS node, v0.1.1-463 from the .deb.

I loaded a 7 GB model into LM Studio with full GPU offload. nvidia-smi went from 121 MiB to 9329 MiB. node-info served the new figure within its usual cadence — curl 127.0.0.1:14318/v1/node-info returned vram_used_bytes: 9782165504 with telemetryValid: true, msSince: 280. The desktop UI's VRAM graph showed the step too, because it reads the node directly.

The discovery snapshot did not move. discovery:get-nodes kept returning vram_used_bytes: 126877696 — the value from daemon start — for as long as I watched, checked at 20 s intervals over several minutes. Restarting the broker made it correct again, until the next change.

Why

onBrowse deliberately skips our own entry (daemon.go: "Never let a browse event touch our own entry. Self is registry-driven"), so the path that re-enriches every peer on every browse never runs for self. publishSelf — the only thing that enriches self — is called at startup, on service (un)register, and after an identity/address change. refreshPeersLoop refreshes advertised addresses, the mesh, cluster identity and models on its 15 s tick, but nothing re-reads self's node-info.

Worth noting that the comment above noteNodeInfo already states the intended behaviour:

The enrichment sweep repeats every peerRefreshInterval for as long as a node is advertised

That holds for peers, not for self.

Who sees it

Only consumers of the discovery snapshot — which includes nvpair-job-scheduler, since the broker fans the same snapshot to it. The UI is unaffected, which is why this is easy to miss.

Repro

  1. Pair two nodes; note the local node's gpus[].vram_used_bytes via discovery:get-nodes.
  2. Load a large model with GPU offload on that node.
  3. curl 127.0.0.1:14318/v1/node-info — fresh.
  4. discovery:get-nodes — unchanged, indefinitely.

A fix that works

Calling d.publishSelf() on the refreshPeersLoop tick converges the directory within 20 s. Verified live in both directions, loading and unloading. It does mean one self node-updated per tick, since publishSelf emits unconditionally; the tidier alternative is an applyInfo path with a changed check, mirroring applyModels. Happy to open a PR for either shape if useful.

主要语言
Go
星标
1.6k
派生
277
平均合并
4 天 18 小时
30 天内合并 PR
33

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

NVIDIA/Personal-AI-Router 的其他 Issue

查看 NVIDIA/Personal-AI-Router 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。