H3 cinema-path speed: follow-up experiments after first_block -22% (threshold, 20 steps, close-up, seeds, MagCache)

Where it stands

Cinema path speed rungs (1344x768, int8, no LoRA, sage, cold open, seed 42):

Rung	Change	Total min	vs baseline	Quality
B3	12 steps	12.9		3.5/5
P2	B3 + first_block 0.05	12.8	0% (no skips)	= B3
P4	B3 + text_kv	12.7	~0%	= B3 (44 dB)
P3	B3 + compile	16.6	+29%	= B3
L5	30 steps	29.5		4/5
P1	L5 + first_block 0.05	23.1	-22%	= L5 (27.5 dB, faces and staging identical)
P5	L5 + taylorseer 3/1	OOM

Denoise is ~56 s/pass, compute-bound. Only skipping passes helps.

Next experiments (in priority order)

first_block threshold 0.08 and 0.10 at 30 steps - how far can it go before faces soften? Judge with the face grid against L5.
first_block 0.05 at 20 steps vs P1 - a 20-step cached final might match 30 steps at ~14-15 min.
P1 on a close-up (C2) and on a second seed - confirm -22% and no artifacts generalize.
MagCache calibration for H3 (calibrate: true, 30 steps) then a MagCache rung - potentially more skips than first_block at equal error.
TaylorSeer at a smaller footprint (fewer refs or 960x544) only if 1-4 disappoint.
Compile with a warm worker across a multi-shot workflow (5 shots, one shape) - does the 289 s amortize, and does the per-pass gain stay ~1%?

Quality judgements needed

Motion: P1 judged on stills and contact sheets. Watch P1 vs L5 in playback for flicker/ghosting that skipped passes can cause in motion.
Audio: first_block skips the whole transformer, including audio tokens. check-script was exact, but nobody listened for audio artifacts (pumping, smearing) in P1.

Source: H3 quality matrix on lem (2x RTX 3090 24 GB, 125 GB host RAM), workspace h3-quality, Known Issues ep 6 shots, seed 42. Full data and per-run assessments: ~/testing/opus/known-issues/quality/matrix.json, report quality/REPORT.md; every run in h3-quality carries a note with its config, minutes and score. Related: #861 (follow-up experiments).

Plan v1: #875 H3 cinema-path speed follow-ups

Written by the lead agent, model claude-opus-5-5 via the anthropic provider. Design session against develop @ 61838a9.

Verdict: don't build this issue as a feature. Run it as a driving session, with one small dw fix carved out first (item 4 can't finish over MCP today).

As with #861 (approved, same shape), the six items are GPU experiments, not code. The existing surface already runs items 1, 2, 3 and 5: run_workflow with a cache override and a note, set_note, get_output_frames, get_output_audio, and tools/ladder.py. Item 4 is the exception.

The gap: MagCache calibration ratios never reach an MCP or REST client

From the read-only sweep (diffusers hooks/mag_cache.py:379-394 in the installed venv):

At the last step, diffusers print()s the ratios and logs them at INFO, then clears the list.
The worker is a spawned process whose stdout goes to the dw.serve console (dw/worker_manager.py:73-81). Its file log handler is attached only to the dw logger (dw/log_setup.py:23-39), and the diffusers logger sits at WARNING, so the INFO line is dropped.
Job events come only from explicit emit_* calls (dw/events.py:246-249 states this). get_job, get_job_events and export_job therefore carry no trace of the ratios.
docs/ACCELERATION.md:78 and dw/workflow_schema.json:808 say calibration "logs the measured ratios … paste that array into mag_ratios". Over MCP there is nothing to paste.

A session with a shell on lem could read them off the dw.serve console. That is a workaround, not the documented path.

Proposed fix (one implementer ticket, no new surface): while a mag cache with calibrate: true runs, capture the ratio list before diffusers clears it. Then emit it as an existing log event, and also as a job warning so it survives the 200-event history trim. The message reads "MagCache calibration (N steps): [ … ] — paste into mag_ratios". Then fix the two doc lines to say where the ratios appear.

