13, 13b and A4: progress a client can actually use, and a still that is not 70s
13. A request may name itself (`request_id` in the body, or an X-Request-Id
header) and poll /v1/{images,video,audio}/progress?request_id=... for its OWN
steps. One global slot per media type meant two callers could not tell their
progress apart, so a client stopped reading them altogether and showed no step
progress at all while the server was drawing. The name is used as the TASK id,
so this is a VIEW over the existing task registry -- which already tracks
step/total/status per task under a lock and prunes finished ones -- rather than
a second place progress is written. Claimed once, because a request registers
a short "loading" task as well and both adopting the id would serve the client
whichever happened to be last. Unknown id = 404, so a client stops polling on
a definite answer instead of reading somebody else's progress.
13b. The encode reports frames written (`encoding 1200/2400 frames`) across the
band it owns, so the longest step of a render stops looking like a stall; and
the job's own log, kept all along but unreachable, is served as a tail in the
status document plus GET /v1/video/compose/{id}/log?since=N for the whole
thing incrementally. The record holds the live list, not a snapshot.
A4. 72s per 768x1344 still -> 21.4s, measured on an idle 3090. The card carried
`offload_strategy: "model"`, which is the model page's DEFAULT, so
enable_model_cpu_offload() ran on a model that fits a 23.56 GB card whole and
paid PCIe for it on every request. `auto` loads on GPU and falls back to
offload only on OOM. The doc's other hypothesis is ruled out rather than
assumed: the live progress endpoint reports total=10, so the card's step count
IS applied, and an explicit steps=10 takes the same 21.2s.
Also: `models.civitai_cache_dir`, configured like hf_cache_dir and
gguf_cache_dir because it is the same kind of thing. Unset, these
multi-gigabyte checkpoints land beside the other caches -- on this host a
140 GB volume, which a 13.5 GB checkpoint took to 99% until the next model
could not write even its config fetch ("No space left on device"). That is
what was actually stopping Z-Image-Turbo-IntoRealism from loading at all.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZnLhydX9QqUcfBbqLu
Showing
Please
register
or
sign in
to comment