Export to ONNX

This is the first node of the acceleration chain, and it's the one that makes everything else possible. It takes the PyTorch model you just loaded and writes a dynamic-shape ONNX graph into ComfyUI/models/depthanything/, then hands you a ready-to-use model handle so you can keep building the graph without refreshing anything.

Fair warning on expectations: ONNX Runtime gets you about 1.4× over PyTorch. If that's the whole prize, and you're doing one image at a time, you might reasonably skip this whole branch. If you want the 2–2.7×, you're exporting anyway, because TensorRT engines are built from the explicit ONNX graph - this is a required step on that road, not an optional one.

How the export works

It re-uses the already-loaded PyTorch model rather than re-reading your checkpoint, which is why it's dramatically cheaper to export right after loading than to run the exporter cold. The graph is traced at opset 17 with the batch, height, and width axes left dynamic, so the resulting file accepts any 14-multiple resolution within reason - one export covers your whole workflow. The encoder and family come from the input model, so the file lands under an honest name:

da2_vitl_fp16_dynamic.onnx     # Depth Anything V2 Large, FP16
dad_vits_fp16_dynamic.onnx     # Distill-Any-Depth Small

That naming is deliberate: a DAD and a DA2 checkpoint that both happen to be vitl will never collide or masquerade as one another in the dropdown. If onnxslim is installed, the graph gets simplified on the way out (a log line tells you either way).

Inputs

• model - the DEPTHACCEL_MODEL handle. Required; there's no "just export a checkpoint" mode.
• precision - fp16 (default) or fp32. This sets the dtype of the graph, which later decides the dtype of your engine. FP32 is the safe one if you're exporting for someone else or for a card where half precision has been misbehaving.
• device - cuda or cpu. Export on GPU when you can; CPU tracing is slower.
• Trace height / Trace width - and here's the thing a lot of people misunderstand: these are trace size only. Inference stays dynamic at any resolution. They exist so the tracer knows what shapes to walk through, and smaller values export faster (560×784 by default).

The output is a single onnx_model handle - DEPTHACCEL_ONNX_MODEL. It goes into Estimate Depth (ONNX) for the quick path, Fuse ONNX Attention if you want ORT's fused attention, or Build TensorRT Engine for the fast path.

Two dependencies, two different jobs

This is the confusion worth clearing up before you hit it. Exporting needs the onnx package (and onnxslim if you want the simplification). Returning the handle needs onnxruntime-gpu, because the node loads the file it just wrote to confirm it's usable:

python -m pip install onnx onnxslim

If you don't have ONNX Runtime installed, the export still happens and the file still lands on disk - you just get a RuntimeError telling you exactly that, plus the fix. Which is a decent failure mode: you've still got the artifact, and the message names the missing package instead of dying silently.

It's a terminal node, on purpose

is_output_node=True means this node executes as a queue endpoint even when nothing is wired to its output. That's a feature: build [Load PyTorch] → [Export to ONNX], hit queue, and you've cached the ONNX file for future sessions. Next time you can skip straight to Load Depth Model (ONNX) and never touch the PyTorch loader again. The files live in the same model folder as your checkpoints, so they're immediately visible in that loader's dropdown.

Gotchas

Keep the explicit graph. Don't export and immediately fuse if you're heading for TensorRT - the fused graph uses ORT-specific com.microsoft operators that the TensorRT parser can't read, and the engine builder will tell you so. Export, build the engine from that, and fuse separately if you want a fast ONNX handle.

Re-export after changing the checkpoint or encoder. Naming follows the source model, so switching from Large to Base produces a second file rather than silently overwriting - good - but your graph will happily keep pointing at the old one until you change the dropdown.

Disk. Large is 335M parameters, so its graphs run to hundreds of megabytes. Cheap, but they accumulate: one file per family/encoder/precision combination, plus _fused variants and .trt engines later.