Forge Compat Sampler

A sampler name is not a specification. dpmpp_2m in Forge and dpmpp_2m in ComfyUI share a solver and disagree about sigma columns, intermediate noise, ancestral eta, and when CFG runs. Forge Compat Sampler executes the Forge side of that disagreement, pinned to a named Forge Neo commit, and - this is the part that earns it a place - it tells you when it can't.

The inputs

Six required, one of them a switch:

• spec - the FORGE_GENERATION_SPEC from Forge Compat Import / Spec.
• model - your MODEL. The family and predictor get read off it.
• conditioning - a FORGE_CONDITIONING from Forge Compat Text.
• noise - a FORGE_NOISE_BUNDLE from Forge Compat Noise.
• latent_image - the latent from that same Noise node.
• trace_level - none, summary (default), or tensors.

Outputs: latent into VAEDecode, sigmas (a SIGMAS of the actual base sigma column, for an advanced sampler or for your own comparison), and report, JSON.

What it checks before it spends your VRAM

It reconciles the spec's config hash, the model family, the real asset binding, shapes and dtypes, and the input latent hash. More interestingly, it re-reads the prompt graph and requires that the node feeding conditioning is literally a Forge Compat Text node whose binding hash matches the one recorded inside the bundle. So a conditioning tensor that passed through some unrelated encoder doesn't get a pass just because it looks right. Mismatched branches give you ASSET_BINDING_MISMATCH or UNVERIFIED_PATCH_CHAIN instead of an image that's subtly wrong.

The run itself is the ported Forge sequence: resolve the family and predictor, resolve automatic plus sampler-specific defaults and forced discard rules, build the sigma column, apply the requested penultimate-sigma discard once (ORed with whatever the sampler forces, generating N+1 and dropping the second-to-last when needed), scale the initial noise once, then sample through private RNG/Brownian with the Forge CFG, negative-skip and prompt-schedule semantics.

The prompt schedule is the quiet one. Forge schedules prompt parts by denoiser call count, not by a percentage of your UI step slider - so second-order solvers that call the denoiser twice per step can land your prompt change on a different image than you'd expect. Here it follows the Forge rule.

Two things it deliberately doesn't do: it won't force steps + 1 sigmas on every scheduler (Beta rounds and dedupes, and that's recorded in the trace rather than papered over), and it won't treat denoise = 0 as a no-op just because that's convenient. On OOM it errors. It does not tile, and it does not quietly drop your resolution.

Using trace_level

summary is the right default: the report tells you which path ran, which parameters were applied, and which were retained-but-inactive. tensors additionally dumps a trace file of the intermediate tensors and call facts - genuinely useful when you're trying to work out whether two UIs differ in the schedule or in the weights, and genuinely useless if you just want an image. none when you want the report field quiet.

Wiring

Forge Compat Import / Spec ──spec──┬──> Forge Compat Text ──conditioning──┐
                                   └──> Forge Compat Noise ──noise────────┤
                                              └──latent───────────────────┤
                                                                          ▼
                                                     Forge Compat Sampler ──latent──> VAEDecode ──> Save Image

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/ComfyUI-ForgeNeo-Bridge.git

Restart ComfyUI, F5 in the browser. The pack adds no pip dependency of its own - it runs on ComfyUI's existing torch/numpy/scipy/Pillow/tqdm, and merely checks that torchsde==0.2.6 is present for the DPM++ 2M SDE path rather than installing a version over yours. It also doesn't replace ComfyUI's global sampler functions or shared RNG state, so it can live beside other sampler packs. Update with git pull --ff-only.

Honest expectations

The pack's own validation record says it plainly: a completed run is not a parity certificate. Real-model GPU parity is not certified, and the certified model list is currently empty. CPU reference comparisons, small-model API tests and browser UI tests are all things this project actually did - pixel matching against Forge on your checkpoint is not one of them.

So treat this node as "closest available reconstruction, with receipts", not "identical output". Between precision, VAE handling and any high-res second pass, differences are expected, and sometimes composition-level. The report is how you find out which difference you're looking at instead of guessing.