Load Depth Model (ONNX)

Exporting is a one-time cost, and this is the node that makes it feel like one. Once da2_vitl_fp16_dynamic_fused.onnx is sitting in ComfyUI/models/depthanything/, this node loads it directly with ONNX Runtime and you never touch the PyTorch side of the pack again until you want a different checkpoint.

Why you'd reach for it

Two reasons, and they're different moods. The boring one: session reuse. Your graph no longer has to load a checkpoint and re-export before it can estimate depth, which shortens startup and makes the whole back half of the pipeline portable across restarts. The interesting one: it's the escape hatch when the PyTorch path refuses your resolution. The PyTorch estimator enforces a ~2.6MP budget in FP32 and ~4.7MP in FP16; an FP16 ONNX graph covers anything up to the advertised 2016×2016 profile, and ONNX Runtime will happily run it on CPU too if your GPU is busy holding a video model.

How it works

It opens an ONNX Runtime session with graph_optimization_level = ORT_ENABLE_ALL, asking for CUDAExecutionProvider with CPU as the fallback. On CUDA it doesn't just hand ORT a NumPy array - the estimator binds the PyTorch CUDA buffer by raw pointer on the same stream, so there's no CPU staging in the hot path. That's part of where the 1.4× comes from, and it's also the origin of this pack's most Windows-flavored gotcha: the module deliberately imports torch before ONNX Runtime, so torch gets to preload its own CUDA and cuDNN libraries first and ORT doesn't fight them.

The loader is picky about the graph contract, which is worth knowing before you point it at a random .onnx file from the internet. It requires exactly one input and one output, a 4D input with 3 channels, a 3D output, matching float32/float16 dtypes on both ends, and genuinely dynamic batch/height/width axes. It also reads the depthaccel.* metadata the exporter wrote - architecture, patch size, precision, encoder - and cross-checks it against the graph. Load an ONNX depth model exported by some other tool and it may well be rejected with a specific complaint rather than failing at inference time. That's the design.

Inputs and output

• model - dropdown over the .onnx files in ComfyUI/models/depthanything/. Both explicit (..._dynamic.onnx) and fused (..._fused.onnx) graphs show up, and when a fused file exists the node defaults to it.
• device - cuda or cpu, defaulting to cuda. CPU is slow, but it's a real fallback rather than a theoretical one, and it's a cheap way to test whether an odd output is a GPU issue.

The output is onnx_model, a DEPTHACCEL_ONNX_MODEL handle that feeds Estimate Depth (ONNX) - or nothing else. It won't go into the PyTorch estimator or the TensorRT one; those take their own handle types, and ComfyUI will simply refuse the wire.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/PineCookie/ComfyUI-DepthAnythingAccel
cd ComfyUI-DepthAnythingAccel
python -m pip install safetensors huggingface-hub onnxruntime-gpu

In Manager, search DepthAnythingAccel. onnxruntime-gpu is the load-bearing one here, and it's the classic dependency-hell candidate in a shared ComfyUI venv - it wants a CUDA runtime version, and you're installing it next to a torch that brought its own. This pack keeps its requirements loose on purpose to avoid making that worse, but if ORT can't see CUDA you'll get an error listing the providers it does have, which is the fastest way to diagnose it. onnx itself is only needed for exporting and fusing, not for loading.

Troubleshooting

"CUDAExecutionProvider is unavailable" - you installed plain onnxruntime instead of onnxruntime-gpu, or the GPU build doesn't match your CUDA runtime. The error prints the available providers; if CPU is the only one, that's your answer.

Empty dropdown - the node only lists .onnx files. If you never exported one, or you put the file somewhere other than ComfyUI/models/depthanything/, there's nothing to pick. Refresh the node list after adding files.

It loaded, but the depth map looks different from the PyTorch one - it shouldn't, and both backends are checked against FP32 at correlation ≈ 1.0. A visible difference means you're comparing two different checkpoints, most likely Large fused versus Small explicit, because the dropdown's default pick changed when you fused.