HDM Tread Gamma
The model's internal cheat code, exposed
- positive
- negative
- CONDITIONING
- CONDITIONING
Of the three nodes in HDM-ext, this is the one you're most likely to leave at zero and never miss. That's not a dig - it's the point. HDM Tread Gamma is a window into what makes the model cheap to train, exposed as a conditioning dial, and for everyday generation the default is fine.
What "tread" even is
TREAD (the acronym is from the paper at arxiv.org/abs/2501.04765) is a training-acceleration trick that HDM used to converge faster. It left a structural trace in the model: the XUT transformer has extra "prev-tread" and "post-tread" branches that fuse encoder and decoder features, and during training those branches drop a fraction of token positions to save compute. The dropout ratio is baked into the config (0.5 by default).
Here's the part that makes this node interesting: at inference, the model normally runs the full dense path - everything through the backbone, no dropping. But if you feed it a tread_gamma, it switches into TREAD-style sparse mode: only a 1 - gamma fraction of token positions go through the backbone, the rest bypass and get recombined by the post-tread transformer. Look at the source and you'll see the selection math - the comment literally reads "higher rate = more dropout = less selection."
So the dial is a bridge: 0 means "default dense inference," anything above 0 switches that conditioning stream into the accelerated sparse pathway and sets how aggressively it drops positions. The author named it "gamma," but it's really a rate on a scale of 0 to 1.
What the node does
It's a conditioning pass-through, same family as the HDM Camera node but with a twist: it lets you set the tread value separately for positive and negative conditioning.
positive/negative(CONDITIONING) - your encoded prompts in, both back out.positive_gamma(FLOAT, default 0, range 0 to 1) - tread rate for the positive stream.negative_gamma(FLOAT, default 0, range 0 to 1) - tread rate for the negative stream.
Both outputs are CONDITIONING, feeding KSampler. The shipped example workflow sets positive_gamma: 0 and negative_gamma: 0.15 - the author nudges only the negative side, which is the pattern to steal if you want to experiment: treat the two streams as independent knobs rather than mirroring them.
The honest take
For 95% of uses, set both to 0 and forget it. The effect is subtle, the author hasn't published a perceptual map of what each value does to the image, and this node mostly matters because the pack is a reference implementation of custom-model conditioning - how to let a custom node inject parameters a custom model actually reads. The README's whole pitch is "only the Loader and HDM Camera are custom, everything else is stock," and Tread Gamma is the supporting example of the same trick.
If you're curious, and you should be, it's cheap to test: fix your seed, nudge positive_gamma up 0.1 at a time, and diff the outputs. Worst case you learn what it doesn't do.
Installing and gotchas
Same pack as the rest of HDM-ext - install once, all three nodes appear. ComfyUI Manager → search "HDM", or:
cd ComfyUI/custom_nodes
git clone https://github.com/KohakuBlueleaf/HDM-ext
Requires transformers>4.51 (4.52+ for Qwen3 support) and the model from https://huggingface.co/KBlueLeaf/HDM-xut-340M-anime in ComfyUI/models/checkpoints. Full walkthrough on the HDM Loader page.
Two things to remember: like the Camera node, this does nothing on non-HDM models - it just stamps a key into the conditioning dict that ordinary models ignore. And because gamma 0 means "use the default," the range is 0-to-1, not a ± dial; there's no "negative tread" to apply. Keep it in that range and you're safe.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| positive | CONDITIONING | — | |
| negative | CONDITIONING | — | |
| positive_gamma | FLOAT | 0.000–1 | — |
| negative_gamma | FLOAT | 0.000–1 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| CONDITIONING | CONDITIONING | — |
| CONDITIONING | CONDITIONING | — |