weeyuga-benchmarks-public/runs/3cc53336-2555-5e90-99c3-7b94dcb40acc/run.md

# Images, music, and the limits of video on a 6 GB GTX 1060

An older gaming GPU can still produce a useful library of images and short music clips. Our October 2026 Packet Foundry campaign on a Windows GTX 1060 with 6 GB VRAM now retains **143 generated files: 130 images, 11 videos and two music clips**, across **150 recorded attempts**. The images include the 100-request FLUX study, ten earlier checks, ten Qwen Turbo Q4 follow-up images and ten matched Q8 comparison outputs. The user judged both music samples usable; videos range from recognizable but flawed motion to colored noise. Every poor output and all seven no-output failures remain in the archive.

The most useful result is the range: roughly a minute for a 512-pixel image in the large FLUX.3 study, around eleven minutes for fifteen seconds of music, and anything from under two minutes to more than an hour for a short video. Those numbers describe these exact configurations and timing boundaries. They are not a general ranking of the models.

Browse the [complete benchmark and retained media](https://benchmarks.weeyuga.com/benchmarks/predator-media-20261021.html) for prompts, seeds, checkpoints, settings, failures and individual timings.

## What we actually tested

The hardware was a GTX 1060 with 6 GB of dedicated VRAM and approximately 28 GiB of system RAM, running Windows 10. ComfyUI 0.42.1 supplied the model runtime. Packet Foundry handled the request, capability routing, execution, media transfer and result acknowledgement; factories connected outward through its registry. LangSmith recorded attempts and media attachments, with completed batches also exported as native comparable experiments where verified.

This was a real application path rather than a model running in an isolated timing loop. In the tables below, **Factory trace time** includes adapter work, loading, model execution and polling. Native Comfy graph durations have different boundaries. A node's observed interval can include preparation, casting and delivery of progress events; it is not an exact GPU kernel time or weight-loading measurement.

We kept operating-system caches, other existing device workloads and the recorded background downloads. These are practical deployment observations with documented confounders, not controlled laboratory throughput measurements. Some initial image pairs deliberately changed a red ceramic fox to blue, as well as changing seed 42 to 43. That forced fresh text conditioning while testing retained loader state; it was not a matched-prompt quality comparison.

## Images: one hundred requests, fifty briefs

The larger image study used FLUX.3 klein SD Q4_K_M at 512 × 512, four Euler steps and CFG 1. Ten scene families each had five increasing levels of detail, from a short description to a long brief with composition, materials, lighting and spatial constraints. Each of those fifty briefs ran twice consecutively, with seeds 42 and 43. The result was exactly 100 successful, retained images, with no failed or cancelled request in that study.

Briefs ranged from 16 to 463 words. Scenes included a fox crossing a creek, tea beside a rainy window, a botanical library and a crafted paper ocean. This matters because a single attractive sample tells little about whether a setup remains usable across subjects and longer instructions.

| FLUX.3 100-image study | Factory trace time |
|---|---:|
| Median across all 100 images | 55.94 s |
| 95th percentile | 99.69 s |
| First request after the fresh process | 242.34 s |
| Median of first seed variants | 74.03 s |
| Median of next seed variants | 39.40 s |

The paired speed difference has concrete cache evidence. Positive conditioning executed fifty times and was reused fifty times; negative conditioning executed once and was reused ninety-nine times. Sampling still ran for each changed seed. Fresh positive-conditioning intervals had an approximate 31.69-second median from recorded event boundaries. Calling every first image “cold” would obscure that most first variants reused an already running model while encoding a new brief.

Longer tiers also tended to take longer, but prompt length, requested detail, seed and cache context change together. This study does not isolate a causal “seconds per word” effect or establish that a longer prompt gives a better image.

We also checked what reached the encoder. The application added an eleven-word instruction/source envelope to each brief. Observed padded token slots ranged from 80 to 640; 80 was not a demonstrated fixed prompt limit. Padded slots include template and padding positions. We have not established content-only token counts or ruled out every tokenizer-internal truncation path. A long prompt being accepted is not proof that every requested detail survived encoding or appeared in the result.

All 100 thumbnails depicted recognizable scene families. Exact lettering, anatomy and compliance with every constraint remain unscored. The gallery lets readers inspect both seeds and the full prompts rather than treating a successful decode as an aesthetic rating.

Earlier fresh-prompt image pairs covered three generators. Their trace times show how much the particular runtime and retained state matter:

| Initial 512 × 512 image pair | First request | Following request |
|---|---:|---:|
| FLUX.3 klein SD Q4_K_M, four steps | 278.63 s | 73.01 s |
| Qwen Image 2.1 Q4_K_M, 25 steps | 716.02 s | 392.57 s |
| FLUX.1 dev Q4_0, twenty steps | 719.67 s | 560.32 s |

These pairs retained the same Comfy process and loader state, with fresh conditioning and sampling on the second request. They used different architectures, step counts and settings, so this table is a record of tested configurations rather than an equal-quality speed contest. Earlier functionality checks, a delivery interruption and an explicit factory-restart recovery test are archived separately instead of being folded into clean pair statistics.

## Generating several variations of one image brief

A useful production workflow is to ask for five seed variations of one brief and choose the preferred image. Our actual evidence covers **two seed variants per brief**, not five, but it shows why keeping those requests together matters.

The existing FLUX.3 study gives the stronger repeated evidence: all **50 second requests** reused both positive and negative text conditioning in the same runtime. Every paired graph differed only in sampler seed 42→43, the sampler ran again, and all 50 pairs produced different retained images. Excluding the initial-load pair, the other 49 pairs had a first/new-brief native median of **70.05s** and a following same-brief median of **38.49s**. The median within-pair saving was **32.12s**, with a median per-pair speed ratio of **1.85×**. Those are native server boundaries, separate from the Factory trace table above.

| Measured FLUX.3 population | First/new-brief native median | Same-brief second native median |
|---|---:|---:|
| All 50 pairs | 71.67s | 38.40s |
| 49 pairs excluding initial loading | 70.05s | 38.49s |

The actual gap from first completion to the second start ranged from **10.422–31.712s**, with a **22.380s** median. These were consecutive requests with observed cache reuse, not zero-gap batch execution. The measured savings closely track the skipped positive encoding, but we did not randomize seed order or run a matched cache-disabled control. A copied encoder-probe duration on a cached request records its earlier encoding; it is not extra encoder work in the second request.

### Qwen Image 2.1 Turbo: ten additional images

We also tested the distinct `unsloth/Qwen-Image-2.1-Turbo-GGUF:Q4_K_M` checkpoint at 512×512, eight Euler steps and CFG1, using the exact official ManualSigmas schedule. All ten retained outputs passed the Foundry relay, independent PNG/checksum checks, actual LangSmith attachment retrieval and the native ten-case experiment check. Every original was also inspected visually; successful delivery does not remove material, geometry or prompt-adherence defects, which remain with each image in the gallery.

Its first image took **320.246s native**, including loading and encoding. The next seed of the same brief took **95.234s** after an actual **34.322s** gap. Text encoding was cached; sampling and decoding executed again. This first-to-second difference combines initial/model-loading and encoding reuse; it does not isolate text-cache benefit alone. The eight following **new briefs**, still using the retained model runtime, had a native median of **199.712s**, range **194.865–223.135s**. Cached seed-variation time therefore must not stand in for fresh-brief latency.

The practical arrangement is to keep a brief's complete composed prompt, input materials and relevant settings identical and send its seed variations consecutively to the same factory, profile and Comfy runtime. The cache belongs to that runtime; it does not travel inside a Foundry packet. Changing the prompt envelope, switching models or factories, restarting, or evicting cached state may remove the benefit. **No five-variation group or five-image completion time has been measured.** These FLUX and Qwen configurations also differ in architecture and step count; this is not an equal-quality speed comparison.

[Browse the ten Turbo images](https://benchmarks.weeyuga.com/benchmarks/bd801c85.html) · [Read the sanitized pair evidence and cache findings](https://benchmarks.weeyuga.com/data/predator-media-20261021/seed-variant-cache-findings.json).

### Qwen Turbo Q4 and Q8: the same ten briefs and seeds

Ten further Q8_0 outputs reuse the exact ten Q4 prompts, seeds 42–51, order and eight-step Euler/CFG1 ManualSigmas settings. The earlier Q4 originals remain unchanged. Only the generator file and output prefix differ in the executed graphs; both sets retain the same CPU INT8 encoder, CPU VAE and FP32 runtime settings. All ten Q8 results passed actual relay/acknowledgement, full decoding/checksums, output-attachment retrieval and paired native ten-case LangSmith experiment checks. Both sets of originals were inspected visually, with defects retained beside each output.

| Matched workload | Q4 native time | Q8 native time |
|---|---:|---:|
| Initial request; actual inherited loading/cache context | 320.246s | 541.410s |
| Same first brief, next seed | 95.234s | 93.391s |
| Eight subsequent new briefs, retained-runtime median | 199.712s | 446.477s |

The Q8 same-brief follow-up started 24.958s after its predecessor finished; its native encoder-cached flag was `true`. These are whole native graph times; Factory traces have separate boundaries. The first Q8 request inherits the existing Comfy/runtime state, so its loading and text-cache history need not match the earlier Q4 first request. Offloading, cache, initialization and other device workloads remain possible timing confounders.

During case 5, the local status coordinator stopped after three connection errors while the native generation continued and completed successfully. Warehouse and native-history readbacks confirmed one successful attempt. The unchanged finite coordinator collected that saved result before submitting case 6, preserving the same factory runtime. The actual case 5-to-case 6 native idle gap was 890.033s; every inter-run gap is retained in the comparison data. This monitoring interruption created no additional generation attempt or failed-generation record.

Fresh-prompt CPU encoding was slower in this Q8 series. The earlier Q4 fresh-brief encoding intervals ranged from 100.109 to 115.984s; the Q8 range was 119.328 to 457.125s. The eight new briefs give these observer-interval medians:

| Observed phase, eight new briefs | Q4 median | Q8 median |
|---|---:|---:|
| CPU text encoding | 103.109s | 247.344s |
| Sampling, including loading | 68.703s | 108.328s |
| VAE decoding | 28.329s | 50.414s |

These intervals include preparation/loading and observer delivery overhead. They locate the extra elapsed time without establishing its cause. A Q8 snapshot recorded many total memory faults but few hard page inputs; it does not establish disk paging as the bottleneck. Windows `PagefileUsage`/`PrivateUsage` counters mean private commit charge, rather than measured disk-pagefile residency. See [Microsoft's process-memory counter definitions](https://learn.microsoft.com/en-us/windows/win32/api/psapi/ns-psapi-process_memory_counters_ex) and [working-set/fault definitions](https://learn.microsoft.com/en-us/windows/win32/memory/working-set).

Q8 stores more weight precision, but it is not automatically a prettier image. Q4 is not a high-precision ground truth, and no aesthetic score or whole-VRAM residency claim follows from the comparison. The Q8 packed file alone is 7.12 GiB, before live working memory. This is still two seed variants for the first brief, not a measured five-image batch. Per-case material, geometry, text and prompt-adherence findings remain visible for both quants.

Smaller generator files are available at the same pinned Unsloth revision. We inspected their published metadata; none of these Q2/Q3 variants was generated in this comparison:

| Available generator quant | Packed file size, decimal GB |
|---|---:|
| [Q2_K](https://huggingface.co/unsloth/Qwen-Image-2.1-Turbo-GGUF/blob/5d1f9f759ea877ae556cda88dbec958b62ad3809/qwen-image-2.1-turbo-Q2_K.gguf) | 2.47 GB |
| [Q3_K_S](https://huggingface.co/unsloth/Qwen-Image-2.1-Turbo-GGUF/blob/5d1f9f759ea877ae556cda88dbec958b62ad3809/qwen-image-2.1-turbo-Q3_K_S.gguf) | 2.72 GB |
| [Q3_K_M](https://huggingface.co/unsloth/Qwen-Image-2.1-Turbo-GGUF/blob/5d1f9f759ea877ae556cda88dbec958b62ad3809/qwen-image-2.1-turbo-Q3_K_M.gguf) | 3.17 GB |
| [Q3_K_XL](https://huggingface.co/unsloth/Qwen-Image-2.1-Turbo-GGUF/blob/5d1f9f759ea877ae556cda88dbec958b62ad3809/qwen-image-2.1-turbo-Q3_K_XL.gguf) | 3.61 GB |

File size leaves out dequantization buffers, compute workspaces, activations, encoder/VAE and other GPU use. A smaller packed file is a candidate for a future residency test, not proof that its entire active stage fits a 6 GB GPU.

[Compare all ten Q4/Q8 image pairs](https://benchmarks.weeyuga.com/benchmarks/ef874435.html) · [Download exact matched timings, cache context and pair mapping](https://benchmarks.weeyuga.com/data/predator-media-20261021/qwen-turbo-q4-q8-comparison.json).

## Music: usable to the listener, expensive per second

YuE2 INT8 ConvRot produced two fully decoded fifteen-second stereo FLAC files at 48 kHz. Factory traces took **700.26 and 634.17 seconds**, approximately 11 minutes 40 seconds and 10 minutes 34 seconds. The native graph durations were 696.921 and 630.994 seconds. Loader state remained available between requests; the second request changed the style wording and seed, so semantic generation and acoustic sampling both ran again.

An earlier CPU semantic-generation trial was cancelled as impractical before producing audio. Moving that stage onto the GPU made complete samples possible. In the completed pair, the observed autoregressive-generation plus acoustic-conditioning intervals still dominated: about 586 and 558 seconds. The thirty-two-step acoustic sampler and CPU audio decoding were much smaller portions of the recorded run.

The user listened to both actual outputs and described both as usable music. That is a useful, explicitly attributed judgement about these two files. It does not establish lyric accuracy, genre faithfulness or a comparative quality score. Full decoding, finite audio samples and the absence of full-scale clipping indicators are technical signal checks, not substitutes for listening.

## Video: completion was easier to prove than quality

Every accepted video in this table is 512 × 320. Duration and frame rate differ, as do architecture, sampler and settings; comparison needs those details beside the time.

| Video configuration | Output length | Factory trace time, seeds 42 / 43 |
|---|---:|---:|
| Wan2.1 T2V 1.3B baseline, FP32 compute | 81 frames at 16 fps | 64m 06s / cancelled |
| Wan2.1 T2V 1.3B Q8_0 | 81 frames at 16 fps | 37m 18s / 34m 16s |
| LTX-Video 2B 0.9.8 distilled Q8_0, text | 121 frames at 24 fps | 3m 01s / 1m 46s |
| Same LTX, text plus image | 121 frames at 24 fps | 2m 01s / 1m 45s |
| CogVideoX2B Q8_0, original bounded-attention bridge | 49 frames at 8 fps | 41m 24s / 39m 48s |
| CogVideoX2B Q8_0, corrected reference-DDIM bridge | 49 frames at 8 fps | 40m 40s / 39m 54s |

Wan's baseline ceramic fox barely changed in the inspected samples. Q8 samples showed some motion but shape inconsistencies. Its second Q8 request followed an idle gap of roughly fifty minutes; recorded cached conditioning does not make that an immediate warm benchmark. The baseline follow-up was deliberately cancelled after the first run's hour-long wait.

LTX was much quicker in this particular distilled configuration. It used one base-resolution pass rather than the official multiscale/upscaling pipeline. The runtime remained loaded across both text and image pairs, so the first image-conditioned request was already warm from the text tests. Sampled frames showed recognizable fox scenes but defects in direction, anatomy and continuity. Fast completion did not establish a usable walking sequence.

CogVideoX exposed a more consequential integration problem. An initial attention allocation failed; the bounded-attention pair then completed, but both clips were unusable colored noise. A source audit found concrete differences between the bridge and the reference implementation: positional embedding construction, diffusion-state coordinates, noise schedule and the selected solver. Those are reasons to correct the bridge. They do not isolate which defect caused the noise, and they prevent blaming the model or Q8 quantization alone.

We retained the same Q8 generator weights for a corrected reference-DDIM pair. The noise disappeared in inspected samples, but prompt adherence was still poor. In one clip the fox exited, reappeared from the other side and developed a detached tail-like region. In the other, four of five inspected frames were empty snow and the visible fox was cropped. Neither sampled sequence established the requested continuous full-body walk. These reviews used five sampled frames per clip; full-rate natural motion remains unverified.

The corrected pair kept the same runtime and configuration, with 46.902 seconds between native executions for transfer and verification. The second request reused conditioning, while sampling and decoding genuinely executed again. That is the evidence behind the retained-state claim—not a filename containing “warm.”

## Why Q8 did not make video fast

Q8 describes the generator's stored weights. These Pascal-compatible tests still used FP32 computation, and other components had their own precision and placement. A smaller checkpoint can reduce weight-storage pressure without shrinking every activation or reducing the amount of arithmetic enough to make a slow sampler fast.

Loading one stage at a time helps avoid keeping several large components active together. It does not prove that all memory used by the active stage fits in physical dedicated VRAM. In the corrected Cog tests, generator peak allocated memory was about 2.73 GiB, while decoder reserved memory reached about 7.52 GiB. “Reserved” and “allocated” are different measures, and Windows WDDM can page CUDA memory. CUDA parameter placement alone therefore does not establish that a run avoided shared memory or paging.

We did not measure isolated kernel times or demonstrate a causal quantization speedup. The archive preserves the actual stage and memory observations so those limits remain visible.

## The failures belong in the dataset

MiniMax H3 produced no accepted media. The first native attempt failed almost immediately while opening its approximately 27 GB text encoder, with Windows error 1455 indicating insufficient paging-file capacity at that file-open/mapping path. That was not a demonstrated GPU out-of-memory failure. A separate dynamic-loading attempt reached further but was cancelled at the user's request because it was too slow; no second completed H3 run exists. Download size is not a simultaneous RAM requirement, and neither cancelled execution establishes a completion-time estimate.

Other retained records include the cancelled YuE2 CPU trial, Cog's initial attention OOM, two LTX storage-guard cancellations, the interrupted Qwen delivery and the cancelled Wan follow-up. Some failures occurred before generation; another produced local media without completing delivery. Keeping those statuses distinct makes the archive more useful than a gallery containing only accepted results.

For accepted outputs, the delivery checks verify checksums, full decoding, durable collection and acknowledgement. Saved LangSmith attachment bytes were independently decoded, and native experiment exports were checked where recorded. LangSmith's media-player UI was not separately inspected. The original noisy Cog videos passed file and delivery checks while failing visual usefulness: the separation is deliberate.

The practical lesson from this machine is specific. The FLUX study completed all 100 planned images, the Qwen Turbo Q4 follow-up completed ten, and the matched Q8 comparison added ten further outputs; each measured subset remains separate. Two short music samples were usable to their listener, at a substantial time cost. Short video could complete, sometimes quickly, but our tested clips did not establish reliable requested motion. The published prompts, settings, poor outputs and failed attempts give the next builder something more actionable than a success headline.