No new event type, MCP tool, field or syntax.
The catch: diffusers appends the final ratio and clears the list in the same forward (_advance_step), so reading after the call is too late. The fix has to either snapshot the list per forward plus the final value, or capture the diffusers.hooks.mag_cache logger record. The implementer picks one, and a unit test pins it against the installed diffusers.
Tester check: run a small cached step (an SD/Flux template, ~10 steps, calibrate: true) and confirm that get_job_events and get_job.warnings carry a list of length = steps. Run the same step without calibrate and confirm no such message.

Overlap: #867 stage 2 (approved) hooks the same mag_cache_leader_block_hook state inside stateful_cache_context (dw/pipeline_processors/components.py:833-864). The two must not land as conflicting edits to that function, hence Q2.

Axes

Value. Real, and Don's. The cinema final is ~23 min per shot × every shot of every episode, so each further cut of a few minutes compounds. The evidence is the h3-quality workspace (63 of Don's jobs, cited in H3 quality ramp: follow-up experiments (seed stability, cross-family composition lock, int4 base draft) #861 and feature: per-phase timing and cache skip stats in get_job / job events #867), with idea: quality-ramp skill - draft -> preview -> final tiers with measured cost/quality trade-offs (H3 first) #862 consuming the results. A working calibrate path also helps every future model with no diffusers preset. Today that is every model except Flux.
Build cost. The fix is ~$2–4, one session. The experiments cost no agent build. GPU time on lem is estimated below.
Inertia. The fix adds one more message shape on existing channels plus two corrected doc lines. The experiments add nothing beyond notes in h3-quality and rows in idea: quality-ramp skill - draft -> preview -> final tiers with measured cost/quality trade-offs (H3 first) #862.
Reversibility. Total.
Cheaper alternatives. Skip item 4 and stay on first_block. That gives up the one lever that might beat -22%. Or read the console on lem: that works once, but leaves the documented calibrate path broken for MCP users.
Overlap.
- H3 quality ramp: follow-up experiments (seed stability, cross-family composition lock, int4 base draft) #861. Its runbook already reruns B3→P1 and C1→C2 at seeds 7 and 1234, which covers most of item 3's "second seed" (below).
- feature: per-phase timing and cache skip stats in get_job / job events #867 reports first_block/mag skip counts (hit_rate). Items 1, 2 and 4 are judged better with it, but wall-clock minutes are enough to start.
- feature: H3 templates - expose attention_backend + cache everywhere, and a quality tier preset that sets the coupled knobs together #865 (H3 templates expose cache) and validate: warn on acceleration settings that can't pay off or won't fit (cache at low steps, TaylorSeer VRAM, compile under offload) #868 (validate warns on cache at low steps) consume these results.

Item-by-item disposition (runbook, not stages)

GPU estimates are from the issue's measured rungs, run one at a time on lem.

first_block 0.08 and 0.10 at 30 steps, seed 42. Run both, ≤ ~23 min each, ~45 min. Judge them with the face grid against L5. Stop at the first threshold where faces soften.
first_block 0.05 at 20 steps. One run, ~15 min. Add an uncached 20-step baseline (~20 min) only if the cached one looks equal to P1, so the skip saving is separable from the step cut.
Generalization.
- Close-up: C2 + first_block 0.05 at seed 42, ~18 min.
- Second seed: take it from H3 quality ramp: follow-up experiments (seed stability, cross-family composition lock, int4 base draft) #861's seed-7 P1 run, and add one uncached L5 at seed 7 (~30 min) so -22% is measured against the same seed. No separate P1 rerun.
MagCache. This needs the fix above first, or a console read on lem (Q1). Run the calibrate pass (30 steps, skips nothing, ~30 min), then one MagCache rung at the default threshold 0.06 (~23 min or less): ~53 min. Ratios measured at 30 steps interpolate to 20 (ACCELERATION.md:76), so a 20-step MagCache rung needs no second calibration.
TaylorSeer at a smaller footprint. Keep the issue's own condition: run it only if 1–4 disappoint.
Compile across a warm 5-shot workflow. Drop it; the arithmetic already answers it. At ~1% per pass, 56 s/pass gives ~0.56 s saved per pass.
- 5 shots × 12 steps saves ~34 s, and even 5 × 30 steps saves only ~84 s. Both are well under the 289 s compile.
- Even if a warm worker never recompiles across shots, compile can't pay off at this per-pass gain.
- Brought back by: a measurement showing per-pass gain well above 5% (e.g. a newer torch, or a different attention backend).

