• 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
Name
Last commit
Last update
..
admin Loading commit data...
api Loading commit data...
backends Loading commit data...
broker Loading commit data...
cluster Loading commit data...
compose Loading commit data...
frontproxy Loading commit data...
models Loading commit data...
ocr Loading commit data...
openai Loading commit data...
pydantic Loading commit data...
queue Loading commit data...
tasks Loading commit data...
util Loading commit data...
__init__.py Loading commit data...
cli.py Loading commit data...
config.py Loading commit data...
hf_cache.py Loading commit data...
main.py Loading commit data...
ocr_fleet_workers.py Loading commit data...
platform_paths.py Loading commit data...
system_app.py Loading commit data...