From 539bdac152aa57155cc280dfaad86eddc2db9528 Mon Sep 17 00:00:00 2001 From: Ilker Manap Date: Fri, 25 Sep 2026 14:43:47 +0200 Subject: [PATCH] Say where the fetch progress actually goes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The gap list said a fetch "reports no progress". It does — the agent logs a percentage as it downloads, with a comment saying a replica pulling a hundred gigabytes and one that is wedged look identical from the control plane. That comment describes the real gap, which is narrower and more useful than the one written down: the progress exists, it just never leaves the node, so the operator looking at ctl or the dashboard still cannot tell those two apart. Co-Authored-By: Claude Opus 5 (1M context) --- docs/install.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/install.md b/docs/install.md index 9324278..1d9a01f 100644 --- a/docs/install.md +++ b/docs/install.md @@ -735,9 +735,12 @@ requests. On a slow model, set `timeouts.generation` higher. ## Known gaps, so you find them here rather than at 2am -- **A fetch is silent while it runs.** llmgw will fetch weights for you, but - it reports no progress, so a first start on a large model looks like a hang. - `ls -l` in the model directory is the only progress bar there is. +- **A fetch reports its progress where nobody is looking.** The agent logs a + percentage as it downloads, so `journalctl -u llmgw-agent` on that node knows + exactly how far along it is. Nothing carries it to the control plane, so from + `ctl` or the dashboard a replica pulling a hundred gigabytes and one that is + wedged still look identical — which is the comparison the log line itself + says matters. - **Every node fetches its own copy.** There is no seeding between nodes, so bringing up eight nodes on a new model is eight downloads from the same origin. On a fabric where the nodes can see each other this is wasteful, and