Address CodeRabbit review on #15410: clear quant_format/layout_type
when a module reloads an unquantized weight (previously stale state
made Linear.forward take the quantized path against a plain
Parameter), and raise instead of silently loading raw bytes when an
Embedding's inferred format is NVFP4, which the embedding path can't
dequantize.
The all-NUL-marker fix only covered layers with no comfy_quant config.
Layers with valid, non-empty comfy_quant JSON that carry a weight_scale
but no "format" key (e.g. a q_proj-style layer in the MiniMax H3 nvfp4
AWQ checkpoint) still hit "Unknown quantization format for layer ...".
Fall back to inferring the format from the on-disk weight dtype
(int8 -> int8_tensorwise, float8_e4m3fn -> float8_e4m3fn, uint8 ->
nvfp4) in both the shared _load_quantized_module path and the
mixed-precision Embedding's own inline handling, matching the
workaround documented in the issue.
Some quantizers mark unquantized layers in a mixed-precision checkpoint
with an all-NUL comfy_quant placeholder tensor instead of omitting the
key. json.loads() misdetects the leading NUL bytes as UTF-32 and raises
UnicodeDecodeError; once that decode is patched around, the resulting
empty {} config still fails with "Unknown quantization format" because
the loader always requires an explicit format for any present marker.
Treat an all-NUL marker as if comfy_quant were absent so the layer loads
as a plain unquantized weight, matching the official MiniMax H3 nvfp4
AWQ text encoder.
Fixes#15400
This avoids name collision (circular imports) for external custom nodes,
for which the comfy path is pushed into sys.path so Python's own logging module
is shadowed otherwise.
fixes: #15229
This priority scheme was broken in the case where you have pin
registration exhaustion while loading a VBAR that gets a big evicition.
The weight would stay in the loaded set but inherit the MRU priority
against other workflow models WRT pin registration which leads to async
offload without pinning.
Fix by universally promiting active pin registration above workflow
pins without concern for the weights/weights-loaded split. This diverges
from the actual budgeting where the split still makes sense.
Changes:
Remove sequential scan hint
Prefer NVML pressure on windows
Add async malloc clamp option (unused by comfy so far)
Workaround AMD windows GPU virtual address space leak
The largest change is the NVML pressure, which works around a cuMemGetInfo
drift from actual VRAM in some circumstances.
Windows has proven this logic works for a long time and there are
corner cases where this materialization actual consumes real RAM
on linux.
Its not as bad as the original windows commit charge surge, but
its still a detectable transient leak. So simplify and unify.
Some long running chaos testing on a 512GB RAM RTX6000 pro showed that this
is a little bit too low for common template workflows switching around. The
original number was just a guess from me, so go with the scientific result
instead.
These were alll non-dynamic (some non-ModelPatcher) code path calling
FreeMemory for management requiring up-front memory freeing. Convert it
to dynamic to avoid legacy free behaviour mixing into otherwise
dynamic workflows.
* Add native Uni3C controlnet support for Wan models
* Dispatch double_block patches in all Wan model variants
* Remove unused grid_sizes assignment in CameraWanModel, WanModel_S2V, HumoWanModel, and AnimateWanModel
chelsealong
Jukka Seppänen
comfyanonymous
endman100
rattus
rivadart
Oliver Freyermuth
blepping
Barish Ozbay
彼彼