Quality judgements. Motion playback (flicker or ghosting, P1 vs L5) and listening for audio pumping or smearing are Don's. An agent can't watch or listen, though get_output_audio lets a session check levels. They apply to P1 and to whichever rung from items 1, 2 and 4 wins.

Total: ~2.7 h of lem GPU time with item 4, ~1.8 h without, plus the optional 20-step baseline.

Results go to notes in h3-quality and to #862's table. Closing this issue as completed is Don's call.

Questions

Q1. Should the calibration fix be filed before item 4 runs? Default: yes. I'd file it as an owner:implementer bug ("MagCache calibrate ratios unreachable over MCP/REST; docs claim they're logged"), scoped as above. If no: item 4 runs with a console read on lem, and the doc lines stay wrong until someone hits them again.
Q2. Should that fix land before or after feature: per-phase timing and cache skip stats in get_job / job events #867 stage 2? Both edit stateful_cache_context. Default: independent, whichever lands first; the second rebases. It is a few lines, and feature: per-phase timing and cache skip stats in get_job / job events #867's counter hook could later absorb the capture. If you'd rather fold it into feature: per-phase timing and cache skip stats in get_job / job events #867 stage 2: that is a re-plan of feature: per-phase timing and cache skip stats in get_job / job events #867 (a v2 there), not an edit here.
Q3. Drop item 6 on the arithmetic above? Default: yes. If no: it's ~2.2 h of GPU (5 shots × B3, compiled vs not) to confirm a number the arithmetic already bounds.
Q4. Is the disposition right: no feature, a runbook for a driving session, and this issue kept open under owner:don as the tracker? Default: yes. If you'd rather close it now: item 1's thresholds and item 4 go to idea: quality-ramp skill - draft -> preview -> final tiers with measured cost/quality trade-offs (H3 first) #862's Open questions.

Reply in comments and hand back with owner:lead. Approve by adding status:plan-approved yourself. No agent may set it.

Review: approve, with one addition to the fix ticket.

Code claims verified against develop:

diffusers _advance_step (hooks/mag_cache.py:379-394) prints the ratios, logs them at INFO, and clears the list in the same call.
dw/log_setup.py attaches handlers only to the dw logger.
docs/ACCELERATION.md:78 and the schema's calibrate description promise ratios that an MCP client never sees.
Flux is the only preset diffusers ships.
feature: per-phase timing and cache skip stats in get_job / job events #867 is approved, so the overlap in stateful_cache_context (components.py:834) is real.

Addition to the fix ticket: under CFG, dw nests cache_context("cond") and cache_context("uncond"). Each context has its own MagCacheState, so a CFG run produces two ratio lists, but mag_ratios takes one array. The ticket must say which list it emits: emit both, labeled, or emit cond and say so. The tester check should use a CFG template, not a guidance-distilled one.

Q1: yes, file the calibration fix before item 4 runs. The docs are wrong for every MCP user.
Q2: independent. Whichever of this fix and #867 stage 2 lands second rebases.
Q3: drop item 6. At about 84 s saved at best, it can't recover a 289 s compile.
Q4: yes. No feature, a runbook for a driving session, and this issue stays open under owner:don as the tracker after the fix ticket is filed.

claude-opus-5-5 / anthropic, for Don

Plan v1, carried out as approved: no stages, so no decomposition.

Lead agent, model claude-opus-5-5 via the anthropic provider.

The driver routed this here as "plan v1 not decomposed". The approved verdict is don't build as a feature (Q4), so I filed no stages and wrote no decomposed marker. What Don's answers asked for:

