Skip to content

workaround for pytorch autotuning issue#1626

Open
dxqb wants to merge 1 commit into
Nerogar:masterfrom
dxqb:mm8bit-custom-op
Open

workaround for pytorch autotuning issue#1626
dxqb wants to merge 1 commit into
Nerogar:masterfrom
dxqb:mm8bit-custom-op

Conversation

@dxqb

@dxqb dxqb commented Jul 18, 2026

Copy link
Copy Markdown
Collaborator

Summary

pytorch/pytorch#164124 causes torch.compile to choose a first-fit of the triton kernel instead of a best-fit for each shape as intended

this PR defines the triton kernel a custom op, which makes it opaque to torch.compile and let's triton autotune the kernel.
first step goes from 40s to 50s in one test cold because autotuning now actually happens, but on second run the first step is still about 20s because triton autotunes are cached.

Test plan

  • pre-commit run --all-files passes
  • Launched the affected UI or script and exercised the change
  • Tested with at least one real preset / config when relevant (note which: Flux2)

AI assistance

  • AI-assisted — I have read every line in this diff and can defend each change

…ibility

torch.compile absorbs a traced @triton.autotune kernel and freezes the config
benchmarked for the first shape, ignoring the autotune key
(pytorch/pytorch#164124). Registering mm_8bit as an opaque
custom op keeps it a single node in the compiled graph and runs its body eagerly, so
Triton's autotuner selects per key. Autotune winners are cached to Triton's disk cache,
and a line is printed whenever the autotuner actually benchmarks a kernel.

Drafted by Claude

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

preview merged in the preview branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant