Skip to content

bug: MagCache calibrate on H3 reports no ratios - H3 runs N-1 forwards, the counter waits for N #927

Closed

Description

@dkackman

Observed

On lem (develop @ f08cc3c, which includes #891), an H3 Ref2VA run with "cache": {"type": "mag", "calibrate": true, "num_inference_steps": 30} and num_inference_steps: 30 finished cleanly (job cf62ad421f48, workspace h3-quality, rung M1 in #875) but emitted no ratios: there was no MagCache calibration (...) warning or log event.

Its cache_stats event:

"type": "mag", "calibrate": true, "num_inference_steps": 30, "forwards": 29, "computed": 29, "skipped": 0

Cause

diffusers' MiniMax-H3 scheduler turns num_inference_steps sigmas into num_inference_steps - 1 model evaluations (schedulers/scheduling_minimax_h3.py, set_timesteps: "the schedule holds num_inference_steps sigmas and drives num_inference_steps - 1 model evaluations, exposed as self.timesteps = 1 - sigmas[:-1]"). unique_consecutive on the shifted sigmas can drop more.

captured_mag_calibration (dw/pipeline_processors/components.py) sets the config's num_inference_steps to the call's num_inference_steps argument, which is 30. diffusers only prints, logs and clears the ratios when its step counter reaches that number, in MagCacheHook._advance_step. At 29 forwards it never does, so the record #891's handler listens for is never written. Every H3 calibration loses its ratios this way, and the job looks successful.

Fix scope

  • Count the forwards the call actually runs, not the argument: e.g. the scheduler's timesteps length after set_timesteps, or a pipeline-specific rule for H3 (N-1). The implementer picks the mechanism. Keep it model-agnostic if it can be (see CLAUDE.md, model knowledge lives in plugins/catalog). A calibrate run whose last forward never reached the counter should at least warn (calibrate was on but no ratios were reported: N forwards for M configured steps), so this failure mode can't be silent again.
  • Check the non-calibrate path too. A mag cache on H3 with num_inference_steps: 30 and mag_ratios of length 30 sees 29 forwards. Confirm the per-step ratio indexing and the end-of-run state reset are still right, or warn/adjust the same way.
  • Docs: docs/ACCELERATION.md says the cache's num_inference_steps "must match pipeline arguments". For H3 the effective count is one less. Say so, or make it unnecessary.

Tester check

  1. An H3 template (the smallest canvas/steps that runs, e.g. 960x544 int4 base at 8-12 steps) with mag + calibrate: true: get_job.warnings and get_job_events carry a ratio list of length = the forwards in cache_stats.
  2. The same on a non-H3 CFG template (bug: MagCache calibrate ratios never reach an MCP/REST client - docs say they're logged #891's original check) still emits labeled lists of length = steps.

Blocks

#875 item 4 (MagCache rung M2 needs these ratios). Related: #891.

Activity

  1. dkackman commented on Oct 15, 2026

    @dkackman
    OwnerAuthor

    Fixed in Don's session: d8f6044, merged to develop as 6fd260c. Not pushed or deployed yet. lem is running the #861/#875 ladder batch until about 16:10 CDT, and a deploy restarts dw.serve.

    • Fix: stateful_cache_context now reports the ratios a completed calibrating call left in each context's mag state, just before the reset drops them. It's model-agnostic and doesn't hard-code H3's N−1. A calibration that finishes normally has nothing left over, because diffusers clears the list when it logs, so nothing is reported twice. An errored call reports nothing partial.
    • Docs and schema: the cache's num_inference_steps is the forwards the call actually runs. A 30-step H3 call reports 29 ratios, so set it to 29 when pasting them.
    • Tests: 3 new tests in tests/test_cache_blocks.py, nesting the contexts the way Pipeline.__call__ does. The short-call test failed before the fix. Full suite: 14689 passed.
    • Still to do: after the batch, push and deploy, rerun M1 and confirm a 29-entry list, then run M2 (threshold 0.06, num_inference_steps: 29) for H3 cinema-path speed: follow-up experiments after first_block -22% (threshold, 20 steps, close-up, seeds, MagCache) #875 item 4, then close.

    Relabelled owner:implementer → owner:don so the loop doesn't pick this up. claude-opus-5-5 / anthropic, for Don

  2. added
    owner:donParked for human decision
    and removed on Oct 15, 2026
  3. added a commit that references this issue on Oct 15, 2026
  4. added and removed
    owner:donParked for human decision
    on Oct 15, 2026
  5. dkackman commented on Oct 15, 2026

    @dkackman
    OwnerAuthor

    Verified on lem at 6fd260c. M1 rerun: job 39c06ce0c8e8, H3 Ref2VA, 1344x768 int8, 30 steps, mag + calibrate: true.

    • get_job_events and job warnings both carry MagCache calibration (29 steps): [1.0, 1.0171, 1.0188, … 1.0200] — paste into mag_ratios. It's one unlabelled list, so H3's modular pipeline doesn't run separate cond/uncond cache contexts.
    • cache_stats: forwards: 29, computed: 29, skipped: 0, calibrate: true. So the list length matches the forwards, as the fix intends.
    • The same rung before the fix (job cf62ad421f48) emitted nothing.

    The ratios are now feeding #875's M2 rung (threshold 0.06, num_inference_steps: 29), job 26534894d560. Closing as completed. claude-opus-5-5 / anthropic, for Don

  6. added
    status:verifiedTester confirmed the fix via a real MCP call
    and removed on Oct 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backend:sharedbugSomething isn't workingowner:testerTester's turn to actperformanceTiming/perf regression flagged by the regression agentstatus:verifiedTester confirmed the fix via a real MCP calltarget:lem

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions