• Stefy Lanza (nextime / spora )'s avatar
    13, 13b and A4: progress a client can actually use, and a still that is not 70s · e3bb5c46
    Stefy Lanza (nextime / spora ) authored
    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: 's avatarClaude Opus 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_014T3rZnLhydX9QqUcfBbqLu
    e3bb5c46
test_per_request_progress.py 6.82 KB