Q1: filed the calibration fix as bug: MagCache calibrate ratios never reach an MCP/REST client - docs say they're logged #891 (owner:implementer). It includes your CFG addition: two MagCacheStates, so emit both lists labeled or cond only, and say which. Its tester check uses a CFG template.
Q2: bug: MagCache calibrate ratios never reach an MCP/REST client - docs say they're logged #891 says it's independent of feature: per-phase timing and cache skip stats in get_job / job events #867 stage 2. Whichever lands second rebases.
Q3: item 6 is dropped.
Q4: this issue goes back to owner:don as the tracker. The runbook is plan v1's Item-by-item disposition, with item 6 struck. Item 4 waits on bug: MagCache calibrate ratios never reach an MCP/REST client - docs say they're logged #891, or a console read on lem.

status:plan-approved stays on as the record of the approval.

Batch started 2026-10-15 on lem (f08cc3c): L5 at seed 7, P6, P7, P8 and P9 are queued behind #861's seed runs, and results go to ladder.jsonl and the run notes in h3-quality.

Item 4 is blocked by #927. The M1 calibrate pass (job cf62ad421f48, 30 steps, 29.8 min) ran but reported no ratios. H3 makes N−1 transformer forwards, and the #891 capture waits for N. M2 is dropped from this batch. When #927 lands, rerun M1, then M2 at threshold 0.06. claude-opus-5-5 / anthropic, for Don

Done 2026-10-15. All the GPU runs were on lem, and Don judged them. Baseline is L5, the uncached 30-step run at 29.5 min.

Item 1, threshold: P6 (first_block 0.08) took 19.5 min, −34%, and P7 (0.10) took 17.8 min, −40%. Don picked 0.08 as the highest threshold to ship.
Item 2, 20 steps: P8 (20 steps + first_block 0.05) took 18.9 min and Don judged it equal to P1. The uncached 20-step baseline took 20.3 min, so the saving at 20 steps is the step cut, not the cache.
Item 3, does it generalize: the cache holds on the close-up (P9, 19.3 min vs C2's 22.3, the same picture). At seed 7, P1 took 23.2 min against L5's 29.7, so −22% holds on a second seed.
Item 4, MagCache: this needed a fix first. Calibration on H3 never reported its ratios, filed as bug: MagCache calibrate on H3 reports no ratios - H3 runs N-1 forwards, the counter waits for N #927 and fixed in 6fd260c. With the fix, M1 calibrated 29 ratios, and M2 (MagCache 0.06) took 18.1 min, −39%, skipping 15 of 29 passes. Don chose it as the cinema-final cache.
Item 5, TaylorSeer: skipped (Don).
Item 6, compile: dropped earlier, on arithmetic.
Motion and audio: Don watched and listened to P1, P6 and M2 against L5. All ok.

The ratios and rows are in #862's ladder table. #865 (template tier presets) can now pick up MagCache 0.06 with the H3 ratios. Closing as completed (Don). claude-opus-5-5 / anthropic, for Don

Navigation Menu

Repository navigation

H3 cinema-path speed: follow-up experiments after first_block -22% (threshold, 20 steps, close-up, seeds, MagCache) #875

Where it stands

Next experiments (in priority order)

Quality judgements needed

Plan v1: #875 H3 cinema-path speed follow-ups

Verdict: don't build this issue as a feature. Run it as a driving session, with one small dw fix carved out first (item 4 can't finish over MCP today).

The gap: MagCache calibration ratios never reach an MCP or REST client

Axes

Item-by-item disposition (runbook, not stages)

Questions

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

H3 cinema-path speed: follow-up experiments after first_block -22% (threshold, 20 steps, close-up, seeds, MagCache) #875

Description

Where it stands

Next experiments (in priority order)

Quality judgements needed

Activity

dkackman commented on Oct 14, 2026

Plan v1: #875 H3 cinema-path speed follow-ups

Verdict: don't build this issue as a feature. Run it as a driving session, with one small dw fix carved out first (item 4 can't finish over MCP today).

The gap: MagCache calibration ratios never reach an MCP or REST client

Axes

Item-by-item disposition (runbook, not stages)

Questions

dkackman commented on Oct 14, 2026

dkackman commented on Oct 14, 2026

dkackman commented on Oct 15, 2026

dkackman commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions