Processing time over 30s for a single image

[aryajadu]

I am running sharp on a google cloud vm instance with these specs:

a2-highgpu-1g (12 vCPUs, 85 GB Memory)
1 x NVIDIA A100 40GB

Here is the log from a single image processing. The time it takes is about 30s give or take consistently time after time. I am wondering what could be the reason?

(sharp) am@instance-20251217-221536:~/ml-sharp$ sharp predict -i ./images -o ./gaussians -c sharp_2572gikvuh.pt
2026-01-20 15:11:44,375 | INFO | Processing 1 valid image files.
2026-01-20 15:11:44,392 | INFO | Using device cuda
2026-01-20 15:11:44,392 | INFO | Loading checkpoint from sharp_2572gikvuh.pt
2026-01-20 15:11:45,789 | INFO | Using preset ViT dinov2l16_384.
2026-01-20 15:11:49,860 | INFO | Using preset ViT dinov2l16_384.
2026-01-20 15:11:55,614 | INFO | Processing images/IMG_9617.HEIC
2026-01-20 15:11:56,154 | INFO | Running preprocessing.
2026-01-20 15:11:56,278 | INFO | Running inference.
2026-01-20 15:11:57,718 | INFO | Running postprocessing.
2026-01-20 15:12:02,795 | INFO | Saving 3DGS to gaussians

[aryajadu]

Thanks @hafeezhmha applying this patch and it reduced the processing time by a few seconds but still looking at ~25s processing time for a single image

[hafeezhmha]

@aryajadu Thanks for testing.
Yeah, the 25s you're seeing matches what I observed as well. The Ply saving optimization helps, but the main bottleneck is still the ViT model initialization which loads twice during startup, that would need a bigger architectural change. If you're processing multiple images in batch, the initialization cost gets amortized so the per image time should be better.But for single image processing, that 6s init is hard to avoid without refactoring how the models are loaded.

The architecture uses two separate encoder instances (patch_encoder and image_encoder) with separate state dict namespaces, which seems to be an intentional design from the original paper. However both default to the same dinov2l16_384 preset and load identical weights, which doubles the init time and memory . I was thinking if weight sharing would require either architectural changes or checkpoint conversion since the state dict has separate keys for each encoder. Probably needs input from the original authors on whether that's feasible.

[aryajadu]

monodepth_encoder.py

Very good point here is my simple fix for the double loading of ViT issue. this fix brings down the processing from 25s to 19s exactly that 6s you mentioned.

[kroaton]

I tried your fix, but depth looks broken due to the fact that the weights are slightly different.
Compare to a few images before/after your fix and you will see the issue.

[aryajadu]

I see it is probably come from the fact that in the initial design image_encoder was created by passing intermediate_features_ids=None which is different from patch_encoder that was created using intermediate_features_ids=patch_encoder_block_ids

[hafeezhmha]

I tried your fix, but depth looks broken due to the fact that the weights are slightly different. Compare to a few images before/after your fix and you will see the issue.

Yeah thats why i did not implement it. The weights, although, similar, are different.

[aryajadu]

So we are back to on average 25s on such a powerful sever:

a2-highgpu-1g (12 vCPUs, 85 GB Memory)
1 x NVIDIA A100 40GB