DYNAMIC TRT_MODEL CONVERSION

Most people should start here. DYNAMIC_TRT_MODEL_CONVERSION builds a TensorRT engine that works across a range of resolutions and batch sizes, which is what you want if you don't generate the exact same shape every single time. The README says it plainly: most users will prefer dynamic engines, and it's the node the pack's bundled SD1.5 workflows default to. Set an opt (optimal) shape for what you use most, give it a min and max band around that, and one engine covers everything in between.

The price of flexibility is real, though. The wider your min–max range, the more VRAM the engine consumes and the longer it takes to build - TensorRT has to plan for every shape in the band. Don't set 256–4096 "just in case." Set a band you actually generate in, like 768–1216 for SDXL, and you'll get most of the benefit for a fraction of the cost.

How it works

Same pipeline as its static sibling: the UNet is exported to ONNX (with batch, height, and width as dynamic axes), the TensorRT builder parses it, and a serialized engine is written out. The difference is the optimization profile: each of min, opt, and max shapes gets fed to the builder, and performance is best at the opt values. It builds with FP16 enabled (BF16 for Flux), and a persistent timing cache makes repeat builds dramatically faster.

The filename is a full spec of what the engine accepts: dyn-b-1-1-1-h-512-512-512-w-… reads as dyn-batch[min]-[max]-[opt]-height[min]-[max]-[opt]-width[min]-[max]-[opt]. Once you can parse that string, you'll never wonder which engine does what again.

The inputs that matter

• model - the MODEL output of a Load Checkpoint node; that's the only wire you need to pull.
• filename_prefix - tensorrt/ComfyUI_DYN by default. Keep tensorrt/ and give it a name you'll recognize in the loader.
• batch_size_min / opt / max - batch 1–100. Leave at 1 unless you actually batch.
• height_min / opt / max and width_min / opt / max - 256–4096, stepping by 64. Set opt to the resolution you generate most (1024 for SDXL, 512 for SD1.5, whatever your model's native size is) and keep min/max as a tight band you genuinely use.
• context_min / opt / max - how many text-embedding chunks to support. 1 covers a normal prompt; leave it alone until you know why you'd raise it.
• num_video_frames - for SVD and SVD-XT, where it multiplies the batch dimension. Only touch this for video models; the default 14 is right for a standard SVD clip.

Like the static node, there are no outputs - the engine file is the result, and you'll see build progress in the console. First build on a fresh checkpoint is the slow one: 3–10 minutes for image models, up to 10–25 for SVD, and SVD-XT can take close to an hour. Subsequent builds ride the timing cache and go much faster.

Install and gotchas

Installation is the pack standard: ComfyUI Manager (search "TensorRT Node for ComfyUI"), or

cd ComfyUI/custom_nodes
git clone https://github.com/comfyanonymous/ComfyUI_TensorRT
cd ComfyUI_TensorRT
pip install -r requirements.txt

That requirements.txt pulls tensorrt>=10.0.1 and onnx, and the whole thing assumes an RTX card - the README's very first requirement. A few things to brace for: engines don't support LoRAs or ControlNets yet (bake LoRAs into a checkpoint first if you need them); your engine is tied to your GPU and TensorRT version, so it won't survive a machine swap; and if you generate outside the min–max range you'll get an error, not a graceful fallback. Build wide enough for how you actually work, and this is the node you stop thinking about - the loader just picks it up, and the speed boost is yours.