master-956: post-graph-cut weight re-load pathologically slow (MB/s) - 11.5x wall-time regression on Qwen-Image vs master-945 (Vulkan, 16 GB) #2127

Activity

1. laurentvv commented on Oct 11, 2026

   

   laurentvv

   on Oct 11, 2026

   Author

   More actions

   Withdrawn — not a build regression. Closing.

   Further testing within the hour disproved the binary A/B:

   • The restored master-945 binary (same 2-step probe, then the full factory workflow with --offload-to-cpu) shows the same slow post-graph-cut re-read (265 tensors at 2.78-30 MB/s across runs, and an 11.5x-slow full render), on the SAME install where the morning run measured 123.4 s.
   • Root cause found on our side: the models live on an external USB 3.0 spinning drive (TOSHIBA 2 TB). The post-graph-cut tensor re-read hits real disk once the file is evicted from the page cache (the morning clean 123.4 s ran with the 7 GB model still cached in RAM; after the day's 29 GB-RAM H3 runs it was not). Read throughput on that device varies 3-30 MB/s depending on seek order — which also explains why my two "A/B" probes (5.66 vs 30.4 MB/s) differed: same disk, different cache/seek state, minutes apart.

   So: same-day machine-state confound, no master-956 regression demonstrated. The observed behavior (post-graph-cut re-read of all DiT tensors, disk-bound) is still real and maybe interesting for a cold-cache optimization, but it is not what this issue claimed. Sorry for the noise — closing as invalid.

   (The #1976 H3 datapoint on 956 posted earlier stands — that one is a deterministic memory-graph signature, unrelated to disk speed.)
2. laurentvv

   closed this as not plannedon Oct 11, 2026